Skill

role-architect:adr-writer

Writes Architecture Decision Records (ADRs) with structured format, numbering, indexing, status lifecycle, linking, and team review processes.

Markdown

Git

documentation

git-workflow

npx claudepluginhub rnavarych/alpha-engineer --plugin role-architect

Popularity

Parent stars

Parent forks

Invocation

How this skill is triggered — by the user, by Claude, or both

Slash command

/role-architect:adr-writer

User invocable

Model invocable

Inline context

Default effort

Tool Access

This skill is limited to the following tools:

ReadGrepGlobBash

Context Preview

The summary Claude sees in its skill listing — used to decide when to auto-load this skill

- Writing a new Architecture Decision Record for a significant design choice

Supporting Files

references/adr-format-and-lifecycle.mdreferences/adr-team-review-process.md

SKILL.md

30 lines · ~514 tokens

Similar Skills

adr-generator

Generates Architectural Decision Records (ADRs) by detecting project template conventions, assigning sequential numbers, supporting MADR/Nygard/Alexandrian formats, and saving markdown files. Use for documenting technical decisions.

project-toolkit

develop-adr

251

Creates Architecture Decision Records (ADRs) in Nygard format to document significant technical decisions, context, and consequences. Use for system architecture, technology selection, or development patterns.

2 files

pm-skills

create-adr

Interactive guided process for creating architecture decision records (ADRs). Collects context, analyzes options, records consequences, and can supersede previous ADRs.

3 tools

accelerator

Stats

LanguageShell

Parent stars13

Parent forks1

MaintenanceGood

Last CommitMar 3, 2026

Actions

View Source View Plugin View on GitHub View README

Help us improve

Share bugs, ideas, or general feedback.

Stats

Actions

Help us improve

Share bugs, ideas, or general feedback.

ADR Writer

When to use

Writing a new Architecture Decision Record for a significant design choice

Deciding between a full ADR and a lightweight ADR for a smaller decision

Managing ADR status transitions (Proposed, Accepted, Deprecated, Superseded)

Setting up ADR numbering, file naming, and the index table

Linking related ADRs with bidirectional dependency and supersession references

Running an asynchronous team review process for a proposed decision

Core principles

Title states the decision, not the question — imperative mood, not interrogative

Context is specific, not generic — include concrete numbers, constraints, and what changed now

Consequences must include negatives — a consequences section with only positives is incomplete

Never delete a superseded ADR — the history of wrong turns is as valuable as the right ones

ADR formalizes the conversation, not starts it — discuss informally first, document after alignment

Reference Files

references/adr-format-and-lifecycle.md — full ADR structure (Title, Status, Context, Decision, Consequences), good vs bad title examples, ADR numbering convention, index table format, file naming pattern, Proposed/Accepted/Deprecated/Superseded status lifecycle with transition rules, lightweight ADR format and when to use it, and bidirectional linking with relationship types (Depends on, Supersedes, Informed by, Enables)

references/adr-team-review-process.md — pre-writing data gathering, asynchronous PR-based review process, reviewer selection criteria, review deadline convention (3-5 business days), post-acceptance communication and onboarding integration, and 6-month review checkpoint scheduling for high-impact decisions

ADR Writer

When to use

Writing a new Architecture Decision Record for a significant design choice
Deciding between a full ADR and a lightweight ADR for a smaller decision
Managing ADR status transitions (Proposed, Accepted, Deprecated, Superseded)
Setting up ADR numbering, file naming, and the index table
Linking related ADRs with bidirectional dependency and supersession references
Running an asynchronous team review process for a proposed decision

Core principles

Title states the decision, not the question — imperative mood, not interrogative
Context is specific, not generic — include concrete numbers, constraints, and what changed now
Consequences must include negatives — a consequences section with only positives is incomplete
Never delete a superseded ADR — the history of wrong turns is as valuable as the right ones
ADR formalizes the conversation, not starts it — discuss informally first, document after alignment

Reference Files

references/adr-format-and-lifecycle.md — full ADR structure (Title, Status, Context, Decision, Consequences), good vs bad title examples, ADR numbering convention, index table format, file naming pattern, Proposed/Accepted/Deprecated/Superseded status lifecycle with transition rules, lightweight ADR format and when to use it, and bidirectional linking with relationship types (Depends on, Supersedes, Informed by, Enables)
references/adr-team-review-process.md — pre-writing data gathering, asynchronous PR-based review process, reviewer selection criteria, review deadline convention (3-5 business days), post-acceptance communication and onboarding integration, and 6-month review checkpoint scheduling for high-impact decisions

role-architect:adr-writer

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

Similar Skills

Help us improve

Help us improve

Find plugins for your project

role-architect:adr-writer

Popularity

Invocation

Tool Access

Context Preview

Supporting Files

SKILL.md

ADR Writer

When to use

Core principles

Reference Files

Similar Skills

Help us improve

ADR Writer

When to use

Core principles

Reference Files