Create or evaluate an architecture decision record (ADR). Use when choosing between technologies (e.g., Kafka vs SQS), documenting a design decision with trade-offs and consequences, reviewing a system design proposal, or designing a new component from requirements and constraints.

/architecture If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md). Create an Architecture Decision Record (ADR) or evaluate a system design. Usage 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 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 1. State constraints upfront — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer. 2. Name your options — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives. 3. Include non functional requirements — Latency, cost, team expertise, and maintenance burden matter as much as features.