architecture

Name: architecture
Author: anthropics

4.9kinstalls2.7kforks

How to install architecture?

anthropics/knowledge-work-plugins/architecture

$npx -y skills add anthropics/knowledge-work-plugins --skill architecture

Installs into the current project.

Summary

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 constraint

Files · 1

View on GitHub

SKILL.md

1	# /architecture
2
3	> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
4
5	Create an Architecture Decision Record (ADR) or evaluate a system design.
6
7	## Usage
8
9	```
10	/architecture $ARGUMENTS
11	```
12
13	## Modes
14
15	Create an ADR: "Should we use Kafka or SQS for our event bus?"
16	Evaluate a design: "Review this microservices proposal"
17	System design: "Design the notification system for our app"
18
19	See the system-design skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.
20
21	## Output — ADR Format
22
23	```markdown
24	# ADR-[number]: [Title]
25
26	Status: Proposed \| Accepted \| Deprecated \| Superseded
27	Date: [Date]
28	Deciders: [Who needs to sign off]
29
30	## Context
31	[What is the situation? What forces are at play?]
32
33	## Decision
34	[What is the change we're proposing?]
35
36	## Options Considered
37
38	### Option A: [Name]
39	\| Dimension \| Assessment \|
40	\|-----------\|------------\|
41	\| Complexity \| [Low/Med/High] \|
42	\| Cost \| [Assessment] \|
43	\| Scalability \| [Assessment] \|
44	\| Team familiarity \| [Assessment] \|
45
46	Pros: [List]
47	Cons: [List]
48
49	### Option B: [Name]
50	[Same format]
51
52	## Trade-off Analysis
53	[Key trade-offs between options with clear reasoning]
54
55	## Consequences
56	- [What becomes easier]
57	- [What becomes harder]
58	- [What we'll need to revisit]
59
60	## Action Items
61	1. [ ] [Implementation step]
62	2. [ ] [Follow-up]
63	```
64
65	## If Connectors Available
66
67	If ~~knowledge base is connected:
68	- Search for prior ADRs and design docs
69	- Find relevant technical context
70
71	If ~~project tracker is connected:
72	- Link to related epics and tickets
73	- Create implementation tasks
74
75	## Tips
76
77	1. State constraints upfront — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.
78	2. Name your options — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives.
79	3. Include non-functional requirements — Latency, cost, team expertise, and maintenance burden matter as much as features.

People who liked this also viewed

6 picks

Type

architecture

4.9kinstalls2.7kforks

View on GitHub

How to install architecture?

anthropics/knowledge-work-plugins/architecture

$npx -y skills add anthropics/knowledge-work-plugins --skill architecture

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# /architecture
2
3	> If you see unfamiliar placeholders or need to check which tools are connected, see [CONNECTORS.md](../../CONNECTORS.md).
4
5	Create an Architecture Decision Record (ADR) or evaluate a system design.
6
7	## Usage
8
9	```
10	/architecture $ARGUMENTS
11	```
12
13	## Modes
14
15	Create an ADR: "Should we use Kafka or SQS for our event bus?"
16	Evaluate a design: "Review this microservices proposal"
17	System design: "Design the notification system for our app"
18
19	See the system-design skill for detailed frameworks on requirements gathering, scalability analysis, and trade-off evaluation.
20
21	## Output — ADR Format
22
23	```markdown
24	# ADR-[number]: [Title]
25
26	Status: Proposed \| Accepted \| Deprecated \| Superseded
27	Date: [Date]
28	Deciders: [Who needs to sign off]
29
30	## Context
31	[What is the situation? What forces are at play?]
32
33	## Decision
34	[What is the change we're proposing?]
35
36	## Options Considered
37
38	### Option A: [Name]
39	\| Dimension \| Assessment \|
40	\|-----------\|------------\|
41	\| Complexity \| [Low/Med/High] \|
42	\| Cost \| [Assessment] \|
43	\| Scalability \| [Assessment] \|
44	\| Team familiarity \| [Assessment] \|
45
46	Pros: [List]
47	Cons: [List]
48
49	### Option B: [Name]
50	[Same format]
51
52	## Trade-off Analysis
53	[Key trade-offs between options with clear reasoning]
54
55	## Consequences
56	- [What becomes easier]
57	- [What becomes harder]
58	- [What we'll need to revisit]
59
60	## Action Items
61	1. [ ] [Implementation step]
62	2. [ ] [Follow-up]
63	```
64
65	## If Connectors Available
66
67	If ~~knowledge base is connected:
68	- Search for prior ADRs and design docs
69	- Find relevant technical context
70
71	If ~~project tracker is connected:
72	- Link to related epics and tickets
73	- Create implementation tasks
74
75	## Tips
76
77	1. State constraints upfront — "We need to ship in 2 weeks" or "Must handle 10K rps" shapes the answer.
78	2. Name your options — Even if you're leaning one way, I'll give a more balanced analysis with explicit alternatives.
79	3. Include non-functional requirements — Latency, cost, team expertise, and maintenance burden matter as much as features.

People who liked this also viewed

6 picks

Type