8.3 KiB

Raw Blame History

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:

decision-needed findings (unchecked): - [ ] [Review][Decision] <Title> — <Detail>
patch findings (unchecked): - [ ] [Review][Patch] <Title> [<file>:<line>]
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. decision-needed,
patch, defer, 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?

Apply every patch — fix all of them now, no per-finding confirmation. Defer and decision-needed items are not touched.

Leave as action items — they are already in the story file

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?

Apply every patch — fix all of them now, no per-finding confirmation. Defer and decision-needed items are not touched.

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:
Patches handled:
Deferred:
Dismissed:

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:

Load the FULL {sprint_status} file.
Find the development_status entry matching {story_key}.
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.
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: Dismissed:

7. Next steps

Present the user with follow-up options:

What would you like to do next?

Start the next story — run dev-story to pick up the next ready-for-dev story

Re-run code review — address findings and review again

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.

8.3 KiB Raw Blame History