Skills anthropics knowledge-work-plugins
architecture
- Use it when:
- You're choosing between technologies, such as Kafka or SQS, reviewing a design proposal, or designing a new component.
- You get:
- An ADR in Markdown: status, context, decision, a table per option on complexity, cost, scalability and team familiarity, trade-offs, consequences and action items.
- With connectors:
- It looks for earlier ADRs and design docs in your knowledge base, links related epics and tickets, and creates implementation tasks in your project tracker.
- Unlike system-design:
- That one walks a design through requirements, deep dive and scaling; this one records one decision and its options in a fixed template.
- Runs:
- As /architecture with the decision or system, or when you ask about one.
- Part of:
- The engineering plugin of Anthropic's knowledge-work plugins.
TL;DR
An ADR, or architecture decision record, is a short document that captures one design decision, the options weighed and why one won. This skill writes one in a fixed template: status (proposed, accepted, deprecated or superseded), date and who signs off, then the context and the proposed decision. Each option considered gets a table rating complexity, cost, scalability and team familiarity, with pros and cons, followed by a trade-off analysis, the consequences (what gets easier, what gets harder, what to revisit) and a checklist of action items. It takes three kinds of request: a choice such as Kafka or SQS for an event bus, a review of an existing proposal, or the design of a new system, and points to the system-design skill for deeper frameworks. Stating constraints such as a deadline or a load target, naming the options and including latency, cost and maintenance needs sharpen its analysis. With a knowledge base connected it searches for earlier ADRs and design docs; with a project tracker it links related epics and tickets and creates implementation tasks.
Summarizes the skill at ab4cb1c.
npx skills add https://github.com/anthropics/knowledge-work-plugins --skill architecture skills.sh pageSource on GitHubAll skills from anthropics/knowledge-work-plugins
- Total Downloads
- 6,900 on skills.sh, Nov 9, 2026
- Repo stars
- 35,234 anthropics/knowledge-work-plugins
- First seen
- Mar 13, 2026 on skills.sh
Weekly values
| Week to | Installs |
|---|---|
| Sep 21 | 139 |
| Sep 28 | 134 |
| Oct 5 | 100 |
| Oct 12 | 110 |
| Oct 19 | 120 |
| Oct 26 | 123 |
| Nov 2 | 119 |
| Nov 9 | 119 |
| Category |
Make the agent question you and write the plan down before it writes code. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills. |
|---|---|
| Type |
A one-shot action you invoke by name, such as turning the conversation into a PRD. |
| Effect |
Its own steps change something outside your machine: post, send, deploy, provision, file issues, drive a website, or upload data to a service. |
| Needs |
Instructions only. Works in any agent that supports skills. |
| Publisher |
A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates. |
| Topics |
SKILL.md
From anthropics/knowledge-work-plugins at ab4cb1c. Checked daily, last changed Nov 6, 2026.
Frontmatter
name: architecture
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.
argument-hint: "<decision or system to design>"/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.