--- deferred_work_file: '{implementation_artifacts}/deferred-work.md' --- # Step 4: Present and Act ## RULES - YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}` - When `{spec_file}` is set, always write findings to the story file before offering action choices. - `decision-needed` findings must be resolved before handling `patch` findings. ## AUTOMATION MODE If `{auto_mode}`, run this step with these substitutions (see `../automation-mode.md`): - Sections 1, 2, 3, and 6 run as written (no waiting after section 3). - Section 4: no `decision-needed` findings should remain (step-03's automation rule reclassified them). If any do, treat each as `defer` with reason "auto-mode: needs human decision" and record an escalation. - Section 5: do not present the menu — **Apply every patch**, then check off the patch items in the story file. - Section 7: skip entirely. - After section 6, write `$BMAD_AUTO_RUN_DIR/tasks/$BMAD_AUTO_TASK_ID/result.json` per the schema in `../automation-mode.md` (`clean` is true only when `{new_status}` = `done` was set on disk), state the outcome in one line, and end your turn. ## INSTRUCTIONS ### 1. Clean review shortcut If no **actionable** findings remain after triage — no `decision-needed`, `patch`, or `defer` findings (every finding was dismissed, or none were raised): state that and proceed to section 6 (Sprint Status Update). Set-aside dismissed findings do not count as "remaining". **If `{auto_mode}`:** when any findings were dismissed, do NOT skip straight to section 6 — first perform section 2's Review Ledger append (the `#### Review Ledger ({date})` subsection) so the next cycle's reviewers do not re-litigate them, then proceed to section 6. ### 2. Write findings to the story file If `{spec_file}` exists and contains a Tasks/Subtasks section, append a `### Review Findings` subsection. Write all findings in this order: 1. **`decision-needed`** findings (unchecked): `- [ ] [Review][Decision] — <Detail>` 2. **`patch`** findings (unchecked): `- [ ] [Review][Patch] <Title> [<file>:<line>]` 3. **`defer`** findings (checked off, marked deferred): `- [x] [Review][Defer] <Title> [<file>:<line>] — deferred, pre-existing` Also append each `defer` finding to `{deferred_work_file}` under a heading `## Deferred from: code review ({date})`. If `{spec_file}` is set, include its basename in the heading (e.g., `code review of story-3.3 (2026-03-18)`). One bullet per finding with description. **If `{auto_mode}`:** instead of the heading-based append above, append each `defer` finding to `{deferred_work_file}` as a `DW-<seq>` entry following the format and dedupe rule in `../deferred-work-format.md` (this skill's own copy). Use `origin: code review of <spec basename>, {date}`, and set the entry's `severity:` from the finding's own severity. Then append a `#### Review Ledger ({date})` subsection to `{spec_file}` recording every triaged finding on one line each — `<verdict>: <title> [<location>] — <one-line reason>` — including the dismissed ones set aside in step-03. The ledger is append-only across review cycles; it is what stops the next cycle's fresh reviewers from re-litigating findings that were already adjudicated. ### 3. Present summary Announce what was written: > **Code review complete.** <D> `decision-needed`, <P> `patch`, <W> `defer`, <R> dismissed as noise. If `{spec_file}` is set, add: `Findings written to the review findings section in {spec_file}.` Otherwise add: `Findings are listed above. No story file was provided, so nothing was persisted.` ### 4. Resolve decision-needed findings If `decision_needed` findings exist, present each one with its detail and the options available. The user must decide — the correct fix is ambiguous without their input. Walk through each finding (or batch related ones) and get the user's call. Once resolved, each becomes a `patch`, `defer`, or is dismissed. If the user chooses to defer, ask: Quick one-line reason for deferring this item? (helps future reviews): — then append that reason to both the story file bullet and the `{deferred_work_file}` entry. **HALT** — I am waiting for your numbered choice. Reply with only the number. Do not proceed until you select an option. ### 5. Handle `patch` findings If `patch` findings exist (including any resolved from step 4), HALT. Ask the user: If `{spec_file}` is set, present all three options: > **How would you like to handle the `<P>` `patch` findings?** > 1. **Apply every patch** — fix all of them now, no per-finding confirmation. Defer and decision-needed items are not touched. > 2. **Leave as action items** — they are already in the story file > 3. **Walk through each patch** — show details for each before deciding If `{spec_file}` is **not** set, present only options 1 and 2 (omit "Leave as action items" — findings were not written to a file): > **How would you like to handle the `<P>` `patch` findings?** > 1. **Apply every patch** — fix all of them now, no per-finding confirmation. Defer and decision-needed items are not touched. > 2. **Walk through each patch** — show details for each before deciding **HALT** — I am waiting for your numbered choice. Reply with only the number. Do not proceed until you select an option. - **Apply every patch**: Apply every patch finding without per-finding confirmation. Do not modify defer or decision-needed items. After all patches are applied, present a summary of changes made. If `{spec_file}` is set, check off the patch items in the story file (leave defer items as-is). - **Leave as action items** (only when `{spec_file}` is set): Done — findings are already written to the story. - **Walk through each patch**: Present each finding with full detail, diff context, and suggested fix. After walkthrough, re-offer the applicable options above. **HALT** — I am waiting for your numbered choice. Do not proceed until you select an option. **✅ Code review actions complete** - Decision-needed resolved: <D> - Patches handled: <P> - Deferred: <W> - Dismissed: <R> ### 6. Update story status and sync sprint tracking Skip this section if `{spec_file}` is not set. #### Determine new status based on review outcome - If all `decision-needed` and `patch` findings were resolved (fixed or dismissed) AND no unresolved HIGH/MEDIUM issues remain: set `{new_status}` = `done`. Update the spec's YAML frontmatter `status:` field to `done`. - If `patch` findings were left as action items, or unresolved issues remain: set `{new_status}` = `in-progress`. Update the spec's YAML frontmatter `status:` field to `in-progress`. Save the story file. #### Sync sprint-status.yaml If `{story_key}` is not set, skip this subsection and note that sprint status was not synced because no story key was available. If `{sprint_status}` file exists: 1. Load the FULL `{sprint_status}` file. 2. Find the `development_status` entry matching `{story_key}`. 3. If found: update `development_status[{story_key}]` to `{new_status}`. Update `last_updated` to current date. Save the file, preserving ALL comments and structure including STATUS DEFINITIONS. 4. If `{story_key}` not found in sprint status: warn the user that the story file was updated but sprint-status sync failed. If `{sprint_status}` file does not exist, note that story status was updated in the story file only. #### Completion summary > **Review Complete!** > > **Story Status:** `{new_status}` > **Issues Fixed:** <fixed_count> > **Action Items Created:** <action_count> > **Deferred:** <W> > **Dismissed:** <R> ### 7. Next steps Present the user with follow-up options: > **What would you like to do next?** > 1. **Start the next story** — run `dev-story` to pick up the next `ready-for-dev` story > 2. **Re-run code review** — address findings and review again > 3. **Done** — end the workflow **HALT** — I am waiting for your choice. Do not proceed until the user selects an option. ## On Complete **If `{auto_mode}`:** skip this section entirely — result.json (written after section 6) is the LAST action of the run (see `../automation-mode.md`); the orchestrator owns commit and everything after it. Run: `python3 {project-root}/_bmad/scripts/resolve_customization.py --skill {skill-root} --key workflow.on_complete` If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.