* 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.
Implementation Planning — Turn approved specs into executable delivery plans
Why Install This Skill
A great specification answers "what to build." It does not answer "how to build it across three teams, two repositories, a data migration, and a staged rollout." That gap — between an approved requirement and the first line of code — is where teams lose weeks to misalignment, missed dependencies, and last-minute surprises.
Implementation Planning fills that gap. Give your agent an approved spec or product brief, and it returns a concrete, dependency-aware delivery plan with work breakdown, critical path analysis, ownership, rollout strategy, rollback paths, and verification traceability back to the original requirement.
This skill is designed for real-world complexity: cross-team coordination, multi-repository changes, data migrations with rollback, and staged rollouts with observability gates. It does not assume a single repo or a single team.
What You Get
| Directory entry | What it provides |
|---|---|
SKILL.md |
Core planning workflow: ingest approved input, decompose into workstreams, map dependencies, find the critical path, assign ownership, sequence and parallelize, design rollout and rollback, verify against the original requirement. Includes entry gate (stop if not approved), handoff table to specialist skills, and cross-team/cross-repo guidance. |
README.md |
This file — human-facing overview of what the skill does and how to use it. |
references/discovery-brief.md |
Bounded comparison of existing planning material across the catalog (SDD task plans, release-engineering rollout plans, SRE change plans, product-discovery) and a clear definition of what implementation-planning owns vs. hands off. |
templates/implementation-plan-template.md |
Fillable template for a complete implementation plan: workstreams, ownership, sequencing, rollout stages, rollback triggers, and verification checklist. |
templates/dependency-record.md |
Structured record for dependency mapping, critical path, and handoff contracts between teams or repositories. |
templates/risk-decision-verification.md |
Sections for recording risks, assumptions, unresolved decisions, and verification traceability from plan back to requirement. |
evals/evals.json |
Five output-quality evaluation cases covering ambiguous requirements, cross-repository dependencies, a data migration, a risky rollout, and a plan rejection due to missing prerequisite approval. |
Quick Start
- Ensure you have an approved requirement or specification ready. The skill will stop and decline if the input is not approved.
- Load the skill: your agent reads
SKILL.mdand follows the core workflow. - The agent produces a plan using the templates in
templates/, starting with the implementation plan template. - Review the plan, resolve any open decisions, and hand it off to the specialist skills named in the handoff table.
Triggers
Load this skill when:
- An approved spec or product brief needs a delivery plan.
- A cross-team or multi-repo feature needs work coordination and dependency mapping.
- A data migration needs a staged execution plan with rollback.
- A risky or high-stakes change needs a rollout strategy with observability gates.
- Multiple workstreams need critical-path analysis and ownership assignment.
Do not load this skill when:
- The requirement has not been approved — route to product-discovery or spec-driven-development first.
- You need to write a spec from scratch — route to spec-driven-development.
- You are coding, debugging, or implementing — route to the appropriate engineering skill.
- You are executing the neckbeard issue-to-PR delivery flow — this skill plans work, it does not execute delivery.
Requirements
- No runtime dependencies, API keys, or external services.
- The skill expects an approved requirement or specification as input. An unapproved input triggers the stop condition — no plan is produced.
- Templates use markdown and work with any text editor or agent.