Architecture Decision Record

This is a solid implementation of the Nygard ADR format with templates and guardrails to keep you honest about tradeoffs. It comes with a script that auto-generates numbered ADRs with metadata filled in, plus three interrogation rules that force you to think about scalability, reliability, and security before you commit to a decision. The best practices section is worth reading even if you've written ADRs before, especially the bit about keeping them immutable and documenting why you rejected alternatives. Good for teams that need architectural memory without turning every decision into a 20-page design doc.

skills.sh installs: 1.5K
GitHub stars: 301
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add yonatangross/orchestkit --skill architecture-decision-record --agent claude-code

Installs into .claude/skills of the current project.

Files

Architecture Decision Records

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.

Overview

Making significant technology choices (databases, frameworks, cloud providers)
Designing system architecture or major components
Establishing patterns or conventions for the team
Evaluating trade-offs between multiple approaches
Documenting decisions that will impact future development

Why ADRs Matter

ADRs serve as architectural memory for your team:

Context Preservation: Capture why decisions were made, not just what was decided
Onboarding: Help new team members understand architectural rationale
Prevent Revisiting: Avoid endless debates about settled decisions
Track Evolution: See how architecture evolved over time
Accountability: Clear ownership and decision timeline