CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

architecture-decision-records

Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.

Quality

66%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/architecture-decision-records/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is highly actionable — complete templates, real tooling commands, and useful checklists — but it is token-inefficient, padding ~450 lines with redundant scope guidance, explanations of concepts Claude already knows, and five fully worked exemplars. Splitting templates into reference files and trimming the duplicated guidance would substantially improve it.

Suggestions

Move the five full templates into a references/ directory (e.g. references/templates.md or one file per format) and keep only short skeletons or one exemplar in SKILL.md, linking each explicitly.

Remove the redundant when-to-use material: keep one of the three ("Use this skill when" bullets, the Write/Skip table, or the Limitations restatement) and delete the description echo at the top of the body.

Delete the "What is an ADR?" and lifecycle explanations of concepts Claude already knows, or compress them to a single line, and trim Template 1's fully worked PostgreSQL example to a fillable skeleton.

DimensionReasoningScore

Conciseness

The ~450-line body is noticeably verbose: it repeats the frontmatter description verbatim, explains what an ADR is (Context/Decision/Consequences — concepts Claude already knows), states when-to-use guidance three times (bullets, the Write/Skip table, and Limitations), and inlines five fully worked templates (~230 lines) where two or three would cover the cases. This matches the score-2 anchor of several unnecessary explanations or padded sections, rather than the mostly-efficient score-3 anchor.

2 / 5

Actionability

Guidance is fully executable and copy-paste ready: five complete markdown templates (MADR, lightweight, Y-statement, deprecation, RFC), real adr-tools commands ("adr init docs/adr", "adr new -s 3 ...", "adr link 2 ..."), a concrete directory layout, and a fillable review checklist covering the common cases.

5 / 5

Workflow Clarity

Sequences are clear: the Instructions give the authoring order (capture context → document options → record decision → link/update status), the README section gives a numbered creation flow (copy template → fill → PR → update index), and the Review Process checklists act as checkpoints before/during/after acceptance. It falls short of score 5 because the main authoring workflow lacks an explicit validate-and-fix feedback loop, though this skill involves no destructive or batch operations that would trigger the score-3 cap.

4 / 5

Progressive Disclosure

Section headers and internal navigation are decent, but the skill is a single monolithic file with no bundle (references/, scripts/, assets/ are absent) and no one-level-deep references — the five full templates are exactly the content that should live in separate reference files. This fits the score-3 anchor: some structure, but content that should be separate is inline.

3 / 5

Total

14

/

20

Passed

Description

53%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description clearly identifies the ADR niche with both the full term and its acronym, but it reads as a domain statement rather than a trigger-optimized description: the action verbs are generic, natural trigger variations are missing, and there is no "Use when" clause telling Claude when to invoke the skill.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user asks to record, document, or review an architecture/technical decision, or mentions ADRs, design decisions, or a decision log."

Replace the generic verb cluster ("creating, maintaining, and managing") with distinct concrete capabilities such as "draft ADRs from decision context, structure considered options with trade-offs, track status through proposed/accepted/superseded lifecycles, and maintain an ADR index."

Include a few natural user phrasings ("write an ADR", "decision record", "why did we choose X") to broaden trigger coverage.

DimensionReasoningScore

Specificity

The description names the ADR domain and a cluster of actions ("creating, maintaining, and managing") plus a concrete purpose ("capture the context and rationale behind significant technical decisions"), but the verbs are generic near-synonyms rather than several distinct specific actions, matching the score-3 anchor better than score 4.

3 / 5

Completeness

The "what" is clear (create, maintain, and manage ADRs capturing context and rationale), but there is no "Use when..." clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3.

3 / 5

Trigger Term Quality

"Architecture Decision Records (ADRs)" covers the full name and acronym and "significant technical decisions" is a relevant phrase, but coverage is a single term family — common variations a user might say ("design decisions", "decision log", "tech choice") are absent, fitting the score-3 anchor of relevant keywords missing common variations.

3 / 5

Distinctiveness Conflict Risk

"Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions" carves out a clear niche with only minor overlap risk against generic documentation skills; it is not score 5 because no explicit trigger phrasing fully disambiguates it from adjacent documentation/decision-making skills.

4 / 5

Total

13

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository

sickn33/agentic-awesome-skills

Path

skills/architecture-decision-records/SKILL.md

Reviewed

Table of Contents

Is this your skill?

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.