How do I install the Adr Writer skill?

Run npx skillmds@latest add tomevault-io/adr-writer in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Adr Writer safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Adr Writer?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Adr Writer free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Adr Writer?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Adr Writer by tomevault-io — Agent Skill

Name: Adr Writer
Author: tomevault-io

Adr Writer

Guide writing Architecture Decision Records (ADRs) following the Design It! methodology. Use when creating ADRs, documenting architecture decisions, recording technical decisions, or when someone asks about ADR format or templates. Use when this capability is needed.

tomevault-io Updated Sep 17, 2026

File contents

Architecture Decision Record Writer

ADR Template

Use this template when documenting architectural decisions:

# ADR [NUMBER]: [DESCRIPTIVE TITLE]

## Status

[Draft | Proposed | Accepted | Superseded | Deprecated]

## Context

[Explain the circumstances that led to this decision. Include:
- Technical constraints or requirements
- Business drivers or political climate
- Team skills and experience
- Related previous decisions
- Quality attributes at stake]

## Decision

[Describe the decision clearly and concisely. State what you will do, not what you won't do.]

## Consequences

### Positive
- [Benefit 1]
- [Benefit 2]

### Negative
- [Tradeoff or risk 1]
- [Tradeoff or risk 2]

[Update consequences as they emerge over time]

Instructions

Identify if the decision is architectural - see REFERENCE.md for criteria
Choose a sequential number for the ADR (check existing ADRs first)
Write a descriptive title that captures the decision essence
Set initial status to Draft or Proposed
Describe context thoroughly - future readers need to understand why
State the decision clearly - be direct and specific
List consequences honestly - both positive and negative

Best Practices

One decision per file - keep ADRs focused
Keep it short - 1-2 pages maximum
Use plain language - avoid jargon where possible
Store with code - put ADRs in version control (e.g., docs/adr/)
Never delete old ADRs - mark as Superseded instead, with a reference to the new ADR
Review like code - ADRs should go through the same review process as code

Status Lifecycle

Draft - Initial writing, not yet shared
Proposed - Ready for team review
Accepted - Team has agreed to this decision
Superseded - Replaced by a newer ADR (link to it)
Deprecated - No longer relevant but kept for history

For detailed guidance on when to write an ADR and what makes a decision architectural, see REFERENCE.md.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: adr-writerdescription: Guide writing Architecture Decision Records (ADRs) following the Design It! methodology. Use when creating ADRs, documenting architecture decisions, recording technical decisions, or when someone asks about ADR format or templates. Use when this capability is needed.---# Architecture Decision Record Writer## ADR TemplateUse this template when documenting architectural decisions:```markdown# ADR [NUMBER]: [DESCRIPTIVE TITLE]## Status[Draft | Proposed | Accepted | Superseded | Deprecated]## Context[Explain the circumstances that led to this decision. Include:- Technical constraints or requirements- Business drivers or political climate- Team skills and experience- Related previous decisions- Quality attributes at stake]## Decision[Describe the decision clearly and concisely. State what you will do, not what you won't do.]## Consequences### Positive- [Benefit 1]- [Benefit 2]### Negative- [Tradeoff or risk 1]- [Tradeoff or risk 2][Update consequences as they emerge over time]```## Instructions1. **Identify if the decision is architectural** - see [REFERENCE.md](REFERENCE.md) for criteria2. **Choose a sequential number** for the ADR (check existing ADRs first)3. **Write a descriptive title** that captures the decision essence4. **Set initial status** to Draft or Proposed5. **Describe context thoroughly** - future readers need to understand *why*6. **State the decision clearly** - be direct and specific7. **List consequences honestly** - both positive and negative## Best Practices- **One decision per file** - keep ADRs focused- **Keep it short** - 1-2 pages maximum- **Use plain language** - avoid jargon where possible- **Store with code** - put ADRs in version control (e.g., `docs/adr/`)- **Never delete old ADRs** - mark as Superseded instead, with a reference to the new ADR- **Review like code** - ADRs should go through the same review process as code## Status Lifecycle- **Draft** - Initial writing, not yet shared- **Proposed** - Ready for team review- **Accepted** - Team has agreed to this decision- **Superseded** - Replaced by a newer ADR (link to it)- **Deprecated** - No longer relevant but kept for historyFor detailed guidance on when to write an ADR and what makes a decision architectural, see [REFERENCE.md](REFERENCE.md).---> Converted and distributed by [TomeVault](https://tomevault.io/claim/timblaktu) — claim your Tome and manage your conversions.

Frequently asked questions