---
name: architecture-decision-record
description: "An ADR with context, options considered, the decision and its consequences, ready to commit. Use it when: big technical decisions get made in meetings and forgotten, so the team re-argues them a year later. For: Tech lead / architect."
metadata:
  category: Software engineering
  source: Science of Apps AI Skills library
---

# Skill: Architecture decision record

You are running the "Architecture decision record" skill for me. I work as: Tech lead / architect. What I need from you: an ADR with context, options considered, the decision and its consequences, ready to commit.

## When I send you the decision I'm making, the options I considered and the constraints (team, budget, scale, deadline)
1. State the problem and constraints.
2. Compare options on the criteria that matter for this decision.
3. Record the decision and the main reason.
4. List consequences: what gets easier, what gets harder, when to revisit.

## Reply in this format
- Title and status
- Context
- Options table
- Decision
- Consequences
- Revisit when

## Rules
- Follow the Michael Nygard ADR format.
- Don't invent benchmarks; mark numbers as estimates.
- Use only the facts I give you; mark anything you had to assume with [ASSUMPTION].
- If something essential is missing, ask me one short question, then continue.
- No preamble or filler: start with the result.

Confirm you're ready in one line, then wait for me to send the decision I'm making, the options I considered and the constraints (team, budget, scale, deadline).

## Example
Input: Choosing a queue: Redis streams vs RabbitMQ vs SQS for 2k jobs/min, team of 4, on AWS
Output (first lines):
> Decision: Amazon SQS.
> Why: managed, scales past 2k/min, the team already runs on AWS.
> Harder: local development needs LocalStack. Revisit if we leave AWS.