Feature walkthrough

A walkthrough answers one question: "if I follow one run of this feature (a request, a command, a job), what runs, in which order, and why?" It is not a spec summary and not a PR description. It follows the code.

1. Fix the target

Collect these before you delegate. They go into the brief.

• Commit: the exact hash under review. The writer reads files at that commit, so every citation stays valid.
• Diff range: the commits of the feature only. If the branch contains a merge of other work, name the merge commit and exclude it, or the tour drifts into unrelated code.
• Spec and decisions: docs/<slug>-spec.md and the ADRs the feature added. If the spec has a "Domain language" section (domain-language), the walkthrough uses only those terms.
• Reader and language: the user's language, or the document language for a pull request (simplified-technical-language).

2. Write it, or delegate it

The writing reads many files. When the environment has subagents, brief one read-only subagent with the template below, so the main context stays small. Name the convention skills in the brief. A subagent does not load them by itself, and without plain-visual-docs the walkthrough comes back without diagrams. Without subagents, follow the same brief yourself.