Architecture

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

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

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.