Step 2: Walkthrough

Display: Orientation → [Walkthrough] → Detail Pass → Testing

Follow Global Step Rules in SKILL.md

Organize by concern, not by file. A concern is a cohesive design intent — e.g., "input validation," "state management," "API contract." One file may appear under multiple concerns; one concern may span multiple files.
The walkthrough activates design judgment, not correctness checking. Frame each concern as "here's what this change does and why" — the human evaluates whether it's the right approach for the system.

BUILD THE WALKTHROUGH

Identify Concerns

With Suggested Review Order (full-trail mode — the normal path, including when step-01 generated a trail):

Read the Suggested Review Order stops from the spec (or from conversation context if generated by step-01 fallback).
Resolve each stop to a file in the current repo. Output in path:line format per the standing rule.
Read the diff to understand what each stop actually does.
Group stops by concern. Stops that share a design intent belong together even if they're in different files. A stop may appear under multiple concerns if it serves multiple purposes.

Without Suggested Review Order (fallback when trail generation failed, e.g., git unavailable):

Get the diff against the appropriate baseline (same rules as step 1).
Identify concerns by reading the diff for cohesive design intents:
- Functional groupings — what user-facing behavior does each cluster of changes support?
- Architectural layers — does the change cross boundaries (API → service → data)?
- Design decisions — where did the author choose between alternatives?
For each concern, identify the key code locations as path:line stops.

Order for Comprehension

Sequence concerns top-down: start with the highest-level intent (the "what and why"), then drill into supporting implementation. Within each concern, order stops so each one builds on the previous. The reader should never encounter a reference to something they haven't seen yet.

If the change has a natural entry point (e.g., a new public API, a config change, a UI entry point), lead with it.

Write Each Concern

For each concern, produce:

Heading — a short phrase naming the design intent (not a file name, not a module name).
Why — 1–2 sentences: what problem this concern addresses, why this approach was chosen over alternatives. If the spec documents rejected alternatives, reference them here.
Stops — each stop on its own line: path:line followed by a brief phrase (not a sentence) describing what this location does for the concern. Keep framing under 15 words per stop.

Target 2–5 concerns for a typical change. A single-concern change is fine — don't invent groupings. A change with more than 7 concerns is a signal the scope may be too large, but present it anyway.

PRESENT

Output the full walkthrough as a single message with this structure:

Orientation → [Walkthrough] → Detail Pass → Testing

Then each concern group using this format:

### {Concern Heading}

{Why — 1–2 sentences}

- `path:line` — {brief framing}
- `path:line` — {brief framing}
- ...

End the message with:

---

Take your time — click through the stops, read the diff, trace the logic. While you are reviewing, you can:
- "run advanced elicitation on the error handling"
- "party mode on whether this schema migration is safe"
- or just ask anything

When you're ready, say **next** and I'll surface the highest-risk spots.

EARLY EXIT

If at any point the human signals they want to make a decision about this {change_type} (e.g., "let's ship it", "this needs a rethink", "I'm done reviewing", or anything suggesting they're ready to decide), confirm their intent:

If they want to approve and ship → read fully and follow ./step-05-wrapup.md
If they want to reject and rework → read fully and follow ./step-05-wrapup.md
If you misread them → acknowledge and continue the current step.

Default: read fully and follow ./step-03-detail-pass.md

4.1 KiB Raw Blame History Unescape Escape