architecture
The facts
Its description
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.
The description the agent reads to decide when to use it.
When it starts
A person is weighing a technical choice, wants a design decision written down with trade-offs and consequences, or wants a proposed system design reviewed or sketched out from requirements. The agent would pick this when the talk turns to picking between technologies, recording an architecture decision, or designing a new component.
Things a person might say (the model's guesses)
- “Should we use Kafka or SQS for our event bus?”
- “Write up an ADR for moving our auth service to a managed provider.”
- “Review this microservices proposal for the payments team.”
A model's summary of when it is used.
What it takes when started
<decision or system to design>
What to type after its name when you start it.
What it leads to
- requires system-design line 25
Other skills this one hands off to, calls, requires or offers instead, as a model read them.
Licence
Apache-2.0, from LICENSE
The terms its author shares it under, which let it be shown here.
The text
Most marks come from matching words in the file, so treat them as pointers.
/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.
Raw lines 1 to 12Boilerplate, lines 13 to 18. The same text appears in 24 other files here. Close
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.
Raw lines 19 to 26Output — 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.
From anthropics/knowledge-work-plugins at 2574e29, 2026-10-27. Skills read by DeepSeek V4.1 Flash on 2026-11-04. Summary and techniques by Claude Opus 5.5 on 2026-11-06.