Bmad Spec

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 (Read it)
• 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):

## 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-spec to turn the kernel into a

deployable spec.

• BMad Method / Enterprise track → hand off to bmad-product-brief or the

PM role (bmad-prfaq) for a full PRD.

• If no workspace exists yet, suggest running /bmad-planning-orchestrator:bmad-init

first 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 in decision-log.md.

• Validate — review SPEC.md against 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.