Records

Design decisions, implementation plans, and feature specs that persist across sessions.

What Are Records?

Records are Markdown files in docs/records/ that document:

  • Architecture decisions
  • Feature specifications
  • Design documents
  • Implementation plans

They start as planning docs and become permanent documentation.

When to Create a Record

SituationRecord?Why
Feature spanning multiple sessionsYesDetails don’t belong in CLAUDE.md
Architecture/design decisionYes”Why X instead of Y” for future reference
Complex implementation planYesSteps + acceptance criteria
Bug fixNoCode comment or commit message suffices
Small changeNoCommit message suffices

Rule of thumb: If you’d write more than 5 lines in CLAUDE.md → create a Record.

Record Format

docs/records/
├── 001-authentication-design.md
├── 002-api-refactoring.md
└── 003-caching-strategy.md

Each Record follows this structure:

# Record 001: Authentication Design
 
**Status:** Done
**Priority:** High
**Date:** 2026-01-15
 
## Problem
 
What problem does this solve?
 
## Solution
 
What approach did we take?
 
## Alternatives Considered
 
What else was considered and why rejected?
 
## Trade-offs
 
Pros and cons of the chosen approach.

Records vs Recent Decisions

LayerPersistenceExample
RecordsPermanentArchitecture decisions, feature specs
Recent DecisionsTemporary (max 20)“pip —user for yt-dlp”
ChatLost after /clearDiscussion context

Recent Decisions are for small choices with a “why” worth remembering, but too small for a full Record.

How Records Are Used

  1. During work: Create Records when making significant decisions
  2. /wrapup: Syncs Records table in CLAUDE.md
  3. /catchup: Loads Records referenced in active work