/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.