Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.
78
66%
Does it follow best practices?
Impact
99%
1.45xAverage score across 3 eval scenarios
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/documentation-generation/skills/architecture-decision-records/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a solid description with excellent completeness (explicit 'Use when' clause) and strong distinctiveness for a well-defined niche. The trigger terms cover the natural vocabulary users would employ. The main weakness is that the specific capabilities could be more concrete—listing actions like 'create ADR templates, update decision statuses, link superseded records' would strengthen it.
Suggestions
Add more specific concrete actions beyond 'write and maintain', such as 'create ADR templates, update decision statuses, link superseded records, format context/decision/consequences sections'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (ADRs/technical decision documentation) and some actions ('write and maintain', 'documenting', 'reviewing', 'establishing decision processes'), but doesn't list specific concrete actions like creating templates, updating statuses, linking related decisions, or formatting sections. | 2 / 3 |
Completeness | Clearly answers both 'what' (write and maintain ADRs following best practices) and 'when' (explicit 'Use when' clause covering documenting decisions, reviewing past choices, and establishing processes). | 3 / 3 |
Trigger Term Quality | Includes strong natural trigger terms: 'Architecture Decision Records', 'ADRs', 'technical decisions', 'architectural choices', 'decision documentation', 'decision processes'. These cover the main ways users would refer to this topic. | 3 / 3 |
Distinctiveness Conflict Risk | ADRs are a very specific niche within documentation. The terms 'Architecture Decision Records', 'ADRs', and 'architectural choices' are distinct and unlikely to conflict with general documentation or coding skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill is highly actionable with excellent concrete templates and examples, but is severely bloated for a SKILL.md file. It reads more like a comprehensive reference guide than a concise skill instruction, explaining concepts Claude already understands and inlining content that should be split across multiple files. The workflow for actually creating an ADR could be more clearly sequenced as a primary path.
Suggestions
Reduce to ~50-80 lines by keeping one primary template inline and moving the other 4 templates to separate referenced files (e.g., templates/lightweight.md, templates/y-statement.md).
Remove the 'Core Concepts' section entirely — Claude knows what ADRs are, when to write them, and their lifecycle states.
Add a clear top-level workflow: 1. Choose template → 2. Fill sections → 3. Run review checklist → 4. Submit PR → 5. Update index, as the primary sequential guide.
Move the review checklist, best practices, and adr-tools commands into a separate REFERENCE.md file linked from the main skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~300+ lines. Explains basic concepts Claude already knows (what an ADR is, when to write one, lifecycle states). Includes 5 full template examples with extensive fictional content that could be drastically condensed. The 'Core Concepts' section is unnecessary padding. | 1 / 3 |
Actionability | Provides fully concrete, copy-paste ready templates with realistic examples, executable bash commands for adr-tools, specific directory structures, and detailed checklists. Every section contains actionable content rather than abstract descriptions. | 3 / 3 |
Workflow Clarity | The review process checklist and migration plan in Template 4 show good sequencing. However, the overall workflow for creating an ADR is scattered across sections rather than presented as a clear sequential process with validation checkpoints. The 'Creating a New ADR' steps are buried in the index example. | 2 / 3 |
Progressive Disclosure | Monolithic wall of content with no references to external files. Five full templates are inlined when they should be separate files (e.g., templates/standard.md, templates/lightweight.md). No bundle files exist to offload this content, and the skill doesn't organize for progressive discovery. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
34632bc
Table of Contents
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.