CLAUDE.md Configuration Examples for MemoryGraph

Ready-to-use CLAUDE.md snippets for configuring Claude to proactively use MemoryGraph.

Quick Start (Minimal)

Add this to ~/.claude/CLAUDE.md for basic memory functionality:

## Memory Protocol

### REQUIRED: Before Starting Work
You MUST use `recall_memories` before any task. Query by project, tech, or task type.

### REQUIRED: Automatic Storage Triggers
Store memories on ANY of:
- **Git commit** → what was fixed/added
- **Bug fix** → problem + solution
- **Version release** → summarize changes
- **Architecture decision** → choice + rationale
- **Pattern discovered** → reusable approach

### Timing Mode (default: on-commit)
`memory_mode: immediate | on-commit | session-end`

### Memory Fields
- **Type**: solution | problem | code_pattern | fix | error | workflow
- **Title**: Specific, searchable (not generic)
- **Content**: Accomplishment, decisions, patterns
- **Tags**: project, tech, category (REQUIRED)
- **Importance**: 0.8+ critical, 0.5-0.7 standard, 0.3-0.4 minor
- **Relationships**: Link related memories when they exist

Do NOT wait to be asked. Memory storage is automatic.

Recommended (Comprehensive)

Add this to ~/.claude/CLAUDE.md for full proactive memory usage:

## Memory Protocol

### REQUIRED: Before Starting Work
You MUST use `recall_memories` before any task. Query by project, tech, or task type.

### REQUIRED: Automatic Storage Triggers
Store memories on ANY of:
- **Git commit** → what was fixed/added
- **Bug fix** → problem + solution
- **Version release** → summarize changes
- **Architecture decision** → choice + rationale
- **Pattern discovered** → reusable approach

### Timing Mode (default: on-commit)
`memory_mode: immediate | on-commit | session-end`

### Memory Fields
- **Type**: solution | problem | code_pattern | fix | error | workflow
- **Title**: Specific, searchable (not generic)
- **Content**: Accomplishment, decisions, patterns
- **Tags**: project, tech, category (REQUIRED)
- **Importance**: 0.8+ critical, 0.5-0.7 standard, 0.3-0.4 minor
- **Relationships**: Link related memories when they exist

### Common Relationship Patterns
- Solutions SOLVE problems
- Fixes ADDRESS errors
- Patterns APPLY_TO projects
- Decisions IMPROVE previous approaches
- Errors TRIGGER problems
- Changes CAUSE issues

### Session Management
At the end of each session:
1. Use `store_memory` with type=task to summarize what was accomplished
2. Include what's next in the content
3. Tag with project name and date

Do NOT wait to be asked. Memory storage is automatic.

Project-Specific Configuration

Add this to .claude/CLAUDE.md in your project root for project-specific memory:

## Project: [Your Project Name]

### Memory Storage Protocol
This project uses MemoryGraph for team knowledge sharing.

When working on this project:
1. Before starting: "What do you remember about [component]?"
2. After solving issues: Store the problem and solution, link them
3. After implementing features: Store the pattern used
4. At session end: Store a task summary

### Tagging Convention
Always tag memories with:
- `project:[project-name]`
- `component:[auth|api|database|frontend|etc]`
- `type:[fix|feature|optimization|refactor]`
- Relevant technologies: `fastapi`, `react`, `postgresql`, etc.

### Memory Types for This Project
- **solution**: Working implementations (API endpoints, features)
- **problem**: Issues we encountered (performance, bugs)
- **code_pattern**: Reusable patterns (error handling, validation)
- **decision**: Architecture choices (why we chose X over Y)
- **task**: Sprint work, feature completion

### Example Memory Flow
When fixing a bug:
1. Store problem: type=problem, title="API timeout under load"
2. Store solution: type=solution, title="Fixed with connection pooling"
3. Link them: solution SOLVES problem
4. Both tagged: `project:myapp`, `component:api`, `postgresql`

Advanced: Team Collaboration

For teams using shared memory, add this to ~/.claude/CLAUDE.md:

## Team Memory Protocol

### Shared Memory Guidelines
This team uses MemoryGraph for collective knowledge. Follow these practices:

#### Storage Standards
- **Be descriptive**: Others will search for your memories
- **Include context**: Why decisions were made, not just what
- **Tag consistently**: Use agreed-upon tags (see below)
- **Link everything**: Create relationships between related memories

#### Team Tagging Convention
Required tags for all team memories:
- `team:[team-name]` - Which team stored this
- `project:[project-name]` - Which project it applies to
- `component:[component-name]` - Which part of the system
- Technology tags: `python`, `fastapi`, `postgresql`, `react`, etc.

#### Memory Ownership
- Add your name or initials in tags: `author:[yourname]`
- Update existing memories if you discover new information
- Leave a comment in the content explaining changes

#### Session Routine
**Start of day**:
- "What did the team work on yesterday?"
- "Recall any issues in [component] I should know about"

**During work**:
- Store solutions to non-trivial problems
- Link to existing problems when you solve them
- Update memories if approach changes

**End of day**:
- "Store a summary of what I accomplished today"
- Tag with `daily-summary` and current date

#### Common Memory Flows
**Bug fixing**:
1. Check: "Have we seen [error] before?"
2. Store: Problem (if new) + Solution
3. Link: solution SOLVES problem
4. Tag: `bug-fix`, component, technologies

**Feature development**:
1. Check: "What patterns have we used for [use case]?"
2. Store: Implementation as code_pattern
3. Link: pattern APPLIES_TO project
4. Tag: `feature`, component, pattern-name

**Architecture decisions**:
1. Store: Decision with full rationale
2. Link: decision IMPROVES previous_approach (if applicable)
3. Tag: `architecture`, `decision`, affected components

### Sprint Workflows
**Sprint planning**:
- "Recall problems from last sprint"
- "What technical debt did we identify?"

**Sprint retro**:
- "What solutions worked well this sprint?"
- Store top improvements as decision memories

**Onboarding**:
- New team members: "Catch me up on [project/component]"
- Returns: Decisions, patterns, known issues

Domain-Specific Examples

Web Development

## Memory Protocol - Web Development

### Store These Patterns
- **API Design**: Endpoint structure, error handling, validation
- **Authentication**: JWT flows, session management, OAuth patterns
- **Database**: Query optimization, migration patterns, schema decisions
- **Frontend**: Component patterns, state management, performance tricks
- **Deployment**: CI/CD configs, environment setup, rollback procedures

### Common Relationships
- API endpoint patterns APPLY_TO projects
- Performance optimizations IMPROVE slow_queries
- Security fixes ADDRESS vulnerabilities
- New patterns REPLACE deprecated_patterns

### Typical Session Flow
1. Start: "Recall API patterns for [feature]"
2. Develop: [Implementation]
3. Store: "Store this error handling pattern"
4. Link: pattern APPLIES_TO this_project
5. End: "Store feature completion summary"

Data Science / ML

## Memory Protocol - Data Science

### Store These Patterns
- **Model Training**: Hyperparameters, architectures, training tricks
- **Data Pipeline**: ETL patterns, preprocessing steps, validation
- **Experiments**: Results, what worked/didn't, insights
- **Deployment**: Serving patterns, monitoring, drift detection

### Common Relationships
- Model improvements IMPROVE baseline_model
- Feature engineering SOLVES data_quality_problem
- Experiment results CONFIRM hypothesis
- New approach CONTRADICTS previous_assumption

### Experiment Tracking
After each experiment:
1. Store: Results with type=solution or type=problem
2. Tag: `experiment`, model-type, dataset-name
3. Link: If improvement, link: new_model IMPROVES previous_model
4. Include: Metrics, parameters, insights in content

DevOps / Infrastructure

## Memory Protocol - DevOps

### Store These Patterns
- **Deployment**: CI/CD configs, rollback procedures
- **Monitoring**: Alert configurations, runbook procedures
- **Incidents**: Root causes, resolutions, preventions
- **Infrastructure**: IaC patterns, networking configs, security setups

### Common Relationships
- Incident resolution SOLVES incident
- Infrastructure change CAUSES issue (if it breaks)
- Runbook procedure ADDRESSES alert_type
- New config IMPROVES previous_config

### Incident Response Flow
1. Alert fires: "Recall similar incidents for [service]"
2. Debug: [Investigation]
3. Store incident: type=problem with root cause
4. Store resolution: type=solution with fix steps
5. Link: solution SOLVES incident
6. Update runbook: Store updated procedure

Testing Your Configuration

After adding memory protocols to CLAUDE.md, verify they work:

Test 1: Check Protocol Recognition

You: "What's our memory protocol?"
Expected: Claude should reference the protocol from your CLAUDE.md

Test 2: Proactive Storage

You: [Fix a bug together]
Expected: Claude should suggest storing the solution or ask if you want to store it

Test 3: Proactive Recall

You: "Let's work on authentication"
Expected: Claude should proactively check: "What do you remember about authentication?"

Test 4: Relationship Creation

You: "Store this solution: [description]"
Expected: Claude should ask if it relates to any existing memories or search for related problems

Test 5: Session Wrap-Up

You: "Let's wrap up"
Expected: Claude should suggest storing a session summary

Troubleshooting

Claude Isn't Using Memory Tools

Issue: Claude doesn't proactively store or recall memories.

Solutions:

Verify CLAUDE.md is loaded: Ask "What's in my CLAUDE.md?" - Claude should see your memory protocol
Be explicit initially: Use trigger phrases like "Store this..." until the habit forms
Check file location:
- Global: ~/.claude/CLAUDE.md
- Project: .claude/CLAUDE.md in project root
Restart Claude Code: After editing CLAUDE.md, restart for changes to take effect

Claude Stores Too Many/Few Memories

Too many: Make protocol more specific about what to store:

### Storage Criteria
Only store memories when:
- Solution is non-trivial (not a simple one-liner)
- Problem is likely to recur
- Pattern is reusable across contexts
- Decision has long-term impact

Too few: Make protocol more proactive:

### Proactive Storage
After ANY of these events, ALWAYS store a memory:
- Solving a bug that took >30 minutes
- Implementing a new feature
- Making an architecture decision
- Discovering a useful pattern
- Encountering an error and fixing it

Memories Aren't Well-Formatted

Add formatting requirements to your protocol:

### Memory Content Template
Always structure content like this:

**What**: Brief description of what was done
**Why**: Reasoning and context
**How**: Key implementation details
**Trade-offs**: What was considered and why this was chosen
**Related**: Links to docs, PRs, or other resources

Migration from Other Systems

From CLAUDE.md Static Notes

If you've been storing knowledge in CLAUDE.md as static text:

Before (in CLAUDE.md):

## Known Issues
- Redis timeout: increase connection pool to 50
- API rate limiting: use exponential backoff

After (using MemoryGraph):

## Memory Protocol
[Memory protocol from examples above]

## Static Knowledge (Keep for rules/preferences)
- Code style: 2-space indentation
- Commit messages: conventional commits format

Migration:

Ask Claude: "Convert these known issues to memory entries"
Claude will use store_memory for each
Create relationships between related issues
Remove from CLAUDE.md (now in memory graph)
Keep only static rules/preferences in CLAUDE.md

From Notion/Confluence/Docs

If your team has external documentation:

Strategy:

Keep docs for: Long-form guides, API docs, architecture diagrams
Move to MemoryGraph: Solutions, problems, decisions, patterns, incidents
Link them: Store memory with link to doc in content

Example:

Content: "Use repository pattern for database access. See full guide: https://docs.company.com/db-patterns"
Type: code_pattern
Tags: database, pattern, architecture

Navigation Menu

CLAUDE.md Configuration Examples for MemoryGraph

Quick Start (Minimal)

Recommended (Comprehensive)

Project-Specific Configuration

Advanced: Team Collaboration

Domain-Specific Examples

Web Development

Data Science / ML

DevOps / Infrastructure

Testing Your Configuration

Test 1: Check Protocol Recognition

Test 2: Proactive Storage

Test 3: Proactive Recall

Test 4: Relationship Creation

Test 5: Session Wrap-Up

Troubleshooting

Claude Isn't Using Memory Tools

Claude Stores Too Many/Few Memories

Memories Aren't Well-Formatted

Migration from Other Systems

From CLAUDE.md Static Notes

From Notion/Confluence/Docs

Related Documentation

FilesExpand file tree

CLAUDE_MD_EXAMPLES.md

Latest commit

History

CLAUDE_MD_EXAMPLES.md

File metadata and controls

CLAUDE.md Configuration Examples for MemoryGraph

Quick Start (Minimal)

Recommended (Comprehensive)

Project-Specific Configuration

Advanced: Team Collaboration

Domain-Specific Examples

Web Development

Data Science / ML

DevOps / Infrastructure

Testing Your Configuration

Test 1: Check Protocol Recognition

Test 2: Proactive Storage

Test 3: Proactive Recall

Test 4: Relationship Creation

Test 5: Session Wrap-Up

Troubleshooting

Claude Isn't Using Memory Tools

Claude Stores Too Many/Few Memories

Memories Aren't Well-Formatted

Migration from Other Systems

From CLAUDE.md Static Notes

From Notion/Confluence/Docs

Related Documentation