| name | development-memory |
| description | 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. |
| allowed-tools | mcp__miller__checkpoint, mcp__miller__recall, mcp__miller__fast_search |
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"
