From e64cef80b6c60e267c252a4178ac34ec945de2e3 Mon Sep 17 00:00:00 2001 From: Nikolas Hor <116851567+nikolasdehor@users.noreply.github.com> Date: Thu, 12 Mar 2026 00:32:00 -0300 Subject: [PATCH 1/3] fix: add brainstorming reconciliation step to PRD polish workflow (#1914) When feeding brainstorming sessions into the PRD workflow, soft/qualitative ideas (tone, personality, interaction design, coaching philosophy) get silently dropped because they don't map cleanly to the PRD's structured template (FR/NFR format). The resulting PRD reads as complete, so the loss is invisible without manually diffing against the brainstorming output. Add a reconciliation check in step-11 (polish) that cross-references the brainstorming document against the finished PRD, flags ideas that didn't land anywhere, and lets the user decide which to incorporate. --- .../create-prd/steps-c/step-11-polish.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md b/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md index d6df4caea..709676509 100644 --- a/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md +++ b/src/bmm/workflows/2-plan-workflows/create-prd/steps-c/step-11-polish.md @@ -99,6 +99,22 @@ Review the entire document with PRD purpose principles in mind: - Are technical terms used appropriately? - Would stakeholders find this easy to understand? +### 2b. Brainstorming Reconciliation (if brainstorming input exists) + +**Check the PRD frontmatter `inputDocuments` for any brainstorming document** (e.g., `brainstorming-session*.md`, `brainstorming-report.md`). If a brainstorming document was used as input: + +1. **Load the brainstorming document** and extract all distinct ideas, themes, and recommendations +2. **Cross-reference against the PRD** — for each brainstorming idea, check if it landed in any PRD section (requirements, success criteria, user journeys, scope, etc.) +3. **Identify dropped ideas** — ideas from brainstorming that do not appear anywhere in the PRD. Pay special attention to: + - Tone, personality, and interaction design ideas (these are most commonly lost) + - Design philosophy and coaching approach ideas + - "What should this feel like" ideas (UX feel, not just UX function) + - Qualitative/soft ideas that don't map cleanly to functional requirements +4. **Present findings to user**: "These brainstorming ideas did not make it into the PRD: [list]. Should any be incorporated?" +5. **If user wants to incorporate dropped ideas**: Add them to the most appropriate PRD section (success criteria, non-functional requirements, or a new section if needed) + +**Why this matters**: Brainstorming documents are often long, and the PRD's structured template has an implicit bias toward concrete/structural ideas. Soft ideas (tone, philosophy, interaction feel) frequently get silently dropped because they don't map cleanly to FR/NFR format. + ### 3. Optimization Actions Make targeted improvements: @@ -193,6 +209,7 @@ When user selects 'C', replace the entire document content with the polished ver ✅ User's voice and intent preserved ✅ Document is more readable and professional ✅ A/P/C menu presented and handled correctly +✅ Brainstorming reconciliation completed (if brainstorming input exists) ✅ Polished document saved when C selected ## FAILURE MODES: From 9cd362d2d8629a412c354a2da0399e08e7273530 Mon Sep 17 00:00:00 2001 From: Nikolas Hor <116851567+nikolasdehor@users.noreply.github.com> Date: Thu, 12 Mar 2026 00:33:50 -0300 Subject: [PATCH 2/3] fix: remove mandatory minimum issue count from code review workflow (#1913) The code review workflow required finding 3-10 issues minimum per review and forced the agent to keep looking if fewer than 3 were found. This created an endless review cycle where every review manufactures issues even after previous fixes were applied, because the workflow cannot conclude with "no issues found." Replace the hard minimum with a zero-issue sanity check that allows clean reviews after a thorough re-examination, while preserving the adversarial review approach for genuine issues. --- .../4-implementation/code-review/workflow.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/src/bmm/workflows/4-implementation/code-review/workflow.md b/src/bmm/workflows/4-implementation/code-review/workflow.md index f4dd8188b..1abb4d174 100644 --- a/src/bmm/workflows/4-implementation/code-review/workflow.md +++ b/src/bmm/workflows/4-implementation/code-review/workflow.md @@ -13,7 +13,7 @@ description: 'Perform adversarial code review finding specific issues. Use when - Generate all documents in {document_output_language} - Your purpose: Validate story file claims against actual implementation - Challenge everything: Are tasks marked [x] actually done? Are ACs really implemented? -- Find 3-10 specific issues in every review minimum - no lazy "looks good" reviews - YOU are so much better than the dev agent that wrote this slop +- Be thorough and specific — find real issues, not manufactured ones. If the code is genuinely good after fixes, say so - Read EVERY file in the File List - verify implementation against story requirements - Tasks marked complete but not done = CRITICAL finding - Acceptance Criteria not implemented = HIGH severity finding @@ -136,17 +136,14 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve: 5. **Test Quality**: Are tests real assertions or placeholders? - - NOT LOOKING HARD ENOUGH - Find more problems! - Re-examine code for: + + Double-check by re-examining code for: - Edge cases and null handling - Architecture violations - - Documentation gaps - Integration issues - Dependency problems - - Git commit message quality (if applicable) - Find at least 3 more specific, actionable issues + If still no issues found after thorough re-examination, that is a valid outcome — report a clean review From df9a7f9b679ca3835d198a1a73d619e69579eab0 Mon Sep 17 00:00:00 2001 From: Nikolas Hor <116851567+nikolasdehor@users.noreply.github.com> Date: Thu, 12 Mar 2026 00:35:27 -0300 Subject: [PATCH 3/3] docs: fix contradictory Quinn workflow placement in testing reference (#1911) The testing reference page incorrectly described Quinn's Automate workflow as running per-story before Code Review, contradicting the workflow map which positions it after epic completion. Align the testing page with the workflow map: Quinn runs after all stories in an epic are implemented and code-reviewed. --- docs/reference/testing.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/reference/testing.md b/docs/reference/testing.md index c8a73747f..f7832c2e6 100644 --- a/docs/reference/testing.md +++ b/docs/reference/testing.md @@ -95,11 +95,11 @@ TEA also supports P0-P3 risk-based prioritization and optional integrations with ## How Testing Fits into Workflows -Quinn's Automate workflow appears in Phase 4 (Implementation) of the BMad Method workflow map. A typical sequence: +Quinn's Automate workflow appears in Phase 4 (Implementation) of the BMad Method workflow map. It is designed to run **after a full epic is complete** — once all stories in an epic have been implemented and code-reviewed. A typical sequence: -1. Implement a story with the Dev workflow (`DS`) -2. Generate tests with Quinn (`QA`) or TEA's Automate workflow -3. Validate implementation with Code Review (`CR`) +1. For each story in the epic: implement with Dev (`DS`), then validate with Code Review (`CR`) +2. After the epic is complete: generate tests with Quinn (`QA`) or TEA's Automate workflow +3. Run retrospective (`bmad-retrospective`) to capture lessons learned Quinn works directly from source code without loading planning documents (PRD, architecture). TEA workflows can integrate with upstream planning artifacts for traceability.