Agent skill · product strategy · aj-geddes
bmad-architecture
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.
Why this skill is useful
Generates a comprehensive architecture document with ADRs and systematic NFR coverage, providing a structured approach to design decisions that the AI cannot infer on its own.
What it needs
Requires bash installed locally. About 4k tokens when loaded. Last updated 2026-06-20. 471 stars on the source repository.
What this skill does
BMAD Architecture (Solutioning) 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. Why this skill is load-bearing 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: API style — REST vs GraphQL vs gRPC, decided once. Data model — entities, relationships, ownership, decided once. State management — server/client state strategy, decided once. Naming & conventions — casing, resource naming, error shape, decided once. Security approach — authn/authz model, secrets, decided once. 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. Scope (PLAN, never build) 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. Inputs 1. prd.md (required for BMad/Enterprise tracks) — source of FRs and NFRs. 2. project-context.md — the project "constitution" (constraints, existing stack, team size). Load it; respect it. 3. decision-log.md — prior cross-workflow decisions. Read before deciding; append new ADR summaries after. 4. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aj-geddes/bmad-architecture