| name | architecture-decision-records |
| description | 在 Claude Code 会话期间捕获架构决策为结构化 ADR。自动检测决策时刻，记录上下文、考虑的替代方案和理由。维护 ADR 日志，以便未来的开发人员理解代码库为何采用这种形状。 |
| origin | ECC |
架构决策记录
在编码过程中捕获架构决策。不再让决策仅存在于 Slack 线程、PR 评论或某人的记忆中，此技能生成与代码共存的结构化 ADR 文档。
何时激活
- 用户明确说"让我们记录这个决策"或"ADR 这个"
- 用户在重要替代方案之间做出选择（框架、库、模式、数据库、API 设计）
- 用户说"我们决定..."或"我们做 X 而不是 Y 的原因是..."
- 用户问"为什么我们选择了 X？"（读取现有 ADR）
- 在规划阶段讨论架构权衡时
ADR 格式
使用 Michael Nygaard 提出的轻量级 ADR 格式，针对 AI 辅助开发进行调整：
# ADR-NNNN: [决策标题]
**Date**: YYYY-MM-DD
**Status**: proposed | accepted | deprecated | superseded by ADR-NNNN
**Deciders**: [参与人员]
## Context
促使我们做出此决策或更改的问题是什么？
[2-5 句话描述情况、约束和影响因素]
## Decision
我们提议和/或正在做的更改是什么？
[1-3 句话清楚地陈述决策]
## Alternatives Considered
### Alternative 1: [名称]
- **Pros**: [好处]
- **Cons**: [缺点]
- **Why not**: [拒绝此选项的具体原因]
### Alternative 2: [名称]
- **Pros**: [好处]
- **Cons**: [缺点]
- **Why not**: [拒绝此选项的具体原因]
## Consequences
由于此更改，什么变得更容易或更困难？
### Positive
- [好处 1]
- [好处 2]
### Negative
- [权衡 1]
- [权衡 2]
### Risks
- [风险和缓解措施]
工作流
捕获新的 ADR
当检测到决策时刻时：
- 初始化（仅首次） — 如果
docs/adr/ 不存在，在创建目录之前请求用户确认，创建一个带有索引表头的 README.md（见下文 ADR 索引格式）和用于手动使用的空白 template.md。不要在未经明确同意的情况下创建文件。
- 识别决策 — 提取正在做出的核心架构选择
- 收集上下文 — 什么问题促成了此决策？存在什么约束？
- 记录替代方案 — 还考虑了哪些其他选项？为何拒绝它们？
- 陈述后果 — 有哪些权衡？什么变得更容易/更难？
- 分配编号 — 扫描
docs/adr/ 中的现有 ADR 并递增
- 确认并写入 — 向用户展示 ADR 草稿以供审查。只有在明确批准后才写入
docs/adr/NNNN-decision-title.md。如果用户拒绝，则丢弃草稿而不写入任何文件。
- 更新索引 — 追加到
docs/adr/README.md
读取现有 ADR
当用户问"为什么我们选择了 X？"时：
- 检查
docs/adr/ 是否存在 — 如果不存在，响应："此项目中未找到 ADR。您想要开始记录架构决策吗？"
- 如果存在，扫描
docs/adr/README.md 索引以查找相关条目
- 读取匹配的 ADR 文件并展示 Context 和 Decision 部分
- 如果未找到匹配项，响应："未找到该决策的 ADR。您想要现在记录一个吗？"
ADR 目录结构
docs/
└── adr/
├── README.md ← 所有 ADR 的索引
├── 0001-use-nextjs.md
├── 0002-postgres-over-mongo.md
├── 0003-rest-over-graphql.md
└── template.md ← 用于手动使用的空白模板
ADR 索引格式
# 架构决策记录
| ADR | 标题 | 状态 | 日期 |
|-----|-------|--------|------|
| [0001](0001-use-nextjs.md) | 使用 Next.js 作为前端框架 | accepted | 2026-01-15 |
| [0002](0002-postgres-over-mongo.md) | PostgreSQL over MongoDB 作为主数据存储 | accepted | 2026-01-20 |
| [0003](0003-rest-over-graphql.md) | REST API over GraphQL | accepted | 2026-02-01 |
决策检测信号
注意对话中的这些模式，它们表示架构决策：
明确信号
- "让我们使用 X"
- "我们应该使用 X 而不是 Y"
- "这个权衡是值得的，因为..."
- "将此记录为 ADR"
隐式信号（建议记录 ADR —— 不要在未经用户确认的情况下自动创建）
- 比较两个框架或库并得出结论
- 做出带有陈述理由的数据库模式设计选择
- 在架构模式之间进行选择（单体 vs 微服务、REST vs GraphQL）
- 决定认证/授权策略
- 在评估替代方案后选择部署基础设施
什么是好的 ADR
做
- 具体 — "使用 Prisma ORM" 而不是"使用一个 ORM"
- 记录原因 — 理由比内容更重要
- 包括被拒绝的替代方案 — 未来的开发人员需要知道考虑了什么
- 诚实地陈述后果 — 每个决策都有权衡
- 保持简短 — ADR 应该在 2 分钟内可读
- 使用现在时态 — "我们使用 X" 而不是"我们将使用 X"
不做
- 记录琐碎的决策 — 变量命名或格式选择不需要 ADR
- 写长文 — 如果上下文部分超过 10 行，就太长了
- 省略替代方案 — "我们就这样选了"不是有效的理由
- 在不标记的情况下回填 — 如果记录过去的决策，注明原始日期
- 让 ADR 过时 —— 被取代的决策应该引用其替换者
ADR 生命周期
proposed → accepted → [deprecated | superseded by ADR-NNNN]
- proposed: 决策正在讨论中，尚未承诺
- accepted: 决策生效并正在遵循
- deprecated: 决策不再相关（例如，功能已移除）
- superseded: 较新的 ADR 替换了此决策（始终链接替换者）
值得记录的决策类别
| 类别 | 示例 |
|---|
| 技术选择 | 框架、语言、数据库、云提供商 |
| 架构模式 | 单体 vs 微服务、事件驱动、CQRS |
| API 设计 | REST vs GraphQL、版本策略、认证机制 |
| 数据建模 | 模式设计、规范化决策、缓存策略 |
| 基础设施 | 部署模式、CI/CD 管道、监控栈 |
| 安全 | 认证策略、加密方法、密钥管理 |
| 测试 | 测试框架、覆盖率目标、E2E vs 集成平衡 |
| 流程 | 分支策略、审查流程、发布节奏 |
与其他技能的集成
- Planner agent: 当规划者提出架构更改时，建议创建 ADR
- Code reviewer agent: 标记引入架构更改而没有相应 ADR 的 PR
