# Create Clear Architecture Decision Records

Important technical decisions often lose their context, alternatives, and rationale. This skill creates structured ADRs and supports consistent review, indexing, and lifecycle management.

## Install

```bash
npx skillstore add sickn33/architecture-decision-records
```

## Metadata

- Status: approved
- Slug: sickn33-architecture-decision-records
- Skillstore revision: r2
- Version status: missing
- Tree hash: f1ba9ccbbd9d72b4b205e5dd01eb0719247fe08b9cc67875304e13bb41b07974
- Author: sickn33
- GitHub username: sickn33
- License: MIT
- Repository: https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/architecture-decision-records
- Ref: 86d877f219e2131f05dd5b37c5e329c71c7b8ec4
- Supported tools: Claude, Codex, Claude Code
- Audit status: complete
- Agent install advisory: allowed
- Manual install advisory: allowed
- Artifact signature: available
- Audit attestation: unavailable
- Human verification: not\_verified
- Risk factors: external\_commands, network
- Quality score: 78
- Quality tier: bronze
- Public page: https://skillstore.pages.dev/skills/sickn33-architecture-decision-records
- Manifest: https://skillstore.pages.dev/api/skills/sickn33-architecture-decision-records/manifest

## Capabilities

- Creates standard, lightweight, Y-statement, deprecation, and RFC-style decision records.
- Documents context, decision drivers, considered options, rationale, consequences, risks, and references.
- Builds ADR indexes with identifiers, titles, statuses, and dates.
- Explains proposed, accepted, rejected, deprecated, and superseded lifecycle states.
- Provides review checklists for submission, stakeholder consultation, acceptance, and follow-up.
- Shows optional adr-tools commands for creating, linking, superseding, and indexing records.

## Use Cases

- Record a Technology Choice: Compare database, framework, or platform options and capture the selected option with its rationale and consequences.
- Review a Proposed Decision: Check whether an ADR covers viable alternatives, affected teams, security, cost, reversibility, and implementation follow-up.
- Understand Historical Context: Use indexed and linked ADRs to learn why current systems exist and which earlier decisions were superseded.

## Prompt Templates

### Create a Basic ADR

```
Create a lightweight ADR for [decision]. Include status, context, decision, positive consequences, negative consequences, and mitigations.
```

### Compare Architecture Options

```
Draft a standard ADR comparing [options] for [system]. Evaluate each option against [drivers] and explain the final recommendation.
```

### Supersede an Existing ADR

```
Write an ADR that supersedes [ADR identifier]. Explain changed conditions, migration phases, risks, mitigations, and links between both records.
```

### Develop an RFC-Style Decision

```
Create an RFC-style ADR for [proposal]. Cover motivation, detailed design, drawbacks, alternatives, unresolved questions, implementation plan, and review criteria.
```

## Limitations

- Does not validate assumptions against the project environment or current production data.
- Does not replace security, legal, cost, or compliance review by qualified stakeholders.
- Requires project context, constraints, options, and decision ownership for useful results.
- Does not execute adr-tools commands or maintain repository files automatically.

## Best Practices

- Write the ADR before implementation and involve affected stakeholders during review.
- State concrete decision drivers and present both benefits and costs for every viable option.
- Preserve accepted records, then create linked ADRs when decisions change or become obsolete.

## Anti Patterns

- Do not use ADRs for routine maintenance, minor patches, or isolated implementation details.
- Do not omit context, rejected alternatives, negative consequences, or unresolved risks.
- Do not silently edit accepted decisions or leave indexes and related records outdated.

## Security Audit

- Audited at: 2026-07-23T20:11:29.707\+00:00
- Summary: All 32 static findings are false positives caused by Markdown fences, inline literals, documentation links, and a manual command example. No prompt injection, covert execution, credential access, or exfiltration intent was found in SKILL.md.

## Stats

- Views: 125
- Downloads: 10
- Favorites: 1
- Popularity score: 0
