Dx Review Triage

dx-review-triage

Turn a review report's findings into decisions — and, when you say so, into edits. dx-plan-review and dx-impl-review only analyze and report; this is the one place that acts on a finding, editing plan.md or the code it reviewed, one finding at a time, only on your confirmation. That split keeps both review gates pure: a reviewer that never fixes what it checks doesn't need to graduate into a tool-restricted agent.

Guard. Resolve <change-id> under context/changes/. reviews/ must contain plan-review.md or impl-review.md — if the directory is missing or empty, point at /dx-plan-review or /dx-impl-review instead. If the path is under context/archive/, refuse: archived work is done.

Load first

The review-report reference (invoke dx-references with review-report) — the finding-ID/Resolution schema, the resume rule, and the file conventions this skill reads and writes.

1 — Resolve which report

Each type has exactly one file — reviews/plan-review.md or reviews/impl-review.md — always the current review, since re-running dx-plan-review/dx-impl-review overwrites rather than dating a new file. A second argument names the type (plan or impl) directly. No argument: exactly one file present → use it; both present → ask which, since a plan-review and an impl-review can each carry open findings on the same change at once.

2 — Load what the fix touches

• plan-review → plan.md in full — this is what gets edited.
• impl-review → the same diff scope dx-impl-review used to review: git log/git diff for the commits that landed this change's phases, plus the specific files each pending finding names. Don't reload files findings you're skipping don't touch.

3 — Walk findings in order

Resume per the review-report reference: the first finding with Resolution: PENDING, document order. For each, show its title, location, detail, and suggested fix, then ask:

• Fix now — apply the suggested fix (or a variant you propose); show the before/after edit first, apply on confirmation.
• Fix differently — ask what they'd prefer instead, apply that.
• Skip — leave it for now, move on.
• Accept risk — leave it, record the one-line reason.
• Record as lesson — hand the finding's title and detail to /dx-lesson's entry shape and tell the user to confirm there. Never append to foundation/lessons.md yourself — that file has exactly one writer.

Immediately rewrite that finding's Resolution: line in place per the reference's rules. If an edit you already applied for an earlier finding also resolves a later one (one fix closing both a Plan-Drift and the Safety finding it caused, say), mark the later finding FIXED too, pointing at the same edit — don't manufacture a redundant second edit or commit just to keep one fix per finding.

4 — Commit code fixes, not plan fixes, never the report

• impl-review fixes touch shipped code — commit each applied fix on its own, same Conventional Commit shape dx-implement uses: fix(<change-id>): <finding title> (review).
• plan-review fixes touch plan.md only. dx-plan never commits the plan itself, so neither does this.
• Never commit the report file itself (plan-review.md/impl-review.md), in either case — it's working state like plan.md, not a deliverable; the user commits it on their own schedule.

On disagreement

If applying a fix would contradict something the plan or a standard states elsewhere, stop and say so — don't silently pick a side.

Done when

Every finding in the resolved report has a Resolution: other than PENDING — or you've stopped partway, which is fine, since re-running resumes from the next pending one. Print a one-line tally and stop, no auto-chain:

Triaged <report file>: <n> fixed, <n> skipped, <n> accepted, <n> dismissed
Next: /dx-plan-review <change-id>   or  /dx-implement <change-id>   (plan-review triaged)
  or: /dx-impl-review <change-id>   or  /dx-archive <change-id>     (impl-review triaged)