BMAD Spec — Five-Field Kernel Distiller
Function: Accept messy, unstructured, or verbose input and produce a lean
SPEC.md kernel (five fields, no more) that anchors every downstream planning
workflow. This is a planning skill. It never writes application code, runs
tests, or builds anything.
What it produces
A single file under the configured output folder (default bmad-output/):
bmad-output/ └── SPEC.md # the five-field kernel
The kernel is intentionally small — a SPEC is not a PRD, not a brief, not an architecture doc. It is the shared definition of what is being built and why. Every downstream skill (PRD, tech-spec, architecture) loads it as the ground truth for scope.
The five fields
| Field | Purpose |
|---|---|
| Problem | The one thing that hurts right now and why it matters |
| Capabilities | What the solution must be able to do (outcome-framed) |
| Constraints | Hard limits that are not negotiable (budget, tech, time, compliance) |
| Non-Goals | Scope that is explicitly out — prevents creep and confusion |
| Success Metrics | Observable signals that confirm the problem is solved |
See templates/spec.template.md for the exact template with guidance and examples.
Workflow
1. Ingest
Accept whatever the user hands over:
- Paste of raw text, notes, or a transcript
- A path to an existing file (
Readit) - Verbal description in the chat
If the input exceeds a few hundred words, briefly acknowledge what you received before proceeding. Do not ask the user to reformat it — that is the skill's job.
2. Extract (silent analysis)
Read the input and locate signal for each field:
- Problem: What pain, gap, or failure state is described? Who experiences it?
- Capabilities: What outcomes or abilities are requested? Rephrase features as capabilities ("users can …", "the system supports …").
- Constraints: What is fixed? Look for budget figures, tech mandates, deadlines, regulatory mentions, team-size limits.
- Non-Goals: What is the input silent about that a reader might assume? What is explicitly ruled out? What is deferred?
- Success Metrics: What does "done" or "working" look like? Numbers, observable behaviors, thresholds.
3. Draft and present
Write a concise draft of all five fields and show it to the user in the chat before writing to disk. Keep each field tight:
- Problem: 2–5 sentences max.
- Capabilities: 3–7 bullet points, outcome-framed.
- Constraints: 2–6 bullet points, hard limits only.
- Non-Goals: 2–6 bullet points, clear and unambiguous.
- Success Metrics: 2–5 bullet points, each with a measurable signal.
After presenting, ask one targeted question: "Does anything here need to change before I write SPEC.md?"
4. Write
Once the user confirms (or revises), write SPEC.md using the template:
${CLAUDE_PLUGIN_ROOT}/skills/bmad-spec/templates/spec.template.md
Output path: <outputFolder>/SPEC.md (read bmad-output/config.yaml if it
exists to find the configured output folder; fall back to bmad-output/).
Append a new entry to bmad-output/decision-log.md (create it if absent):
markdown## SPEC created — <ISO date> - Source: <one-line description of the input, e.g. "stakeholder brain dump"> - Key scope decision: <the single most important Non-Goal or Constraint>
5. Hand off
After writing, tell the user what the SPEC unlocks:
- Quick Flow track → hand off to
bmad-tech-specto turn the kernel into a deployable spec. - BMad Method / Enterprise track → hand off to
bmad-product-briefor the PM role (bmad-prfaq) for a full PRD. - If no workspace exists yet, suggest running
/bmad-planning-orchestrator:bmad-initfirst to pick a track.
Three intents
- Create — distill fresh input into a new
SPEC.md(the common case). - Update — the user has new information or changed scope. Read the existing
SPEC.md, apply the changes, present a diff-style summary, confirm, then overwrite. Record the change indecision-log.md. - Validate — review
SPEC.mdagainst the five-field contract: are all fields present and non-empty? Is the Problem one coherent statement? Are Capabilities outcome-framed (not feature-list)? Are Non-Goals unambiguous? Flag any gaps and offer to fix them.
Distillation heuristics
Follow these when mapping noisy input to the five fields:
| Input pattern | Maps to |
|---|---|
| "we need to fix / users complain / it's broken" | Problem |
| "it should / users can / the system supports" | Capabilities |
| "we can't / no budget / must use / by deadline" | Constraints |
| "not in scope / later / out of v1 / won't do" | Non-Goals |
| "if X% then / we'll know it works when / target" | Success Metrics |
When a constraint sounds aspirational (e.g., "we'd like to finish in Q3"), move it to Non-Goals or flag it as a soft constraint and note the ambiguity.
When capabilities sound like features rather than outcomes, rephrase: "add a search bar" → "users can find any record within 3 keystrokes".
When no success metrics appear in the input, use the Problem statement to derive proxy metrics: if the problem is "users can't find X", a metric is "time-to-find X reduced by Y%".
Guardrails
- Lean by design. Resist adding a sixth field. If important information does not fit the five fields, note it as context in the file header and direct the user to expand it in the PRD or tech-spec stage.
- No solutioning. The Capabilities field names outcomes, not implementation choices. Architecture, tech stack, and approach live downstream.
- No story points, velocity, or burndown anywhere in the SPEC.
- Scope law. This skill's last artifact is
SPEC.md. It does not create stories, write code, or produce acceptance criteria. Hand those to downstream skills.
See REFERENCE.md for extended distillation patterns and edge cases.
Part of the BMAD Planning & Orchestrator plugin — a Claude Code harness for the BMAD Method by the BMAD Code Organization (https://github.com/bmad-code-org/BMAD-METHOD). Implements the spirit of
bmad-spec. All methodology credit belongs to the BMAD Code Organization.
