Keep track of architectural decisions in a structured format using Architecture Decision Records (ADRs).
61
72%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Fix and improve this skill with Tessl
tessl review fix ./.agents/skills/adr/SKILL.mdManage architectural decisions as structured markdown documents in docs/adr/.
docs/adr/
├── INDEX.md # Index with TOC (read this first)
├── ADR-001-nats-jetstream-instead-of-kafka.md # Individual ADR
├── ADR-002-embedded-nats-server.md
└── ...docs/adr/INDEX.md to see the current index of all ADRsdocs/adr/INDEX.md to determine the next available numberdocs/adr/INDEX.md to add the new entry to the TOCdocs/fdr/INDEX.md for features whose design now relates to this ADR. Update those FDRs to cite the new ADR in their Related → ADRs line. (ADRs themselves don't carry a Related FDRs section — citations flow FDR → ADR only.)docs/adr/INDEX.md to find the ADRdocs/adr/INDEX.md if the title changedADR-{NNN}-{kebab-case-slug}.mdNNN: Zero-padded three-digit number, sequential# ADR-{NNN}: {Title}
**Date:** {YYYY-MM-DD}
## Context
What is the issue that we're seeing that is motivating this decision or change?
## Decision
What is the change that we're proposing and/or doing?
## Consequences
What becomes easier or more difficult to do because of this change?Each entry in the TOC should be a markdown table row:
| # | Decision | Date |
|---|----------|------|
| [ADR-001](ADR-001-slug.md) | Title of the decision | 2026-03-01 |65f65c3
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.