assist-review

name	assist-review
description	Reviewing someone else's PR for handoff/sign-off. Isolates structural changes from trivial edits, flags HLD/LLD drift and guardrail violations, points the reviewer at what to scrutinize. Use when prepping to review another engineer's work — NOT for first-pass self-review (use review / quick-review).

Draft Assist Review: Human-in-the-Loop Gateway

Help human reviewers effectively review an executed track without shifting the entire cognitive burden onto them.

Red Flags - STOP if you're:

• Conducting standard unit tests; use /draft:review for that.
• Fixing code rather than explaining logic and risk profiles to the human.
• Reviewing output without first summarizing the source spec.md intent.

---

Workflow Constraints

1. Context Extraction:

   • Load the track's spec.md and plan.md.
   • Load the track's hld.md and lld.md if present — extract Key Design Decisions, Alternatives Considered, and (LLD) class invariants and error policies.
   • Re-summarize the Intent of what this track was supposed to achieve in exactly two sentences.

2. Blast Radius Isolation:

   • Scan the git diff generated by the target track.
   • Separate trivial edits (naming, routing adjustments, formatting) from Structural Edits (schema updates, concurrency alterations, middleware auth changes, API surface changes).
   • Present structural edits first — these are where review time should be spent.

3. Generate the Human Helper Guide:

   • Instead of a traditional bug hunt, generate an executive summary containing a Risk Assessment.
   • For each structural edit, cite the originating decision: "I chose [Pattern] for [File/Function] because hld.md §Key Design Decisions / Alternatives Considered selected it over [rejected alternative]. You should specifically scrutinize lines X–Y because they touch [global state / auth boundary / shared schema]." Fall back to architecture.md only when no HLD exists.
   • Highlight any code that violates an LLD §Classes and Interfaces invariant (thread safety, idempotency, ordering) or contradicts an HLD §Checklist claim (e.g., "code introduces a new shared mutex but HLD declared single-writer").
   • Highlight any code that touches shared state, auth boundaries, data persistence, or concurrency.

4. Knowledge Base Verification:

   • Verify if any pattern implemented violates the draft/guardrails.md learned anti-patterns.
   • Verify the diff is consistent with hld.md/lld.md commitments. If the diff makes structural changes not reflected in HLD §Detailed Design or LLD §Classes/Interfaces: flag for the reviewer that HLD/LLD must be amended (/draft:change) before merge.
   • If so, specifically direct the human reviewer to veto the change unless an ADR is created via /draft:adr.

5. Output Format:

   • Track Intent (2 sentences)
   • HLD/LLD Decision Trace (per structural edit: which §Key Design Decision or §Alternatives Considered row drove this code; or "no HLD justification — reviewer must request one")
   • Structural Edits (table: file, change type, risk level, review guidance)
   • Trivial Edits (collapsed list — skim only)
   • HLD/LLD Drift (diff makes claims that HLD/LLD does not document — recommend /draft:change)
   • Guardrail Violations (if any — with ADR recommendation)
   • Suggested Review Order (which files to review first, based on blast radius)

---