mirror of
https://github.com/magnus919/agent-skills.git
synced 2026-09-11 19:47:12 +03:00
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.
50 lines
1.3 KiB
Markdown
50 lines
1.3 KiB
Markdown
---
|
|
status: ready-for-dev
|
|
slug: story-slug
|
|
parent-spec: SPEC.md
|
|
owner: human
|
|
created: YYYY-MM-DD
|
|
---
|
|
|
|
# Story: <name>
|
|
|
|
One bounded, dispatchable work unit. A story is coherent, independently finishable,
|
|
and carries everything the implementing agent needs without inventing decisions.
|
|
|
|
## Context
|
|
|
|
- Parent spec or intent contract (link).
|
|
- The slice of the contract this story owns.
|
|
- What is already true in the codebase (verify, do not assume).
|
|
|
|
## Acceptance criteria
|
|
|
|
- Observable, binary outcomes (PASS/FAIL possible).
|
|
- Each criterion traces to a contract capability or constraint.
|
|
|
|
## Boundaries
|
|
|
|
- In scope.
|
|
- Out of scope (and where deferred items are tracked).
|
|
- Architecture decisions already made that this story must preserve.
|
|
|
|
## Implementation notes
|
|
|
|
- Files or components expected to change (draft; the implementer verifies).
|
|
- Commands with non-obvious prerequisites.
|
|
- Known pitfalls observed in this area.
|
|
|
|
## Verification
|
|
|
|
- Tests to run (focused first).
|
|
- Evaluations or manual observations required.
|
|
- Independent review needed? (separate evaluator where risk warrants it)
|
|
|
|
## Status history
|
|
|
|
- `ready-for-dev` — passed readiness.
|
|
- `in-progress` — implementation underway.
|
|
- `in-review` — review/triage underway.
|
|
- `done` — completed and accepted.
|
|
- `blocked` — cannot continue safely; routing signal.
|