mirror of
https://github.com/bmad-code-org/BMAD-METHOD.git
synced 2026-08-28 19:20:41 +08:00
refactor(quick-dev,dev-auto): minimal handoff, drop Code Map nudge (#2635)
Walk back two bits of overprompting from #2629: - The `implementation_handoff` guardrail block was premature mitigation to speculative failure modes (don't commit, don't revert unrelated changes, don't edit the spec). Collapse the default to what it should have always been: read the spec fully, load its `context:`, implement, report back. The key stays customizable — that seam exists to run implementation on a different model or an external tool via bash — only the default shrinks. - Revert the Code Map spec-template enrichment. Granular entries were always permitted; step-02 already instructs planning to populate the Code Map, so the template comment/example nudge was redundant and half-relegitimized a root cause (#2629) that the natural experiment had already disproved. Both skills' handoffs are now identical again. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -34,22 +34,16 @@ persistent_facts = [
|
||||
on_complete = ""
|
||||
|
||||
# Handoff for the implementation subagent in step 03. The whole execution
|
||||
# recipe — a subagent by default, but an override may run anything (e.g. an
|
||||
# external coding tool via bash). {spec_file} is substituted at run time.
|
||||
# recipe — a subagent by default, but an override may run it any other way
|
||||
# (a different model, an external coding tool via bash). {spec_file} is
|
||||
# substituted at run time.
|
||||
|
||||
implementation_handoff = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Read {spec_file} fully and implement it. The spec is the sole source of truth for this change; its Spec Change Log entries are binding constraints, not history.
|
||||
> Read {spec_file} fully and implement it — the spec is the sole source of truth. Load every file listed in its frontmatter `context:` before you start.
|
||||
>
|
||||
> Guardrails:
|
||||
>
|
||||
> - Work in the current project. Before starting, load every file listed in the spec frontmatter `context:`.
|
||||
> - Do not edit the spec file itself.
|
||||
> - Do not revert or overwrite changes unrelated to this spec.
|
||||
> - Run the verification described in the spec, plus focused checks for the code you touched.
|
||||
>
|
||||
> When done, report: files changed with one line each, verification commands run and their outcomes, any files changed beyond the spec's tasks and why each was needed, anything you could not complete and why, and residual risks.
|
||||
> When done, report what you changed, how you verified it, and anything left incomplete or risky.
|
||||
"""
|
||||
|
||||
# Review layers for the review step. `instruction` is the layer's whole
|
||||
|
||||
@@ -48,10 +48,10 @@ warnings: [] # optional: machine-readable warnings for orchestration, e.g. overs
|
||||
|
||||
## Code Map
|
||||
|
||||
<!-- Agent-populated during planning: the distilled investigation map, so the spec carries what exploration found and the implementation handoff need only point here. Annotated paths prevent blind codebase searching. Entries may drill to symbol/line and carry reuse pointers ("mirror X at FILE:LINE") or read-only evidence, where they save the implementer a search. -->
|
||||
<!-- Agent-populated during planning. Annotated paths prevent blind codebase searching. -->
|
||||
|
||||
- `FILE` -- ROLE_OR_RELEVANCE
|
||||
- `FILE:LINE` -- ROLE_OR_RELEVANCE; reuse pointer or READ-ONLY evidence when relevant
|
||||
- `FILE` -- ROLE_OR_RELEVANCE
|
||||
|
||||
## Tasks & Acceptance
|
||||
|
||||
|
||||
@@ -33,27 +33,17 @@ persistent_facts = [
|
||||
|
||||
on_complete = ""
|
||||
|
||||
# Handoff for the implementation subagent in step 03 — nailed down here the same
|
||||
# way the review layers below are, so the main session never improvises a fat
|
||||
# dispatch prompt. The spec is the subagent's sole source of truth; investigation
|
||||
# findings belong in the spec's Code Map (see step 02), not re-narrated here.
|
||||
# {spec_file} is substituted at run time. An override may replace the whole recipe
|
||||
# (e.g. drive an external coding tool via bash).
|
||||
# Handoff for the implementation subagent in step 03. The whole execution
|
||||
# recipe — a subagent by default, but an override may run it any other way
|
||||
# (a different model, an external coding tool via bash). {spec_file} is
|
||||
# substituted at run time.
|
||||
|
||||
implementation_handoff = """
|
||||
Launch a subagent with no prior conversation context, with this prompt:
|
||||
|
||||
> Read {spec_file} fully and implement it. The spec is the sole source of truth for this change; its Code Map is your investigation map, and its Spec Change Log entries are binding constraints, not history.
|
||||
> Read {spec_file} fully and implement it — the spec is the sole source of truth. Load every file listed in its frontmatter `context:` before you start.
|
||||
>
|
||||
> Guardrails:
|
||||
>
|
||||
> - Work in the current project. Before starting, load every file listed in the spec frontmatter `context:`.
|
||||
> - Do not edit the spec file itself.
|
||||
> - Do not commit or push — that happens later in the workflow.
|
||||
> - Do not revert or overwrite changes unrelated to this spec.
|
||||
> - Run the verification described in the spec, plus focused checks for the code you touched.
|
||||
>
|
||||
> When done, report: files changed with one line each, verification commands run and their outcomes, any files changed beyond the spec's tasks and why each was needed, anything you could not complete and why, and residual risks.
|
||||
> When done, report what you changed, how you verified it, and anything left incomplete or risky.
|
||||
"""
|
||||
|
||||
# Review layers for the review step. `instruction` is the layer's whole
|
||||
|
||||
@@ -46,10 +46,10 @@ context: [] # optional: `{project-root}/`-prefixed paths to project-wide standar
|
||||
|
||||
## Code Map
|
||||
|
||||
<!-- Agent-populated during planning: the distilled investigation map, so the spec carries what exploration found and the implementation handoff need only point here. Annotated paths prevent blind codebase searching. Entries may drill to symbol/line and carry reuse pointers ("mirror X at FILE:LINE") or read-only evidence, where they save the implementer a search. -->
|
||||
<!-- Agent-populated during planning. Annotated paths prevent blind codebase searching. -->
|
||||
|
||||
- `FILE` -- ROLE_OR_RELEVANCE
|
||||
- `FILE:LINE` -- ROLE_OR_RELEVANCE; reuse pointer or READ-ONLY evidence when relevant
|
||||
- `FILE` -- ROLE_OR_RELEVANCE
|
||||
|
||||
## Tasks & Acceptance
|
||||
|
||||
|
||||
Reference in New Issue
Block a user