Architecture

What This Skill Does

This skill assists in creating Architecture Decision Records (ADRs) and evaluating system designs. It helps teams document architectural decisions and analyze trade-offs. It's useful for software architects, engineers, and technical leads making key technology choices.

When to Use

• Create an Architecture Decision Record (ADR).
• Evaluate a system design proposal.
• Design a system architecture.
• Document architectural decisions.
• Analyze trade-offs between technology options.
• Assess the consequences of architectural choices.

Key Features

• Generates ADRs with context, decision, and consequences.
• Evaluates design options based on complexity, cost, and scalability.
• Analyzes trade-offs between different architectural approaches.
• Provides a structured format for documenting architectural decisions.
• Suggests action items for implementing architectural changes.
• Connects to knowledge bases and project trackers for context.

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]

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

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]

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.