adr-format-y-statement

Transform architectural decisions into standardized Y-Statements with context, options, and trade-offs.

5|3|Updated Jan 17, 2026
One-click install
npx skills add https://github.com/zircote/adr --skill adr-format-y-statement
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: adr-format-y-statement
Source: https://github.com/zircote/adr/tree/main/skills/adr-format-y-statement
Command: npx skills add https://github.com/zircote/adr --skill adr-format-y-statement

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

The Y-Statement ADR format provides a concise, structured way to document architectural decisions, consolidating context, options, and outcomes into a single referenceable statement.

Core Features & Use Cases

  • Fixed structure: enforces a consistent layout that includes context, concern, chosen option, rejected options, goal, and trade-offs.
  • Ease of use: enables rapid generation of decision records for projects, modules, or teams requiring lightweight ADRs.
  • Guided examples: provides templates and examples to standardize decision documentation across teams.

Quick Start

Provide a complete Y-Statement example for a given architectural context using the template.

Frequently Asked Questions about adr-format-y-statement

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

FAQPage Schema
What is a Y-Statement in architectural decision records?▼

A Y-Statement in architectural decision records is a concise, single-sentence format that captures context, concern, chosen option, alternatives, quality goals, and trade-offs. It enforces a fixed structure to standardize lightweight decision tracking across project teams.

How do I write concise ADRs for my software architecture?▼

You write concise ADRs by applying the Y-Statement format, which transforms architectural decisions into a single structured sentence. You provide the required context, concern, chosen option, rejected alternatives, and trade-offs to create a quick, consistent decision record.

When should I use a single-sentence ADR format instead of detailed documentation?▼

Use a single-sentence ADR format for project-level or module-level architectural decisions when your team needs quick, consistent decision records without the overhead of lengthy documentation. It suits lightweight ADR needs where capturing context and trade-offs rapidly is the priority.

What fields are required in a Y-Statement architectural decision record?▼

Required fields in a Y-Statement architectural decision record include context, concern, chosen option, rejected alternatives, quality goal, and trade-offs. It also prompts for an optional rationale to further justify the architectural decision.

Can I use the Y-Statement format for module-level architectural decisions?▼

Yes, you can use the Y-Statement format for module-level architectural decisions. It is specifically designed for both project-level and module-level ADR creation, enabling rapid generation of standardized decision records across different scopes of your architecture.

What is the best way to standardize architecture decision documentation across teams?▼

The best way to standardize architecture decision documentation across teams is to enforce a fixed Y-Statement structure. By using provided templates and examples, teams generate consistent, lightweight decision records that consolidate context, options, and outcomes uniformly.