Project Memory Skill
Use the memory MCP (mcp__memory__*) to persist project knowledge across sessions. This complements personal memory (Qdrant) by focusing on project-specific technical context.
When to Store
Architectural Decisions
Store when you make or discover significant choices:
- •"We chose X pattern over Y because..."
- •"This service uses Z approach for..."
- •"The team decided to structure components as..."
Store: "Auth architecture: JWT tokens with httpOnly cookies, refresh tokens in Redis, 15min access / 7d refresh. Chosen over session-based for API scalability." Tags: ["architecture", "auth", "decisions"]
Solved Problems
Store when you fix non-trivial issues:
- •Complex debugging sessions
- •Performance optimizations
- •Integration gotchas
Store: "Prisma N+1 fix: Use `include` with explicit `select` for nested relations.
findMany({ include: { posts: { select: { id: true, title: true } } } })"
Tags: ["prisma", "performance", "patterns"]
Project-Specific Patterns
Store recurring patterns unique to this codebase:
- •Custom hooks and their usage
- •Service layer conventions
- •Error handling approaches
Store: "Error handling pattern: All API errors extend BaseError with code, statusCode, isOperational. Use errorHandler middleware for centralized catching." Tags: ["patterns", "errors", "conventions"]
Implementation Learnings
Store insights from implementation:
- •"This API requires X header"
- •"This library has quirk Y"
- •"Integration with Z needs..."
When to Recall
Before Implementation
Check memory when starting work that might have prior context:
- •"Implementing auth" → recall auth-related memories
- •"Adding new API endpoint" → recall API patterns
- •"Fixing performance" → recall past optimizations
When Stuck
Query memory when facing challenges:
- •"Similar error before?"
- •"How did we handle this pattern?"
- •"What was the decision about X?"
During Review
Check for consistency with past decisions:
- •"Does this align with our patterns?"
- •"Have we solved this differently elsewhere?"
How to Use
Storing Memories
Use mcp__memory__store or similar tool:
- content: Clear, searchable description
- tags: Relevant categories for retrieval
- metadata: { project: "project-name", type: "decision|pattern|fix|learning" }
Good memory content:
- •Concise but complete
- •Includes the "why" not just "what"
- •Searchable keywords
- •Context for future recall
Recalling Memories
Use mcp__memory__search or similar tool: - query: Natural language description of what you need - tags: Filter by category if known - limit: Start with 5, expand if needed
Effective queries:
- •"authentication implementation decisions"
- •"prisma performance patterns"
- •"error handling conventions"
- •"API rate limiting approach"
Memory Categories
Use consistent tags for organization:
| Tag | Use For |
|---|---|
architecture | System design, service boundaries |
patterns | Recurring code patterns |
decisions | Why we chose X over Y |
fixes | Bug fixes and debugging solutions |
performance | Optimizations, bottlenecks |
integrations | External API quirks, configs |
conventions | Team standards, naming, structure |
gotchas | Non-obvious behaviors, pitfalls |
What NOT to Store
- •Generic programming knowledge (you already know this)
- •Trivial fixes (typos, simple syntax)
- •Temporary workarounds (unless documenting tech debt)
- •Sensitive data (credentials, keys, PII)
Relationship with Personal Memory (Qdrant)
| Project Memory | Personal Memory (Qdrant) |
|---|---|
| Technical decisions | Life experiences |
| Code patterns | Personal preferences |
| Project-specific | Cross-project/personal |
| Implementation details | Skills, relationships |
| Ephemeral (project lifetime) | Permanent (life memory) |
Rule: If it's about THIS project's code → project memory. If it's about Berry → Qdrant.
Session Start Reminder
At session start, consider:
- •What work am I continuing?
- •Are there relevant memories to load?
- •Query: "recent decisions about [current task area]"
Examples
Example 1: Storing an Architecture Decision
After implementing a feature:
"Implemented image generation queue with Bull + Redis. Chose over in-memory because: 1) Survives restarts, 2) Rate limiting per user, 3) Priority queues for premium users. Max 3 concurrent jobs per user, 10 global." Tags: ["architecture", "queue", "images", "decisions"]
Example 2: Recalling Before Work
Starting work on similar feature:
Query: "queue implementation patterns" → Recalls Bull + Redis decision → Apply same patterns for consistency
Example 3: Storing a Gotcha
After debugging:
"Gemini API safetySettings must be top-level param, NOT inside generationConfig. Wasted 2 hours on this. SDK docs are misleading." Tags: ["gotchas", "gemini", "api", "integrations"]
Integration with Workflow
- •Issue Pickup → Recall related context
- •Implementation → Store patterns/decisions as you go
- •PR Creation → Ensure key decisions are stored
- •Review → Check consistency with stored patterns