adr-template

Generate Architecture Decision Records with context, decision, and consequences.

7|1|Updated Oct 16, 2025
One-click install
npx skills add https://github.com/xloxn69/AgileFlow --skill adr-template
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: adr-template
Source: https://github.com/xloxn69/AgileFlow/tree/main/skills/adr-template
Command: npx skills add https://github.com/xloxn69/AgileFlow --skill adr-template

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Architectural decisions are often made in meetings and then forgotten or poorly documented, leading to re-debates, inconsistent patterns, and a critical lack of historical context for future teams.

Core Features & Use Cases

  • Structured ADR Generation: Create Architecture Decision Records with clear sections for context, decision, consequences, and alternatives considered.
  • Decision History: Maintain a traceable and durable record of why key technical choices were made, fostering shared understanding.
  • Use Case: Your team just decided to use JWT for authentication instead of sessions. This skill helps you document the decision, its context, the alternatives considered, and the pros/cons, creating a durable record for future reference.

Quick Start

Use the adr-template skill to document our decision to use GraphQL instead of REST for the new API, including the reasons and trade-offs.

Frequently Asked Questions about adr-template

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

FAQPage Schema
How do I document architectural decisions my team makes?

Architecture Decision Records (ADRs) document the context, decision, and consequences of major technical choices. ADRs create a durable, searchable history of why technologies or patterns were chosen, preventing re-debates and providing critical context for future teams. This skill generates a complete ADR structure with required sections and YAML frontmatter, outputting to docs/03-decisions/adr-XXXX.md.

What should an ADR include besides the decision itself?

An effective ADR captures context (the problem and constraints), the decision made, consequences (trade-offs and impact), alternatives considered, and links to related stories. This structure ensures future readers understand not just what was decided, but why that choice won against other options and what problems it solves.

When should I create an ADR for a technical choice?

Create an ADR for major architectural decisions during implementation—when choosing authentication methods, APIs, frameworks, or patterns that significantly affect the system's design. ADRs are most valuable for decisions that involve trade-offs, cost implications, or long-term maintainability impact that future teams need to understand.

Can I use ADRs to track technical debt decisions?

Yes. ADRs document not only forward-looking architectural choices but also decisions about technical debt—why a shortcut was taken, what the consequences are, and when it should be revisited. This keeps technical debt visible and intentional rather than forgotten.

What format does an ADR use for storage and sharing?

ADRs are stored as Markdown files in docs/03-decisions/ with YAML frontmatter containing metadata (adr_id, title, status, date). This format makes them version-controllable, searchable, and easy to link from code and documentation, creating a centralized decision log accessible to the entire team.