CtrlK
BlogDocsLog inGet started
Tessl Logo

writing-adrs

Use when authoring an Architecture Decision Record (ADR) — a short document that captures one significant, hard-to-reverse technical or architectural decision, its context, and its consequences. Triggered by the sdlc ADR pipeline (the knowledge-engineer agent behind /sdlc:docs seed adr and /sdlc:docs distill) when generating an ADR from a story, and by anyone hand-authoring an ADR under docs/adr/ today. Covers why ADRs are kept short and inverted-pyramid, the required sections (Title, Status, Decision, Context, Alternatives Considered, Consequences), the proposed→accepted→superseded (or →rejected) status lifecycle and the never-edit-only-supersede immutability rule, the NNNN-decision-slug.md filename convention, and the ADR frontmatter fields (status, agents, source-stories) the pipeline reads to route a generated ADR into docs/adr/index.md.

68

Quality

81%

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

SKILL.md
Quality
Evals
Security

Quality

Content

71%Scale 1-5

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

This is a well-crafted, highly actionable skill with excellent concrete guidance including a template, worked example, checklist, and anti-patterns table. Its main weakness is verbosity — several sections over-explain concepts (immutability rationale, pipeline routing edge cases, index regeneration caveats) that could be stated more concisely, and the document would benefit from splitting some content into separate reference files rather than inlining everything.

Suggestions

Tighten the prose throughout — the immutability rule paragraph, supersede flow, and pipeline routing section each contain 2-3 sentences of rationale/caveats that Claude doesn't need. State the rule, not why the rule exists.

Consider extracting the worked example and/or the template into separate bundle files (e.g., TEMPLATE.md, EXAMPLE.md) and referencing them from the main skill, reducing the monolithic feel.

Trim the frontmatter/pipeline routing section significantly — the paragraph about when hand-editing index.md is fine vs. not fine contains multiple conditional clauses that could be a two-line rule.

DimensionReasoningScore

Conciseness

The skill is thorough but noticeably verbose in several areas. The immutability rule explanation, supersede flow, and frontmatter/pipeline routing sections are over-explained with caveats and edge cases that Claude could infer. The worked example is valuable but lengthy. Several paragraphs could be tightened significantly (e.g., the long paragraph about index.md regeneration).

3 / 5

Actionability

Highly actionable with a complete, copy-paste-ready template, a fully worked example showing all sections filled in correctly, concrete filename conventions, exact frontmatter YAML, a self-review checklist, and an anti-patterns table with specific fixes. Claude would know exactly what to produce.

5 / 5

Workflow Clarity

The status lifecycle is clearly diagrammed with an ASCII state machine, the supersede flow is well-sequenced with explicit ordering constraints (flip both statuses at the same moment), and the self-review checklist serves as a validation checkpoint. Minor gap: the 'before assigning a new number, list docs/adr/' step could be more prominently placed in a numbered workflow rather than buried in a paragraph.

4 / 5

Progressive Disclosure

The content is well-structured with clear section headers, but it's essentially a monolithic document at ~250+ lines. The frontmatter/pipeline routing section, the worked example, and the anti-patterns table could reasonably be split into separate reference files. There are references to external resources (adr-tools GitHub, martinfowler.com) but no bundle files to offload detail into. The template and worked example inline substantial content that could be linked.

3 / 5

Total

15

/

20

Passed

Description

92%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.

This is a strong, well-crafted skill description that thoroughly covers what the skill does and when it should be triggered. It provides comprehensive specificity about ADR structure, lifecycle, and pipeline integration, and clearly delineates its niche. The only minor weakness is that trigger terms lean toward pipeline-specific jargon, which could miss some natural user phrasings for requesting help with architectural decisions.

DimensionReasoningScore

Specificity

The description lists multiple concrete actions and details: required sections (Title, Status, Decision, Context, Alternatives Considered, Consequences), the status lifecycle (proposed→accepted→superseded/rejected), the immutability rule, filename convention (NNNN-decision-slug.md), and frontmatter fields (status, agents, source-stories). This is comprehensive coverage of what the skill teaches.

5 / 5

Completeness

The description explicitly answers both 'what' (authoring ADRs with specific sections, lifecycle, naming conventions, frontmatter) and 'when' ('Use when authoring an Architecture Decision Record', 'Triggered by the sdlc ADR pipeline... when generating an ADR from a story, and by anyone hand-authoring an ADR under docs/adr/'). Both are concrete and well-specified.

5 / 5

Trigger Term Quality

Includes strong trigger terms like 'ADR', 'Architecture Decision Record', 'docs/adr/', '/sdlc:docs seed adr', '/sdlc:docs distill', and 'NNNN-decision-slug.md'. However, some natural user phrases are missing — e.g., 'architecture decision', 'design decision', 'technical decision document' — and the terms lean somewhat toward pipeline-specific jargon rather than what a general user might say.

4 / 5

Distinctiveness Conflict Risk

This skill occupies a very clear niche — ADR authoring with specific pipeline integration, naming conventions, and lifecycle rules. It is highly unlikely to conflict with other skills due to its precise domain (Architecture Decision Records) and specific triggers like '/sdlc:docs seed adr'.

5 / 5

Total

19

/

20

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
whimzyLive/nightshift-ai
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.