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