bmad-build and bmad-code-review duplicate 3 identical review layers — wasted time/tokens if both are run, and bmad-build alone never reaches done

Version: 6.11.0 Skills involved: bmad-build, bmad-code-review

Issue 1: Duplicate review layers waste time and tokens when both skills run on the same diff

bmad-build's step-04-review.md and bmad-code-review's step-02-review.md both execute a review_layers list defined in each skill's customize.toml. Three of these layers are byte-for-byte identical between the two skills:

• blind-hunter — identical inline instruction in both customize.toml files
• edge-case-hunter — identical instruction, and identical underlying prompt file (review-prompts/edge-case-hunter.md is byte-identical between the two skill directories)
• verification-gap — same, review-prompts/verification-gap.md is byte-identical

bmad-code-review additionally has a fourth layer, acceptance-auditor, not present in bmad-build.

Because these are separate skills with independently-copied prompt files (not a shared reference), a workflow where a user runs bmad-build to implement+review a story and then runs bmad-code-review on the same diff (which is a natural thing to do, see Issue 2) re-executes the exact same three subagent reviews against the exact same diff, producing the same findings twice. This burns real wall-clock time (3 redundant subagent launches) and token spend for zero additional signal — bmad-code-review's only incremental value in that scenario is acceptance-auditor plus its triage/present step.

Suggested fix (one of):

1. Have bmad-build's review step delegate the 3 shared layers to bmad-code-review instead of duplicating them (or vice versa), so there's one canonical implementation.
2. Or, document clearly that bmad-build and bmad-code-review are meant as alternatives for the review step, not a pipeline — i.e., pick one, don't run both on the same diff.
3. At minimum, deduplicate the underlying prompt files so edge-case-hunter.md/verification-gap.md aren't maintained as two independent copies that can drift.

Issue 2: bmad-build never advances a story to done — only bmad-code-review does

bmad-build advances development_status in sprint-status.yaml through in-progress → review (via the shared sync-sprint-status.md sub-step, called from step-03-implement.md and step-05-present.md/step-oneshot.md). It never sets done. Only bmad-code-review's step-04-present.md does that, after triaging findings.

So a user whose workflow is "run bmad-build, then move on" — without separately invoking bmad-code-review afterward — has a story permanently stuck at review in sprint-status.yaml, with no signal from bmad-build's output that a second, separate skill run is required to close it out. This is confusing precisely because bmad-build already runs its own full review pass (see Issue 1) — it looks complete, but the sprint tracking says otherwise.

Suggested fix (one of):

1. Document explicitly, in bmad-build's completion summary and SKILL.md, that bmad-code-review must be run separately to reach done.
2. Or have bmad-build's step-05 completion prompt to advance straight to done when its own review found no blocking issues, instead of leaving review as a dead-end-looking state.
3. Or resolve this together with Issue 1: if the two review passes are meant to be a single pipeline, unify them into one skill (or one clearly delegates to the other) so the status lifecycle and the review effort are consistent with each other.

Repro

1. Run bmad-build on a story tracked in sprint-status.yaml; let it complete through step-05 (review_layers run, status becomes review).
2. Separately run bmad-code-review on the same diff: observe blind-hunter, edge-case-hunter, verification-gap execute again with identical prompts/output to step 1, before acceptance-auditor adds anything new.
3. If step 2 is skipped: observe sprint-status.yaml keeps the story at review indefinitely.