Architecture
Produce or review Architecture Decision Records so technology and design choices stay explicit before you lock in implementation.
Overview
architecture is an agent skill most often used in Build (also Validate, Ship) that creates or evaluates Architecture Decision Records with options, trade-offs, and consequences when choosing technologies or reviewing des
Install
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill architectureWhat is this skill?
- Three modes: create ADR, evaluate an existing design, or greenfield system design from requirements
- Structured ADR output with Context, Decision, Options Considered, and per-option dimension tables
- Explicit comparison dimensions: complexity, cost, scalability, and team familiarity
- Status lifecycle: Proposed, Accepted, Deprecated, or Superseded with dated deciders
- Pointers to system-design frameworks for requirements, scalability, and trade-off depth
- 3 invocation modes: create ADR, evaluate design, system design
Adoption & trust: 3.4k installs on skills.sh; 19.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are staring at equivalent infrastructure or design paths with no durable record of why one option won or what you gave up.
Who is it for?
Solo builders who want written accountability before committing to event buses, service boundaries, or new subsystems.
Skip if: Skipping when you only need a quick spike with throwaway code and no need to justify or revisit the choice later.
When should I use this skill?
Choosing between technologies, documenting a design decision with trade-offs, reviewing a system design proposal, or designing a new component from requirements and constraints.
What do I get? / Deliverables
You get a sign-off-ready ADR or structured design review with compared options and explicit trade-offs so implementation can proceed without re-litigating the decision.
- ADR markdown with options tables and status
- Structured design evaluation notes
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
ADRs are the canonical artifact when a solo builder turns fuzzy options into an agreed technical direction during product construction. Build/pm is where decision records, trade-off tables, and sign-off live alongside specs—not only after code is written.
Where it fits
Compare Kafka versus SQS for an event bus before you prototype the producer.
Design the notification system from app requirements and document the chosen adapter pattern.
Capture deciders and status on a proposed caching layer ADR tied to your milestone.
Evaluate a teammate’s microservices split proposal against scalability and complexity dimensions.
How it compares
Use for decision-grade ADRs and design critique, not as a drop-in code generator or an MCP integration.
Common Questions / FAQ
Who is architecture for?
Indie and solo builders shipping SaaS or APIs who need clear, citable records of technical choices without a formal architecture committee.
When should I use architecture?
During validate when narrowing stack options, in build when documenting a component design, and in ship when reviewing a microservices or integration proposal before merge.
Is architecture safe to install?
It is procedural documentation guidance; review the Security Audits panel on this Prism page before trusting any third-party skill package in your agent.
SKILL.md
READMESKILL.md - 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.