ldy26098
/
BMAD-METHOD
mirror of https://github.com/bmad-code-org/BMAD-METHOD.git
1
0
Fork 0
Code Packages Projects Releases Wiki Activity
BMAD-METHOD/src/bmm-skills/4-implementation/bmad-dev-auto/steps/step-04-review-and-repair.md

3.3 KiB
Raw Blame History

max_review_iterations
5

Step 4: Review and Repair

Rules

  • YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config {communication_language}.
  • Review subagents receive no conversation context.
  • Review subagents provide signals only. This session owns triage and repair decisions.
  • Do not ask the user to run review prompts manually.
  • Do not leave known patch findings unresolved when the fix is unambiguous.

Instructions

  1. Enter review state.

    • Set {spec_file} frontmatter status to in-review.
    • Increment review_iterations in {spec_file} frontmatter.

  2. Construct the review payload.

    • Read baseline_commit from {spec_file} frontmatter.
    • Build a diff covering tracked and untracked changes since baseline_commit.
    • If baseline_commit is missing or NO_VCS, construct a best-effort file-change summary from the working tree.
    • Do not stage files.

  3. Run review layers.

    • Spec compliance: Compare the diff to {spec_file}, including acceptance criteria, boundaries, context docs, and verification expectations.
    • Edge-case review: Walk boundary conditions, failure paths, compatibility risks, and state transitions introduced by the diff.
    • Regression review: Look for unintended behavior changes outside the spec, deleted behavior, security issues, data loss, and integration breakage.
    • Use subagents for independent review signals when available, but perform an inline review yourself even if subagents run.

  4. Classify findings.

    • patch -- caused by this change and unambiguously fixable in code.
    • bad_spec -- caused by this change, but the non-frozen spec failed to direct the implementation clearly enough.
    • intent_gap -- caused by missing or conflicting orchestrator-owned intent inside <frozen-after-resolution>.
    • defer -- real pre-existing issue not caused by this task.
    • reject -- false positive, already handled, or outside scope without actionable evidence.

  5. Process findings in order.

    • If any intent_gap finding exists, revert product-code changes from this run when safe, preserve run artifacts, write {result_file} using the result schema from ../result-schema.md with status = blocked, blocked_reason = intent_gap, and the exact orchestrator decision required. End cleanly.
    • If any bad_spec finding exists, amend only the non-frozen spec sections, append a Spec Change Log entry with KEEP instructions, revert or repair code as needed, then read fully and follow ./step-03-implement.md.
    • If any patch finding exists, apply all unambiguous fixes, rerun relevant verification, then repeat this step from section 1.
    • If any defer finding exists, append it to {deferred_work_file} with source task, evidence, and reason for deferral.
    • Drop reject findings.

  6. Iteration guard.

    • If the review_iterations value in {spec_file} frontmatter exceeds {max_review_iterations}, write {result_file} using the result schema from ../result-schema.md with status = blocked, blocked_reason = review_loop_limit, and the unresolved findings. End cleanly.

  7. Write review artifact.

    • Write {review_file} with review payload summary, findings by classification, actions taken, verification reruns, deferred items, and final open risks.

Next

Read fully and follow ./step-05-finalize.md.