bmad-planning-orchestrator/skills/bmad-builder/SKILL.md
Meta-skill for scaffolding and validating custom PLANNING/ORCHESTRATION skills within the BMAD Planning & Orchestrator plugin. Produces the full skill directory: SKILL.md, scripts, and templates — all pre-targeted at this plugin's path conventions. Includes a scope-violation checker so newly created skills never drift into dev/lint/build/coverage territory. Use when the user says "create a skill", "scaffold a skill", "build a new planning skill", "add a skill to the orchestrator", "extend BMAD planning", "custom orchestration skill", "validate this skill", "check this skill for scope violations", "new skill for the planner", or "bmad-builder". Supports three intents: Create (new skill skeleton), Validate (check an existing SKILL.md), Scaffold (directory structure only). This skill plans and scaffolds only — it NEVER writes application code, runs tests, lints, or builds.
npx skillsauth add aj-geddes/claude-code-bmad-skills bmad-builderInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Function: Scaffold and validate custom planning/orchestration skills for the BMAD Planning & Orchestrator plugin. Produces compliant SKILL.md files, shell scripts, and templates — pre-wired to this plugin's path conventions — and runs scope-violation checks to keep new skills inside the PLAN/ORCHESTRATE boundary.
This skill produces planning artifacts and skill skeleton files. It does NOT write application code, run tests, lint, check coverage, or execute builds. If a skill being designed is tempted to "implement", "fix the code", "run the suite", or "review the diff" — that is a scope violation. Plan and hand off instead.
Always clarify which intent applies before starting.
Gather requirements (use TodoWrite to track):
bmad-; e.g. bmad-example)bmad-risk-assessment)Run the scaffold script to create the directory:
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-builder/scripts/scaffold-skill.sh <skill-name>
This creates skills/<skill-name>/ with scripts/ and templates/ subdirectories and a starter SKILL.md.
Fill the SKILL.md using the skill template:
${CLAUDE_PLUGIN_ROOT}/skills/bmad-builder/templates/skill.template.mdREFERENCE.md in the new skill's own folder${CLAUDE_PLUGIN_ROOT} for all paths to bundled scripts/templatesbmad-output/ (honor user-configured folder)Validate the new skill:
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-builder/scripts/validate-skill.sh \
${CLAUDE_PLUGIN_ROOT}/skills/<skill-name>/SKILL.md
Fix all errors; review all warnings before declaring done.
Run the validator directly against any SKILL.md path:
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-builder/scripts/validate-skill.sh <path-to-SKILL.md>
The validator checks:
name field present and lowercase-hyphendescription field present with trigger phrasesallowed-tools field present (warns if missing)allowed-tools or bodyUse when you want an empty directory skeleton without generating content:
bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-builder/scripts/scaffold-skill.sh <skill-name>
Then fill SKILL.md manually using the template as a guide.
Every skill created by this builder MUST comply with the Scope Law:
The validate-skill.sh script enforces this automatically by flagging forbidden terms.
When designing skills, track the BMAD Method conventions:
| Convention | Rule |
|------------|------|
| Scale Tracks | Quick Flow / BMad Method / Enterprise — user confirms interactively |
| Story size | ~2-8h, one dev-day max; split if larger |
| Delivery tracking | Stories remaining / completion rate — NO Fibonacci points, velocity, or burndown |
| Story name | {epic}.{story}.{slug}.story.md |
| Story status | backlog → ready-for-dev → in-progress → review → done |
| Decision log | Decisions thread through decision-log.md |
| Project constitution | project-context.md loaded across skills |
| Three intents | Create / Update / Validate where applicable |
| Script | Purpose |
|--------|---------|
| scripts/scaffold-skill.sh <name> | Creates skills/<name>/ with subdirs and starter SKILL.md |
| scripts/validate-skill.sh <SKILL.md> | Validates frontmatter, scope, size, and attribution footer |
Invoke with the ${CLAUDE_PLUGIN_ROOT} prefix shown above. The orchestrator marks scripts executable; you may also run them via bash.
| Template | Use for |
|----------|---------|
| templates/skill.template.md | Skeleton for a new planning/orchestration SKILL.md |
| templates/document.template.md | Generic planning document (PRD section, brief, spec section, etc.) |
For creating a full skill package in parallel:
| Agent | Task | Output |
|-------|------|--------|
| Agent 1 | Draft SKILL.md body from gathered requirements | skills/<name>/SKILL.md |
| Agent 2 | Write domain scripts (validators, checklists) | skills/<name>/scripts/ |
| Agent 3 | Write domain templates | skills/<name>/templates/ |
| Agent 4 | Write REFERENCE.md if body exceeds 5K tokens | skills/<name>/REFERENCE.md |
Coordination: gather requirements first (sequential), write spec to bmad-output/skill-spec.md, then fan out. Main context validates all outputs with validate-skill.sh and assembles the final package.
${CLAUDE_PLUGIN_ROOT} for all internal paths — never hardcode ~/.claude or absolute machine paths.bmad-output/ by default.
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-bmb-builder. All methodology credit belongs to the BMAD Code Organization.
testing
Solutioning-phase UX planning skill (optional; activate when the project has a UI). Produces TWO planning documents: DESIGN.md (the visual system — design tokens, color palette, typography, spacing, component specs, WCAG 2.1 AA contract) and EXPERIENCE.md (user journeys, flow diagrams, screen states, error/empty/loading handling). Use when the user says "design the UX", "create UX planning docs", "define the design system", "map the user flows", "UX for this feature", "wireframe the flows", "what are the user journeys", "accessibility design", "WCAG compliance", "design tokens", "responsive design plan", "mobile-first design", or "create DESIGN.md / EXPERIENCE.md". Runs after architecture is drafted and before stories are created. Supports Create / Update / Validate intents.
testing
Quick Flow lightweight technical specification for small-scope work (1-15 stories). Replaces the full PRD + architecture pair when scope is small and requirements are clear. Produces bmad-output/tech-spec.md as the single planning artifact before story creation. Use when the user says: "write a tech spec", "create a technical specification", "I need a tech spec for this feature", "quick spec", "small project spec", "we don't need a full PRD", "just a tech spec", "spec out this change", "document this feature". QUICK FLOW TRACK ONLY (1-15 stories). If scope grows beyond ~15 stories or involves multiple teams / external integrations at scale, stop and redirect to bmad-prd + bmad-architecture instead — those skills are built for that complexity. Supports three intents: Create (new spec), Update (revise an existing tech-spec.md), Validate (review a draft for completeness against BMAD criteria).
tools
Orchestration handoff bridge: emits and maintains sprint-status.yaml as the project's sequencing system-of-record. Orders stories by epic then dependency, assigns parallel-set (wave) membership, and drives the status lifecycle (backlog → ready-for-dev → in-progress → review → done) as a view — never as a metric. Use when the user says "sequence the stories", "build the sprint status", "plan the waves", "create sprint-status.yaml", "assign parallel sets", "order stories by dependency", "what can run in parallel", "set up story sequencing", "initialize sprint tracking", "ready the backlog", or "prepare for dev handoff". Also triggers on "sprint planning" when the project already has epics defined. SCOPE: SEQUENCING AND ORCHESTRATION ONLY. No velocity, no burndown, no committed points, no coverage metrics. Capacity is expressed as wave width (concurrent story count), not points. The final artifact is a ready-for-dev handoff manifest; implementation is delegated to external dev tools.
development
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.