Git-Based Knowledge Graph Memory System for Claude Code
by mourad-ghafiri · v1.0.0
Productivity
ClawHub
8.1
/ 10
1 evaluations
3.6k Downloads
Overview
Provides a persistent, branch-aware knowledge graph memory for coding projects by storing structured notes in git notes, enabling an LLM to silently remember and retrieve project decisions, preferences, tasks, and context across sessions.
Key Advantages
1.Deep integration with git branches: each branch has its own memory, with inheritance and merge support via git notes.
2.Rich memory model: supports decisions, preferences, tasks, learnings, notes, progress, and auto-detected types based on language cues.
3.Powerful retrieval: topic-based `get`, full-text `search`, detailed `recall`, entity listing, and entity-specific queries.
4.Lifecycle-aware design: `sync --start` and `sync --end` provide session context and summaries to maintain continuity.
5.Structured, tagged storage: JSON-based memories with tags, importance levels, entities, and evolution notes for precise updates and querying.
Use Cases
- Long-running software projects where architectural decisions and trade-offs need to be remembered per branch.
- Maintaining user- or team-specific preferences (coding style, frameworks, tools) across multiple coding sessions in the same repo.
- Tracking tasks, blockers, and progress for a feature branch in a codebase without introducing new app-level dependencies.
- Quickly recalling why certain design decisions were made by searching previous discussions and notes.
- Supporting multi-branch workflows where each feature branch maintains its own context and then merges memories after git merges.
Evaluation Scores
8.1
/ 10
Reliability
8.0
Functionality
9.1
Usability
8.5
Safety
6.8
Performance
8.3
Compatibility
8.2
Based on 1 evaluation · Latest: 3/19/2026
Download Trend
Loading...
Evaluation History (1)
8.1/103/19/2026▼
OS: darwin-arm64LLM: google/gemini-2.5-flash-lite
### Quick judgment
High-functionality, well-specified git-backed memory system that fits naturally into code-centric, branch-based workflows. Very strong on features and retrieval, but it introduces silent, persistent storage with limited user visibility, which is a notable safety/consent concern.
### Key strengths
- **Rich, structured memory model:** Decisions, preferences, tasks, notes, learnings, progress, with auto-detected types and importance flags.
- **Git-native and branch-aware:** Uses git notes per branch, inheritance from main, and a `merge-branch` workflow to keep memories aligned with git history.
- **Powerful retrieval & maintenance:** `get`, `search`, `recall`, `update`, `evolve`, `forget`, plus entity listing and entity-specific queries.
- **Session lifecycle support:** `sync --start` returns a compact context overview (branch, top topics, critical and high-importance memories), and `sync --end` summarizes sessions.
- **Well-documented behavior:** Clear examples for all commands, output formats for different tiers, and good guidance on what should and should not be remembered.
### Main risks and limitations
- **Silent persistence & transparency:** Explicitly forbids asking about or announcing memory operations. This can conflict with best practices around user consent and awareness, especially for long-term storage.
- **Secret handling relies on model judgment:** It advises not to store secrets, but enforcement is heuristic and can be error-prone in practice.
- **Git dependency and edge cases:** Requires a git repo and working git notes; complex git operations (rebases, non-standard workflows, incorrect `merge-branch` usage) may impact reliability if not handled carefully.
- **Local scope only:** Designed around a single repo directory; not suitable for non-git contexts or cross-repo/global memory without additional tooling.
### Recommended scenarios
- **Best fit:** Long-lived software projects in git where persistent context, decisions, and preferences per branch significantly improve continuity—especially in IDE or code-assistant environments.
- **Use with caution:** Environments with strict privacy/compliance requirements, or where users must be explicitly informed about persistent memory. In such contexts, extra policy or tooling may be needed to ensure transparency and control over what gets stored.
Comments (0)
No comments yet. Be the first!