---
---

# Step 5: Present

## RULES

- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
- NEVER auto-push.

## INSTRUCTIONS

### Generate Review Trail

Before committing, append a `## Review Trail` section to `{spec_file}` **after the last existing section**. This is a post-implementation artifact — do not modify the Code Map.

Read `{baseline_commit}` from `{spec_file}` frontmatter. Construct the diff of all changes since `{baseline_commit}`. If `{baseline_commit}` is missing or `NO_VCS`, use best-effort analysis of the working tree.

Build the trail as an ordered sequence of **stops** — clickable `path:line` references with brief framing — optimized for a human reviewer reading top-down to understand the change:

1. **Order by concern, not by file.** Group stops by the conceptual concern they address (e.g., "validation logic", "schema change", "UI binding"). A single file may appear under multiple concerns.
2. **Lead with the entry point** — the single highest-leverage file:line a reviewer should look at first to grasp the design intent.
3. **Inside each concern**, order stops from most important / architecturally interesting to supporting. Lightly bias toward higher-risk or boundary-crossing stops.
4. **End with peripherals** — tests, config, types, and other supporting changes come last.
5. **Every code reference uses `path:line` format** so editors auto-link them.
6. **Each stop gets one ultra-concise line of framing** (≤15 words) — why this approach was chosen here and what it achieves in the context of the change. No paragraphs.

Format:

```markdown
## Review Trail

### {Concern Name}
- `path/to/file.ts:42` — {one-line framing}
- `path/to/other.ts:17` — {one-line framing}

### {Next Concern}
- `path/to/file.ts:88` — {one-line framing}
```

### Commit and Present

1. Change `{spec_file}` status to `done` in the frontmatter.
2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
3. Display summary of your work to the user, including the commit hash if one was created. Advise on how to review the changes — mention that `{spec_file}` now contains a Review Trail with clickable `path:line` stops sequenced by concern for easy top-down navigation. Offer to push and/or create a pull request.

Workflow complete.