write-adr

Document architecture decisions as ADRs matching repository conventions.

Updated Jun 3, 2026
One-click install
npx skills add https://github.com/0xdeafcafe/skills --skill write-adr-0xdeafcafe
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: write-adr
Source: https://github.com/0xdeafcafe/skills/tree/main/skills/write-adr
Command: npx skills add https://github.com/0xdeafcafe/skills --skill write-adr-0xdeafcafe

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill helps teams capture important architecture and design decisions in a durable ADR instead of leaving the reasoning buried in chats, meetings, or memory. It reduces the risk of future confusion about why one option was chosen over another and keeps decision records consistent with the repository's existing conventions.

Core Features & Use Cases

  • Convention Discovery: Finds the repository's ADR folder, naming pattern, numbering scheme, and document style before drafting anything.
  • Interactive Decision Framing: Pulls out the real forcing function, alternatives considered, and consequences so the ADR reflects an actual decision instead of vague documentation.
  • Repo-Matched Drafting: Writes a concise ADR that fits local formatting, status conventions, and linking practices, including superseding older ADRs when needed.
  • Use Case: Ideal when a team has decided on a database change, library adoption, deployment topology, or other architectural direction and wants a clear written record in the codebase.

Quick Start

Ask the assistant to use write-adr to document a specific architecture decision and include the decision, the alternatives considered, and why the change is happening now.

Frequently Asked Questions about write-adr

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I document architecture decisions in my repository?

Architecture decisions are documented as ADRs by discovering repository conventions, clarifying the decision context, and drafting a reviewable record directly into the codebase. This ensures the rationale is captured durably instead of being lost in chats.

What is an ADR and when do I need to write one?

An ADR is an Architecture Decision Record used to capture important design choices like library selection, database strategy, or deployment topology. You need one when a team decides on an architectural direction and wants a clear written record of the reasoning.

How do I write an ADR that matches my repository's existing formatting?

To write an ADR that matches repository formatting, the skill first discovers your project's ADR folder, naming pattern, numbering scheme, and document style before drafting a concise record that fits local conventions and linking practices.

Can I use this to supersede an older architecture decision record?

Yes, you can supersede older ADRs when documenting a new architecture decision. The skill handles status conventions and cross-links related records, ensuring the new decision document properly references and supersedes prior architecture records.

Does this ADR tool work without predefined templates or dependencies?

Yes, this skill has no external dependencies and works by discovering your repository's existing conventions on the fly. It requires no predefined templates because it analyzes your local folder structure and document style to draft a matching ADR.

What should I include when drafting an architecture decision record?

When drafting an architecture decision record, you should include the decision, the alternatives considered, the forcing function for the change, and the consequences. The skill interactively frames these elements to ensure the ADR reflects an actual decision.