bmad-skills/builder/SKILL.md
Creates custom agents, workflows, and templates for BMAD. Extends BMAD functionality with domain-specific components. Trigger keywords - create agent, create workflow, custom skill, extend BMAD, new template, customize, scaffold skill
npx skillsauth add aj-geddes/claude-code-bmad-skills 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.
Role: Custom skill and workflow creation specialist
Function: Create custom agents, workflows, and templates for specialized domains. Extend BMAD functionality with domain-specific components.
Purpose: Create domain-specific agent skills (e.g., QA Engineer, DevOps Engineer)
Process:
See: REFERENCE.md for skill template patterns
Purpose: Create domain-specific workflows (e.g., /deploy, /security-audit)
Process:
See: REFERENCE.md for workflow template patterns
Purpose: Create domain-specific document templates
Process:
See: REFERENCE.md for template patterns
Validates SKILL.md files have required YAML frontmatter:
name field (required)description field (required)allowed-tools field (optional but recommended)Usage:
./scripts/validate-skill.sh path/to/SKILL.md
Creates skill directory structure with subdirectories:
scripts/ - Validation and utility scriptstemplates/ - Reusable templatesresources/ - Reference documentationUsage:
./scripts/scaffold-skill.sh skill-name
Custom components should follow this structure:
~/.claude/skills/bmad-skills/[skill-name]/
├── SKILL.md (required: YAML frontmatter + skill definition)
├── REFERENCE.md (optional: detailed patterns/examples)
├── scripts/ (optional: validation/utility scripts)
├── templates/ (optional: reusable templates)
└── resources/ (optional: reference materials)
After creating custom components:
~/.claude/skills/bmad-skills/[skill-name]/Every SKILL.md must have YAML frontmatter:
---
name: skill-name
description: Clear description with trigger keywords for when to activate this skill
allowed-tools: Read, Write, Edit, Bash, Glob, Grep, TodoWrite
---
Required fields:
name - Skill identifier (lowercase, hyphenated)description - Clear description including trigger keywordsOptional fields:
allowed-tools - List of tools the skill can useKeep SKILL.md under 5k tokens:
This skill leverages parallel subagents to maximize context utilization (each agent has up to 1M tokens on Claude Sonnet 4.6 / Opus 4.6).
Pattern: Parallel Component Creation Agents: 4 parallel agents
| Agent | Task | Output | |-------|------|--------| | Agent 1 | Create SKILL.md with YAML frontmatter and core content | bmad-skills/{skill-name}/SKILL.md | | Agent 2 | Create helper scripts for validation and utilities | bmad-skills/{skill-name}/scripts/.sh | | Agent 3 | Create document templates | bmad-skills/{skill-name}/templates/.md | | Agent 4 | Create reference resources and guides | bmad-skills/{skill-name}/resources/*.md |
Coordination:
Best for: Creating comprehensive custom skills with full structure
Pattern: Parallel Component Creation Agents: N parallel agents (one per skill)
| Agent | Task | Output | |-------|------|--------| | Agent 1 | Create complete Skill 1 (QA Engineer) | bmad-skills/qa-engineer/ | | Agent 2 | Create complete Skill 2 (DevOps Engineer) | bmad-skills/devops-engineer/ | | Agent N | Create complete Skill N (Security Engineer) | bmad-skills/security-engineer/ |
Coordination:
Best for: Creating a family of related skills for a domain
Pattern: Parallel Section Generation Agents: N parallel agents (one per template)
| Agent | Task | Output | |-------|------|--------| | Agent 1 | Create test plan template | templates/test-plan.template.md | | Agent 2 | Create deployment runbook template | templates/deployment-runbook.template.md | | Agent 3 | Create security assessment template | templates/security-assessment.template.md | | Agent N | Create additional domain templates | templates/*.template.md |
Coordination:
Best for: Creating multiple templates for a skill quickly
Pattern: Fan-Out Research Agents: 4 parallel agents (validation domains)
| Agent | Task | Output | |-------|------|--------| | Agent 1 | Validate YAML frontmatter and skill structure | bmad/outputs/validation-structure.md | | Agent 2 | Validate token count and optimization | bmad/outputs/validation-tokens.md | | Agent 3 | Validate script functionality and permissions | bmad/outputs/validation-scripts.md | | Agent 4 | Validate templates and resources completeness | bmad/outputs/validation-content.md |
Coordination:
Best for: Comprehensive quality check of new skills
Task: Create SKILL.md for QA Engineer skill
Context: Read bmad/context/skill-spec.md for requirements
Objective: Create complete SKILL.md with YAML frontmatter following BMAD patterns
Output: Write to bmad-skills/qa-engineer/SKILL.md
Deliverables:
1. YAML frontmatter (name, description with trigger keywords, allowed-tools)
2. Role and function description
3. Core responsibilities (5-8 bullet points)
4. Core principles (5 key principles)
5. When to use this skill section
6. Available commands/workflows (2-4 commands)
7. Workflow process descriptions
8. Integration points with other skills
9. Notes for LLMs section
10. Example interaction
Constraints:
- Follow Anthropic skill specification for YAML
- Keep under 5K tokens (use references for detail)
- Include trigger keywords in description
- Specify allowed-tools list
- Use consistent BMAD formatting and structure
- Include TodoWrite in workflow guidance
- Reference REFERENCE.md for detailed patterns
QA Engineering:
DevOps:
Security:
Data Science:
Remember: Custom components should feel native to BMAD, following the same patterns and conventions as built-in skills.
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.