菜单
ADR templates in the Nygard format with context, decision, consequences, and alternatives. Use when writing ADRs, recording an architectural decision, or evaluating options.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/yonatangross/orchestkit --skill architecture-decision-record命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
基于 SOC 职业分类
| name | architecture-decision-record |
| license | MIT |
| compatibility | Claude Code 2.1.220+. |
| description | ADR templates in the Nygard format with context, decision, consequences, and alternatives. Use when writing ADRs, recording an architectural decision, or evaluating options. |
| version | 2.0.0 |
| author | OrchestKit |
| tags | ["architecture","documentation","decision-making","backend"] |
| context | fork |
| agent | backend-system-architect |
| user-invocable | false |
| complexity | medium |
| persuasion-type | guidance |
| metadata | {"category":"document-asset-creation"} |
| allowed-tools | ["Read","Glob","Grep","WebFetch","WebSearch"] |
Architecture Decision Records (ADRs) are lightweight documents that capture important architectural decisions along with their context and consequences. This skill provides templates, examples, and best practices for creating and maintaining ADRs in your projects.
ADRs serve as architectural memory for your team:
Each ADR should follow this structure:
Format: ADR-####: [Decision Title]
Example: ADR-0001: Adopt Microservices Architecture
Current state of the decision:
What to include:
What to include:
Be specific and actionable:
What to include:
Document at least 2 alternatives:
For each alternative, explain:
Links to relevant resources:
Proposed → Accepted → [Implemented] → (Eventually) Superseded/Deprecated
↓
Rejected
Once accepted, don't edit ADRs. Create new ADRs that supersede old ones.
ADRs are historical records written as if the decision is being made now.
ADRs capture decisions, not implementation details.
Get input from relevant stakeholders before accepting.
Use 4-digit zero-padded numbers: ADR-0001, ADR-0002, etc. Maintain a single sequence even with multiple projects.
Keep ADRs in version control alongside code:
/docs/adr/ or /architecture/decisions//create-adr [number] [title] to generate ADR with auto-filled contextassets/adr-template.mdscripts/create-adr.md - Dynamic ADR generator with auto-filled context
/create-adr [number] [title]$ARGUMENTS and !command for dynamic contextassets/adr-template.md - Static template for manual use
| Rule | Impact | What It Covers |
|---|---|---|
| interrogation-scalability | HIGH | Scale questions, data volume, growth projections |
| interrogation-reliability | HIGH | Data patterns, UX impact, coherence validation |
| interrogation-security | HIGH | Access control, tenant isolation, attack surface |
❌ Too Technical: "We'll use Kubernetes with these 50 YAML configs..." ✅ Right Level: "We'll use Kubernetes for container orchestration because..."
❌ Too Vague: "We'll use a better database" ✅ Specific: "We'll use PostgreSQL 15+ for transactional data because..."
❌ No Alternatives: Only documenting the chosen solution ✅ Comparative: Document why alternatives weren't chosen
❌ Missing Consequences: Only listing benefits ✅ Balanced: Honest about costs and trade-offs
❌ No Context: "We decided to use Redis" ✅ Contextual: "Given our 1M+ concurrent users and sub-50ms latency requirement..."
ork:api-design: Use when designing APIs referenced in ADRsork:database-patterns: Use when ADR involves database choicesSkill Version: 2.0.0 Last Updated: 2026-01-08 Maintained by: OrchestKit
Keywords: adr, architecture decision, decision record, document decision Solves:
Keywords: when to write adr, adr lifecycle, adr workflow, adr process, adr review, quantify impact Solves:
Keywords: tradeoff, pros cons, alternatives, comparison, evaluate options Solves:
Keywords: consequence, impact, risk, benefit, outcome Solves:
Chain patterns for multi-phase pipelines: MCP detection, handoff files, checkpoint-resume, worktree agents, CronCreate monitoring. Use when building or debugging a pipeline skill.
OrchestKit doctor for health diagnostics across manifest integrity, hook configuration, skill validation, agent frontmatter, MCP server connectivity, CC version compatibility, and permission rules. Reports issues with severity levels and auto-remediation suggestions. Validates component counts, detects orphaned entries, and checks CC version matrix compliance. Use when diagnosing plugin health, troubleshooting configuration issues, or running pre-release checks.
Inspects the OrchestKit telemetry pipeline for the current project — lists all known telemetry files with write counts, sizes, schema status, growth trend, and orphan detection. Use when verifying the observability pipeline is healthy, debugging a missing writer, or auditing which files have schema locks vs. which are drift-vulnerable. Read-only — never modifies telemetry files.