Magnus HedemarkandGitHub
e10508b034
* feat(bmad): add BMad control-plane protocol skill New standalone methodology skill that lets any agent run the BMad method (Breakthrough Method of Agile AI-Driven Development) as a harness-agnostic control-plane protocol: five-field intent contracts, direct/bounded/initiative classification, review-as-triage, failure routing by layer, and autonomy gating with machine-readable spec status. - SKILL.md protocol core with progressive disclosure + When not to use - README.md human-facing install guide - 9 references: protocol, classification, spec, lifecycle, project-context, review-and-failure-routing, autonomy, party-mode, adoption - 4 templates: SPEC, INTENT, STORY, REVIEW - scripts/check-spec.py + 16 tests (stdlib, deterministic spec validation) - evals/evals.json: 9 output-quality cases - Routing seams from bmad to adjacent skills and back from spec-driven-development, product-shaping, implementation-planning, neckbeard - Catalog updates: root README, skill-triggers, marketplace/plugin/llms.txt Closes #399 * fix(bmad): address droid-review findings - check-spec.py: skip headings inside fenced/indented code blocks so a spec cannot PASS on section text that only appears in a code sample - check-spec.py: catch UnicodeDecodeError on non-UTF-8 files and report FAIL instead of crashing - STORY.md template: add created key for resumability/traceability parity - SPEC.md template: split in-progress and in-review status bullets - add 2 regression tests (heading-in-fence, non-UTF-8) * fix(bmad): address droid-review round 2 - check-spec.py: read specs with utf-8-sig so a UTF-8 BOM cannot silently disable the frontmatter status check - check-spec.py: handle standard YAML inline comments after status values (status: draft # pending review) without a false FAIL - references/protocol.md: make lifecycle phrasing consistent with lifecycle.md — four phases plus a learning closeout - add 2 regression tests (BOM, inline comment) * fix(bmad): tolerate trailing whitespace on frontmatter delimiters A spec whose --- delimiter lines carry trailing spaces or tabs would silently disable the status check and let an invalid status PASS. Relax the delimiter pattern and add a regression test. * fix(bmad): ignore inline comments in quoted status values * fix(bmad): tolerate leading blank lines before frontmatter * fix(bmad): fail closed on unparseable frontmatter, matching fence markers Address droid-review round 5 and 6 findings as a single closed class: - Fail closed when a file opens with a --- delimiter that cannot be parsed, so no whitespace/frontmatter permutation can silently disable the status check (previously: unparseable frontmatter was treated as 'no status' warning, letting an invalid status PASS). - Track fence opener markers in collect_headings so a mismatched fence no longer closes a code block early (false-PASS on missing sections) and an unclosed fence no longer swallows real headings. - Accept empty well-formed frontmatter (---\n---) and closing delimiters without a trailing newline. - STORY.md template: parent-spec points at the sibling SPEC.md. - README: status vocabulary is not a strict linear chain; blocked is a resumable routing signal. Whitespace/frontmatter mutation sweep: 9 formatting variants x valid/invalid status all verdict correctly; malformed delimiters fail closed. 29 tests.
3.2 KiB
Autonomy: BMad Build Auto
Build Auto is not a second implementation methodology. It is an unattended execution wrapper around the canonical Build loop — one iteration per run: clarify intent, create or resume a spec, implement, review, write a machine-readable terminal status.
The autonomy gate
Autonomous execution is allowed only when all of these hold:
- the intent contract is coherent;
- acceptance is observable;
- the working boundary is explicit;
- the repository state is safe to modify;
- tests or evaluations can run;
- the agent can write a durable status;
- escalation behavior is defined.
If any condition is missing, do not run unattended. Run supervised instead, or report the missing condition.
Operating rules during autonomous work
- Make one coherent change at a time.
- Do not expand scope because you noticed unrelated improvements — record them as deferred findings.
- Do not merge, deploy, or change external systems unless explicitly authorized.
- Make local commits if the repository convention allows; never push without authorization.
- Stop on: intent gaps, missing capabilities, destructive ambiguity, failed verification, or non-convergent repair.
- Treat
blockedas a routing signal for the orchestrator or human. - Preserve evidence of what was attempted and why it stopped.
Deferred findings
If review finds a real issue outside the current story, record it as deferred. The implementer does not decide what happens to it — the orchestrator decides whether to create a ticket, deduplicate it, escalate it, or ignore it. This is the control-plane boundary: Build Auto owns the implementation run and its spec artifact; the higher-level orchestrator owns backlog policy.
Blocked is a routing signal
blocked normally means a higher-level orchestrator, another workflow, or a human
must take over. When a run reports blocked, the report should say what was
attempted, what stopped it, and what decision or capability is required to continue.
Dark-factory fit
BMad provides the planning, context, implementation, review, and learning patterns. A full dark factory still needs, around it: a work queue; scheduling and dispatch; repository isolation; dependency and credential controls; deterministic tests; product and domain evaluations; policy gates; merge and deployment rules; observability; retry and escalation behavior; cost and time budgets. Build Auto can be one execution primitive inside that larger system — it is not the whole system.
Escalation behavior to define before starting
Before any autonomous run, write down:
- What triggers escalation (blocked, failed verification, new intent gap, cost cap).
- Who or what receives the escalation (orchestrator, queue, human channel).
- What evidence accompanies the escalation.
- What the default is when escalation is unreachable (stop safely, never guess).
Stop before you fake convergence
If each fix to a machine-generated finding produces the next finding, the work is not
converging — the mechanism is. Change the mechanism (fresh context, different
evaluator, better spec) or bound the loop and report. Never report done while a
required gate is unresolved.