EasyPlatform memory-management
[Utilities] Use when saving or retrieving important patterns, decisions, and learnings across sessions. Also use for external memory checkpoints during long-running tasks to prevent context loss. Triggers on keywords like "remember", "save pattern", "recall", "memory", "persist", "knowledge base", "learnings", "checkpoint", "save context", "preserve progress".
git clone https://github.com/duc01226/EasyPlatform
T=$(mktemp -d) && git clone --depth=1 https://github.com/duc01226/EasyPlatform "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/memory-management" ~/.claude/skills/duc01226-easyplatform-memory-management && rm -rf "$T"
.claude/skills/memory-management/SKILL.md<!-- SYNC:critical-thinking-mindset -->[IMPORTANT] Use
to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.TaskCreate
<!-- /SYNC:critical-thinking-mindset --> <!-- SYNC:ai-mistake-prevention -->Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.
<!-- /SYNC:ai-mistake-prevention -->AI Mistake Prevention — Failure modes to avoid on every task:
- Check downstream references before deleting. Deleting components causes documentation and code staleness cascades. Map all referencing files before removal.
- Verify AI-generated content against actual code. AI hallucinates APIs, class names, and method signatures. Always grep to confirm existence before documenting or referencing.
- Trace full dependency chain after edits. Changing a definition misses downstream variables and consumers derived from it. Always trace the full chain.
- Trace ALL code paths when verifying correctness. Confirming code exists is not confirming it executes. Always trace early exits, error branches, and conditional skips — not just happy path.
- When debugging, ask "whose responsibility?" before fixing. Trace whether bug is in caller (wrong data) or callee (wrong handling). Fix at responsible layer — never patch symptom site.
- Assume existing values are intentional — ask WHY before changing. Before changing any constant, limit, flag, or pattern: read comments, check git blame, examine surrounding code.
- Verify ALL affected outputs, not just the first. Changes touching multiple stacks require verifying EVERY output. One green check is not all green checks.
- Holistic-first debugging — resist nearest-attention trap. When investigating any failure, list EVERY precondition first (config, env vars, DB names, endpoints, DI registrations, data preconditions), then verify each against evidence before forming any code-layer hypothesis.
- Surgical changes — apply the diff test. Bug fix: every changed line must trace directly to the bug. Don't restyle or improve adjacent code. Enhancement task: implement improvements AND announce them explicitly.
- Surface ambiguity before coding — don't pick silently. If request has multiple interpretations, present each with effort estimate and ask. Never assume all-records, file-based, or more complex path.
Quick Summary
Goal: Persist patterns, decisions, and task progress across sessions using two complementary memory systems.
Workflow:
- File Checkpoints — Save task-specific context to
every 30-60 minplans/reports/checkpoint-*.md - MCP Memory Graph — Store reusable knowledge (patterns, decisions, bug fixes) as typed entities with relations
- Recovery — On context loss, find latest checkpoint via Glob, read it, resume from documented next steps
Key Rules:
- Use file checkpoints for task-specific progress; MCP memory for cross-session knowledge
- Create checkpoints before expected context compaction and at key milestones
- Always include Recovery Instructions in checkpoint files
Be skeptical. Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence percentages (Idea should be more than 80%).
Memory Management & Knowledge Persistence
Build and maintain a knowledge graph of patterns, decisions, and learnings across sessions. Also provides external file-based checkpoints for long-running tasks.
Two Memory Systems
| System | Storage | Use Case | Persistence |
|---|---|---|---|
| MCP Memory Graph | In-memory graph database | Patterns, decisions, learnings | Cross-session |
| File Checkpoints | | Task progress, analysis | Permanent files |
Use MCP Memory for reusable knowledge. Use File Checkpoints for task-specific context.
Part 1: File-Based External Memory (Checkpoints)
When to Create File Checkpoints
- Starting complex multi-step tasks (investigation, planning, implementation)
- Every 30-60 minutes during long tasks
- At key milestones
- Before expected context compaction
- After completing significant analysis phases
Checkpoint File Location
Files saved to:
plans/reports/checkpoint-{timestamp}-{slug}.md
CHECKPOINT_CREATE Protocol
Create a checkpoint file with this structure:
# Memory Checkpoint: {Task Description} > Created: {ISO timestamp} > Task Type: {investigation|planning|bugfix|feature|docs} > Phase: {current phase number/name} ## Task Context {What you're working on and why} ## Key Findings {Critical discoveries and insights - be specific with file paths and line numbers} ## Files Analyzed | File | Purpose | Status | | ----------------- | ----------- | -------- | | path/file.cs:line | description | ✅/🔄/⏳ | ## Progress - [x] Completed items - [ ] In-progress items - [ ] Remaining items ## Important Context {Information that must be preserved - decisions, assumptions, rationale} ## Next Steps 1. {Immediate next action} 2. {Following action} ## Recovery Instructions {Exact steps to resume: which file to read, which line to continue from}
CHECKPOINT_RECOVER Protocol
When recovering from a checkpoint:
- Search for latest checkpoint:
Glob("plans/reports/checkpoint-*.md") - Read the checkpoint file
- Load any referenced analysis files
- Review Progress section
- Continue from documented Next Steps
- Create new checkpoint after resuming
Auto-Checkpoint (PreCompact Hook)
The system automatically creates checkpoints before context compaction. These auto-checkpoints are minimal - for better context preservation, create manual checkpoints using
/checkpoint.
Part 2: MCP Memory Graph (Knowledge Persistence)
Memory Entity Types
| Entity Type | Purpose | Examples |
|---|---|---|
| Recurring code patterns | CQRS, Validation, Repository |
| Architectural/design decisions | Why we chose X over Y |
| Bug solutions for future reference | Race condition fixes |
| Service ownership and responsibilities | Growth owns Employees |
| End-of-session progress snapshots | Task progress, next steps |
| Cross-service dependencies | Growth depends on Accounts |
| Patterns to avoid | Don't call side effects in cmd |
Memory Operations
Create New Entity
mcp__memory__create_entities([ { name: 'EmployeeValidationPattern', entityType: 'Pattern', observations: [ 'Use project validation fluent API (see docs/project-reference/backend-patterns-reference.md)', 'Chain with .And() and .AndAsync()', "Return validation result, don't throw", 'Location: {Service}.Application/UseCaseCommands/' ] } ]);
Create Relationships
mcp__memory__create_relations([ { from: 'ServiceA', to: 'ServiceB', relationType: 'depends_on' }, { from: 'EmployeeEntity', to: 'UserEntity', relationType: 'syncs_from' } ]);
Add Observations
mcp__memory__add_observations([ { entityName: 'EmployeeValidationPattern', contents: [ 'Also supports .AndNot() for negative validation', 'Use .Of<ICqrsRequest>() for type conversion (see docs/project-reference/backend-patterns-reference.md)' ] } ]);
Search Knowledge
// Search by query mcp__memory__search_nodes({ query: 'validation pattern' }); // Open specific entities mcp__memory__open_nodes({ names: ['EmployeeValidationPattern', 'ServiceAModule'] }); // Read entire graph mcp__memory__read_graph();
Delete Outdated Knowledge
// Delete entities mcp__memory__delete_entities({ entityNames: ['OutdatedPattern'] }); // Delete specific observations mcp__memory__delete_observations([ { entityName: 'EmployeeValidationPattern', observations: ['Outdated observation text'] } ]); // Delete relations mcp__memory__delete_relations([ { from: 'OldService', to: 'NewService', relationType: 'depends_on' } ]);
When to Save to Memory
Always Save
- Discovered Patterns: New code patterns not in documentation
- Bug Solutions: Complex bugs with non-obvious solutions
- Service Boundaries: Which service owns what
- Architectural Decisions: Why a particular approach was chosen
- Anti-Patterns: Mistakes to avoid
Save at Session End
// Session summary template mcp__memory__create_entities([ { name: `Session_${taskName}_${date}`, entityType: 'SessionSummary', observations: [ `Task: ${taskDescription}`, `Completed: ${completedItems.join(', ')}`, `Remaining: ${remainingItems.join(', ')}`, `Key Files: ${keyFiles.join(', ')}`, `Discoveries: ${discoveries.join(', ')}`, `Next Steps: ${nextSteps.join(', ')}` ] } ]);
Memory Retrieval Patterns
Session Start Protocol
// 1. Search for related context const results = mcp__memory__search_nodes({ query: 'current feature or task keywords' }); // 2. Load relevant entities mcp__memory__open_nodes({ names: results.entities.map(e => e.name) }); // 3. Check for incomplete sessions mcp__memory__search_nodes({ query: 'SessionSummary Remaining' });
Before Implementation
// Check for existing patterns mcp__memory__search_nodes({ query: 'CQRS command pattern' }); // Check for anti-patterns mcp__memory__search_nodes({ query: 'AntiPattern command' }); // Check for related decisions mcp__memory__search_nodes({ query: 'Decision validation' });
After Bug Fix
// Save the fix mcp__memory__create_entities([ { name: `BugFix_${bugName}`, entityType: 'BugFix', observations: [ `Symptom: ${symptomDescription}`, `Root Cause: ${rootCause}`, `Solution: ${solution}`, `Files: ${affectedFiles.join(', ')}`, `Prevention: ${preventionTip}` ] } ]);
Knowledge Graph Structure
┌─────────────────────────────────────────────────────────────┐ │ Project Knowledge │ ├─────────────────────────────────────────────────────────────┤ │ Services │ │ ├── ServiceA ──depends_on──> AccountsService │ │ ├── ServiceB ──depends_on──> AccountsService │ │ └── ServiceC ──depends_on──> AccountsService │ │ │ │ Patterns │ │ ├── CQRSCommandPattern │ │ ├── CQRSQueryPattern │ │ ├── EntityEventPattern │ │ └── ValidationPattern │ │ │ │ Entities │ │ ├── Employee ──syncs_from──> User │ │ ├── Company ──syncs_from──> Organization │ │ └── LeaveRequest ──owned_by──> ServiceA │ │ │ │ Sessions │ │ ├── Session_LeaveRequest_2025-01-15 │ │ └── Session_EmployeeImport_2025-01-14 │ └─────────────────────────────────────────────────────────────┘
Importance Scoring
When saving observations, prioritize:
| Score | Criteria |
|---|---|
| 10 | Critical bug fixes, security issues |
| 8-9 | Architectural decisions, service boundaries |
| 6-7 | Code patterns, best practices |
| 4-5 | Session summaries, progress notes |
| 1-3 | Temporary notes, exploration results |
Memory Maintenance
Weekly Cleanup
// Find old session summaries (> 30 days) mcp__memory__search_nodes({ query: 'SessionSummary' }); // Delete outdated sessions mcp__memory__delete_entities({ entityNames: ['Session_OldTask_2024-12-01'] });
Consolidation
When multiple observations cover same topic:
// 1. Read existing entity mcp__memory__open_nodes({ names: ['PatternName'] }); // 2. Delete fragmented observations mcp__memory__delete_observations([ { entityName: 'PatternName', observations: ['Fragment 1', 'Fragment 2'] } ]); // 3. Add consolidated observation mcp__memory__add_observations([ { entityName: 'PatternName', contents: ['Consolidated comprehensive observation'] } ]);
Quick Reference
Create:
mcp__memory__create_entities / mcp__memory__create_relations
Read: mcp__memory__read_graph / mcp__memory__open_nodes / mcp__memory__search_nodes
Update: mcp__memory__add_observations
Delete: mcp__memory__delete_entities / mcp__memory__delete_observations / mcp__memory__delete_relations
Part 3: Integration with Workflows
Long-Running Task Memory Pattern
All long-running workflows should follow this pattern:
┌─────────────────────────────────────────────────────────┐ │ TASK START │ │ └── Create initial checkpoint with task context │ │ └── Initialize todo list │ │ │ │ EVERY 20-30 OPERATIONS │ │ └── Update checkpoint with progress │ │ └── Update todo list status │ │ │ │ MILESTONE REACHED │ │ └── Create detailed checkpoint │ │ └── Save key findings to MCP memory (if reusable) │ │ │ │ BEFORE COMPACTION (auto via PreCompact hook) │ │ └── Auto-checkpoint created by system │ │ │ │ AFTER COMPACTION / SESSION RESUME │ │ └── Read latest checkpoint │ │ └── Search MCP memory for relevant context │ │ └── Continue from documented Next Steps │ │ │ │ TASK COMPLETE │ │ └── Final checkpoint with summary │ │ └── Save reusable patterns to MCP memory │ │ └── Clean up temporary checkpoints │ └─────────────────────────────────────────────────────────┘
Checkpoint Naming Convention
| Type | Format | Example |
|---|---|---|
| Manual checkpoint | | |
| Auto checkpoint | | |
| Analysis notes | | |
| Task notes | | Used by feature-implementation |
Related Commands & Skills
| Command/Skill | Purpose |
|---|---|
| Create manual memory checkpoint |
| Load project context |
| Manually trigger context compaction |
| Generate progress summary |
| Uses task analysis notes pattern |
| Uses investigation logs |
| Uses analysis report pattern |
Memory Decision Matrix
| Context Type | Storage | Why |
|---|---|---|
| Task progress | File checkpoint | Specific to current task |
| Code patterns | MCP memory | Reusable across sessions |
| Bug solutions | MCP memory | Helps future debugging |
| Service boundaries | MCP memory | Architectural knowledge |
| Investigation findings | File checkpoint | Task-specific analysis |
| Architectural decisions | MCP memory | Long-term knowledge |
Related
learncontext-optimization
Closing Reminders
- MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using
BEFORE startingTaskCreate - MANDATORY IMPORTANT MUST ATTENTION search codebase for 3+ similar patterns before creating new code
- MANDATORY IMPORTANT MUST ATTENTION cite
evidence for every claim (confidence >80% to act)file:line - MANDATORY IMPORTANT MUST ATTENTION add a final review todo task to verify work quality <!-- SYNC:critical-thinking-mindset:reminder -->
- MUST ATTENTION apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact. <!-- /SYNC:critical-thinking-mindset:reminder --> <!-- SYNC:ai-mistake-prevention:reminder -->
- MUST ATTENTION apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction. <!-- /SYNC:ai-mistake-prevention:reminder -->