adr-format-y-statement
Scannednpx machina-cli add skill zircote/adr/adr-format-y-statement --openclawY-Statement ADR Format
The Y-Statement format, developed by Olaf Zimmermann, captures architectural decisions in a single structured sentence. It is the most concise ADR format available.
About Y-Statement Format
The Y-Statement format is:
- Concise - Core decision in one sentence
- Structured - Fixed format ensures completeness
- Traceable - Connects decision to context and consequences
- Quick - Minimal documentation overhead
The Y-Statement Structure
Basic Y-Statement
In the context of {use case/user story},
facing {concern/non-functional requirement},
we decided for {option}
and against {other options},
to achieve {quality/goal},
accepting {downside/consequence/trade-off}.
Extended Y-Statement
Adds a "because" clause for additional rationale:
In the context of {use case/user story},
facing {concern/non-functional requirement},
we decided for {option}
and against {other options},
to achieve {quality/goal},
accepting {downside/consequence/trade-off},
because {additional rationale}.
Template Structure
# {NUMBER}. {TITLE}
Date: {DATE}
## Status
{STATUS}
## Decision
In the context of {context},
facing {concern},
we decided for {chosen option}
and against {rejected options},
to achieve {quality goal},
accepting {trade-off}.
## Rationale
{Optional: Expand on the decision with additional context}
## Consequences
{Optional: List specific positive and negative outcomes}
Writing Y-Statements
Fill-in Guide
| Placeholder | What to Include | Example |
|---|---|---|
{context} | Use case or scenario | "building a real-time notification system" |
{concern} | Quality attribute or requirement | "the need for sub-second message delivery" |
{option} | Chosen solution | "WebSockets" |
{other options} | Alternatives rejected | "HTTP polling and Server-Sent Events" |
{quality} | Goal achieved | "low-latency bidirectional communication" |
{trade-off} | Accepted downside | "increased infrastructure complexity" |
Complete Example
# 7. Use WebSockets for Real-Time Notifications
Date: 2025-01-15
## Status
Accepted
## Decision
In the context of building a real-time notification system for our
trading platform, facing the need for sub-second message delivery to
thousands of concurrent users, we decided for WebSockets and against
HTTP long-polling and Server-Sent Events, to achieve low-latency
bidirectional communication with efficient connection management,
accepting increased infrastructure complexity and the need for
WebSocket-aware load balancers.
## Consequences
* Good, because notification latency reduced to <100ms
* Good, because server push eliminates polling overhead
* Bad, because load balancer configuration is more complex
* Bad, because connection state management requires additional code
When to Use Y-Statement Format
Best for:
- Quick decision documentation
- Simple, clear-cut decisions
- Decisions with obvious winner
- Teams valuing brevity
- Lightweight ADR processes
Consider other formats when:
- Complex multi-option analysis needed
- Detailed pros/cons documentation required
- Multiple stakeholders need extensive context
- Decision reasoning is nuanced
Y-Statement Best Practices
Writing Tips
- Keep the statement readable as one (long) sentence
- Be specific in each placeholder
- Name concrete alternatives rejected
- State measurable quality goals
- Be honest about trade-offs
Common Mistakes
| Mistake | Example | Fix |
|---|---|---|
| Vague context | "building our system" | "building the payment processing module" |
| Missing alternatives | "other options" | "manual processing and third-party service" |
| Unclear quality | "better performance" | "sub-100ms response time" |
| Hidden trade-offs | "minor issues" | "monthly maintenance overhead of 4 hours" |
Comparison with Other Formats
| Aspect | Y-Statement | Nygard | MADR |
|---|---|---|---|
| Length | ~1 sentence | 3-5 paragraphs | 1-2 pages |
| Structure | Fixed format | Flexible | Flexible |
| Options | Named in statement | Implicit | Explicit section |
| Best for | Simple decisions | Quick docs | Complex analysis |
Additional Resources
Templates
Template available at:
${CLAUDE_PLUGIN_ROOT}/templates/y-statement/adr-template.md
External Resources
- Y-Statements by Olaf Zimmermann
- Sustainable Architectural Decisions (IEEE Software)
Source
git clone https://github.com/zircote/adr/blob/main/skills/adr-format-y-statement/SKILL.mdView on GitHub Overview
The Y-Statement ADR format captures architectural decisions in a single structured sentence. It is designed to be concise, structured, traceable, and quick, enabling fast, consistent decision documentation while linking to context and consequences.
How This Skill Works
Write a single, structured sentence that encodes the decision context, the primary concern, the chosen option, the alternatives rejected, the quality goal, and the trade-off. You can use the Basic Y-Statement for the core decision or extend it with a 'because' clause for additional rationale, as described in the template structure.
When to Use It
- You need quick ADRs for simple, clear-cut decisions.
- You want a single readable sentence to document a decision and its trade-offs.
- Your team values brevity and lightweight ADR processes.
- There is a clearly preferred option with minimal justification required.
- You want a traceable decision that links context, concern, option, and consequences with minimal overhead.
Quick Start
- Step 1: Gather {context}, {concern}, {option}, {other options}, {quality}, and {trade-off}.
- Step 2: Write the decision as the Basic Y-Statement in one sentence following the template.
- Step 3: If needed, add 'because {rationale}' to form the Extended Y-Statement and publish as the ADR.
Best Practices
- Keep the statement readable as one long sentence.
- Be specific in each placeholder (context, concern, option, other options, quality, trade-off).
- Name concrete alternatives rejected.
- State measurable quality goals.
- Be honest about trade-offs.
Example Use Cases
- 7. Use WebSockets for Real-Time Notifications — an example showing the full Y-Statement format in action.
- In the context of building a real-time notification system for our trading platform, facing sub-second delivery, we decided for WebSockets and against HTTP long-polling and Server-Sent Events, to achieve low-latency bidirectional communication with efficient connection management, accepting increased infrastructure complexity.
- We decided for WebSockets and against polling to achieve low-latency, bidirectional communication in a real-time application.
- A concise one-sentence ADR documenting the choice of WebSockets for real-time updates and the trade-off of higher infrastructure complexity.
- Extended Y-Statement usage: add a rationale clause to justify the decision in the 'because' section for future readers.