project-memory
Persist and recall project-specific context across sessions. Store architectural decisions, patterns, solutions, and learnings. Automatically recall relevant context when facing similar problems.
SKILL.md
Full skill instructions
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
