Skip to content
cccskills
FreePublished on GitHub

architecture-decision-records

Write and maintain Architecture Decision Records (ADRs), documents explaining important technical choices. Capture the context, options, decision, and consequences, then organize records and track their status so teams can revisit the reasoning.

OriginalShow the original 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.

See how to install

Good for

  • Record the reasons for choosing a framework or database
  • Document design options and their trade-offs
  • Explain past technical decisions to new team members
  • Organize decision reviews and replacement records

Files included (3)

  • SKILL.md4.9 KB
  • references/decision-templates.md5.0 KB
  • references/deprecation-rfc-templates.md3.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Architecture Decision Records

Comprehensive patterns for creating, maintaining, and managing Architecture Decision Records (ADRs) that capture the context and rationale behind significant technical decisions.

When to Use This Skill

  • Making significant architectural decisions
  • Documenting technology choices
  • Recording design trade-offs
  • Onboarding new team members
  • Reviewing historical decisions
  • Establishing decision-making processes

Core Concepts

1. What is an ADR?

An Architecture Decision Record captures:

  • Context: Why we needed to make a decision
  • Decision: What we decided
  • Consequences: What happens as a result

2. When to Write an ADR

Write ADRSkip ADR
New framework adoptionMinor version upgrades
Database technology choiceBug fixes
API design patternsImplementation details
Security architectureRoutine maintenance
Integration patternsConfiguration changes

3. ADR Lifecycle

Proposed → Accepted → Deprecated → Superseded
              ↓
           Rejected

Before drafting a standard, lightweight, or Y-statement ADR, read decision templates.

Before drafting a deprecation ADR or RFC, read deprecation and RFC templates.

ADR Management

Directory Structure

docs/
├── adr/
│   ├── README.md           # Index and guidelines
│   ├── template.md         # Team's ADR template
│   ├── 0001-use-postgresql.md
│   ├── 0002-caching-strategy.md
│   ├── 0003-mongodb-user-profiles.md  # [DEPRECATED]
│   └── 0020-deprecate-mongodb.md      # Supersedes 0003

ADR Index (README.md)

# Architecture Decision Records

This directory contains Architecture Decision Records (ADRs) for [Project Name].

## Index

| ADR                                   | Title                              | Status     | Date       |
| ------------------------------------- | ---------------------------------- | ---------- | ---------- |
| [0001](0001-use-postgresql.md)        | Use PostgreSQL as Primary Database | Accepted   | 2024-01-10 |
| [0002](0002-caching-strategy.md)      | Caching Strategy with Redis        | Accepted   | 2024-01-12 |
| [0003](0003-mongodb-user-profiles.md) | MongoDB for User Profiles          | Deprecated | 2023-06-15 |
| [0020](0020-deprecate-mongodb.md)     | Deprecate MongoDB                  | Accepted   | 2024-01-15 |

## Creating a New ADR

1. Copy `template.md` to `NNNN-title-with-dashes.md`
2. Fill in the template
3. Submit PR for review
4. Update this index after approval

## ADR Status

- **Proposed**: Under discussion
- **Accepted**: Decision made, implementing
- **Deprecated**: No longer relevant
- **Superseded**: Replaced by another ADR
- **Rejected**: Considered but not adopted

Automation (adr-tools)

# Install adr-tools
brew install adr-tools

# Initialize ADR directory
adr init docs/adr

# Create new ADR
adr new "Use PostgreSQL as Primary Database"

# Supersede an ADR
adr new -s 3 "Deprecate MongoDB in Favor of PostgreSQL"

# Generate table of contents (to a separate file, so the hand-written
# index and guidelines in README.md are not overwritten)
adr generate toc > docs/adr/toc.md

# Link related ADRs
adr link 2 "Complements" 1 "Is complemented by"

Review Process

## ADR Review Checklist

### Before Submission

- [ ] Context clearly explains the problem
- [ ] All viable options considered
- [ ] Pros/cons balanced and honest
- [ ] Consequences (positive and negative) documented
- [ ] Related ADRs linked

### During Review

- [ ] At least 2 senior engineers reviewed
- [ ] Affected teams consulted
- [ ] Security implications considered
- [ ] Cost implications documented
- [ ] Reversibility assessed

### After Acceptance

- [ ] ADR index updated
- [ ] Team notified
- [ ] Implementation tickets created
- [ ] Related documentation updated

Best Practices

Do's

  • Write ADRs early - Before implementation starts
  • Keep them short - 1-2 pages maximum
  • Be honest about trade-offs - Include real cons
  • Link related decisions - Build decision graph
  • Update status - Deprecate when superseded

Don'ts

  • Don't change accepted ADRs - Write new ones to supersede
  • Don't skip context - Future readers need background
  • Don't hide failures - Rejected decisions are valuable
  • Don't be vague - Specific decisions, specific consequences
  • Don't forget implementation - ADR without action is waste

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Build and review interfaces against WCAG 2.2 accessibility guidelines. Covers keyboard navigation, screen readers that read interface content aloud, accessible forms, mobile support, and display preferences, helping identify and fix barriers to using a website or app.

  • Audit an interface for accessibility issues
  • Add keyboard navigation and focus management
  • Improve screen reader support for forms
wshobson/agents41KUpdated Oct 18, 2026

ai-debt-detector

FreeSummary

Review AI-generated code for problems hidden behind successful runs. Check failure handling, resource cleanup, unusual inputs, nonexistent dependencies, and departures from project conventions to identify missing safeguards before merging or accepting the work as complete.

  • Audit code after an AI generation session
  • Review an AI-generated pull request before merging
  • Investigate brittle code that appears to work
wshobson/agents41KUpdated Oct 18, 2026

Build Apache Airflow workflows for data pipelines and scheduled jobs. The skill guides task dependencies, retries, waiting for conditions, testing, and deployment, with patterns for tasks that can be safely rerun.

  • Building scheduled data pipelines
  • Designing task order and dependencies
  • Implementing custom tasks and condition checks
wshobson/agents41KUpdated Oct 18, 2026

Plan and carry out an AngularJS to Angular migration, from choosing a rewrite strategy to converting components, services, and routes. Includes a hybrid approach that runs both frameworks together while individual features are migrated.

  • Planning an AngularJS to Angular migration
  • Moving a large app one feature at a time
  • Converting directives into Angular components
wshobson/agents41KUpdated Oct 18, 2026

Identify software protections that hinder inspection, such as debugger detection and obfuscation that makes code harder to understand. Support authorized binary analysis and CTF security challenges with protection findings, bypass strategies, reports, and analysis scripts.

  • Identify protections in an authorized malware sample
  • Plan analysis of a packed executable
  • Implement debugger detection for a CTF challenge
wshobson/agents41KUpdated Oct 18, 2026

Design and review REST and GraphQL APIs with consistent naming, data structures, error responses, pagination for large result sets, and versioning strategies. Helps teams define shared standards and plan changes that existing clients can adopt gradually.

  • Designing a new REST or GraphQL API
  • Reviewing API specifications before implementation
  • Establishing shared API design standards
wshobson/agents41KUpdated Oct 18, 2026

See all skills by wshobson

Report a problem with this skill