mcpField
A
adr

adr

github.com/ncklrs开发53138 次安装35 周前更新
代码仓库

关于 adr

用于创建、审查和维护架构决策记录（ADR）的技能。它通过准备度评估、MADR 起草、质量检查和决策日志管理，引导团队完成 ADR 生命周期。

主要功能

  1. 01使用 START 检查决策准备度
  2. 02生成 MADR 模板
  3. 03审查草稿并识别反模式
  4. 04使用 ECADR 检查完整性
  5. 05提供 ADR 日志生命周期指导

适用场景

  1. 01评估架构决策是否适合记录
  2. 02使用 MADR 模板起草 ADR
  3. 03检查 ADR 的完整性与质量
  4. 04维护被取代决策的日志

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/ncklrs/startup-os-skills --skill adr

安装后在 Claude Code 中输入/adr确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

metadata.json
rules/
_sections.md
completion-ecadr-criteria.md
completion-validation.md
creation-anti-patterns.md
creation-madr-template.md
creation-writing-principles.md
lifecycle-management.md
readiness-architectural-significance.md
readiness-start-criteria.md

详细介绍

架构决策记录

基于 Olaf Zimmermann 的研究和 MADR（Markdown 架构决策记录）方法论，提供创建和管理架构决策记录的专业指导。

此技能的工作方式

调用此技能后，它会引导你完成 ADR 的整个生命周期：

  1. 就绪度评估——评估一项决策是否已准备好记录（START 标准）
  2. 创建——使用 MADR 模板编写结构良好的 ADR，并避免反模式
  3. 质量评估——使用 ECADR「完成定义」标准检查完整性
  4. 生命周期管理——维护 ADR 日志、取代过时记录并跟踪决策状态

核心理念

“不要过早做出决策，这会损害灵活性；但也不要太晚做出决策。”

ADR 是决策日志，而不是蓝图或政策。它们记录架构上具有重要意义的选择背后的理由：问题背景、考虑过的替代方案、采用的标准以及接受的后果。优秀的 ADR 是权衡利弊的执行摘要，而不是为预先确定的结果推销。

何时使用此技能

  • 为架构决策创建新的 ADR
  • 评估一项决策是否已准备好记录
  • 检查现有 ADR 的完整性和质量
  • 为项目编写或定制 MADR 模板
  • 评估某项需求在架构上是否具有重要意义
  • 管理 ADR 日志（取代、弃用、关联决策）
  • 培训团队掌握 ADR 最佳实践

命令模式

参数操作
create逐步交互式地创建新的 ADR
review根据质量标准评估现有 ADR
check-ready使用 START 标准评估决策就绪度
check-done使用 ECADR 标准评估 ADR 完整性
template输出可直接填写的空白 MADR 模板
list协助整理和维护 ADR 日志
(无参数)根据上下文提供一般 ADR 指导

MADR 模板（快速参考）

# ADR-NNNN: [Short Title Describing Decision]

## Status
[proposed | accepted | deprecated | superseded by ADR-XXXX]

## Date
YYYY-MM-DD

## Decision Makers
[Who made or approved this decision]

## Context and Problem Statement
[1-3 paragraphs: What is the issue? Why does it matter?
Frame as a question when possible.]

## Decision Drivers
- [Driver 1: quality attribute, business constraint, or technical concern]
- [Driver 2]
- [Driver 3]

## Considered Options
1. [Option A — the chosen option]
2. [Option B]
3. [Option C]

## Decision Outcome
Chosen option: "[Option A]", because [justification referencing decision drivers].

### Consequences
- Good, because [positive consequence]
- Good, because [another benefit]
- Bad, because [accepted tradeoff]
- Bad, because [known limitation]

## Pros and Cons of Options

### Option A
- Good, because [advantage]
- Bad, because [disadvantage]

### Option B
- Good, because [advantage]
- Bad, because [disadvantage]

### Option C
- Good, because [advantage]
- Bad, because [disadvantage]

## Validation
[How will we verify this decision works? Code review, design review,
architectural fitness function, spike, etc.]

## More Information
[Links to related ADRs, RFCs, spikes, or external references.
Note confidence level and planned review date.]

关键框架

START——就绪定义

编写 ADR 前，确认以下五项标准：

  • S：利益相关者已明确且可联系
  • T：时机已到最负责任的时刻
  • A：已确定替代方案（至少两个）
  • R：已记录需求和背景
  • T：已选定并实例化模板
ECADR——完成定义

将 ADR 标记为已接受前，确认以下五项标准：

  • E：有证据表明设计可行
  • C：已应用标准比较至少两个替代方案
  • A：相关利益相关者已达成一致
  • D：已记录并分享文档
  • R：已安排实施和评审计划
ASR 测试——架构重要性

符合以下标准的需求需要编写 ADR：

  • 对业务有重大影响或风险
  • 涉及关键利益相关者的关注事项
  • 服务质量偏离当前架构
  • 外部依赖不可预测或不可控
  • 影响多个组件的横切关注点
  • 团队首次实施此类方案
  • 过去曾因此类问题产生麻烦

此技能提供的内容

  1. 使用 START 标准和检查清单进行就绪度评估
  2. 生成 MADR 模板（完整版和精简版）
  3. 检测草稿 ADR 中的反模式（已知反模式共 11 种）
  4. 使用 ECADR 完成定义评估质量
  5. 评估架构重要性，帮助确定决策优先级
  6. 提供生命周期指导，帮助长期维护 ADR 日志

评论

支持 Markdown