bmad-plus 0.5.0 → 0.6.0

package/src/bmad-plus/packs/pack-dev-studio/categories/architecture/steps/step-07-validation.md

@@ -0,0 +1,361 @@
+# Step 7: Architecture Validation & Completion
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+
+- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
+- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
+- ✅ ALWAYS treat this as collaborative discovery between architectural peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on validating architectural coherence and completeness
+- ✅ VALIDATE all requirements are covered by architectural decisions
+- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- ✅ Run comprehensive validation checks on the complete architecture
+- ⚠️ Present A/P/C menu after generating validation results
+- 💾 ONLY save when user chooses C (Continue)
+- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]` before loading next step
+- 🚫 FORBIDDEN to load next step until C is selected
+
+## COLLABORATION MENUS (A/P/C):
+
+This step will generate content and present choices:
+
+- **A (Advanced Elicitation)**: Use discovery protocols to address complex architectural issues found during validation
+- **P (Party Mode)**: Bring multiple perspectives to resolve validation concerns
+- **C (Continue)**: Save the validation results and complete the architecture
+
+## PROTOCOL INTEGRATION:
+
+- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
+- When 'P' selected: Invoke the `bmad-party-mode` skill
+- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
+- User accepts/rejects protocol changes before proceeding
+
+## CONTEXT BOUNDARIES:
+
+- Complete architecture document with all sections is available
+- All architectural decisions, patterns, and structure are defined
+- Focus on validation, gap analysis, and coherence checking
+- Prepare for handoff to implementation phase
+
+## YOUR TASK:
+
+Validate the complete architecture for coherence, completeness, and readiness to guide AI agents through consistent implementation.
+
+## VALIDATION SEQUENCE:
+
+### 1. Coherence Validation
+
+Check that all architectural decisions work together:
+
+**Decision Compatibility:**
+
+- Do all technology choices work together without conflicts?
+- Are all versions compatible with each other?
+- Do patterns align with technology choices?
+- Are there any contradictory decisions?
+
+**Pattern Consistency:**
+
+- Do implementation patterns support the architectural decisions?
+- Are naming conventions consistent across all areas?
+- Do structure patterns align with technology stack?
+- Are communication patterns coherent?
+
+**Structure Alignment:**
+
+- Does the project structure support all architectural decisions?
+- Are boundaries properly defined and respected?
+- Does the structure enable the chosen patterns?
+- Are integration points properly structured?
+
+### 2. Requirements Coverage Validation
+
+Verify all project requirements are architecturally supported:
+
+**From Epics (if available):**
+
+- Does every epic have architectural support?
+- Are all user stories implementable with these decisions?
+- Are cross-epic dependencies handled architecturally?
+- Are there any gaps in epic coverage?
+
+**From FR Categories (if no epics):**
+
+- Does every functional requirement have architectural support?
+- Are all FR categories fully covered by architectural decisions?
+- Are cross-cutting FRs properly addressed?
+- Are there any missing architectural capabilities?
+
+**Non-Functional Requirements:**
+
+- Are performance requirements addressed architecturally?
+- Are security requirements fully covered?
+- Are scalability considerations properly handled?
+- Are compliance requirements architecturally supported?
+
+### 3. Implementation Readiness Validation
+
+Assess if AI agents can implement consistently:
+
+**Decision Completeness:**
+
+- Are all critical decisions documented with versions?
+- Are implementation patterns comprehensive enough?
+- Are consistency rules clear and enforceable?
+- Are examples provided for all major patterns?
+
+**Structure Completeness:**
+
+- Is the project structure complete and specific?
+- Are all files and directories defined?
+- Are integration points clearly specified?
+- Are component boundaries well-defined?
+
+**Pattern Completeness:**
+
+- Are all potential conflict points addressed?
+- Are naming conventions comprehensive?
+- Are communication patterns fully specified?
+- Are process patterns (error handling, etc.) complete?
+
+### 4. Gap Analysis
+
+Identify and document any missing elements:
+
+**Critical Gaps:**
+
+- Missing architectural decisions that block implementation
+- Incomplete patterns that could cause conflicts
+- Missing structural elements needed for development
+- Undefined integration points
+
+**Important Gaps:**
+
+- Areas that need more detailed specification
+- Patterns that could be more comprehensive
+- Documentation that would help implementation
+- Examples that would clarify complex decisions
+
+**Nice-to-Have Gaps:**
+
+- Additional patterns that would be helpful
+- Supplementary documentation
+- Tooling recommendations
+- Development workflow optimizations
+
+### 5. Address Validation Issues
+
+For any issues found, facilitate resolution:
+
+**Critical Issues:**
+"I found some issues that need to be addressed before implementation:
+
+{{critical_issue_description}}
+
+These could cause implementation problems. How would you like to resolve this?"
+
+**Important Issues:**
+"I noticed a few areas that could be improved:
+
+{{important_issue_description}}
+
+These aren't blocking, but addressing them would make implementation smoother. Should we work on these?"
+
+**Minor Issues:**
+"Here are some minor suggestions for improvement:
+
+{{minor_issue_description}}
+
+These are optional refinements. Would you like to address any of these?"
+
+### 6. Generate Validation Content
+
+Prepare the content to append to the document:
+
+#### Content Structure:
+
+```markdown
+## Architecture Validation Results
+
+### Coherence Validation ✅
+
+**Decision Compatibility:**
+{{assessment_of_how_all_decisions_work_together}}
+
+**Pattern Consistency:**
+{{verification_that_patterns_support_decisions}}
+
+**Structure Alignment:**
+{{confirmation_that_structure_supports_architecture}}
+
+### Requirements Coverage Validation ✅
+
+**Epic/Feature Coverage:**
+{{verification_that_all_epics_or_features_are_supported}}
+
+**Functional Requirements Coverage:**
+{{confirmation_that_all_FRs_are_architecturally_supported}}
+
+**Non-Functional Requirements Coverage:**
+{{verification_that_NFRs_are_addressed}}
+
+### Implementation Readiness Validation ✅
+
+**Decision Completeness:**
+{{assessment_of_decision_documentation_completeness}}
+
+**Structure Completeness:**
+{{evaluation_of_project_structure_completeness}}
+
+**Pattern Completeness:**
+{{verification_of_implementation_patterns_completeness}}
+
+### Gap Analysis Results
+
+{{gap_analysis_findings_with_priority_levels}}
+
+### Validation Issues Addressed
+
+{{description_of_any_issues_found_and_resolutions}}
+
+### Architecture Completeness Checklist
+
+Mark each item `[x]` only if validation confirms it; leave `[ ]` if it is missing, partial, or unverified. Any unchecked item must be reflected in the Gap Analysis above and in the Overall Status below.
+
+**Requirements Analysis**
+
+- [ ] Project context thoroughly analyzed
+- [ ] Scale and complexity assessed
+- [ ] Technical constraints identified
+- [ ] Cross-cutting concerns mapped
+
+**Architectural Decisions**
+
+- [ ] Critical decisions documented with versions
+- [ ] Technology stack fully specified
+- [ ] Integration patterns defined
+- [ ] Performance considerations addressed
+
+**Implementation Patterns**
+
+- [ ] Naming conventions established
+- [ ] Structure patterns defined
+- [ ] Communication patterns specified
+- [ ] Process patterns documented
+
+**Project Structure**
+
+- [ ] Complete directory structure defined
+- [ ] Component boundaries established
+- [ ] Integration points mapped
+- [ ] Requirements to structure mapping complete
+
+### Architecture Readiness Assessment
+
+**Overall Status:** {{READY FOR IMPLEMENTATION | READY WITH MINOR GAPS | NOT READY}} (choose READY FOR IMPLEMENTATION only when all 16 checklist items are `[x]` and no Critical Gaps remain; choose NOT READY when any Critical Gap is open or any Requirements Analysis or Architectural Decisions item is unchecked; otherwise READY WITH MINOR GAPS)
+
+**Confidence Level:** {{high/medium/low}} based on validation results
+
+**Key Strengths:**
+{{list_of_architecture_strengths}}
+
+**Areas for Future Enhancement:**
+{{areas_that_could_be_improved_later}}
+
+### Implementation Handoff
+
+**AI Agent Guidelines:**
+
+- Follow all architectural decisions exactly as documented
+- Use implementation patterns consistently across all components
+- Respect project structure and boundaries
+- Refer to this document for all architectural questions
+
+**First Implementation Priority:**
+{{starter_template_command_or_first_architectural_step}}
+```
+
+### 7. Present Content and Menu
+
+Show the validation results and present choices:
+
+"I've completed a comprehensive validation of your architecture.
+
+**Validation Summary:**
+
+- ✅ Coherence: All decisions work together
+- ✅ Coverage: All requirements are supported
+- ✅ Readiness: AI agents can implement consistently
+
+**Here's what I'll add to complete the architecture document:**
+
+[Show the complete markdown content from step 6]
+
+**What would you like to do?**
+[A] Advanced Elicitation - Address any complex architectural concerns
+[P] Party Mode - Review validation from different implementation perspectives
+[C] Continue - Complete the architecture and finish workflow
+
+### 8. Handle Menu Selection
+
+#### If 'A' (Advanced Elicitation):
+
+- Invoke the `bmad-advanced-elicitation` skill with validation issues
+- Process enhanced solutions for complex concerns
+- Ask user: "Accept these architectural improvements? (y/n)"
+- If yes: Update content, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'P' (Party Mode):
+
+- Invoke the `bmad-party-mode` skill with validation context
+- Process collaborative insights on implementation readiness
+- Ask user: "Accept these changes to the validation results? (y/n)"
+- If yes: Update content, then return to A/P/C menu
+- If no: Keep original content, then return to A/P/C menu
+
+#### If 'C' (Continue):
+
+- Append the final content to `{planning_artifacts}/architecture.md`
+- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5, 6, 7]`
+- Load `./step-08-complete.md`
+
+## APPEND TO DOCUMENT:
+
+When user selects 'C', append the content directly to the document using the structure from step 6.
+
+## SUCCESS METRICS:
+
+✅ All architectural decisions validated for coherence
+✅ Complete requirements coverage verified
+✅ Implementation readiness confirmed
+✅ All gaps identified and addressed
+✅ Comprehensive validation checklist completed
+✅ A/P/C menu presented and handled correctly
+✅ Content properly appended to document when C selected
+
+## FAILURE MODES:
+
+❌ Skipping validation of decision compatibility
+❌ Not verifying all requirements are architecturally supported
+❌ Missing potential implementation conflicts
+❌ Not addressing gaps found during validation
+❌ Providing incomplete validation checklist
+❌ Not presenting A/P/C menu after content generation
+
+❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
+❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
+❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
+
+## NEXT STEP:
+
+After user selects 'C' and content is saved to document, load `./step-08-complete.md` to complete the workflow and provide implementation guidance.
+
+Remember: Do NOT proceed to step-08 until user explicitly selects 'C' from the A/P/C menu and content is saved!

package/src/bmad-plus/packs/pack-dev-studio/categories/architecture/steps/step-08-complete.md

@@ -0,0 +1,82 @@
+# Step 8: Architecture Completion & Handoff
+
+## MANDATORY EXECUTION RULES (READ FIRST):
+
+- 🛑 NEVER generate content without user input
+
+- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
+- ✅ ALWAYS treat this as collaborative completion between architectural peers
+- 📋 YOU ARE A FACILITATOR, not a content generator
+- 💬 FOCUS on successful workflow completion and implementation handoff
+- 🎯 PROVIDE clear next steps for implementation phase
+- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
+- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
+
+## EXECUTION PROTOCOLS:
+
+- 🎯 Show your analysis before taking any action
+- 🎯 Present completion summary and implementation guidance
+- 📖 Update frontmatter with final workflow state
+- 🚫 THIS IS THE FINAL STEP IN THIS WORKFLOW
+
+## YOUR TASK:
+
+Complete the architecture workflow, provide a comprehensive completion summary, and guide the user to the next phase of their project development.
+
+## COMPLETION SEQUENCE:
+
+### 1. Congratulate the User on Completion
+
+Both you and the User completed something amazing here - give a summary of what you achieved together and really congratulate the user on a job well done.
+
+### 2. Update the created document's frontmatter
+
+```yaml
+stepsCompleted: [1, 2, 3, 4, 5, 6, 7, 8]
+workflowType: 'architecture'
+lastStep: 8
+status: 'complete'
+completedAt: '{{current_date}}'
+```
+
+### 3. Next Steps Guidance
+
+Architecture complete. Invoke the `bmad-help` skill.
+
+Upon Completion of task output: offer to answer any questions about the Architecture Document.
+
+
+## SUCCESS METRICS:
+
+✅ Complete architecture document delivered with all sections
+✅ All architectural decisions documented and validated
+✅ Implementation patterns and consistency rules finalized
+✅ Project structure complete with all files and directories
+✅ User provided with clear next steps and implementation guidance
+✅ Workflow status properly updated
+✅ User collaboration maintained throughout completion process
+
+## FAILURE MODES:
+
+❌ Not providing clear implementation guidance
+❌ Missing final validation of document completeness
+❌ Not updating workflow status appropriately
+❌ Failing to celebrate the successful completion
+❌ Not providing specific next steps for the user
+❌ Rushing completion without proper summary
+
+❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
+❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
+❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
+
+## WORKFLOW COMPLETE:
+
+This is the final step of the Architecture workflow. The user now has a complete, validated architecture document ready for AI agent implementation.
+
+The architecture will serve as the single source of truth for all technical decisions, ensuring consistent implementation across the entire project development lifecycle.
+
+## On Complete
+
+<!-- Adapted for BMAD+: original script dependency removed -->
+
+If the resolved `workflow.on_complete` is non-empty, follow it as the final terminal instruction before exiting.

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/checkpoint-preview.md

@@ -0,0 +1,68 @@
+---
+name: bmad-checkpoint-preview
+description: 'LLM-assisted human-in-the-loop review. Make sense of a change, focus attention where it matters, test. Use when the user says "checkpoint", "human review", or "walk me through this change".'
+---
+
+# Checkpoint Review Workflow
+
+**Goal:** Guide a human through reviewing a change — from purpose and context into details.
+
+**Your Role:** You are assisting the user in reviewing a change.
+
+## Conventions
+
+- Bare paths (e.g. `step-01-orientation.md`) resolve from the skill root.
+- `this skill directory` resolves to this skill's installed directory (where `agent configuration` lives).
+- `{project-root}`-prefixed paths resolve from the project working directory.
+- `{skill-name}` resolves to the skill directory's basename.
+
+## On Activation
+
+### Step 1: Resolve the Workflow Block
+
+<!-- Adapted for BMAD+: original script dependency removed -->
+
+**If the script fails**, resolve the `workflow` block yourself by reading these three files in base → team → user order and applying the same structural merge rules as the resolver:
+
+1. `this skill file` — defaults
+2. `{project-root}/custom/{skill-name}.toml` — team overrides
+3. `{project-root}/custom/{skill-name}.user.toml` — personal overrides
+
+Any missing file is skipped. Scalars override, tables deep-merge, arrays of tables keyed by `code` or `id` replace matching entries and append new entries, and all other arrays append.
+
+### Step 2: Execute Prepend Steps
+
+Execute each entry in `{workflow.activation_steps_prepend}` in order before proceeding.
+
+### Step 3: Load Persistent Facts
+
+Treat every entry in `{workflow.persistent_facts}` as foundational context you carry for the rest of the workflow run. Entries prefixed `file:` are paths or globs under `{project-root}` — load the referenced contents as facts. All other entries are facts verbatim.
+
+### Step 4: Load Config
+
+Load config from `{project-root}/project config` and resolve:
+
+- `implementation_artifacts`
+- `planning_artifacts`
+- `communication_language`
+- `document_output_language`
+
+### Step 5: Greet the User
+
+Greet the user, speaking in `{communication_language}`.
+
+### Step 6: Execute Append Steps
+
+Execute each entry in `{workflow.activation_steps_append}` in order.
+
+Activation is complete. Begin the workflow below.
+
+## Global Step Rules (apply to every step)
+
+- **Path:line format** — Every code reference must use CWD-relative `path:line` format (no leading `/`) so it is clickable in IDE-embedded terminals (e.g., `src/auth/middleware.ts:42`).
+- **Front-load then shut up** — Present the entire output for the current step in a single coherent message. Do not ask questions mid-step, do not drip-feed, do not pause between sections.
+- **Language** — Speak in `{communication_language}`. Write any file output in `{document_output_language}`.
+
+## FIRST STEP
+
+Read fully and follow `./step-01-orientation.md` to begin.

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/code-review-steps/step-01-gather-context.md

@@ -0,0 +1,85 @@
+---
+diff_output: '' # set at runtime
+spec_file: '' # set at runtime (path or empty)
+review_mode: '' # set at runtime: "full" or "no-spec"
+story_key: '' # set at runtime when discovered from sprint status
+---
+
+# Step 1: Gather Context
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- The prompt that triggered this workflow IS the intent — not a hint.
+- Do not modify any files. This step is read-only.
+
+## INSTRUCTIONS
+
+1. **Find the review target.** The conversation context before this skill was triggered IS your starting point — not a blank slate. Check in this order — stop as soon as the review target is identified:
+
+   **Tier 1 — Explicit argument.**
+   Did the user pass a PR, commit SHA, branch, spec file, or diff source this message?
+   - PR reference → resolve to branch/commit via `gh pr view`. If resolution fails, ask for a SHA or branch.
+   - Commit or branch → use directly.
+   - Spec file → set `{spec_file}` to the provided path. Check its frontmatter for `baseline_commit`. If found, use as diff baseline. If not found, continue the cascade (a spec alone does not identify a diff source).
+   - Also scan the argument for diff-mode keywords that narrow the scope:
+     - "staged" / "staged changes" → Staged changes only
+     - "uncommitted" / "working tree" / "all changes" → Uncommitted changes (staged + unstaged)
+     - "branch diff" / "vs main" / "against main" / "compared to <branch>" → Branch diff (extract base branch if mentioned)
+     - "commit range" / "last N commits" / "<from-sha>..<to-sha>" → Specific commit range
+     - "this diff" / "provided diff" / "paste" → User-provided diff (do not match bare "diff" — it appears in other modes)
+   - When multiple keywords match, prefer the most specific (e.g., "branch diff" over bare "diff").
+
+   **Tier 2 — Recent conversation.**
+   Do the last few messages reveal what the user wants to be reviewed? Look for spec paths, commit refs, branches, PRs, or descriptions of a change. Apply the same diff-mode keyword scan and routing as Tier 1.
+
+   **Tier 3 — Sprint tracking.**
+   Look for a sprint status file (`*sprint-status*`) in `{implementation_artifacts}` or `{planning_artifacts}`. If found, scan for stories with status `review`:
+   - **Exactly one `review` story:** Set `{story_key}` to the story's key (e.g., `1-2-user-auth`). Suggest it: "I found story <story-id> in `review` status. Would you like to review its changes? [Y] Yes / [N] No, let me choose". If confirmed, use the story context to determine the diff source (branch name derived from story slug, or uncommitted changes). If declined, clear `{story_key}` and fall through.
+   - **Multiple `review` stories:** Present them as numbered options alongside a manual choice option. Wait for user selection. If a story is selected, set `{story_key}` and use its context to determine the diff source. If manual choice is selected, clear `{story_key}` and fall through.
+   - **None:** Fall through.
+
+   **Tier 4 — Current git state.**
+   If version control is unavailable, skip to Tier 5. Otherwise, check the current branch and HEAD. If the branch is not `main` (or the default branch), confirm: "I see HEAD is `<short-sha>` on `<branch>` — do you want to review this branch's changes?" If confirmed, treat as a branch diff against `main`. If declined, fall through.
+
+   **Tier 5 — Ask.**
+   Fall through to instruction 2.
+
+   Never ask extra questions beyond what the cascade prescribes. If a tier above already identified the target, skip the remaining tiers and proceed to instruction 3 (construct diff).
+
+2. HALT. Ask the user: **What do you want to review?** Present these options:
+   - **Uncommitted changes** (staged + unstaged)
+   - **Staged changes only**
+   - **Branch diff** vs a base branch (ask which base branch)
+   - **Specific commit range** (ask for the range)
+   - **Provided diff or file list** (user pastes or provides a path)
+
+3. Construct `{diff_output}` from the chosen source.
+   - For **staged changes only**: run `git diff --cached`.
+   - For **uncommitted changes** (staged + unstaged): run `git diff HEAD`.
+   - For **branch diff**: verify the base branch exists before running `git diff`. If it does not exist, HALT and ask the user for a valid branch.
+   - For **commit range**: verify the range resolves. If it does not, HALT and ask the user for a valid range.
+   - For **provided diff**: validate the content is non-empty and parseable as a unified diff. If it is not parseable, HALT and ask the user to provide a valid diff.
+   - For **file list**: validate each path exists in the working tree. Construct `{diff_output}` by running `git diff HEAD -- <path1> <path2> ...`. If any paths are untracked (new files not yet staged), use `git diff --no-index /dev/null <path>` to include them. If the diff is empty (files have no uncommitted changes and are not untracked), ask the user whether to review the full file contents or to specify a different baseline.
+   - After constructing `{diff_output}`, verify it is non-empty regardless of source type. If empty, HALT and tell the user there is nothing to review.
+
+4. **Set the spec context.**
+   - If `{spec_file}` is already set (from Tier 1 or Tier 2): verify the file exists and is readable, then set `{review_mode}` = `"full"`.
+   - Otherwise, ask the user: **Is there a spec or story file that provides context for these changes?**
+     - If yes: set `{spec_file}` to the path provided, verify the file exists and is readable, then set `{review_mode}` = `"full"`.
+     - If no: set `{review_mode}` = `"no-spec"`.
+
+5. If `{review_mode}` = `"full"` and the file at `{spec_file}` has a `context` field in its frontmatter listing additional docs, load each referenced document. Warn the user about any docs that cannot be found.
+
+6. Sanity check: if `{diff_output}` exceeds approximately 3000 lines, warn the user and offer to chunk the review by file group.
+   - If the user opts to chunk: agree on the first group, narrow `{diff_output}` accordingly, and list the remaining groups for the user to note for follow-up runs.
+   - If the user declines: proceed as-is with the full diff.
+
+### CHECKPOINT
+
+Present a summary before proceeding: diff stats (files changed, lines added/removed), `{review_mode}`, and loaded spec/context docs (if any). HALT and wait for user confirmation to proceed.
+
+
+## NEXT
+
+Read fully and follow `./step-02-review.md`

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/code-review-steps/step-02-review.md

@@ -0,0 +1,35 @@
+---
+failed_layers: '' # set at runtime: comma-separated list of layers that failed or returned empty
+---
+
+# Step 2: Review
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- The Blind Hunter subagent receives NO project context — diff only.
+- The Edge Case Hunter subagent receives diff and project read access.
+- The Acceptance Auditor subagent receives diff, spec, and context docs.
+- All review subagents must run at the same model capability as the current session.
+
+## INSTRUCTIONS
+
+1. If `{review_mode}` = `"no-spec"`, note to the user: "Acceptance Auditor skipped — no spec file provided."
+
+2. Launch parallel subagents without conversation context. If subagents are not available, generate prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
+
+   - **Blind Hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Invoke via the `bmad-review-adversarial-general` skill.
+
+   - **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Invoke via the `bmad-review-edge-case-hunter` skill.
+
+   - **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Its prompt:
+     > You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
+
+3. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
+
+4. Collect all findings from the completed layers.
+
+
+## NEXT
+
+Read fully and follow `./step-03-triage.md`

package/src/bmad-plus/packs/pack-dev-studio/categories/implementation/code-review-steps/step-03-triage.md

@@ -0,0 +1,49 @@
+---
+---
+
+# Step 3: Triage
+
+## RULES
+
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+- Be precise. When uncertain between categories, prefer the more conservative classification.
+
+## INSTRUCTIONS
+
+1. **Normalize** findings into a common format. Expected input formats:
+   - Adversarial (Blind Hunter): markdown list of descriptions
+   - Edge Case Hunter: JSON array with `location`, `trigger_condition`, `guard_snippet`, `potential_consequence` fields
+   - Acceptance Auditor: markdown list with title, AC/constraint reference, and evidence
+
+   If a layer's output does not match its expected format, attempt best-effort parsing. Note any parsing issues for the user.
+
+   Convert all to a unified list where each finding has:
+   - `id` -- sequential integer
+   - `source` -- `blind`, `edge`, `auditor`, or merged sources (e.g., `blind+edge`)
+   - `title` -- one-line summary
+   - `detail` -- full description
+   - `location` -- file and line reference (if available)
+
+2. **Deduplicate.** If two or more findings describe the same issue, merge them into one:
+   - Use the most specific finding as the base (prefer edge-case JSON with location over adversarial prose).
+   - Append any unique detail, reasoning, or location references from the other finding(s) into the surviving `detail` field.
+   - Set `source` to the merged sources (e.g., `blind+edge`).
+
+3. **Classify** each finding into exactly one bucket:
+   - **decision_needed** -- There is an ambiguous choice that requires human input. The code cannot be correctly patched without knowing the user's intent. Only possible if `{review_mode}` = `"full"`.
+   - **patch** -- Code issue that is fixable without human input. The correct fix is unambiguous.
+   - **defer** -- Pre-existing issue not caused by the current change. Real but not actionable now.
+   - **dismiss** -- Noise, false positive, or handled elsewhere.
+
+   If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
+
+4. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
+
+5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
+
+6. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
+
+
+## NEXT
+
+Read fully and follow `./step-04-present.md`