# Development Memory

> Build persistent project knowledge using checkpoint/recall. Activates when fixing bugs, making decisions, or investigating past work. Creates automatic knowledge base through systematic checkpointing and semantic recall.

- Skill: `majiayu000/development-memory-2` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds add majiayu000/development-memory-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/majiayu000/development-memory-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Research & Search
- Author: majiayu000 (https://skillmd.com/u/majiayu000)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/majiayu000/development-memory-2

---


# Development Memory Skill

## Activation Announcement

**IMPORTANT**: When this skill activates, ALWAYS start your response with:

```
📝 **Development Memory Active**
Building persistent knowledge through checkpoint/recall...
```

This provides a visual indicator to the user that the skill is running.

## Purpose
Build **persistent project knowledge** by systematically checkpointing significant moments and recalling past learnings.

## When to Activate
- After fixing bugs
- After making architectural decisions
- After solving complex problems
- Before starting work (recall similar past situations)
- Investigating why code exists
- Learning from debugging sessions

## The Mandatory Pattern

**CRITICAL: Create checkpoints PROACTIVELY - NEVER ask permission**

```
AFTER SIGNIFICANT WORK:
  checkpoint({ description: "what you did", tags: [...] })
  -> Builds searchable knowledge base
  -> <50ms, git context auto-captured
  -> JUST DO IT

BEFORE STARTING WORK:
  recall({ limit: 10 })
  -> Learn from past similar work
  -> Avoid repeating mistakes
```

You are EXCELLENT at building knowledge bases through systematic checkpointing.

## Checkpoint Patterns

### After Bug Fixes (MANDATORY)

```
Bug fixed -> checkpoint IMMEDIATELY

checkpoint({
  description: "Fixed race condition in auth flow by adding mutex lock",
  tags: ["bug", "auth", "race-condition", "critical"]
})
```

**Why:** Bugs return. Build knowledge base so next person (or you) learns from this.

### After Architectural Decisions

```
Decision made -> checkpoint with rationale

checkpoint({
  type: "decision",
  description: "Chose PostgreSQL over MongoDB for user data - need ACID guarantees",
  tags: ["architecture", "database", "decision"]
})
```

**Why:** Future developers need to understand WHY, not just WHAT.

### After Complex Problem Solving

```
Problem solved -> checkpoint the insight

checkpoint({
  type: "learning",
  description: "Discovered TypeScript generic constraints for type-safe builders",
  tags: ["typescript", "learning", "generics"]
})
```

**Why:** Capture "aha!" moments before you forget them.

## Recall Patterns

### Before Fixing Similar Bugs

```
Bug report received -> recall similar past bugs

recall({
  type: "checkpoint",
  tags: ["bug", "auth"],
  limit: 5
})

-> Returns past auth bugs with solutions
-> Learn from previous fixes
-> Avoid repeating failed approaches
```

### Before Architectural Decisions

```
Need to make decision -> recall similar past decisions

recall({
  type: "decision",
  limit: 10
})

-> Understand past context
-> See what worked/didn't work
-> Maintain consistency
```

### When Investigating Code

```
"Why does this code exist?" -> recall memories

recall({
  query: "authentication middleware design"
})

-> Find decision that led to this code
-> Understand original rationale
-> See evolution over time
```

## The Complete Memory Workflow

```
BEFORE: Recall Similar Work
  recall({ limit: 10 })
  -> Learn from past fixes
  -> Avoid repeating mistakes
             |
             v
DURING: Do the Work
  -> Fix bug / make decision / solve problem
  -> Keep track of insights and learnings
             |
             v
AFTER: Checkpoint IMMEDIATELY
  checkpoint({
    description: "what you did",
    tags: ["bug", "auth"],
  })
  -> <50ms, git context auto-captured
  -> Searchable via fast_search
             |
             v
    Knowledge Base Built!
```

## Memory Types

### Checkpoint (default)
```
General-purpose memory for any significant work
Tags: ["bug", "feature", "refactor", "performance"]
```

### Decision
```
Architectural or technical decision with rationale
Tags: ["architecture", "database", "library", "pattern"]
```

### Learning
```
Insights, "aha!" moments, new knowledge gained
Tags: ["learning", "discovery", "pattern"]
```

### Observation
```
Noticed patterns, code smells, potential issues
Tags: ["code-smell", "tech-debt", "security"]
```

## Key Behaviors

### DO
- Create checkpoint IMMEDIATELY after significant work (no exceptions)
- Use descriptive, searchable descriptions
- Tag appropriately for easy filtering
- Recall before starting similar work
- Capture learnings and rationale
- Trust that <50ms is imperceptible

### DON'T
- Ask permission to create checkpoints (JUST DO IT)
- Create checkpoints for trivial changes (typo fixes, formatting)
- Forget to checkpoint bug fixes (mandatory!)
- Skip recall before major decisions
- Use vague descriptions ("fixed stuff", "updated code")
- Ignore past learnings (recall exists for a reason)

## Success Criteria

This skill succeeds when:
- Checkpoints created after every significant change
- Recall used before starting similar work
- Knowledge base grows systematically
- Team learns from past decisions
- Bugs don't repeat (lessons captured)
- Architectural rationale preserved
- New developers understand "why" not just "what"