2.1 KiB

Raw Blame History

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 to determine what changed.

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:

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.
Lead with the entry point — the place a reviewer should look first to understand the design intent.
End with peripherals — tests, config, types, and other supporting changes come last.
Every code reference uses path:line format so editors auto-link them.
Each stop gets one line of framing — what this code does in the context of the change and why. No paragraphs.

Format:

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

Change {spec_file} status to done in the frontmatter.
If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
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} contains a Review Trail with clickable path:line stops for navigating the change. Offer to push and/or create a pull request.

Workflow complete.

2.1 KiB Raw Blame History