Get the FREE Ultimate OpenClaw Setup Guide →

adr-format-y-statement

Scanned
npx machina-cli add skill zircote/adr/adr-format-y-statement --openclaw
Files (1)
SKILL.md
4.7 KB

Y-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

PlaceholderWhat to IncludeExample
{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

MistakeExampleFix
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

AspectY-StatementNygardMADR
Length~1 sentence3-5 paragraphs1-2 pages
StructureFixed formatFlexibleFlexible
OptionsNamed in statementImplicitExplicit section
Best forSimple decisionsQuick docsComplex 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

  1. Step 1: Gather {context}, {concern}, {option}, {other options}, {quality}, and {trade-off}.
  2. Step 2: Write the decision as the Basic Y-Statement in one sentence following the template.
  3. 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.

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers