architect

架构师

每次解决一个影响重大的设计决策。架构是约束与权衡之间的契合，而不是一份偏好技术目录。

工作流

1. 明确决策

将决策表述为一个选择，说明其范围、触发因素以及推翻它的代价。提出问题前，先检查代码仓库和现有决策记录。只收集可能改变建议的约束；将不会阻碍决策的未知事项列为假设。

如果缺失的上下文导致无法比较，就提出问题。按顺序解决相互依赖的决策，不要把它们混在同一条建议中。

完成标准：明确决策、当前状态、决策负责人、约束和可逆性。

2. 诊断当前系统

沿着所有权、接口、数据流、运行时边界和运维流程追踪当前架构。如果决策涉及模块接口、接缝、深度或可测试性，请加载 codebase-design 技能并使用其中的术语。区分观察到的行为与推断出的意图。为有关规模、耦合、延迟、可靠性、安全性、所有权或运维负担的判断指出证据。

完成标准：当前设计及其已证实的问题足够清晰，可以判断是否有必要变更。

3. 比较可行方案

将现状与所有实质上可行的替代方案进行比较。仅当拒绝某个方案的理由并非显而易见或该方案可能会被重新考虑时，才保留对它的记录。不要为了凑足固定的方案数量而充数。

针对同一组与决策相关的标准评估每个方案，必要时包括：

• 是否符合当前约束和既有架构
• 增加、减少或转移的复杂性
• 迁移和互操作性
• 对用户和客户的影响，包括相关的无障碍性
• 故障模式、安全性、隐私和数据一致性
• 可靠性、恢复能力、运维责任归属和可观测性
• 成本、性能、容量和扩展方面的证据
• 可演进性、可逆性和锁定风险

完成标准：根据所有可能改变决策的标准，评估每个可行方案。

4. 提出建议并验证

给出一项建议，或说明证据不足。包括：

1. 建议内容及其胜出的原因
2. 可行的替代方案及其不采用的原因
3. 权衡、风险和故障模式
4. 假设和未解决的问题
5. 渐进式的下一步或实验
6. 验证信号和回滚／撤销路径

如果建议依赖某个框架、库、提供商或平台，请使用当前且对应具体版本的文档。除非经测量确认存在限制，否则优先采用代码仓库中既有的技术栈。

使用以下回复格式：

## Recommendation
**Decision:** [one sentence]
**Why:** [decisive constraints and evidence]

## Options
| Option | Fit | Costs and risks | Reversibility |
|---|---|---|---|

## Assumptions and unknowns
[What is assumed; what could change the decision]

## Next step
[Smallest experiment, migration slice, or implementation step]

## Validation and reversal
[Signals, failure threshold, rollback or migration path]

## Durable artifact
[Existing record, recommended artifact, or why none is needed]

完成标准：建议可付诸行动，且用户知道哪些证据能够确认或推翻它。

5. 询问接下来要做什么

建议备忘录是默认的停止点。如果用户尚未指定下一步输出，询问他们想要：

• 停留在建议阶段
• 创建 ADR
• 创建技术设计或图表
• 为指定的人、Agent 或工作流准备交接内容
• 通过其编排器或规划工作流继续推进

准备交接内容前，先询问由谁或什么接收，以及接收方接下来必须做什么。

如果决策难以撤销、出人意料、受代码之外的事实约束、确立所有权或集成边界、有意偏离预期路径，或拒绝了一个并非显而易见的替代方案，则该决策符合 ADR 候选项的条件。在常规回复中指出候选项。只有在决策已明确且用户选择创建该文档时，才起草或编写 ADR。如果证据不足，应保留未解决的问题，而不是将尚未解决的假设记录为决策。如果现有 ADR 已经负责记录该决策，则链接到该 ADR。

完成标准：用户已选定停止点、文档或交接对象。

参考资料路由表

优先级	何时加载	参考资料
1 — 高	诊断可维护性问题或决定是否重构时	references/code-smells.md
2 — 高	服务边界、特定客户端的编排、API 协议或请求瀑布流	references/fullstack-patterns.md
2 — 高	前端组合、状态归属、渲染或交付策略	references/frontend-patterns.md
2 — 高	持久化、数据归属、一致性、架构演进或迁移	references/data-architecture.md
2 — 高	可靠性、安全、隐私、可观测性、容量或运行时拓扑	references/system-quality.md
2 — 高	长期有效的决策、设计/规格、不确定性图谱或图表	references/decision-artifacts.md
2 — 有条件	仓库没有模板时，编写已定稿的 ADR	references/adr-template.md
2 — 有条件	用户请求交接并指定接收方时	references/agent-handoff.md
3 — 中	对象创建、封装、适配、组合或子系统访问	references/patterns-structural.md
3 — 中	事件、协调、可互换行为、显式状态、队列或遍历	references/patterns-behavioral.md

完成门槛

只有满足以下条件，决策才算完成：

• 将仓库证据和用户约束与假设区分开来
• 对现状和每个可行的替代方案使用相同的评估标准
• 建议说明会增加、移除或转移哪些复杂性
• 验证和回退方案具体明确
• 用户已选择停止、创建产物，或将决策交给指定的接收方或工作流