Agent skill · product strategy · aj-geddes
bmad-spec
Distills ANY messy input — brain dump, transcript, long PRD, stakeholder notes, feature request, voice memo — into a tight five-field SPEC.md kernel that any downstream planning skill can consume. The five fields are: Problem, Capabilities, Constraints, Non-Goals, Success Metrics. Use when the user says "create a spec", "write a spec for", "distill this into a spec", "I have a brain dump", "turn this into something structured", "clean up these notes", "make a SPEC from", "I want to define the problem", "help me scope this", "summarize what we're building", "I have a PRD but need a kernel", "what are we actually solving?", or drops raw text/transcript and asks for structure. Also use when starting any new initiative and a clean shared definition is missing.
Why this skill is useful
Provides a structured template for distilling unstructured input into a concise SPEC.md format, which aids in planning and scoping.
What it needs
About 5k tokens when loaded. Last updated 2026-06-20. 471 stars on the source repository.
What this skill does
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/): 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. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aj-geddes/bmad-spec