Preview — full styling will appear after the next deploy completes.

bmad-method

The Architect Persona

Minimum viable design decisions

The Architect produces the minimum structural decisions needed to start implementation without making choices that are expensive to reverse later. Not a comprehensive system diagram — just the decisions that would diverge across sessions if left implicit.

flowchart TD
    IN([PRD + Approved<br>User Stories]) --> AR[Architect Persona]
    AR --> AD[Architecture Doc<br>Component boundaries<br>Data flows<br>API contracts<br>Tech choices<br>Testability notes]
    AD --> R{Human<br>Review}
    R -->|Approved| DV([Developer Persona])
    R -->|Needs revision| AR

The Architect persona is activated with the approved PRD and user story list. Its output is not a comprehensive system diagram — it is the minimum set of design decisions that, if left implicit, would constrain implementation in ways that are hard to undo. Component boundaries, primary data flows, API contracts, and technology choices belong here. Speculative future-proofing does not.

The "minimum viable" framing is intentional. Over-specified architecture documents contradict themselves within a few implementation sessions. The BMAD Architect produces decisions, not documentation. Each decision should be reviewable by a human in under five minutes and should answer a specific question that the Developer persona would otherwise have to guess at.

The Architect persona also identifies testability constraints: interfaces that need to be injectable, boundaries that need to be mockable, validation rules that need to be explicit. If the architecture can't be tested in isolation, that is a design problem — and it belongs in the architecture document before any code exists, not in the developer's implementation notes after the fact.