/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
markdown# 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 1. [ ] [Implementation step] 2. [ ] [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.

