用途：从已批准的 PRD 与产品方向出发，撰写整系统架构文档，使新工程师能理解系统结构及其重大决策原因，并让单个功能的技术设计能在其中定位。
主要能力：从架构文档模板工具获取章节结构、从 ADR 模板工具获取决策记录形态；按方法填充各节——先划边界（含/不含及归属、参与者、外部依赖），识别干系人及其关注点并确保每项被某节回应，每个组件单一职责，拓扑中每条箭头标注协议与方向且图与叙述同步，每个集成边界写明失败语义，重大技术选型给出驱动因素与被放弃的替代方案，每个 NFR 目标给出实现机制，把可观测性作为系统级关注点，并点明质量属性权衡。关键决策以独立、可链接的 ADR 文件记录，文档只保留索引。
使用方式：先读取调用方注入的 capability_record 作为范围硬约束；从模板工具取结构；读取 PRD 与方向并补齐知识缺口；用深度研究能力将选择建立在既有实践上；按各节方法填充；每个重大决策写成独立 ADR（Status/Context/Decision/Alternatives/Consequences），一文件一决策，被接受的 ADR 不可改写，变更以新 ADR 取代旧者；修订时按增量就地编辑、更新版本与变更日志，并标记下游受影响的 TDD、api-spec、data-model、部署文档。
适用场景：从已批准 PRD 撰写新架构文档；把单薄的产品方向扩展为整系统架构；将研究充分、决策完整的内容填入模板并链接 ADR。
限制：不用于评审架构文档（用 reviewing-architecture-doc）、单个功能实现设计（用技术设计技能）、逐端点 API 规格或逐表数据模型；不设定 NFR 目标（PRD 负责）；不枚举每个端点或表；不得编造拓扑、基准、厂商声明或理由，未知应标为假设；无模板时需获取或回退到规范章节集；无研究能力时不得虚构，应标记为待验证假设。