Publish Sign in

Architecture Decision Records

Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation.

You say
Install this skill Read the source first Free Written by wshobson · unverified publisher
Context cost
3.2k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 12.7 kBtext throughout, nothing executable
Licence
MITfree to use
Last change
—no release on file
Servers it uses
Noneruns standalone

What it does

Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.

Installed, it changes the agent in these ways.

What this skill changes about the agent is not written down here yet. The listing was collected from its source, and the description is in its own SKILL.md.

Expertise

Domain judgement the base model does not have.

documentation
Filed under

Learning & Documentation

The skill itself

This is the whole product. A skill is instructions the model reads, so there is nothing behind the listing you cannot see first — the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md12.7 kB · 442 lines
--- name: architecture-decision-records description: Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes. ---
6# Architecture Decision Records
7
8Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.
9
10## When to Use This Skill
11
12- Making significant architectural decisions
13- Documenting technology choices
14- Recording design trade-offs
15- Onboarding new team members
16- Reviewing historical decisions
17- Establishing decision-making processes
18
19## Core Concepts
20
21### 1. What is an ADR?
22
23An Architecture Decision Record captures:
24
25- **Context**: Why we needed to make a decision
26- **Decision**: What we decided
27- **Consequences**: What happens as a result
28
29### 2. When to Write an ADR
30
31| Write ADR | Skip ADR |
32| -------------------------- | ---------------------- |
33| New framework adoption | Minor version upgrades |
34| Database technology choice | Bug fixes |
35| API design patterns | Implementation details |
36| Security architecture | Routine maintenance |
37| Integration patterns | Configuration changes |
38
39### 3. ADR Lifecycle
40
41```
42Proposed → Accepted → Deprecated → Superseded
43 ↓
44 Rejected
45```
46
47## Templates
48
49### Template 1: Standard ADR (MADR Format)
50
51```markdown
52# ADR-0001: Use PostgreSQL as Primary Database
53
54## Status
55
56Accepted
57
58## Context
59
60We need to select a primary database for our new e-commerce platform. The system
61will handle:
62
63- ~10,000 concurrent users
64- Complex product catalog with hierarchical categories
65- Transaction processing for orders and payments
66- Full-text search for products
67- Geospatial queries for store locator
68
69The team has experience with MySQL, PostgreSQL, and MongoDB. We need ACID
70compliance for financial transactions.
71
72## Decision Drivers
73
74- **Must have ACID compliance** for payment processing
75- **Must support complex queries** for reporting
76- **Should support full-text search** to reduce infrastructure complexity
77- **Should have good JSON support** for flexible product attributes
78- **Team familiarity** reduces onboarding time
79
80## Considered Options
81
82### Option 1: PostgreSQL
83
84- **Pros**: ACID compliant, excellent JSON support (JSONB), built-in full-text
85 search, PostGIS for geospatial, team has experience
86- **Cons**: Slightly more complex replication setup than MySQL
87
88### Option 2: MySQL
89
90- **Pros**: Very familiar to team, simple replication, large community
91- **Cons**: Weaker JSON support, no built-in full-text search (need
92 Elasticsearch), no geospatial without extensions
93
94### Option 3: MongoDB
95
96- **Pros**: Flexible schema, native JSON, horizontal scaling
97- **Cons**: No ACID for multi-document transactions (at decision time),
98 team has limited experience, requires schema design discipline
99
100## Decision
101
102We will use **PostgreSQL 15** as our primary database.
103
104## Rationale
105
106PostgreSQL provides the best balance of:
107
1081. **ACID compliance** essential for e-commerce transactions
1092. **Built-in capabilities** (full-text search, JSONB, PostGIS) reduce
110 infrastructure complexity
1113. **Team familiarity** with SQL databases reduces learning curve
1124. **Mature ecosystem** with excellent tooling and community support
113
114The slight complexity in replication is outweighed by the reduction in
115additional services (no separate Elasticsearch needed).
116
117## Consequences
118
119### Positive
120
121- Single database handles transactions, search, and geospatial queries
122- Reduced operational complexity (fewer services to manage)
123- Strong consistency guarantees for financial data
124- Team can leverage existing SQL expertise
125
126### Negative
127
128- Need to learn PostgreSQL-specific features (JSONB, full-text search syntax)
129- Vertical scaling limits may require read replicas sooner
130- Some team members need PostgreSQL-specific training
131
132### Risks
133
134- Full-text search may not scale as well as dedicated search engines
135- Mitigation: Design for potential Elasticsearch addition if needed
136
137## Implementation Notes
138
139- Use JSONB for flexible product attributes
140- Implement connection pooling with PgBouncer
141- Set up streaming replication for read replicas
142- Use pg_trgm extension for fuzzy search
143
144## Related Decisions
145
146- ADR-0002: Caching Strategy (Redis) - complements database choice
147- ADR-0005: Search Architecture - may supersede if Elasticsearch needed
148
149## References
150
151- [PostgreSQL JSON Documentation](https://www.postgresql.org/docs/current/datatype-json.html)
152- [PostgreSQL Full Text Search](https://www.postgresql.org/docs/current/textsearch.html)
153- Internal: Performance benchmarks in /docs/benchmarks/database-comparison.md
154```
155
156### Template 2: Lightweight ADR
157
158```markdown
159# ADR-0012: Adopt TypeScript for Frontend Development
160
161**Status**: Accepted
162**Date**: 2024-01-15
163**Deciders**: @alice, @bob, @charlie
164
165## Context
166
167Our React codebase has grown to 50+ components with increasing bug reports
168related to prop type mismatches and undefined errors. PropTypes provide
169runtime-only checking.
170
171## Decision
172
173Adopt TypeScript for all new frontend code. Migrate existing code incrementally.
174
175## Consequences
176
177**Good**: Catch type errors at compile time, better IDE support, self-documenting
178code.
179
180**Bad**: Learning curve for team, initial slowdown, build complexity increase.
181
182**Mitigations**: TypeScript training sessions, allow gradual adoption with
183allowJs: true.
184```
185
186### Template 3: Y-Statement Format
187
188```markdown
189# ADR-0015: API Gateway Selection
190
191In the context of **building a microservices architecture**,
192facing **the need for centralized API management, authentication, and rate limiting**,
193we decided for **Kong Gateway**
194and against **AWS API Gateway and custom Nginx solution**,
195to achieve **vendor independence, plugin extensibility, and team familiarity with Lua**,
196accepting that **we need to manage Kong infrastructure ourselves**.
197```
198
199### Template 4: ADR for Deprecation
200
201```markdown
202# ADR-0020: Deprecate MongoDB in Favor of PostgreSQL
203
204## Status
205
206Accepted (Supersedes ADR-0003)
207
208## Context
209
210ADR-0003 (2021) chose MongoDB for user profile storage due to schema flexibility
211needs. Since then:
212
213- MongoDB's multi-document transactions remain problematic for our use case
214- Our schema has stabilized and rarely changes
215- We now have PostgreSQL expertise from other services
216- Maintaining two databases increases operational burden
217
218## Decision
219
220Deprecate MongoDB and migrate user profiles to PostgreSQL.
221
222## Migration Plan
223
2241. **Phase 1** (Week 1-2): Create PostgreSQL schema, dual-write enabled
2252. **Phase 2** (Week 3-4): Backfill historical data, validate consistency
2263. **Phase 3** (Week 5): Switch reads to PostgreSQL, monitor
2274. **Phase 4** (Week 6): Remove MongoDB writes, decommission
228
229## Consequences
230
231### Positive
232
233- Single database technology reduces operational complexity
234- ACID transactions for user data
235- Team can focus PostgreSQL expertise
236
237### Negative
238
239- Migration effort (~4 weeks)
240- Risk of data issues during migration
241- Lose some schema flexibility
242
243## Lessons Learned
244
245Document from ADR-0003 experience:
246
247- Schema flexibility benefits were overestimated
248- Operational cost of multiple databases was underestimated
249- Consider long-term maintenance in technology decisions
250```
251
252### Template 5: Request for Comments (RFC) Style
253
254```markdown
255# RFC-0025: Adopt Event Sourcing for Order Management
256
257## Summary
258
259Propose adopting event sourcing pattern for the order management domain to
260improve auditability, enable temporal queries, and support business analytics.
261
262## Motivation
263
264Current challenges:
265
2661. Audit requirements need complete order history
2672. "What was the order state at time X?" queries are impossible
2683. Analytics team needs event stream for real-time dashboards
2694. Order state reconstruction for customer support is manual
270
271## Detailed Design
272
273### Event Store
274```
275
276OrderCreated { orderId, customerId, items[], timestamp }
277OrderItemAdded { orderId, item, timestamp }
278OrderItemRemoved { orderId, itemId, timestamp }
279PaymentReceived { orderId, amount, paymentId, timestamp }
280OrderShipped { orderId, trackingNumber, timestamp }
281
282```
283
284### Projections
285
286- **CurrentOrderState**: Materialized view for queries
287- **OrderHistory**: Complete timeline for audit
288- **DailyOrderMetrics**: Analytics aggregation
289
290### Technology
291
292- Event Store: EventStoreDB (purpose-built, handles projections)
293- Alternative considered: Kafka + custom projection service
294
295## Drawbacks
296
297- Learning curve for team
298- Increased complexity vs. CRUD
299- Need to design events carefully (immutable once stored)
300- Storage growth (events never deleted)
301
302## Alternatives
303
3041. **Audit tables**: Simpler but doesn't enable temporal queries
3052. **CDC from existing DB**: Complex, doesn't change data model
3063. **Hybrid**: Event source only for order state changes
307
308## Unresolved Questions
309
310- [ ] Event schema versioning strategy
311- [ ] Retention policy for events
312- [ ] Snapshot frequency for performance
313
314## Implementation Plan
315
3161. Prototype with single order type (2 weeks)
3172. Team training on event sourcing (1 week)
3183. Full implementation and migration (4 weeks)
3194. Monitoring and optimization (ongoing)
320
321## References
322
323- [Event Sourcing by Martin Fowler](https://martinfowler.com/eaaDev/EventSourcing.html)
324- [EventStoreDB Documentation](https://www.eventstore.com/docs)
325```
326
327## ADR Management
328
329### Directory Structure
330
331```
332docs/
333├── adr/
334│ ├── README.md # Index and guidelines
335│ ├── template.md # Team's ADR template
336│ ├── 0001-use-postgresql.md
337│ ├── 0002-caching-strategy.md
338│ ├── 0003-mongodb-user-profiles.md # [DEPRECATED]
339│ └── 0020-deprecate-mongodb.md # Supersedes 0003
340```
341
342### ADR Index (README.md)
343
344```markdown
345# Architecture Decision Records
346
347This directory contains Architecture Decision Records (ADRs) for [Project Name].
348
349## Index
350
351| ADR | Title | Status | Date |
352| ------------------------------------- | ---------------------------------- | ---------- | ---------- |
353| [0001](0001-use-postgresql.md) | Use PostgreSQL as Primary Database | Accepted | 2024-01-10 |
354| [0002](0002-caching-strategy.md) | Caching Strategy with Redis | Accepted | 2024-01-12 |
355| [0003](0003-mongodb-user-profiles.md) | MongoDB for User Profiles | Deprecated | 2023-06-15 |
356| [0020](0020-deprecate-mongodb.md) | Deprecate MongoDB | Accepted | 2024-01-15 |
357
358## Creating a New ADR
359
3601. Copy template.md to NNNN-title-with-dashes.md
3612. Fill in the template
3623. Submit PR for review
3634. Update this index after approval
364
365## ADR Status
366
367- **Proposed**: Under discussion
368- **Accepted**: Decision made, implementing
369- **Deprecated**: No longer relevant
370- **Superseded**: Replaced by another ADR
371- **Rejected**: Considered but not adopted
372```
373
374### Automation (adr-tools)
375
376```bash
377# Install adr-tools
378brew install adr-tools
379
380# Initialize ADR directory
381adr init docs/adr
382
383# Create new ADR
384adr new "Use PostgreSQL as Primary Database"
385
386# Supersede an ADR
387adr new -s 3 "Deprecate MongoDB in Favor of PostgreSQL"
388
389# Generate table of contents
390adr generate toc > docs/adr/README.md
391
392# Link related ADRs
393adr link 2 "Complements" 1 "Is complemented by"
394```
395
396## Review Process
397
398```markdown
399## ADR Review Checklist
400
401### Before Submission
402
403- [ ] Context clearly explains the problem
404- [ ] All viable options considered
405- [ ] Pros/cons balanced and honest
406- [ ] Consequences (positive and negative) documented
407- [ ] Related ADRs linked
408
409### During Review
410
411- [ ] At least 2 senior engineers reviewed
412- [ ] Affected teams consulted
413- [ ] Security implications considered
414- [ ] Cost implications documented
415- [ ] Reversibility assessed
416
417### After Acceptance
418
419- [ ] ADR index updated
420- [ ] Team notified
421- [ ] Implementation tickets created
422- [ ] Related documentation updated
423```
424
425## Best Practices
426
427### Do's
428
429- **Write ADRs early** - Before implementation starts
430- **Keep them short** - 1-2 pages maximum
431- **Be honest about trade-offs** - Include real cons
432- **Link related decisions** - Build decision graph
433- **Update status** - Deprecate when superseded
434
435### Don'ts
436
437- **Don't change accepted ADRs** - Write new ones to supersede
438- **Don't skip context** - Future readers need background
439- **Don't hide failures** - Rejected decisions are valuable
440- **Don't be vague** - Specific decisions, specific consequences
441- **Don't forget implementation** - ADR without action is waste
442
In the file
SKILL.md1,730 words
Files1
LicenceMIT
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈80
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
3,095
on trigger
The instruction body, read only when the skill fires.
1.6%
of a 200k window
Ten skills this size would take about 16% of the window before you open a file.
050k100k150k200k context window

3.2k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

Adoption
Installsnone yet
Ratingno reviews yet

The procedure it runs

The procedure has not been published here. It is in the skill’s own SKILL.md, which its author has not sent to the marketplace yet.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

It writes no files and reaches no network. All it changes is how the model reasons and writes.

What it asks for
Writes filesno
Network accessno

Read from the allowed-tools line of this skill’s own SKILL.md. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 12.7 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md12.7 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The MIT licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

# Architecture Decision Records · 3.2k tokens when loaded npx mcprush@latest skill add wshobson/architecture-decision-records

Writes to .claude/skills/architecture-decision-records/ in the current project. Add --global to put it in your home directory instead, for every project.

Which clients pick it up on their own

A skill is a folder of text. A client with a skills folder reads it without being told; everywhere else the same text works, it is just handed to the model rather than found.

Claude Code.claude/skills/
Claude Desktop
ChatGPT
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok.grok/skills/
Zed.agents/skills/
Windsurf.windsurf/skills/
Agent SDK.claude/skills/
HTTP / API
This release
Versionnot versioned
Publishedno release date on file
PriceFree
Referencewshobson/architecture-decision-records

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

v
  • No earlier releases have been published to the marketplace.
Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

—no reviews yet · no installs yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Who can post

Only accounts that have had the skill installed for fourteen days, so a review is written after living with it rather than after reading it. Publishers may reply once.

Who wrote it

WS
wshobson

Publishes on mcprush.

0 servers listed11 skills listednot claimed
Profile
Publisher
Servers0