# Architecture Decision Records

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

- Repository: https://github.com/rmyndharis/antigravity-skills (1913 stars)
- Category: Writing
- License: MIT
- Last updated: 2026-10-14
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add rmyndharis/antigravity-skills --skill architecture-decision-records -g -a claude-code -y`
Codex: `npx skills add rmyndharis/antigravity-skills --skill architecture-decision-records -g -a codex -y`
Cursor: `npx skills add rmyndharis/antigravity-skills --skill architecture-decision-records -g -a cursor -y`
Gemini CLI: `npx skills add rmyndharis/antigravity-skills --skill architecture-decision-records -g -a gemini-cli -y`

## 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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Architecture Decision Records

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

## Use this skill when

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

## Do not use this skill when

- You only need to document small implementation details
- The change is a minor patch or routine maintenance
- There is no architectural decision to capture

## Instructions

1. Capture the decision context, constraints, and drivers.
2. Document considered options with tradeoffs.
3. Record the decision, rationale, and consequences.
4. Link related ADRs and update status over time.

## 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 ADR | Skip ADR |
|-----------|----------|
| New framework adoption | Minor version upgrades |
| Database technology choice | Bug fixes |
| API design patterns | Implementation details |
| Security architecture | Routine maintenance |
| Integration patterns | Configuration changes |

### 3. ADR Lifecycle

```
Proposed → Accepted → Deprecated → Superseded
              ↓
           Rejected
```

## Templates

### Template 1: Standard ADR (MADR Format)

```markdown
# ADR-0001: Use PostgreSQL as Primary Database

## Status

Accepted

## Context

We need to select a primary database for our new e-commerce platform. The system
will handle:
- ~10,000 concurrent users
- Complex product catalog with hierarchical categories
- Transaction processing for orders and payments
- Full-text search for products
- Geospatial queries for store locator

The rest: https://github.com/rmyndharis/antigravity-skills/blob/HEAD/skills/architecture-decision-records/SKILL.md