用途
Architecture Decision Records（ADR）用于记录重要的技术决策，让未来的自己或团队成员理解当初为何做出某项选择。当一项决策难以逆转、影响系统多个部分、涉及多个有效方案之间的权衡，或者六个月后会被人质疑时，就应当撰写 ADR。典型例子包括：选择数据库、采用某个框架、更改认证策略、重构 API、添加构建工具。
主要能力
该技能提供了一套结构化的 ADR 模板与工作流程，帮助团队规范地记录决策。模板包含以下部分：
- 标题与编号：如
# ADR-001: Use PostgreSQL for primary database - 状态（Status）：Accepted（已接受）、Proposed（提议中）、Deprecated（已弃用）、Superseded by ADR-XXX（被某 ADR 取代）
- 日期（Date）：如 2026-04-10
- 背景（Context）：描述需要决策的问题或情况，包括约束条件、需求和影响因素
- 备选方案（Options Considered）：列出至少 2-3 个方案，并分别说明优缺点
- 决策（Decision）：说明最终选择了哪个方案以及理由
- 后果（Consequences）：记录该决策带来的影响和需要接受的限制
使用方式
工作流程如下：
- 确定正在做出的决策
- 研究备选方案（至少 2-3 个替代方案）
- 使用模板撰写 ADR
- 与团队评审（通过 PR 或讨论）
- 合并为已接受状态
- 在相关代码注释中引用，例如
// See ADR-001
文件存放在 docs/decisions/（或 adr/）目录下，采用顺序编号命名，例如：
docs/decisions/
├── 001-use-postgresql.md
├── 002-adopt-trpc-over-rest.md
├── 003-switch-to-pnpm.md
└── template.md
适用场景
适用于需要记录技术选型与架构变更的软件团队，尤其是决策影响面广、难以回退、需要长期追溯理由的情况。
限制与注意事项
- ADR 应保持简短，最多 1-2 页
- 使用现在时撰写（如 "We choose X" 而非 "We chose X"）
- 如果决策时忘记撰写，事后补写也是可以的
- 被取代的 ADR 应链接到替代它的新 ADR，而不是删除
- ADR 不是设计文档，它只记录决策本身，而非完整设计
暂未提供的信息
关于该技能的具体安装命令、支持的平台、是否收费及价格等信息，资料中暂未提供。