Reviewee Judgment

Purpose and Value

Treat review findings as evidence about an artifact, not as work orders. A finding can expose a real problem while proposing the wrong fix, the wrong owner, or a response whose cost exceeds its value.

This skill prevents automatic finding-closure and automatic rejection from replacing product judgment. It preserves the requested outcome while favoring durable quality: maintainability for code, execution precision for prompts, and decision integrity for specifications. It also makes structural debt, verification limits, and user-owned tradeoffs visible before implementation begins.

Consider no change, removal or narrowing, and reuse before a mechanism-preserving or additive repair. Unnecessary repairs create their own contracts, tests, and maintenance burden. Prior phase passage does not exempt a mechanism from this judgment.

Use this process before planning or performing changes derived from received review results. Success is an evidence-backed response to the underlying problems, not a larger change set or a higher count of closed findings.

Its input is a completed set of review results. Producing review findings remains outside this skill's scope.

The flow is: establish the outcome boundary, separate each problem from its proposed fix, group findings by underlying problem, locate the responsible cause, compare eligible responses in order, then recommend or execute within the granted authority.

Artifact Context

Read the current artifact, received findings, user-required outcome, explicit constraints, exclusions, and actual consumer contracts. Mark material claims as observed, inferred, or unknown. Treat upstream implementation choices as revisable within that outcome boundary; a generated document or test is not evidence that the user needs its mechanism.

Load the reference that matches each reviewed artifact:

• Code, configuration, schema, or migration: references/code.md
• Prompt, agent instruction, or skill content: references/prompt.md
• Requirement, ADR, design document, plan, or other decision-carrying specification: references/spec.md

For mixed findings, load every matching reference and apply this core process once across the shared problem set.

Core Distinctions

Problem and Proposed Fix

Extract the reported behavior, its evidence, and its consequence independently from the reviewer's proposed change. Evaluate the proposal only after the problem is confirmed and owned.

Same Problem and Similar Surface

Group findings when they arise from the same responsibility, contract, decision, state transition, or causal rule. Similar wording, syntax, file shape, or patch mechanics alone does not establish the same problem.

Inspect other instances only when they affect the current correction within the agreed scope. On a rerun, retain resolved findings and examine only the correction and inconsistencies it directly introduced.

Local Defect and Structural Defect

A local defect is fully owned by one otherwise sound unit and can be corrected without retaining the same causal failure elsewhere.

A structural defect is owned by a misplaced responsibility, contradictory contract, duplicated decision, or unnecessary mechanism. Repeated local edits do not resolve that owner.

Decision Order

Evaluate candidates through these gates in order. A later gate cannot compensate for a failure at an earlier gate.

1. Outcome boundary: Preserve user-required outcomes, explicit constraints, exclusions, and actual consumer obligations. Reconsider upstream technical means even when previously passed. Escalate a requirement change only when evidence shows the current conditions cannot deliver the required outcome; optional capabilities remain unadopted.
2. Finding validity: Confirm the reported behavior and its material effect on the requested outcome or the matching reference's Quality Objective. When the material effect is a lifecycle cost, record its evidenced frequency or magnitude for gate 7 to compare against response cost. Base validity on that evidence, and record the reviewer's priority and proposed fix separately as context.
3. Cause and ownership: Identify the underlying problem and the artifact or responsibility that owns it.
4. Subtraction first: If no required defect or worthwhile in-scope improvement remains, decline. Otherwise test removal or narrowing, then reuse, before a retaining or additive repair. Identify a response that resolves the cause within the outcome boundary, then evaluate it through gates 5–8. Expand alternatives only when those checks make another candidate decision-relevant.
5. Durable quality: Apply the matching reference's Quality Objective and Candidate Comparison. Prefer the candidate that improves the artifact's long-term quality without adding unnecessary concepts or parallel sources of truth.
6. Verification safety: Determine whether the change and its affected boundaries can be proved safe with available evidence.
7. Lifecycle value: Evidence makes an option evaluable, not mandatory. Compare the supported effect from gate 2 with implementation, verification, migration, maintenance, review, execution, and retained-debt cost. A required outcome defect needs a sufficient response, including removal when it resolves the defect. Decline discretionary work whose benefit does not justify that cost. A document discrepancy alone does not require preserving the documented mechanism.
8. Authority: Execute only authorized corrections within gate 1; report unavailable authority or access as the specific blocker.

Confirm that the response resolves the cause before cost ranks candidates. Stop when a sufficient response passes the remaining gates; a required defect still needs correction. Missing verification warrants the evidence needed for that correction, not a new improvement target.

Resolution Method

Follow steps 1–5 in order; perform step 6 only when execution is authorized. Complete each step before starting the next.

1. Normalize the Findings

Separate these elements before accepting any proposed fix, consolidating repeated evidence across findings:

• the supplied finding identifier, or the shortest source label needed for traceability;
• the reported problem;
• the supporting evidence and confidence;
• the observable or downstream effect;
• the proposed fix, if any;
• the governing outcome or contract it may affect.

2. Form Problem Groups

Group findings by shared cause or owner. Keep independent findings separate even when their suggested fixes look alike. Add unreported instances only when evidence shows the same underlying problem.

Preserve supplied finding identifiers within each group. For every source finding, record whether its reported problem is confirmed, unsupported, or unresolved. The group-level response resolves the shared problem without replacing these source assessments.

3. Classify the Owner

Classify each problem group by the responsibility that owns the cause. When evidence supports more than one layer, retain the causal chain and evaluate the highest owner whose correction can remove the downstream failures.

• New mechanism: the recently introduced mechanism creates its own inconsistency or duplicates an existing responsibility. Compare removing or simplifying it, redesigning it at the owner, and using the existing structure before considering patches inside it.
• Existing structure: the pre-existing responsibility, contract, or decision is the cause. Consider removal or narrowing when it preserves the user-required outcome, including when the user requested removing the feature. Inspect actual remaining consumers rather than assuming existence creates a preservation obligation.
• Local unit: one otherwise sound unit owns the entire problem. A local correction is eligible when no instance of the same causal failure remains.
• No confirmed defect: evidence does not establish an outcome-relevant problem. Decline the finding when the available evidence is sufficient, or request the material evidence needed to resolve it. End candidate comparison for this group because no confirmed cause is available to resolve.

This classification selects candidates; it does not predetermine the answer. Structural change must earn its place through durable quality and verification safety, just as a patch must account for the debt it retains.

4. Compare Complete Candidates

Use gate 4's order before selecting a response. For a repair that retains or adds a mechanism, state why no change, removal or narrowing, and existing behavior cannot deliver the required result. This is a selection condition, not a requirement to enumerate alternatives for every finding.

The resulting comparison must make clear:

• whether the reviewed change or mechanism is necessary at all;
• which cause it resolves;
• which concepts, responsibilities, or constraints it adds or removes;
• what same-problem instances remain;
• what evidence proves the changed boundary;
• what compatibility or migration work it requires;
• what debt and future change cost it retains.

Exclude speculative alternatives that do not map to evidence. The goal is a sufficient decision, not an architecture exercise.

5. Choose a Disposition

Assign one disposition to each problem group:

• apply: the problem or improvement is confirmed and the selected response passed all gates. A required correction is apply when a sufficient, safe response passes the gates; lifecycle cost ranks the eligible responses. A discretionary improvement is apply when the material effect established at gate 2 exceeds its total lifecycle cost. The Authority gate separately determines whether to recommend or execute it;
• decline: evidence establishes no material effect at gate 2, the finding is outside the outcome boundary or reverses an exclusion, or a discretionary improvement's total lifecycle cost equals or exceeds its material effect;
• evidence required: a material unknown could change finding validity, ownership, response selection, or verification. Pause changes for that problem group, continue independent groups, and report the exact evidence needed, its source when known, the decision it controls, and the condition for resuming;
• user decision required: evidence shows the required outcome cannot be achieved without changing a user requirement, explicit constraint, actual consumer obligation, or available authority. A technical reduction alone returns to the orchestrator for affected artifact updates, not renewed user approval. Optional expansion is declined.

Return evidence required and user decision required to the skill caller. The caller resolves them when it owns the required evidence or decision and otherwise routes them to the responsible authority.

An interim correction must also satisfy the agreed boundary. Report a required unresolved result and its evidence; optional structural improvements remain outside the correction.

6. Execute and Verify

When changes are authorized, implement the selected response at the responsible owner and verify the affected boundary described by the applicable reference. Re-evaluate the original problem groups after verification; completion requires their observable causes to be resolved or explicitly dispositioned.

Response Contract

Report decisions by underlying problem group rather than by comment count:

Problem:
Findings grouped:
  - <finding ID or source label>: confirmed | unsupported | unresolved
Evidence: observed | inferred | unknown
Cause and owner:
Reviewed change or mechanism necessity and decision-changing alternatives considered:
Recommendation and disposition:
Authority: recommend only | execute selected response
Why it wins in the decision order:
Retained debt or required proof:
Required evidence and resume condition, if any:
User decision, if any:

Keep the report proportional. Use the existing response to retain the disposition and reason; for a mechanism-preserving or additive repair, include the required result that subtraction cannot deliver. Keep the problem/fix separation, causal owner, and any user-owned tradeoff. No separate plan tool, file, or alternative inventory is required.

Completion Check

• Every accepted finding maps to a confirmed underlying problem and material effect.
• Every supplied finding identifier remains traceable to its source assessment and problem group.
• Required corrections were identified before lifecycle comparison, and lifecycle cost selected among their sufficient responses.
• Every discretionary apply names its material effect and why it exceeds the total lifecycle cost.
• Selected repairs explain why declining, removing or narrowing, and reusing are insufficient for the required result.
• Reviewer-proposed fixes were evaluated as candidates rather than inherited as requirements.
• Same-problem instances were grouped by cause, not by surface similarity.
• Candidate selection followed the fixed decision order without using cost to skip causal or quality analysis.
• Disposition and execution authority are explicit and separate.
• Patches state the debt they retain; structural changes state the proof and migration safety they require.
• Artifact-specific quality and verification criteria came from the matching reference.
• Evidence-required groups remain unchanged until their named resume condition is satisfied; independent groups may continue.
• Other unknowns and user-owned decisions are explicit.
• Completion is measured against outcomes and resolved causes, not the number of findings changed.