bmad-planning-orchestrator/skills/bmad-ux/SKILL.md
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.
npx skillsauth add aj-geddes/claude-code-bmad-skills bmad-uxInstall 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.
Produces the two-document UX contract that downstream story authors and the external dev tool rely on. This is a planning skill. It produces specifications, not code.
Under bmad-output/ (or the folder in config.yaml):
bmad-output/
├── DESIGN.md # Visual system: tokens, components, accessibility contract
└── EXPERIENCE.md # Journeys, flows, states, error/empty/loading specs
Both documents are locked planning artifacts. The external dev tool may read them
but must not edit them. All design decisions should be recorded in decision-log.md.
decision-log.md explaining what changed and why.Before drafting, read (in order):
bmad-output/config.yaml — project name, track, output folder.bmad-output/project-context.md — user personas, platform targets, constraints.bmad-output/prd.md (if present) — feature list, user stories, acceptance criteria.bmad-output/architecture.md (if present) — component boundaries, API contracts.If any of these are missing, ask the user for the key inputs before proceeding.
Use ${CLAUDE_PLUGIN_ROOT}/skills/bmad-ux/templates/design.template.md.
The document covers:
1. Design Tokens
Commit to concrete values. Placeholders are not acceptable for tokens.
2. Component Specs
For each component: visual defaults, all interaction states (default / hover / focus / active / disabled / loading / error / success), responsive behavior, and accessibility annotations (ARIA roles, aria-label placement, focus-trap rules, min touch target 44×44px on mobile).
Core components to specify: buttons (primary / secondary / destructive), text inputs, select / checkbox / radio, cards, modals, navigation (desktop + mobile hamburger), loading/skeleton states, error banners.
3. WCAG 2.1 AA Contract
Enumerate the concrete accessibility requirements the visual system guarantees:
Run the checklist to produce the contract summary:
bash "${CLAUDE_PLUGIN_ROOT}/skills/bmad-ux/scripts/wcag-checklist.sh"
Check specific color pairs with:
python "${CLAUDE_PLUGIN_ROOT}/skills/bmad-ux/scripts/contrast-check.py" #foreground #background
Verify responsive breakpoint rules:
bash "${CLAUDE_PLUGIN_ROOT}/skills/bmad-ux/scripts/responsive-breakpoints.sh"
Use ${CLAUDE_PLUGIN_ROOT}/skills/bmad-ux/templates/experience.template.md.
The document covers:
1. User Journeys
One section per major journey (onboarding, core workflow, settings, error recovery, etc.). Each journey: goal, persona, entry points, happy-path flow diagram (ASCII or bullet steps), estimated time, and drop-off risk notes.
2. Screen / State Inventory
For every screen or major view: purpose, layout wireframe (ASCII encouraged), component hierarchy, and all named states:
aria-live="polite" announced.3. Decision Points & Alternative Paths
For each journey, map the branch points (validation failure, auth required, network error, timeout, etc.). Each branch: trigger, display, and recovery path.
4. Interaction & Animation Notes
Timing and easing for transitions. Respect prefers-reduced-motion. Note which
animations are decorative vs. meaningful.
For projects with more than four major journeys, fan out parallel subagents:
| Agent | Task | Output file |
|-------|------|-------------|
| Agent 1 | Design tokens + color/contrast pairs → DESIGN.md §1 | bmad-output/ux-tokens-draft.md |
| Agent 2 | Core component specs → DESIGN.md §2 | bmad-output/ux-components-draft.md |
| Agent 3 | WCAG contract + a11y annotations | bmad-output/ux-a11y-draft.md |
| Agent N | One major user journey + screen states | bmad-output/ux-journey-N-draft.md |
Write shared context to bmad-output/ux-shared-context.md (personas, brand intent,
breakpoints) before launching agents. The main context assembles the drafts into the
two final documents and runs the WCAG checklist across all screens.
Example subagent prompt:
Task: Design the [journey name] user flow with full state coverage.
Context: Read bmad-output/ux-shared-context.md for personas, tokens, and component patterns.
Objective: Produce the [journey name] section of EXPERIENCE.md covering: entry points,
happy-path flow diagram, all screen states (loading/empty/error/success), decision
branch map, and accessibility annotations.
Output: Write to bmad-output/ux-journey-[name]-draft.md.
Constraints:
- Follow design tokens from context (colors, spacing, typography).
- WCAG 2.1 AA compliance: 4.5:1 contrast, keyboard accessible, 44px touch targets.
- Design mobile-first (320px), then scale to tablet and desktop.
- Specify all interaction states per component.
- No application code — planning specifications only.
decision-log.md.See REFERENCE.md for design pattern library, full breakpoint reference, and
component state matrix.
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-ux-designer. All methodology credit belongs to the BMAD Code Organization.
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.
development
Conducts market, competitive, domain, and technical research using live web sources, producing a cited research-report.md to inform BMAD planning decisions. Use when the user says: - "research [topic/market/technology]" - "competitive analysis" or "who are the competitors" - "market size" or "market landscape" - "technical research" or "evaluate [technology/framework]" - "domain research" or "industry analysis" - "what does the market look like" - "find out about [technology/space]" - "I need research before we plan" - "gather information on [topic]" Supports three modes: Create (new research), Update (refresh existing report with new sources), Validate (cross-check claims in an existing report against live sources). Output lands in bmad-output/ as a cited research-report.md ready for downstream planning skills (business-analyst, product-manager, system-architect).