new-adr

Create numbered architecture decision records with frontmatter and constraints.

15|5|Updated May 4, 2026
One-click install
npx skills add https://github.com/eugenelim/agent-ready-repo --skill new-adr-eugenelim
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: new-adr
Source: https://github.com/eugenelim/agent-ready-repo/tree/main/.agents/skills/new-adr
Command: npx skills add https://github.com/eugenelim/agent-ready-repo --skill new-adr-eugenelim

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and assets (resource) components.

What problem does it solve?

This Skill helps you capture architecture decisions as clear, reusable ADRs instead of letting important tradeoffs disappear into chat logs or ad hoc notes.

Core Features & Use Cases

  • New ADR creation: Creates a numbered ADR from the bundled template in the docs adr folder.
  • Decision quality checks: Verifies the choice is about architecture, already decided or formally proposed, and includes a real tradeoff.
  • Lifecycle handling: Supports proposed, accepted, rejected, deprecated, and superseded outcomes so decisions stay readable over time.
  • Use case: Use it when you need to record a choice like storage, deployment, service boundaries, or infrastructure standards in a durable format.

Quick Start

Ask the skill to draft a new ADR for a concrete architecture decision and have it fill the template, validate the tradeoffs, and keep the record in proposed status.

Frequently Asked Questions about new-adr

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

FAQPage Schema
How do I document architecture decisions and tradeoffs in a reusable format?

Architecture decision records capture technical choices in a durable format with required frontmatter, declarative statements, explicit constraints, and honest consequences. This prevents important tradeoffs from disappearing into chat logs or ad hoc notes.

What is the best way to create a new ADR for infrastructure or service boundary choices?

Create a new ADR by drafting a numbered record from a template in the docs folder. The process validates that the choice involves architecture, includes a real tradeoff, and records alternatives with explicit rejection reasons.

Can I track the lifecycle of an architecture decision record through proposed and accepted states?

Architecture decision records support lifecycle handling with proposed, accepted, rejected, deprecated, and superseded outcomes. This ensures decisions stay readable and maintain accurate historical context as system standards evolve.

Does this ADR template enforce quality checks for technical tradeoffs and alternatives?

Decision quality checks verify the choice involves architecture, is already decided or formally proposed, and includes a real tradeoff. Required elements include explicit constraints, honest consequences, and recorded alternatives with rejection reasons.

When do I need to use an architecture decision record instead of standard documentation?

Use an architecture decision record for made or formally proposed technical choices involving storage, deployment, service boundaries, or tooling standards. It provides strong guardrails ensuring durable, reusable capture of shared-system decisions.