用途：将已批准的产品需求（PRD）与史诗路线图转化为“决策架构”，向实施团队说明组件结构、技术选择及其理由。
主要能力：识别架构驱动因素（质量属性、约束、集成）；设计组件拓扑、数据流与技术选型，并保持与需求的可追溯性；记录关键决策、被否决方案与缓解策略；生成或更新架构文档；输出风险与决策日志摘要，供干系人查看。
使用方式：在用户询问“How should we build this?”“What's the architecture?”“Tech stack?”“System design?”或提到 architecture、technical decisions、stack 等时自动激活；PRD 与史诗获批（Phase 3）后触发。所需输入包括 prd（最新 PRD 与史诗路线图）、constraints（非功能需求、合规规则、集成）、existing_assets（仓库、现有架构图或技术标准）、project_level（BMAD 规模分级，决定设计深度）。缺失输入须先上报编排器或来源技能。输出为按 assets/decision-architecture-template.md.template 编写的 ARCHITECTURE.md；若有结构化数据，可用 scripts/generate_architecture.py 生成或更新。流程为：用 CHECKLIST.md 校验前置条件并确认规划产物已批准，识别架构驱动因素，设计拓扑与选型，记录决策与替代方案，生成文档，最后按质量清单复核并发布摘要与后续行动。
适用场景：需要正式架构设计的中大型项目，或需明确技术栈与系统设计决策的团队。
限制：PRD 未就绪时不应调用（先用 bmad-product-planning）；已有架构时跳过，直接进入 stories；简单 Level 0-1 项目可能不需要正式架构。出现矛盾或缺口时，应引用具体需求或假设，向 product-requirements、UX 或 discovery-analysis 技能请求澄清，并在记录解决方案前暂缓实施。质量门禁不通过时应停止。