/architecture

> If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.

Create an Architecture Decision Record (ADR) or evaluate a system design.

Usage

/architecture $ARGUMENTS

Modes

Create an ADR: "Should we use Kafka or SQS for our event bus?"

Evaluate a design: "Review this microservices proposal"

System design: "Design the notification system for our app"

See the system-design skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.

Output — ADR Format

# ADR-[number]: [Title]

Status: Proposed | Accepted | Deprecated | Superseded
Date: [Date]
Deciders: [Who needs to sign off]

Context
[What is the situation? What forces are at play?]

Decision
[What is the change we're proposing?]

Options Considered

Option A: [Name]
| Dimension | Assessment |
|-----------|------------|
| Complexity | [Low/Med/High] |
| Cost | [Assessment] |
| Scalability | [Assessment] |
| Team familiarity | [Assessment] |

Pros: [List]
Cons: [List]

Option B: [Name]
[Same format]

Trade-off Analysis
[Key trade-offs between options with clear reasoning]

Consequences
[What becomes easier]
[What becomes harder]
[What we'll need to revisit]

Action Items
[ ] [Implementation step]
[ ] [Follow-up]

If Connectors Available

If ~~knowledge base is connected:

• Search for prior ADRs and design docs
• Find relevant technical context

If ~~project tracker is connected:

• Link to related epics and tickets
• Create implementation tasks

Tips

• State constraints upfront — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.
• Name your options — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives.
• Include non-functional requirements — Latency, cost, team expertise, and maintenance burden matter as much as features.