git:20260517.6abc798 to git:20260819.fda278e

---

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.

- 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)

---