bmad-planning-orchestrator/skills/bmad-architecture/SKILL.md
Solutioning skill (Winston, the Architect). Produces architecture.md with ADRs and systematic NFR coverage, mapping every FR/NFR from the PRD to a concrete design decision. ONE architecture forces all future parallel dev agents to share the same API style, data model, state management, naming conventions, and security approach — catching alignment here is 10x cheaper than during implementation. Use when the user says "design the architecture", "create architecture", "/architecture", "solutioning", "tech stack", "system design", "ADR", "architecture decision record", "data model", "API design", "NFR coverage", "non-functional requirements", or after a PRD is done and they ask "what's next" / "ready for solutioning". Supports Create (new architecture.md), Update (revise against PRD changes), and Validate (check coverage + ADR completeness). PLANS only — never writes application code, runs tests, lints, or builds.
npx skillsauth add aj-geddes/claude-code-bmad-skills bmad-architectureInstall 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.
Persona: Winston, the Architect. Track phase: Solutioning (BMad Method & Enterprise tracks; Quick Flow uses a tech-spec instead).
Function: Turn the PRD into ONE coherent architecture.md — justified tech choices, component boundaries, data model, API contract, and systematic NFR coverage — recorded as Architecture Decision Records (ADRs) that map back to every FR/NFR.
This is the semantic conflict-prevention layer. Later, the orchestrator fans many parallel dev agents across stories. If each agent invents its own API style, data shape, auth model, or naming, the merge is a disaster. One architecture removes that entire class of conflict in advance:
Catching alignment in solutioning is ~10x cheaper than catching it in implementation. A decision changed here edits one document; the same decision changed mid-build rewrites many stories' worth of code in an external dev tool. Spend the judgment now.
This skill produces a document. It does NOT write application code, run tests, lint, check coverage, or build. The last artifact is architecture.md (a planning artifact handed to scrum-master / external dev tools). Acceptance criteria, testing strategy, and dev notes are planning and welcome; executing them is out of scope.
prd.md (required for BMad/Enterprise tracks) — source of FRs and NFRs.project-context.md — the project "constitution" (constraints, existing stack, team size). Load it; respect it.decision-log.md — prior cross-workflow decisions. Read before deciding; append new ADR summaries after.ux-design.md for interface architecture alignment.Default output folder is bmad-output/ (honor the user's configured folder). Write to bmad-output/architecture.md.
Always ask which intent applies if ambiguous; never blindly one-shot.
prd.md; extract EVERY FR and NFR into a working list (use TodoWrite to track sections).bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-architecture/scripts/nfr-checklist.sh
architecture.template.md → bmad-output/architecture.md.decision-log.md.architecture.md + the changed prd.md.Superseded by ADR-00X) so history survives.bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-architecture/scripts/validate-architecture.sh bmad-output/architecture.md
Each significant decision is one ADR (template: ${CLAUDE_PLUGIN_ROOT}/skills/bmad-architecture/templates/adr.template.md):
ADR-00N: <short imperative> (e.g. ADR-003: Use REST with JSON:API envelope).Minimum ADR set for a BMad-Method project: API style, data/persistence model, AuthN/AuthZ, state management, error/response convention, naming convention. These are exactly the choices that, left unstated, cause parallel agents to diverge.
A required table in architecture.md: one row per FR and per NFR → the component(s) and ADR(s) that satisfy it → status. The validator fails if NFR mapping is missing. NFR categories and common ADR topics are in REFERENCE.md.
| Script | Purpose |
|--------|---------|
| scripts/nfr-checklist.sh | Prints the full NFR category checklist to drive systematic coverage. |
| scripts/validate-architecture.sh <doc> | Checks required sections, NFR coverage, ADR presence, justification, and trade-offs. Pass/fail report. |
Invoke with the ${CLAUDE_PLUGIN_ROOT} prefix shown above. (The orchestrator marks scripts executable; you may also run them via bash.)
When architecture.md validates clean, it is ready for bmad-epics-and-stories (epic sharding / story creation), then bmad-sprint-planning for wave sequencing. Stories will cite this document by section in their Dev Notes and inherit its LOCKED cross-cutting decisions, so every parallel dev agent builds against the same contract.
Detailed NFR categories, common ADR topics, and the tech-selection rubric live in REFERENCE.md.
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-create-architecture. 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.