fa7e166f3e
- Add reminders page with navigation support - Upgrade BMad builder module to skills-based architecture - Refactor MCP server: extract tools and auth into separate modules - Add connections cache, custom AI provider support - Update prisma schema and generated client - Various UI/UX improvements and i18n updates - Add service worker for PWA support Made-with: Cursor
130 lines
6.2 KiB
Markdown
130 lines
6.2 KiB
Markdown
---
|
|
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.
|
|
|
|
## INSTRUCTIONS
|
|
|
|
### 1. Clean review shortcut
|
|
|
|
If zero findings remain after triage (all dismissed or none raised): state that and proceed to section 6 (Sprint Status Update).
|
|
|
|
### 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] <Title> — <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.
|
|
|
|
### 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 (or "0" for batch). 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 (if >3 `patch` findings exist, also show option 0):
|
|
|
|
> **How would you like to handle the <Z> `patch` findings?**
|
|
> 0. **Batch-apply all** — automatically fix every non-controversial patch (recommended when there are many)
|
|
> 1. **Fix them automatically** — I will apply fixes now
|
|
> 2. **Leave as action items** — they are already in the story file
|
|
> 3. **Walk through each** — let me show details before deciding
|
|
|
|
If `{spec_file}` is **not** set, present only options 1 and 3 (omit option 2 — findings were not written to a file). If >3 `patch` findings exist, also show option 0:
|
|
|
|
> **How would you like to handle the <Z> `patch` findings?**
|
|
> 0. **Batch-apply all** — automatically fix every non-controversial patch (recommended when there are many)
|
|
> 1. **Fix them automatically** — I will apply fixes now
|
|
> 2. **Walk through each** — let me show details before deciding
|
|
|
|
**HALT** — I am waiting for your numbered choice. Reply with only the number (or "0" for batch). Do not proceed until you select an option.
|
|
|
|
- **Option 0** (only when >3 findings): Apply all non-controversial patches without per-finding confirmation. Skip any finding that requires judgment. Present a summary of changes made and any skipped findings.
|
|
- **Option 1**: Apply each fix. After all patches are applied, present a summary of changes made. If `{spec_file}` is set, check off the items in the story file.
|
|
- **Option 2** (only when `{spec_file}` is set): Done — findings are already written to the story.
|
|
- **Walk through each**: 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. Reply with only the number (or "0" for batch). 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 story file Status section to `done`.
|
|
- If `patch` findings were left as action items, or unresolved issues remain: set `{new_status}` = `in-progress`. Update the story file Status section 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.
|