{"owner":"tirth8205","repo":"code-review-graph","hasSkills":true,"totalSkillsCount":12,"totalTokensCount":9638,"categories":["anthropic-skill","copilot-instructions","project-spec","claude-rule","gemini-rule","root-instruction"],"hasMcp":true,"mcpConfig":{"mcpServers":{"code-review-graph":{"command":"npx","args":["-y","@modelcontextprotocol/server-code-review-graph"]}}},"found":["skills/review-changes/SKILL.md","skills/review-pr/SKILL.md",".github/copilot-instructions.md","docs/architecture.md","skills/review-delta/SKILL.md","skills/refactor-safely/SKILL.md","CLAUDE.md","skills/debug-issue/SKILL.md","GEMINI.md","skills/build-graph/SKILL.md","AGENTS.md","skills/explore-codebase/SKILL.md"],"skills":{"skills/review-changes/SKILL.md":"---\nname: review-changes\ndescription: Perform a structured code review using change detection and impact\n---\n\n## Review Changes\n\nReview a change set with risk scores and blast radius from the knowledge graph.\n\n### Steps\n\n1. Call `detect_changes_tool` for risk-scored changed functions, test gaps and affected flows.\n2. Call `get_affected_flows_tool` only when you need the steps of an affected flow.\n3. For each high-risk function, call `query_graph_tool` with `pattern=\"tests_for\"` to check test coverage.\n4. Call `get_impact_radius_tool` when the blast radius is not clear from step 1.\n5. Suggest specific test cases for untested changes.\n\n### Output Format\n\nGroup findings by risk level (high, medium, low). For each finding give what changed and why it matters, its test coverage, and the suggested fix. End with a merge recommendation.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","skills/review-pr/SKILL.md":"---\nname: review-pr\ndescription: Review a PR or branch diff using the knowledge graph for full structural context. Outputs a structured review with blast-radius analysis.\nargument-hint: \"[PR number or branch name]\"\n---\n\n# Review PR\n\nReview all commits of a pull request or branch against its base branch.\n\n## Steps\n\n1. Identify the changes. With a branch name run `git diff --name-only main...<branch>`; otherwise diff the current branch against `main` (or `master`). Use that ref as `base` below.\n2. Call `get_minimal_context_tool(task=\"review PR\", base=\"main\")`. If it returns `status: not_ready`, call `build_or_update_graph_tool()` and continue.\n3. Call `detect_changes_tool(base=\"main\", detail_level=\"minimal\")` for risk-scored changed functions, test gaps and affected flows across the whole branch.\n4. For high-risk functions call `query_graph_tool(pattern=\"callers_of\", target=\"<function>\")` and `query_graph_tool(pattern=\"tests_for\", target=\"<function>\")`. Flag public API changes whose callers were not updated.\n5. Call `get_review_context_tool(base=\"main\")` for source snippets, or `get_impact_radius_tool(base=\"main\")` for the full dependent list, only when step 3 leaves a high-risk item unclear.\n6. Read the changed source of the highest-impact files first. Do not load whole files unless the change needs it.\n\n## Output\n\n```\n## PR Review: <title>\n\n### Summary\n<1-3 sentences>\n\n### Risk\n- Overall: Low / Medium / High\n- Blast radius: <n> files, <m> functions\n- Test coverage: <covered> of <changed> changed functions\n\n### Files\n#### <path>\n- Changes: <what>\n- Impact: <who depends on it>\n- Issues: <bugs, style, concerns>\n\n### Missing Tests\n- <function> in <file>\n\n### Recommendations\n1. <action>\n```\n\n## Tips\n\n- Use `semantic_search_nodes_tool` to find related code the PR may have missed.\n",".github/copilot-instructions.md":"<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","docs/architecture.md":"# Architecture\n\n## Overview\n\n`code-review-graph` keeps a persistent, incrementally updated graph of a codebase in SQLite\nand exposes it through a CLI and an MCP server. AI coding tools query the graph for\nstructural context (callers, dependents, tests, impact) instead of reading whole files.\nClaude Code is one supported client among several.\n\n## Components\n\n```text\n┌──────────────────────────────────────────────────────────────┐\n│                    AI coding clients / CLI                   │\n│                                                              │\n│  MCP clients              Hooks / watch mode                 │\n│  ├── Codex                └── incremental update             │\n│  ├── Claude Code, CodeBuddy Code                             │\n│  ├── Cursor, Windsurf, Zed, Continue                         │\n│  └── Gemini CLI, Qwen, Qoder, Copilot, OpenCode              │\n│          │                        │                          │\n│          ▼                        ▼                          │\n│  ┌────────────────────────────────────────────┐              │\n│  │      MCP Server (stdio or localhost HTTP)  │              │\n│  │                                            │              │\n│  │  30 MCP tools + 5 MCP prompts              │              │\n│  │  ├── Core: build, impact, query, review,   │              │\n│  │  │   search, traverse, embed, stats, docs  │              │\n│  │  ├── Flows: list, get, affected            │              │\n│  │  ├── Communities: list, get, architecture  │              │\n│  │  ├── Analysis: detect_changes, refactor,   │              │\n│  │  │   apply_refactor, hubs, bridges, gaps   │              │\n│  │  ├── Wiki: generate, get_page              │              │\n│  │  └── Multi-repo: list_repos, cross_search  │              │\n│  └────────────────┬───────────────────────────┘              │\n└───────────────────┼──────────────────────────────────────────┘\n                    │\n        ┌───────────┼───────────────┐\n        ▼           ▼               ▼\n   ┌─────────┐ ┌─────────┐  ┌─────────────┐\n   │ Parser  │ │  Graph  │  │ Incremental │\n   │         │ │  Store  │  │   Engine    │\n   └────┬────┘ └────┬────┘  └──────┬──────┘\n        │           │              │\n        ▼           ▼              ▼\n   Tree-sitter   SQLite DB      git/svn diff\n   grammars      (.code-review- subprocess\n                 graph/\n                 graph.db)\n```\n\n## Modules\n\nAll modules live in `code_review_graph/`.\n\n| Module | Role |\n|---|---|\n| `parser.py` | Tree-sitter multi-language parser plus targeted fallbacks; emits nodes and edges per file |\n| `custom_languages.py` | Config-driven languages from `.code-review-graph/languages.toml` |\n| `graph.py` | `GraphStore`: SQLite storage, queries, impact radius |\n| `migrations.py` | Versioned schema migrations, currently v11 (see `schema.md`) |\n| `incremental.py` | File collection and ignore rules, git/SVN change detection, full and incremental builds, post-build resolvers |\n| `postprocessing.py` | `run_post_processing()`: endpoint resolution, signatures, FTS sync, flows, communities, embedding refresh |\n| `python_resolver.py`, `jedi_resolver.py`, `tsconfig_resolver.py`, `spring_resolver.py`, `event_resolver.py`, `temporal_resolver.py`, `rescript_resolver.py`, `hcl_resolver.py`, `scoped_resolver.py` | Post-build cross-file resolution |\n| `flows.py` | Execution flow detection and criticality scoring |\n| `communities.py` | Leiden community detection (igraph) with a file-based fallback |\n| `search.py` | Hybrid search: FTS5 BM25 plus vector similarity |\n| `embeddings.py` | Embedding providers and the `embeddings` table |\n| `changes.py`, `refactor.py`, `analysis.py`, `hints.py`, `uncertainty.py`, `context_savings.py` | Change risk analysis, refactoring helpers, hub/bridge/gap analysis, response hints, empty-result markers, savings estimates |\n| `tools/` | MCP tool implementations, split by domain |\n| `main.py`, `prompts.py` | FastMCP server (30 tools, 5 prompts) |\n| `cli.py`, `daemon.py`, `daemon_cli.py` | CLI and the multi-repo watch daemon |\n| `visualization.py`, `exports.py`, `wiki.py`, `graph_diff.py`, `memory.py`, `forget.py` | HTML visualisation, export formats, wiki generation, snapshot diffing, Q&A memory, file removal |\n| `skills.py`, `uninstall.py`, `registry.py`, `enrich.py`, `http_origin_guard.py`, `config_keys.py`, `constants.py` | Platform install/uninstall, multi-repo registry, hook enrichment, HTTP Host/Origin checks, shared helpers |\n| `eval/`, `token_benchmark.py` | Evaluation framework and standalone token benchmark |\n\n## Data Flow\n\n### Full build (`incremental.full_build()`)\n1. `collect_all_files()` lists tracked files (`git ls-files` when git is available, so\n   untracked and gitignored files are skipped) and applies `.code-review-graphignore`.\n2. Each file is read once; the bytes are hashed (SHA-256) and passed to\n   `CodeParser.parse_bytes()`, which walks the Tree-sitter tree and emits nodes and edges.\n3. `GraphStore.store_file_nodes_edges()` (or `store_file_batch()`) replaces the file's rows\n   in one transaction, storing the hash for change detection.\n4. Metadata is written: `last_updated`, `last_build_type`, and the git or SVN head.\n5. Post-build resolvers qualify cross-file targets, then `run_post_processing()` computes\n   signatures, rebuilds the FTS index, traces flows, detects communities and refreshes\n   embeddings, unless skipped. An incremental update rewrites only the changed files'\n   FTS entries (`search.update_fts_index`); a full build rebuilds the index.\n\n### Incremental update (`incremental.incremental_update()`)\n1. `get_changed_files()` asks the VCS for changed paths (git diff by default; SVN is\n   supported).\n2. `find_dependents()` collects files with `IMPORTS_FROM`, `CALLS`, `INHERITS` or\n   `IMPLEMENTS` edges into the changed files, up to two hops and 500 files.\n3. Changed and dependent files whose hash differs from the stored one are re-parsed; the\n   rest are skipped.\n4. Only those files' rows are replaced, then post-processing runs as for a full build.\n\n### Review context (`tools/review.py: get_review_context()`)\n1. Changed files come from a git diff or an explicit list.\n2. `GraphStore.get_impact_radius()` finds the impacted nodes (see below).\n3. Source snippets are extracted for the changed regions only, within a file budget.\n4. `_generate_review_guidance()` adds warnings: changed functions without `TESTED_BY`\n   edges, more than 20 impacted nodes, and inheritance changes.\n5. `attach_context_savings()` adds an estimate of the tokens saved against reading the\n   files, labelled `estimated: true`.\n\nThe MCP entry points are `get_review_context_tool`, `get_impact_radius_tool` and\n`detect_changes_tool` in `main.py`.\n\n## Impact Analysis\n\n`GraphStore.get_impact_radius()` delegates to `get_impact_radius_sql()`, a bounded\nbest-score relaxation run inside SQLite. Setting `CRG_BFS_ENGINE=networkx` selects the older\nPython-side traversal instead.\n\n1. Seed with every node in the changed files.\n2. For each depth step (default 2, `CRG_MAX_IMPACT_DEPTH`), propagate along edges in the\n   direction set per edge kind in `constants.IMPACT_EDGE_DIRECTIONS`: dependency-shaped\n   edges such as `CALLS` and `IMPORTS_FROM` flow from target to source (callers and\n   importers of changed code), `TESTED_BY` flows from production code to its tests, and\n   `CONTAINS` is not expanded because the whole file is already seeded.\n3. Each reached node keeps its best score: previous score x edge weight\n   (`constants.IMPACT_EDGE_WEIGHTS`, default 0.5) x depth decay\n   (`CRG_IMPACT_DEPTH_DECAY`, default 0.6).\n4. Results are ordered by score and cut at `CRG_MAX_IMPACT_NODES` (default 500); the\n   response says whether it was truncated.\n\n## Storage\n\nOne SQLite database, `.code-review-graph/graph.db`, in WAL mode so readers are not blocked\nduring updates. Tables: `nodes`, `edges`, `metadata`, `flows`, `flow_memberships`,\n`communities`, `nodes_fts` (FTS5), `nodes_fts_state`, `community_summaries`,\n`flow_snapshots`, `risk_index`, and\n`embeddings` (created by `EmbeddingStore` in the same file). Columns, indexes and the\nmigration history are in [schema.md](schema.md).\n\nNodes are identified by qualified name: the file path for File nodes, `path::name` for\ntop-level symbols and `path::Class.method` for members.\n\n## Parsing\n\nThe parser walks the Tree-sitter tree directly rather than using tree-sitter query files,\nwhich keeps it independent of query syntax differences between grammar versions. Per-language\nnode type tables (`_CLASS_TYPES`, `_FUNCTION_TYPES` and similar in `parser.py`) drive:\n\n1. Class, function and type extraction with names, parameters, return types and bases.\n2. Call detection inside function bodies.\n3. Import resolution to module paths, refined later by the post-build resolvers.\n\nLanguages without a grammar can be added through `.code-review-graph/languages.toml`\n(`docs/CUSTOM_LANGUAGES.md`). Some formats (notebooks, Vue and Svelte SFCs, SQL, Ansible,\nSpring configuration) use targeted parsers instead of Tree-sitter.\n\n## Visualisation\n\n`visualization.py` writes a self-contained HTML file with a D3.js force-directed graph of the\nnodes and edges, with filters by node and edge kind and a search box.\n","skills/review-delta/SKILL.md":"---\nname: review-delta\ndescription: Review only changes since last commit using impact analysis. Token-efficient delta review with automatic blast-radius detection.\nargument-hint: \"[file or function name]\"\n---\n\n# Review Delta\n\nReview only the changed code and its blast radius.\n\n## Steps\n\n1. Call `get_minimal_context_tool(task=\"review changes\")`. If it returns `status: not_ready`, call `build_or_update_graph_tool()` and continue.\n2. Call `detect_changes_tool(detail_level=\"minimal\")` for risk-scored changed functions, test gaps and affected flows. Changes come from `git diff` against `HEAD~1`; if the argument names a file, pass it in `changed_files`.\n3. Call `get_review_context_tool(detail_level=\"minimal\")` when you need source snippets for the changed areas and `review_guidance` (untested functions, wide blast radius, inheritance changes).\n4. For each untested high-risk function, confirm with `query_graph_tool(pattern=\"tests_for\", target=\"<function>\")`.\n5. Use `detail_level=\"standard\"` only for a high-risk item the minimal output leaves unclear. Do not load whole files unless a snippet is not enough.\n\n## Report\n\n- Summary: one line\n- Risk: low, medium or high, from the blast radius\n- Issues: bugs, missing tests, style\n- Blast radius: impacted files and functions\n- Recommendations\n","skills/refactor-safely/SKILL.md":"---\nname: refactor-safely\ndescription: Plan and execute safe refactoring using dependency analysis\n---\n\n## Refactor Safely\n\nPlan a refactor from the dependency graph and apply renames from a preview.\n\n### Steps\n\n1. Call `refactor_tool` with `mode=\"suggest\"` for refactoring candidates, or `mode=\"dead_code\"` for unreferenced code.\n2. For a rename, call `refactor_tool` with `mode=\"rename\"`, `old_name` and `new_name`. Check the returned edit list before applying.\n3. Call `apply_refactor_tool` with the returned `refactor_id` to apply the rename.\n4. Before a large refactor, call `get_impact_radius_tool` and `get_affected_flows_tool` to see the dependents and critical paths involved.\n5. Call `find_large_functions_tool` to find functions worth splitting.\n6. After the change, call `detect_changes_tool` to confirm the impact matches the plan.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","CLAUDE.md":"# CLAUDE.md - Project Context for Claude Code\n\n## Project Overview\n\ncode-review-graph is a local-first knowledge graph for code review. It parses a repository with Tree-sitter (plus targeted fallbacks), stores nodes and edges in SQLite, updates the graph incrementally from Git changes, and serves compact context over MCP and the CLI to AI coding tools. Supported platforms are the entries in `PLATFORMS` in `skills.py`: Claude Code, Codex, Cursor, Windsurf, Zed, Continue, OpenCode, Antigravity, Gemini CLI, Qwen Code, Kiro, Qoder, GitHub Copilot, GitHub Copilot CLI, Hermes Agent and CodeBuddy Code.\n\n## Graph Tool Usage (Token-Efficient)\n\nWhen using code-review-graph MCP tools:\n\n1. Call `get_minimal_context_tool(task=\"<description>\")` first. It costs about 100 tokens and gives the overview.\n2. Use `detail_level=\"minimal\"` on every later call unless that is not enough.\n3. Prefer `query_graph_tool` with a specific target over broad `list_*` calls.\n4. Follow the `next_tool_suggestions` field in each response.\n5. Target: at most 5 tool calls and 800 tokens of graph context per task.\n\nAll registered tool names end in `_tool`. The 30 tools are defined in `main.py`.\n\n## Architecture\n\nCore package `code_review_graph/` (Python 3.10+):\n\n- `main.py`: FastMCP server entry point. Registers 30 tools and 5 prompts.\n- `tools/`: tool implementations by domain: `build.py`, `query.py`, `review.py`, `context.py`, `flows_tools.py`, `community_tools.py`, `refactor_tools.py`, `docs.py`, `registry_tools.py`, `analysis_tools.py`; shared helpers in `_common.py`.\n- `prompts.py`: 5 MCP prompts (review_changes, architecture_map, debug_issue, onboard_developer, pre_merge_check).\n- `cli.py`: the `code-review-graph` command. `daemon.py` and `daemon_cli.py`: the `crg-daemon` multi-repo watch daemon.\n- `parser.py`: Tree-sitter multi-language parser with fallbacks for notebooks and other formats. `custom_languages.py`: languages defined in `.code-review-graph/languages.toml` (see docs/CUSTOM_LANGUAGES.md).\n- `graph.py`: SQLite graph store (nodes, edges, impact analysis). `migrations.py`: schema migrations; the current schema version is 13 and must equal `SUPPORTED_SCHEMA_VERSION` in the VS Code extension (CI checks this).\n- `incremental.py`: full build, Git/SVN change detection, incremental update, stale-file reconciliation, watch mode. `postprocessing.py`: shared post-build pipeline (signatures, flows, communities, FTS).\n- Post-build resolvers: `python_resolver.py`, `jedi_resolver.py` (optional `enrichment` extra), `spring_resolver.py`, `event_resolver.py`, `temporal_resolver.py`, `config_keys.py`, `scoped_resolver.py` (PHP, Rust, C#), `rescript_resolver.py`, `hcl_resolver.py`, `tsconfig_resolver.py` (tsconfig and jsconfig path aliases).\n- `flows.py`: execution flows and criticality. `communities.py`: Leiden via igraph (optional) or file-based grouping, plus the architecture overview. `analysis.py`: hub and bridge nodes, knowledge gaps, surprise scoring, suggested questions.\n- `search.py`: FTS5 keyword search combined with optional vector search. `embeddings.py`: providers for local sentence-transformers, OpenAI-compatible endpoints, Google Gemini, MiniMax and Voyage AI.\n- `changes.py`: risk-scored change analysis. `refactor.py`: rename preview, dead code, suggestions. `hints.py`: `next_tool_suggestions`. `uncertainty.py`: `confidence` notes on empty results. `context_savings.py`: estimated context-savings metadata.\n- `visualization.py`: D3.js HTML graph (D3 is bundled in `assets/`). `exports.py`: JSON, GraphML, Neo4j Cypher, Obsidian, SVG. `wiki.py`: Markdown wiki. `graph_diff.py`: snapshot diffing. `memory.py`: stored Q&A feedback.\n- `skills.py`: `install` (platform MCP configs, hooks, skills, instruction blocks). `_legacy_instructions.py`: instruction blocks shipped by earlier releases. `jsonc.py`: comment-preserving JSONC tokenising and splices, shared by install and uninstall so neither flattens a commented config. `uninstall.py`: reverses `install`. `enrich.py`: PreToolUse hook enrichment. `forget.py`: drops files from the graph. `registry.py`: multi-repo registry. `http_origin_guard.py`: Host/Origin checks for `serve --http`. `token_benchmark.py` and `eval/`: benchmarks. `constants.py`: shared constants.\n- `docs/LLM-OPTIMIZED-REFERENCE.md`: the reference served by `get_docs_section_tool`.\n\nVS Code extension: `code-review-graph-vscode/` (TypeScript, separate `package.json` and `tsconfig.json`). Reads `.code-review-graph/graph.db` directly.\n\nDatabase: `.code-review-graph/graph.db` (SQLite, WAL mode).\n\n## Key Commands\n\n```bash\n# Development\nuv run pytest tests/ --tb=short -q\nuv run ruff check code_review_graph/\nuv run mypy code_review_graph/ --ignore-missing-imports --no-strict-optional\n\n# Graph\nuv run code-review-graph build              # full build\nuv run code-review-graph update             # incremental update\nuv run code-review-graph status             # graph statistics\nuv run code-review-graph detect-changes     # risk-scored change analysis (read-only)\nuv run code-review-graph forget PATH        # drop files from the graph\nuv run code-review-graph serve              # MCP server (stdio; --http for localhost)\nuv run code-review-graph wiki               # Markdown wiki\nuv run code-review-graph register <path>    # add a repo to the multi-repo registry\nuv run code-review-graph eval               # benchmarks\nuv run code-review-graph --help             # full command list\n```\n\n## Code Conventions\n\n- Line length 100 (ruff). Python 3.10+.\n- SQL: parameterised queries with `?` placeholders. Never format values into SQL strings.\n- Errors: catch specific exceptions and log with `logger.warning` or `logger.error`.\n- Threads: `threading.Lock` around shared caches; SQLite opened with `check_same_thread=False`.\n- Node names: pass through `_sanitize_name()` before returning them to MCP clients.\n- File reads: read the bytes once, hash them, then parse the same bytes.\n\n## Security Invariants\n\n- No `eval()`, `exec()`, `pickle` or `yaml.unsafe_load()`.\n- No `shell=True` in subprocess calls.\n- `_validate_repo_root()` requires an existing directory containing `.git`, `.svn` or `.code-review-graph`, which blocks path traversal through `repo_root`.\n- `_sanitize_name()` strips control characters and caps names at 256 characters.\n- `escH()` in `visualization.py` escapes HTML entities including quotes and backticks; `</script>` is escaped inside embedded JSON.\n- D3.js is bundled and loaded with an SRI hash; the CDN fallback carries the same hash.\n- `http_origin_guard.py` validates Host and Origin for `serve --http`.\n- API keys come from environment variables only.\n\n## Test Structure\n\n`tests/` holds over 100 pytest modules. The main groups:\n\n- Core: `test_parser.py`, `test_graph.py`, `test_incremental.py`, `test_tools.py`, `test_main.py`, `test_cli*.py`.\n- Features: `test_flows.py`, `test_communities.py`, `test_changes.py`, `test_refactor.py`, `test_search.py`, `test_hints.py`, `test_prompts.py`, `test_wiki.py`, `test_embeddings.py`, `test_eval.py`, `test_registry.py`, `test_migrations.py`, `test_uncertainty.py`, `test_context_savings.py`, `test_token_budget.py` (per-tool token budgets).\n- Languages: `test_multilang.py`, `test_custom_languages.py`, `test_notebook.py`, plus per-language files such as `test_php_*.py`, `test_spring_*.py`, `test_kotlin_imports.py`, `test_go_embeddings.py`, `test_cpp_*.py`, `test_typescript_node_extensions.py`, `test_tsconfig_resolver.py`, `test_hcl_parser.py`, `test_dbt_parser.py`, `test_ansible_parser.py`.\n- Regression modules are named after the behaviour they pin, not the PR that produced them. The originating PR number goes in the module docstring.\n- Watch and daemon: `test_watch_*.py`, `test_daemon*.py`.\n- Install and platforms: `test_skills.py`, `test_cli_install.py`, `test_uninstall.py`, `test_git_hook_worktree.py`, `test_hermes_install.py`, `test_qoder_bundled_skills.py`, `test_installer_ownership.py` (what install may rewrite and what belongs to the user), `test_released_shapes.py` (reads the hooks and MCP entries every released tag wrote and requires them to still be recognised; needs tags, skips without them), `test_platform_lifecycle.py` (opt-in marker `platform_lifecycle`).\n- Windows: `test_windows_compat.py`, `test_windows_path_identity.py`.\n- Docs and GitHub Action: `test_documentation.py`, `test_action_render.py`.\n- Distribution gate: `test_packaging.py`, marked `packaging` and **skipped by default**. Builds a wheel and an sdist with `python -m build`, installs each into its own virtual environment, and drives the installed program with the checkout out of reach. Needs network and takes a couple of minutes. Run it before a release with `uv run --python 3.13 python -m pytest tests/test_packaging.py -m packaging`.\n- `tests/fixtures/`: sample files per supported language.\n\n## CI Pipeline\n\n`.github/workflows/ci.yml`:\n\n- lint: ruff on Python 3.10.\n- type-check: mypy.\n- security: bandit with the exemptions in `pyproject.toml`.\n- schema-sync: `LATEST_VERSION` in `migrations.py` must equal `SUPPORTED_SCHEMA_VERSION` in the VS Code extension.\n- test: pytest on Python 3.10, 3.11, 3.12 and 3.13; coverage must be at least 65%.\n- google-embeddings: constructs the Google provider with the `google-embeddings` and `all` extras.\n- windows-native: a subset of the suite on windows-latest.\n\n<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->\n## Beads Issue Tracker\n\nThis project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.\n\n### Quick Reference\n\n```bash\nbd ready              # Find available work\nbd show <id>          # View issue details\nbd update <id> --claim  # Claim work\nbd close <id>         # Complete work\n```\n\n### Rules\n\n- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists\n- Run `bd prime` for detailed command reference and session close protocol\n- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files\n\n## Branching Model\n\nThree long-lived branches, one direction: feature PR → `staging` (default) → `testing` → `main` → tag → PyPI.\nOpen every PR against `staging`. Never push to or open PRs against `testing` or `main`; those only\nreceive promotion PRs, always merged with a merge commit.\n\n`staging` → `testing` is automatic: `.github/workflows/auto-promote.yml` runs once a day and merges\nthe promotion PR when `staging` is ahead, every required check is green, and the promotion gate has\nnot failed on `testing`. The decision lives in `scripts/auto_promote.py`. It merges only a PR it\nopened itself — same repository, correctly aimed, labelled `auto-promotion`, pinned to the commit\nwhose checks were read — so a promotion PR you open by hand is left alone. It needs Settings →\nActions → General → Workflow permissions → *Allow GitHub Actions to create and approve pull\nrequests*. **Promotion to `main` is never automatic** — the maintainer opens and merges that PR by\nhand. Full rules in CONTRIBUTING.md \"Branching and promotion\".\n\n## Session Completion\n\n**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.\n\n**MANDATORY WORKFLOW:**\n\n1. **File issues for remaining work** - Create issues for anything that needs follow-up\n2. **Run quality gates** (if code changed) - Tests, linters, builds\n3. **Update issue status** - Close finished work, update in-progress items\n4. **PUSH TO REMOTE** - This is MANDATORY:\n   ```bash\n   git pull --rebase\n   bd dolt push\n   git push\n   git status  # MUST show \"up to date with origin\"\n   ```\n5. **Clean up** - Clear stashes, prune remote branches\n6. **Verify** - All changes committed AND pushed\n7. **Hand off** - Provide context for next session\n\n**CRITICAL RULES:**\n- Work is NOT complete until `git push` succeeds\n- NEVER stop before pushing - that leaves work stranded locally\n- NEVER say \"ready to push when you are\" - YOU must push\n- If push fails, resolve and retry until it succeeds\n<!-- END BEADS INTEGRATION -->\n\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","skills/debug-issue/SKILL.md":"---\nname: debug-issue\ndescription: Systematically debug issues using graph-powered code navigation\n---\n\n## Debug Issue\n\nTrace a bug through the knowledge graph before reading source.\n\n### Steps\n\n1. Call `semantic_search_nodes_tool` to find code related to the issue.\n2. Call `query_graph_tool` with `callers_of` and `callees_of` to trace the call chain in both directions.\n3. Call `get_flow_tool` for the execution path that reaches the suspect code. Its entry point is where the bug is triggered.\n4. Call `detect_changes_tool` to check whether a recent change caused the issue.\n5. Call `get_impact_radius_tool` on the suspect files to see what a fix would affect.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","GEMINI.md":"# Gemini\n\nAgent rules for this repository live in [AGENTS.md](AGENTS.md). Project\ncontext (architecture, commands, conventions, tests) lives in\n[CLAUDE.md](CLAUDE.md). Both apply to Gemini CLI and Antigravity.\n\nThis file used to be a byte-identical copy of\n[.github/copilot-instructions.md](.github/copilot-instructions.md), which only\nexists because Copilot reads that exact path. Keeping a pointer here means the\ninstructions are maintained in one place.\n","skills/build-graph/SKILL.md":"---\nname: build-graph\ndescription: Build or update the code review knowledge graph. Run this first to initialize, or let hooks keep it updated automatically.\nargument-hint: \"[full]\"\n---\n\n# Build Graph\n\nBuild or incrementally update the knowledge graph for this repository.\n\n## Steps\n\n1. Call `list_graph_stats_tool`. If `last_updated` is null, the graph has never been built.\n2. For a first build, or when the argument is `full`, call `build_or_update_graph_tool(full_rebuild=True)`. Otherwise call `build_or_update_graph_tool()` for an incremental update.\n3. Report the response: `status` (`ok`, `partial` or `error`) and `summary`.\n\n## When to Use\n\n- First set-up of a repository, or after a branch switch or large refactor.\n- When the graph looks stale. Hooks installed by `code-review-graph install` run an update after each edit and before each commit, so manual builds are rarely needed.\n\n## Notes\n\n- The database is `.code-review-graph/graph.db` in the repository root.\n- Binary files, dependency and build directories, and patterns in `.code-review-graphignore` are skipped.\n- For the list of supported languages call `get_docs_section_tool(section_name=\"languages\")`.\n","AGENTS.md":"# Agent Instructions\n\nProject context (architecture, commands, conventions, tests) is in `CLAUDE.md`. This file holds the rules for every coding agent working in this repository.\n\n## Non-Interactive Shell Commands\n\n`cp`, `mv` and `rm` may be aliased with `-i` on some systems, which leaves an agent waiting for a y/n answer that never comes. Always pass the non-interactive flag:\n\n```bash\ncp -f source dest\nmv -f source dest\nrm -f file\nrm -rf directory\ncp -rf source dest\n```\n\nOther commands that may prompt: `scp` and `ssh` (`-o BatchMode=yes`), `apt-get` (`-y`), `brew` (`HOMEBREW_NO_AUTO_UPDATE=1`).\n\n<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->\n## Beads Issue Tracker\n\nThis project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.\n\n### Quick Reference\n\n```bash\nbd ready              # Find available work\nbd show <id>          # View issue details\nbd update <id> --claim  # Claim work\nbd close <id>         # Complete work\n```\n\n### Rules\n\n- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists\n- Run `bd prime` for detailed command reference and session close protocol\n- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files\n\n## Session Completion\n\n**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.\n\n**MANDATORY WORKFLOW:**\n\n1. **File issues for remaining work** - Create issues for anything that needs follow-up\n2. **Run quality gates** (if code changed) - Tests, linters, builds\n3. **Update issue status** - Close finished work, update in-progress items\n4. **PUSH TO REMOTE** - This is MANDATORY:\n   ```bash\n   git pull --rebase\n   bd dolt push\n   git push\n   git status  # MUST show \"up to date with origin\"\n   ```\n5. **Clean up** - Clear stashes, prune remote branches\n6. **Verify** - All changes committed AND pushed\n7. **Hand off** - Provide context for next session\n\n**CRITICAL RULES:**\n- Work is NOT complete until `git push` succeeds\n- NEVER stop before pushing - that leaves work stranded locally\n- NEVER say \"ready to push when you are\" - YOU must push\n- If push fails, resolve and retry until it succeeds\n<!-- END BEADS INTEGRATION -->\n\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","skills/explore-codebase/SKILL.md":"---\nname: explore-codebase\ndescription: Navigate and understand codebase structure using the knowledge graph\n---\n\n## Explore Codebase\n\nUse the code-review-graph MCP tools to find your way around the codebase.\n\n### Steps\n\n1. Call `get_architecture_overview_tool` for the community structure. Call `list_communities_tool`, then `get_community_tool`, only for the modules you need.\n2. Call `semantic_search_nodes_tool` to find a function or class by name or keyword.\n3. Call `query_graph_tool` with `callers_of`, `callees_of` or `imports_of` to trace relationships. `children_of` on a file lists its functions and classes.\n4. Call `list_flows_tool`, then `get_flow_tool` for one flow, to follow an execution path.\n5. Call `find_large_functions_tool` to find oversized functions.\n6. Call `list_graph_stats_tool` only when you need node, edge and language counts.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n"},"files":{"skills/review-changes/SKILL.md":"---\nname: review-changes\ndescription: Perform a structured code review using change detection and impact\n---\n\n## Review Changes\n\nReview a change set with risk scores and blast radius from the knowledge graph.\n\n### Steps\n\n1. Call `detect_changes_tool` for risk-scored changed functions, test gaps and affected flows.\n2. Call `get_affected_flows_tool` only when you need the steps of an affected flow.\n3. For each high-risk function, call `query_graph_tool` with `pattern=\"tests_for\"` to check test coverage.\n4. Call `get_impact_radius_tool` when the blast radius is not clear from step 1.\n5. Suggest specific test cases for untested changes.\n\n### Output Format\n\nGroup findings by risk level (high, medium, low). For each finding give what changed and why it matters, its test coverage, and the suggested fix. End with a merge recommendation.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","skills/review-pr/SKILL.md":"---\nname: review-pr\ndescription: Review a PR or branch diff using the knowledge graph for full structural context. Outputs a structured review with blast-radius analysis.\nargument-hint: \"[PR number or branch name]\"\n---\n\n# Review PR\n\nReview all commits of a pull request or branch against its base branch.\n\n## Steps\n\n1. Identify the changes. With a branch name run `git diff --name-only main...<branch>`; otherwise diff the current branch against `main` (or `master`). Use that ref as `base` below.\n2. Call `get_minimal_context_tool(task=\"review PR\", base=\"main\")`. If it returns `status: not_ready`, call `build_or_update_graph_tool()` and continue.\n3. Call `detect_changes_tool(base=\"main\", detail_level=\"minimal\")` for risk-scored changed functions, test gaps and affected flows across the whole branch.\n4. For high-risk functions call `query_graph_tool(pattern=\"callers_of\", target=\"<function>\")` and `query_graph_tool(pattern=\"tests_for\", target=\"<function>\")`. Flag public API changes whose callers were not updated.\n5. Call `get_review_context_tool(base=\"main\")` for source snippets, or `get_impact_radius_tool(base=\"main\")` for the full dependent list, only when step 3 leaves a high-risk item unclear.\n6. Read the changed source of the highest-impact files first. Do not load whole files unless the change needs it.\n\n## Output\n\n```\n## PR Review: <title>\n\n### Summary\n<1-3 sentences>\n\n### Risk\n- Overall: Low / Medium / High\n- Blast radius: <n> files, <m> functions\n- Test coverage: <covered> of <changed> changed functions\n\n### Files\n#### <path>\n- Changes: <what>\n- Impact: <who depends on it>\n- Issues: <bugs, style, concerns>\n\n### Missing Tests\n- <function> in <file>\n\n### Recommendations\n1. <action>\n```\n\n## Tips\n\n- Use `semantic_search_nodes_tool` to find related code the PR may have missed.\n",".github/copilot-instructions.md":"<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","docs/architecture.md":"# Architecture\n\n## Overview\n\n`code-review-graph` keeps a persistent, incrementally updated graph of a codebase in SQLite\nand exposes it through a CLI and an MCP server. AI coding tools query the graph for\nstructural context (callers, dependents, tests, impact) instead of reading whole files.\nClaude Code is one supported client among several.\n\n## Components\n\n```text\n┌──────────────────────────────────────────────────────────────┐\n│                    AI coding clients / CLI                   │\n│                                                              │\n│  MCP clients              Hooks / watch mode                 │\n│  ├── Codex                └── incremental update             │\n│  ├── Claude Code, CodeBuddy Code                             │\n│  ├── Cursor, Windsurf, Zed, Continue                         │\n│  └── Gemini CLI, Qwen, Qoder, Copilot, OpenCode              │\n│          │                        │                          │\n│          ▼                        ▼                          │\n│  ┌────────────────────────────────────────────┐              │\n│  │      MCP Server (stdio or localhost HTTP)  │              │\n│  │                                            │              │\n│  │  30 MCP tools + 5 MCP prompts              │              │\n│  │  ├── Core: build, impact, query, review,   │              │\n│  │  │   search, traverse, embed, stats, docs  │              │\n│  │  ├── Flows: list, get, affected            │              │\n│  │  ├── Communities: list, get, architecture  │              │\n│  │  ├── Analysis: detect_changes, refactor,   │              │\n│  │  │   apply_refactor, hubs, bridges, gaps   │              │\n│  │  ├── Wiki: generate, get_page              │              │\n│  │  └── Multi-repo: list_repos, cross_search  │              │\n│  └────────────────┬───────────────────────────┘              │\n└───────────────────┼──────────────────────────────────────────┘\n                    │\n        ┌───────────┼───────────────┐\n        ▼           ▼               ▼\n   ┌─────────┐ ┌─────────┐  ┌─────────────┐\n   │ Parser  │ │  Graph  │  │ Incremental │\n   │         │ │  Store  │  │   Engine    │\n   └────┬────┘ └────┬────┘  └──────┬──────┘\n        │           │              │\n        ▼           ▼              ▼\n   Tree-sitter   SQLite DB      git/svn diff\n   grammars      (.code-review- subprocess\n                 graph/\n                 graph.db)\n```\n\n## Modules\n\nAll modules live in `code_review_graph/`.\n\n| Module | Role |\n|---|---|\n| `parser.py` | Tree-sitter multi-language parser plus targeted fallbacks; emits nodes and edges per file |\n| `custom_languages.py` | Config-driven languages from `.code-review-graph/languages.toml` |\n| `graph.py` | `GraphStore`: SQLite storage, queries, impact radius |\n| `migrations.py` | Versioned schema migrations, currently v11 (see `schema.md`) |\n| `incremental.py` | File collection and ignore rules, git/SVN change detection, full and incremental builds, post-build resolvers |\n| `postprocessing.py` | `run_post_processing()`: endpoint resolution, signatures, FTS sync, flows, communities, embedding refresh |\n| `python_resolver.py`, `jedi_resolver.py`, `tsconfig_resolver.py`, `spring_resolver.py`, `event_resolver.py`, `temporal_resolver.py`, `rescript_resolver.py`, `hcl_resolver.py`, `scoped_resolver.py` | Post-build cross-file resolution |\n| `flows.py` | Execution flow detection and criticality scoring |\n| `communities.py` | Leiden community detection (igraph) with a file-based fallback |\n| `search.py` | Hybrid search: FTS5 BM25 plus vector similarity |\n| `embeddings.py` | Embedding providers and the `embeddings` table |\n| `changes.py`, `refactor.py`, `analysis.py`, `hints.py`, `uncertainty.py`, `context_savings.py` | Change risk analysis, refactoring helpers, hub/bridge/gap analysis, response hints, empty-result markers, savings estimates |\n| `tools/` | MCP tool implementations, split by domain |\n| `main.py`, `prompts.py` | FastMCP server (30 tools, 5 prompts) |\n| `cli.py`, `daemon.py`, `daemon_cli.py` | CLI and the multi-repo watch daemon |\n| `visualization.py`, `exports.py`, `wiki.py`, `graph_diff.py`, `memory.py`, `forget.py` | HTML visualisation, export formats, wiki generation, snapshot diffing, Q&A memory, file removal |\n| `skills.py`, `uninstall.py`, `registry.py`, `enrich.py`, `http_origin_guard.py`, `config_keys.py`, `constants.py` | Platform install/uninstall, multi-repo registry, hook enrichment, HTTP Host/Origin checks, shared helpers |\n| `eval/`, `token_benchmark.py` | Evaluation framework and standalone token benchmark |\n\n## Data Flow\n\n### Full build (`incremental.full_build()`)\n1. `collect_all_files()` lists tracked files (`git ls-files` when git is available, so\n   untracked and gitignored files are skipped) and applies `.code-review-graphignore`.\n2. Each file is read once; the bytes are hashed (SHA-256) and passed to\n   `CodeParser.parse_bytes()`, which walks the Tree-sitter tree and emits nodes and edges.\n3. `GraphStore.store_file_nodes_edges()` (or `store_file_batch()`) replaces the file's rows\n   in one transaction, storing the hash for change detection.\n4. Metadata is written: `last_updated`, `last_build_type`, and the git or SVN head.\n5. Post-build resolvers qualify cross-file targets, then `run_post_processing()` computes\n   signatures, rebuilds the FTS index, traces flows, detects communities and refreshes\n   embeddings, unless skipped. An incremental update rewrites only the changed files'\n   FTS entries (`search.update_fts_index`); a full build rebuilds the index.\n\n### Incremental update (`incremental.incremental_update()`)\n1. `get_changed_files()` asks the VCS for changed paths (git diff by default; SVN is\n   supported).\n2. `find_dependents()` collects files with `IMPORTS_FROM`, `CALLS`, `INHERITS` or\n   `IMPLEMENTS` edges into the changed files, up to two hops and 500 files.\n3. Changed and dependent files whose hash differs from the stored one are re-parsed; the\n   rest are skipped.\n4. Only those files' rows are replaced, then post-processing runs as for a full build.\n\n### Review context (`tools/review.py: get_review_context()`)\n1. Changed files come from a git diff or an explicit list.\n2. `GraphStore.get_impact_radius()` finds the impacted nodes (see below).\n3. Source snippets are extracted for the changed regions only, within a file budget.\n4. `_generate_review_guidance()` adds warnings: changed functions without `TESTED_BY`\n   edges, more than 20 impacted nodes, and inheritance changes.\n5. `attach_context_savings()` adds an estimate of the tokens saved against reading the\n   files, labelled `estimated: true`.\n\nThe MCP entry points are `get_review_context_tool`, `get_impact_radius_tool` and\n`detect_changes_tool` in `main.py`.\n\n## Impact Analysis\n\n`GraphStore.get_impact_radius()` delegates to `get_impact_radius_sql()`, a bounded\nbest-score relaxation run inside SQLite. Setting `CRG_BFS_ENGINE=networkx` selects the older\nPython-side traversal instead.\n\n1. Seed with every node in the changed files.\n2. For each depth step (default 2, `CRG_MAX_IMPACT_DEPTH`), propagate along edges in the\n   direction set per edge kind in `constants.IMPACT_EDGE_DIRECTIONS`: dependency-shaped\n   edges such as `CALLS` and `IMPORTS_FROM` flow from target to source (callers and\n   importers of changed code), `TESTED_BY` flows from production code to its tests, and\n   `CONTAINS` is not expanded because the whole file is already seeded.\n3. Each reached node keeps its best score: previous score x edge weight\n   (`constants.IMPACT_EDGE_WEIGHTS`, default 0.5) x depth decay\n   (`CRG_IMPACT_DEPTH_DECAY`, default 0.6).\n4. Results are ordered by score and cut at `CRG_MAX_IMPACT_NODES` (default 500); the\n   response says whether it was truncated.\n\n## Storage\n\nOne SQLite database, `.code-review-graph/graph.db`, in WAL mode so readers are not blocked\nduring updates. Tables: `nodes`, `edges`, `metadata`, `flows`, `flow_memberships`,\n`communities`, `nodes_fts` (FTS5), `nodes_fts_state`, `community_summaries`,\n`flow_snapshots`, `risk_index`, and\n`embeddings` (created by `EmbeddingStore` in the same file). Columns, indexes and the\nmigration history are in [schema.md](schema.md).\n\nNodes are identified by qualified name: the file path for File nodes, `path::name` for\ntop-level symbols and `path::Class.method` for members.\n\n## Parsing\n\nThe parser walks the Tree-sitter tree directly rather than using tree-sitter query files,\nwhich keeps it independent of query syntax differences between grammar versions. Per-language\nnode type tables (`_CLASS_TYPES`, `_FUNCTION_TYPES` and similar in `parser.py`) drive:\n\n1. Class, function and type extraction with names, parameters, return types and bases.\n2. Call detection inside function bodies.\n3. Import resolution to module paths, refined later by the post-build resolvers.\n\nLanguages without a grammar can be added through `.code-review-graph/languages.toml`\n(`docs/CUSTOM_LANGUAGES.md`). Some formats (notebooks, Vue and Svelte SFCs, SQL, Ansible,\nSpring configuration) use targeted parsers instead of Tree-sitter.\n\n## Visualisation\n\n`visualization.py` writes a self-contained HTML file with a D3.js force-directed graph of the\nnodes and edges, with filters by node and edge kind and a search box.\n","skills/review-delta/SKILL.md":"---\nname: review-delta\ndescription: Review only changes since last commit using impact analysis. Token-efficient delta review with automatic blast-radius detection.\nargument-hint: \"[file or function name]\"\n---\n\n# Review Delta\n\nReview only the changed code and its blast radius.\n\n## Steps\n\n1. Call `get_minimal_context_tool(task=\"review changes\")`. If it returns `status: not_ready`, call `build_or_update_graph_tool()` and continue.\n2. Call `detect_changes_tool(detail_level=\"minimal\")` for risk-scored changed functions, test gaps and affected flows. Changes come from `git diff` against `HEAD~1`; if the argument names a file, pass it in `changed_files`.\n3. Call `get_review_context_tool(detail_level=\"minimal\")` when you need source snippets for the changed areas and `review_guidance` (untested functions, wide blast radius, inheritance changes).\n4. For each untested high-risk function, confirm with `query_graph_tool(pattern=\"tests_for\", target=\"<function>\")`.\n5. Use `detail_level=\"standard\"` only for a high-risk item the minimal output leaves unclear. Do not load whole files unless a snippet is not enough.\n\n## Report\n\n- Summary: one line\n- Risk: low, medium or high, from the blast radius\n- Issues: bugs, missing tests, style\n- Blast radius: impacted files and functions\n- Recommendations\n","skills/refactor-safely/SKILL.md":"---\nname: refactor-safely\ndescription: Plan and execute safe refactoring using dependency analysis\n---\n\n## Refactor Safely\n\nPlan a refactor from the dependency graph and apply renames from a preview.\n\n### Steps\n\n1. Call `refactor_tool` with `mode=\"suggest\"` for refactoring candidates, or `mode=\"dead_code\"` for unreferenced code.\n2. For a rename, call `refactor_tool` with `mode=\"rename\"`, `old_name` and `new_name`. Check the returned edit list before applying.\n3. Call `apply_refactor_tool` with the returned `refactor_id` to apply the rename.\n4. Before a large refactor, call `get_impact_radius_tool` and `get_affected_flows_tool` to see the dependents and critical paths involved.\n5. Call `find_large_functions_tool` to find functions worth splitting.\n6. After the change, call `detect_changes_tool` to confirm the impact matches the plan.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","CLAUDE.md":"# CLAUDE.md - Project Context for Claude Code\n\n## Project Overview\n\ncode-review-graph is a local-first knowledge graph for code review. It parses a repository with Tree-sitter (plus targeted fallbacks), stores nodes and edges in SQLite, updates the graph incrementally from Git changes, and serves compact context over MCP and the CLI to AI coding tools. Supported platforms are the entries in `PLATFORMS` in `skills.py`: Claude Code, Codex, Cursor, Windsurf, Zed, Continue, OpenCode, Antigravity, Gemini CLI, Qwen Code, Kiro, Qoder, GitHub Copilot, GitHub Copilot CLI, Hermes Agent and CodeBuddy Code.\n\n## Graph Tool Usage (Token-Efficient)\n\nWhen using code-review-graph MCP tools:\n\n1. Call `get_minimal_context_tool(task=\"<description>\")` first. It costs about 100 tokens and gives the overview.\n2. Use `detail_level=\"minimal\"` on every later call unless that is not enough.\n3. Prefer `query_graph_tool` with a specific target over broad `list_*` calls.\n4. Follow the `next_tool_suggestions` field in each response.\n5. Target: at most 5 tool calls and 800 tokens of graph context per task.\n\nAll registered tool names end in `_tool`. The 30 tools are defined in `main.py`.\n\n## Architecture\n\nCore package `code_review_graph/` (Python 3.10+):\n\n- `main.py`: FastMCP server entry point. Registers 30 tools and 5 prompts.\n- `tools/`: tool implementations by domain: `build.py`, `query.py`, `review.py`, `context.py`, `flows_tools.py`, `community_tools.py`, `refactor_tools.py`, `docs.py`, `registry_tools.py`, `analysis_tools.py`; shared helpers in `_common.py`.\n- `prompts.py`: 5 MCP prompts (review_changes, architecture_map, debug_issue, onboard_developer, pre_merge_check).\n- `cli.py`: the `code-review-graph` command. `daemon.py` and `daemon_cli.py`: the `crg-daemon` multi-repo watch daemon.\n- `parser.py`: Tree-sitter multi-language parser with fallbacks for notebooks and other formats. `custom_languages.py`: languages defined in `.code-review-graph/languages.toml` (see docs/CUSTOM_LANGUAGES.md).\n- `graph.py`: SQLite graph store (nodes, edges, impact analysis). `migrations.py`: schema migrations; the current schema version is 13 and must equal `SUPPORTED_SCHEMA_VERSION` in the VS Code extension (CI checks this).\n- `incremental.py`: full build, Git/SVN change detection, incremental update, stale-file reconciliation, watch mode. `postprocessing.py`: shared post-build pipeline (signatures, flows, communities, FTS).\n- Post-build resolvers: `python_resolver.py`, `jedi_resolver.py` (optional `enrichment` extra), `spring_resolver.py`, `event_resolver.py`, `temporal_resolver.py`, `config_keys.py`, `scoped_resolver.py` (PHP, Rust, C#), `rescript_resolver.py`, `hcl_resolver.py`, `tsconfig_resolver.py` (tsconfig and jsconfig path aliases).\n- `flows.py`: execution flows and criticality. `communities.py`: Leiden via igraph (optional) or file-based grouping, plus the architecture overview. `analysis.py`: hub and bridge nodes, knowledge gaps, surprise scoring, suggested questions.\n- `search.py`: FTS5 keyword search combined with optional vector search. `embeddings.py`: providers for local sentence-transformers, OpenAI-compatible endpoints, Google Gemini, MiniMax and Voyage AI.\n- `changes.py`: risk-scored change analysis. `refactor.py`: rename preview, dead code, suggestions. `hints.py`: `next_tool_suggestions`. `uncertainty.py`: `confidence` notes on empty results. `context_savings.py`: estimated context-savings metadata.\n- `visualization.py`: D3.js HTML graph (D3 is bundled in `assets/`). `exports.py`: JSON, GraphML, Neo4j Cypher, Obsidian, SVG. `wiki.py`: Markdown wiki. `graph_diff.py`: snapshot diffing. `memory.py`: stored Q&A feedback.\n- `skills.py`: `install` (platform MCP configs, hooks, skills, instruction blocks). `_legacy_instructions.py`: instruction blocks shipped by earlier releases. `jsonc.py`: comment-preserving JSONC tokenising and splices, shared by install and uninstall so neither flattens a commented config. `uninstall.py`: reverses `install`. `enrich.py`: PreToolUse hook enrichment. `forget.py`: drops files from the graph. `registry.py`: multi-repo registry. `http_origin_guard.py`: Host/Origin checks for `serve --http`. `token_benchmark.py` and `eval/`: benchmarks. `constants.py`: shared constants.\n- `docs/LLM-OPTIMIZED-REFERENCE.md`: the reference served by `get_docs_section_tool`.\n\nVS Code extension: `code-review-graph-vscode/` (TypeScript, separate `package.json` and `tsconfig.json`). Reads `.code-review-graph/graph.db` directly.\n\nDatabase: `.code-review-graph/graph.db` (SQLite, WAL mode).\n\n## Key Commands\n\n```bash\n# Development\nuv run pytest tests/ --tb=short -q\nuv run ruff check code_review_graph/\nuv run mypy code_review_graph/ --ignore-missing-imports --no-strict-optional\n\n# Graph\nuv run code-review-graph build              # full build\nuv run code-review-graph update             # incremental update\nuv run code-review-graph status             # graph statistics\nuv run code-review-graph detect-changes     # risk-scored change analysis (read-only)\nuv run code-review-graph forget PATH        # drop files from the graph\nuv run code-review-graph serve              # MCP server (stdio; --http for localhost)\nuv run code-review-graph wiki               # Markdown wiki\nuv run code-review-graph register <path>    # add a repo to the multi-repo registry\nuv run code-review-graph eval               # benchmarks\nuv run code-review-graph --help             # full command list\n```\n\n## Code Conventions\n\n- Line length 100 (ruff). Python 3.10+.\n- SQL: parameterised queries with `?` placeholders. Never format values into SQL strings.\n- Errors: catch specific exceptions and log with `logger.warning` or `logger.error`.\n- Threads: `threading.Lock` around shared caches; SQLite opened with `check_same_thread=False`.\n- Node names: pass through `_sanitize_name()` before returning them to MCP clients.\n- File reads: read the bytes once, hash them, then parse the same bytes.\n\n## Security Invariants\n\n- No `eval()`, `exec()`, `pickle` or `yaml.unsafe_load()`.\n- No `shell=True` in subprocess calls.\n- `_validate_repo_root()` requires an existing directory containing `.git`, `.svn` or `.code-review-graph`, which blocks path traversal through `repo_root`.\n- `_sanitize_name()` strips control characters and caps names at 256 characters.\n- `escH()` in `visualization.py` escapes HTML entities including quotes and backticks; `</script>` is escaped inside embedded JSON.\n- D3.js is bundled and loaded with an SRI hash; the CDN fallback carries the same hash.\n- `http_origin_guard.py` validates Host and Origin for `serve --http`.\n- API keys come from environment variables only.\n\n## Test Structure\n\n`tests/` holds over 100 pytest modules. The main groups:\n\n- Core: `test_parser.py`, `test_graph.py`, `test_incremental.py`, `test_tools.py`, `test_main.py`, `test_cli*.py`.\n- Features: `test_flows.py`, `test_communities.py`, `test_changes.py`, `test_refactor.py`, `test_search.py`, `test_hints.py`, `test_prompts.py`, `test_wiki.py`, `test_embeddings.py`, `test_eval.py`, `test_registry.py`, `test_migrations.py`, `test_uncertainty.py`, `test_context_savings.py`, `test_token_budget.py` (per-tool token budgets).\n- Languages: `test_multilang.py`, `test_custom_languages.py`, `test_notebook.py`, plus per-language files such as `test_php_*.py`, `test_spring_*.py`, `test_kotlin_imports.py`, `test_go_embeddings.py`, `test_cpp_*.py`, `test_typescript_node_extensions.py`, `test_tsconfig_resolver.py`, `test_hcl_parser.py`, `test_dbt_parser.py`, `test_ansible_parser.py`.\n- Regression modules are named after the behaviour they pin, not the PR that produced them. The originating PR number goes in the module docstring.\n- Watch and daemon: `test_watch_*.py`, `test_daemon*.py`.\n- Install and platforms: `test_skills.py`, `test_cli_install.py`, `test_uninstall.py`, `test_git_hook_worktree.py`, `test_hermes_install.py`, `test_qoder_bundled_skills.py`, `test_installer_ownership.py` (what install may rewrite and what belongs to the user), `test_released_shapes.py` (reads the hooks and MCP entries every released tag wrote and requires them to still be recognised; needs tags, skips without them), `test_platform_lifecycle.py` (opt-in marker `platform_lifecycle`).\n- Windows: `test_windows_compat.py`, `test_windows_path_identity.py`.\n- Docs and GitHub Action: `test_documentation.py`, `test_action_render.py`.\n- Distribution gate: `test_packaging.py`, marked `packaging` and **skipped by default**. Builds a wheel and an sdist with `python -m build`, installs each into its own virtual environment, and drives the installed program with the checkout out of reach. Needs network and takes a couple of minutes. Run it before a release with `uv run --python 3.13 python -m pytest tests/test_packaging.py -m packaging`.\n- `tests/fixtures/`: sample files per supported language.\n\n## CI Pipeline\n\n`.github/workflows/ci.yml`:\n\n- lint: ruff on Python 3.10.\n- type-check: mypy.\n- security: bandit with the exemptions in `pyproject.toml`.\n- schema-sync: `LATEST_VERSION` in `migrations.py` must equal `SUPPORTED_SCHEMA_VERSION` in the VS Code extension.\n- test: pytest on Python 3.10, 3.11, 3.12 and 3.13; coverage must be at least 65%.\n- google-embeddings: constructs the Google provider with the `google-embeddings` and `all` extras.\n- windows-native: a subset of the suite on windows-latest.\n\n<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->\n## Beads Issue Tracker\n\nThis project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.\n\n### Quick Reference\n\n```bash\nbd ready              # Find available work\nbd show <id>          # View issue details\nbd update <id> --claim  # Claim work\nbd close <id>         # Complete work\n```\n\n### Rules\n\n- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists\n- Run `bd prime` for detailed command reference and session close protocol\n- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files\n\n## Branching Model\n\nThree long-lived branches, one direction: feature PR → `staging` (default) → `testing` → `main` → tag → PyPI.\nOpen every PR against `staging`. Never push to or open PRs against `testing` or `main`; those only\nreceive promotion PRs, always merged with a merge commit.\n\n`staging` → `testing` is automatic: `.github/workflows/auto-promote.yml` runs once a day and merges\nthe promotion PR when `staging` is ahead, every required check is green, and the promotion gate has\nnot failed on `testing`. The decision lives in `scripts/auto_promote.py`. It merges only a PR it\nopened itself — same repository, correctly aimed, labelled `auto-promotion`, pinned to the commit\nwhose checks were read — so a promotion PR you open by hand is left alone. It needs Settings →\nActions → General → Workflow permissions → *Allow GitHub Actions to create and approve pull\nrequests*. **Promotion to `main` is never automatic** — the maintainer opens and merges that PR by\nhand. Full rules in CONTRIBUTING.md \"Branching and promotion\".\n\n## Session Completion\n\n**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.\n\n**MANDATORY WORKFLOW:**\n\n1. **File issues for remaining work** - Create issues for anything that needs follow-up\n2. **Run quality gates** (if code changed) - Tests, linters, builds\n3. **Update issue status** - Close finished work, update in-progress items\n4. **PUSH TO REMOTE** - This is MANDATORY:\n   ```bash\n   git pull --rebase\n   bd dolt push\n   git push\n   git status  # MUST show \"up to date with origin\"\n   ```\n5. **Clean up** - Clear stashes, prune remote branches\n6. **Verify** - All changes committed AND pushed\n7. **Hand off** - Provide context for next session\n\n**CRITICAL RULES:**\n- Work is NOT complete until `git push` succeeds\n- NEVER stop before pushing - that leaves work stranded locally\n- NEVER say \"ready to push when you are\" - YOU must push\n- If push fails, resolve and retry until it succeeds\n<!-- END BEADS INTEGRATION -->\n\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","skills/debug-issue/SKILL.md":"---\nname: debug-issue\ndescription: Systematically debug issues using graph-powered code navigation\n---\n\n## Debug Issue\n\nTrace a bug through the knowledge graph before reading source.\n\n### Steps\n\n1. Call `semantic_search_nodes_tool` to find code related to the issue.\n2. Call `query_graph_tool` with `callers_of` and `callees_of` to trace the call chain in both directions.\n3. Call `get_flow_tool` for the execution path that reaches the suspect code. Its entry point is where the bug is triggered.\n4. Call `detect_changes_tool` to check whether a recent change caused the issue.\n5. Call `get_impact_radius_tool` on the suspect files to see what a fix would affect.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","GEMINI.md":"# Gemini\n\nAgent rules for this repository live in [AGENTS.md](AGENTS.md). Project\ncontext (architecture, commands, conventions, tests) lives in\n[CLAUDE.md](CLAUDE.md). Both apply to Gemini CLI and Antigravity.\n\nThis file used to be a byte-identical copy of\n[.github/copilot-instructions.md](.github/copilot-instructions.md), which only\nexists because Copilot reads that exact path. Keeping a pointer here means the\ninstructions are maintained in one place.\n","skills/build-graph/SKILL.md":"---\nname: build-graph\ndescription: Build or update the code review knowledge graph. Run this first to initialize, or let hooks keep it updated automatically.\nargument-hint: \"[full]\"\n---\n\n# Build Graph\n\nBuild or incrementally update the knowledge graph for this repository.\n\n## Steps\n\n1. Call `list_graph_stats_tool`. If `last_updated` is null, the graph has never been built.\n2. For a first build, or when the argument is `full`, call `build_or_update_graph_tool(full_rebuild=True)`. Otherwise call `build_or_update_graph_tool()` for an incremental update.\n3. Report the response: `status` (`ok`, `partial` or `error`) and `summary`.\n\n## When to Use\n\n- First set-up of a repository, or after a branch switch or large refactor.\n- When the graph looks stale. Hooks installed by `code-review-graph install` run an update after each edit and before each commit, so manual builds are rarely needed.\n\n## Notes\n\n- The database is `.code-review-graph/graph.db` in the repository root.\n- Binary files, dependency and build directories, and patterns in `.code-review-graphignore` are skipped.\n- For the list of supported languages call `get_docs_section_tool(section_name=\"languages\")`.\n","AGENTS.md":"# Agent Instructions\n\nProject context (architecture, commands, conventions, tests) is in `CLAUDE.md`. This file holds the rules for every coding agent working in this repository.\n\n## Non-Interactive Shell Commands\n\n`cp`, `mv` and `rm` may be aliased with `-i` on some systems, which leaves an agent waiting for a y/n answer that never comes. Always pass the non-interactive flag:\n\n```bash\ncp -f source dest\nmv -f source dest\nrm -f file\nrm -rf directory\ncp -rf source dest\n```\n\nOther commands that may prompt: `scp` and `ssh` (`-o BatchMode=yes`), `apt-get` (`-y`), `brew` (`HOMEBREW_NO_AUTO_UPDATE=1`).\n\n<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->\n## Beads Issue Tracker\n\nThis project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.\n\n### Quick Reference\n\n```bash\nbd ready              # Find available work\nbd show <id>          # View issue details\nbd update <id> --claim  # Claim work\nbd close <id>         # Complete work\n```\n\n### Rules\n\n- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists\n- Run `bd prime` for detailed command reference and session close protocol\n- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files\n\n## Session Completion\n\n**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.\n\n**MANDATORY WORKFLOW:**\n\n1. **File issues for remaining work** - Create issues for anything that needs follow-up\n2. **Run quality gates** (if code changed) - Tests, linters, builds\n3. **Update issue status** - Close finished work, update in-progress items\n4. **PUSH TO REMOTE** - This is MANDATORY:\n   ```bash\n   git pull --rebase\n   bd dolt push\n   git push\n   git status  # MUST show \"up to date with origin\"\n   ```\n5. **Clean up** - Clear stashes, prune remote branches\n6. **Verify** - All changes committed AND pushed\n7. **Hand off** - Provide context for next session\n\n**CRITICAL RULES:**\n- Work is NOT complete until `git push` succeeds\n- NEVER stop before pushing - that leaves work stranded locally\n- NEVER say \"ready to push when you are\" - YOU must push\n- If push fails, resolve and retry until it succeeds\n<!-- END BEADS INTEGRATION -->\n\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","skills/explore-codebase/SKILL.md":"---\nname: explore-codebase\ndescription: Navigate and understand codebase structure using the knowledge graph\n---\n\n## Explore Codebase\n\nUse the code-review-graph MCP tools to find your way around the codebase.\n\n### Steps\n\n1. Call `get_architecture_overview_tool` for the community structure. Call `list_communities_tool`, then `get_community_tool`, only for the modules you need.\n2. Call `semantic_search_nodes_tool` to find a function or class by name or keyword.\n3. Call `query_graph_tool` with `callers_of`, `callees_of` or `imports_of` to trace relationships. `children_of` on a file lists its functions and classes.\n4. Call `list_flows_tool`, then `get_flow_tool` for one flow, to follow an execution path.\n5. Call `find_large_functions_tool` to find oversized functions.\n6. Call `list_graph_stats_tool` only when you need node, edge and language counts.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Agent Instructions\n\nProject context (architecture, commands, conventions, tests) is in `CLAUDE.md`. This file holds the rules for every coding agent working in this repository.\n\n## Non-Interactive Shell Commands\n\n`cp`, `mv` and `rm` may be aliased with `-i` on some systems, which leaves an agent waiting for a y/n answer that never comes. Always pass the non-interactive flag:\n\n```bash\ncp -f source dest\nmv -f source dest\nrm -f file\nrm -rf directory\ncp -rf source dest\n```\n\nOther commands that may prompt: `scp` and `ssh` (`-o BatchMode=yes`), `apt-get` (`-y`), `brew` (`HOMEBREW_NO_AUTO_UPDATE=1`).\n\n<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->\n## Beads Issue Tracker\n\nThis project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.\n\n### Quick Reference\n\n```bash\nbd ready              # Find available work\nbd show <id>          # View issue details\nbd update <id> --claim  # Claim work\nbd close <id>         # Complete work\n```\n\n### Rules\n\n- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists\n- Run `bd prime` for detailed command reference and session close protocol\n- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files\n\n## Session Completion\n\n**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.\n\n**MANDATORY WORKFLOW:**\n\n1. **File issues for remaining work** - Create issues for anything that needs follow-up\n2. **Run quality gates** (if code changed) - Tests, linters, builds\n3. **Update issue status** - Close finished work, update in-progress items\n4. **PUSH TO REMOTE** - This is MANDATORY:\n   ```bash\n   git pull --rebase\n   bd dolt push\n   git push\n   git status  # MUST show \"up to date with origin\"\n   ```\n5. **Clean up** - Clear stashes, prune remote branches\n6. **Verify** - All changes committed AND pushed\n7. **Hand off** - Provide context for next session\n\n**CRITICAL RULES:**\n- Work is NOT complete until `git push` succeeds\n- NEVER stop before pushing - that leaves work stranded locally\n- NEVER say \"ready to push when you are\" - YOU must push\n- If push fails, resolve and retry until it succeeds\n<!-- END BEADS INTEGRATION -->\n\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","isInternal":false,"tokens":1108,"sizeBytes":4593},{"name":"architecture.md","path":"docs/architecture.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/docs/architecture.md","title":"docs - System Architecture & Module Boundaries","category":"project-spec","format":"markdown","content":"# Architecture\n\n## Overview\n\n`code-review-graph` keeps a persistent, incrementally updated graph of a codebase in SQLite\nand exposes it through a CLI and an MCP server. AI coding tools query the graph for\nstructural context (callers, dependents, tests, impact) instead of reading whole files.\nClaude Code is one supported client among several.\n\n## Components\n\n```text\n┌──────────────────────────────────────────────────────────────┐\n│                    AI coding clients / CLI                   │\n│                                                              │\n│  MCP clients              Hooks / watch mode                 │\n│  ├── Codex                └── incremental update             │\n│  ├── Claude Code, CodeBuddy Code                             │\n│  ├── Cursor, Windsurf, Zed, Continue                         │\n│  └── Gemini CLI, Qwen, Qoder, Copilot, OpenCode              │\n│          │                        │                          │\n│          ▼                        ▼                          │\n│  ┌────────────────────────────────────────────┐              │\n│  │      MCP Server (stdio or localhost HTTP)  │              │\n│  │                                            │              │\n│  │  30 MCP tools + 5 MCP prompts              │              │\n│  │  ├── Core: build, impact, query, review,   │              │\n│  │  │   search, traverse, embed, stats, docs  │              │\n│  │  ├── Flows: list, get, affected            │              │\n│  │  ├── Communities: list, get, architecture  │              │\n│  │  ├── Analysis: detect_changes, refactor,   │              │\n│  │  │   apply_refactor, hubs, bridges, gaps   │              │\n│  │  ├── Wiki: generate, get_page              │              │\n│  │  └── Multi-repo: list_repos, cross_search  │              │\n│  └────────────────┬───────────────────────────┘              │\n└───────────────────┼──────────────────────────────────────────┘\n                    │\n        ┌───────────┼───────────────┐\n        ▼           ▼               ▼\n   ┌─────────┐ ┌─────────┐  ┌─────────────┐\n   │ Parser  │ │  Graph  │  │ Incremental │\n   │         │ │  Store  │  │   Engine    │\n   └────┬────┘ └────┬────┘  └──────┬──────┘\n        │           │              │\n        ▼           ▼              ▼\n   Tree-sitter   SQLite DB      git/svn diff\n   grammars      (.code-review- subprocess\n                 graph/\n                 graph.db)\n```\n\n## Modules\n\nAll modules live in `code_review_graph/`.\n\n| Module | Role |\n|---|---|\n| `parser.py` | Tree-sitter multi-language parser plus targeted fallbacks; emits nodes and edges per file |\n| `custom_languages.py` | Config-driven languages from `.code-review-graph/languages.toml` |\n| `graph.py` | `GraphStore`: SQLite storage, queries, impact radius |\n| `migrations.py` | Versioned schema migrations, currently v11 (see `schema.md`) |\n| `incremental.py` | File collection and ignore rules, git/SVN change detection, full and incremental builds, post-build resolvers |\n| `postprocessing.py` | `run_post_processing()`: endpoint resolution, signatures, FTS sync, flows, communities, embedding refresh |\n| `python_resolver.py`, `jedi_resolver.py`, `tsconfig_resolver.py`, `spring_resolver.py`, `event_resolver.py`, `temporal_resolver.py`, `rescript_resolver.py`, `hcl_resolver.py`, `scoped_resolver.py` | Post-build cross-file resolution |\n| `flows.py` | Execution flow detection and criticality scoring |\n| `communities.py` | Leiden community detection (igraph) with a file-based fallback |\n| `search.py` | Hybrid search: FTS5 BM25 plus vector similarity |\n| `embeddings.py` | Embedding providers and the `embeddings` table |\n| `changes.py`, `refactor.py`, `analysis.py`, `hints.py`, `uncertainty.py`, `context_savings.py` | Change risk analysis, refactoring helpers, hub/bridge/gap analysis, response hints, empty-result markers, savings estimates |\n| `tools/` | MCP tool implementations, split by domain |\n| `main.py`, `prompts.py` | FastMCP server (30 tools, 5 prompts) |\n| `cli.py`, `daemon.py`, `daemon_cli.py` | CLI and the multi-repo watch daemon |\n| `visualization.py`, `exports.py`, `wiki.py`, `graph_diff.py`, `memory.py`, `forget.py` | HTML visualisation, export formats, wiki generation, snapshot diffing, Q&A memory, file removal |\n| `skills.py`, `uninstall.py`, `registry.py`, `enrich.py`, `http_origin_guard.py`, `config_keys.py`, `constants.py` | Platform install/uninstall, multi-repo registry, hook enrichment, HTTP Host/Origin checks, shared helpers |\n| `eval/`, `token_benchmark.py` | Evaluation framework and standalone token benchmark |\n\n## Data Flow\n\n### Full build (`incremental.full_build()`)\n1. `collect_all_files()` lists tracked files (`git ls-files` when git is available, so\n   untracked and gitignored files are skipped) and applies `.code-review-graphignore`.\n2. Each file is read once; the bytes are hashed (SHA-256) and passed to\n   `CodeParser.parse_bytes()`, which walks the Tree-sitter tree and emits nodes and edges.\n3. `GraphStore.store_file_nodes_edges()` (or `store_file_batch()`) replaces the file's rows\n   in one transaction, storing the hash for change detection.\n4. Metadata is written: `last_updated`, `last_build_type`, and the git or SVN head.\n5. Post-build resolvers qualify cross-file targets, then `run_post_processing()` computes\n   signatures, rebuilds the FTS index, traces flows, detects communities and refreshes\n   embeddings, unless skipped. An incremental update rewrites only the changed files'\n   FTS entries (`search.update_fts_index`); a full build rebuilds the index.\n\n### Incremental update (`incremental.incremental_update()`)\n1. `get_changed_files()` asks the VCS for changed paths (git diff by default; SVN is\n   supported).\n2. `find_dependents()` collects files with `IMPORTS_FROM`, `CALLS`, `INHERITS` or\n   `IMPLEMENTS` edges into the changed files, up to two hops and 500 files.\n3. Changed and dependent files whose hash differs from the stored one are re-parsed; the\n   rest are skipped.\n4. Only those files' rows are replaced, then post-processing runs as for a full build.\n\n### Review context (`tools/review.py: get_review_context()`)\n1. Changed files come from a git diff or an explicit list.\n2. `GraphStore.get_impact_radius()` finds the impacted nodes (see below).\n3. Source snippets are extracted for the changed regions only, within a file budget.\n4. `_generate_review_guidance()` adds warnings: changed functions without `TESTED_BY`\n   edges, more than 20 impacted nodes, and inheritance changes.\n5. `attach_context_savings()` adds an estimate of the tokens saved against reading the\n   files, labelled `estimated: true`.\n\nThe MCP entry points are `get_review_context_tool`, `get_impact_radius_tool` and\n`detect_changes_tool` in `main.py`.\n\n## Impact Analysis\n\n`GraphStore.get_impact_radius()` delegates to `get_impact_radius_sql()`, a bounded\nbest-score relaxation run inside SQLite. Setting `CRG_BFS_ENGINE=networkx` selects the older\nPython-side traversal instead.\n\n1. Seed with every node in the changed files.\n2. For each depth step (default 2, `CRG_MAX_IMPACT_DEPTH`), propagate along edges in the\n   direction set per edge kind in `constants.IMPACT_EDGE_DIRECTIONS`: dependency-shaped\n   edges such as `CALLS` and `IMPORTS_FROM` flow from target to source (callers and\n   importers of changed code), `TESTED_BY` flows from production code to its tests, and\n   `CONTAINS` is not expanded because the whole file is already seeded.\n3. Each reached node keeps its best score: previous score x edge weight\n   (`constants.IMPACT_EDGE_WEIGHTS`, default 0.5) x depth decay\n   (`CRG_IMPACT_DEPTH_DECAY`, default 0.6).\n4. Results are ordered by score and cut at `CRG_MAX_IMPACT_NODES` (default 500); the\n   response says whether it was truncated.\n\n## Storage\n\nOne SQLite database, `.code-review-graph/graph.db`, in WAL mode so readers are not blocked\nduring updates. Tables: `nodes`, `edges`, `metadata`, `flows`, `flow_memberships`,\n`communities`, `nodes_fts` (FTS5), `nodes_fts_state`, `community_summaries`,\n`flow_snapshots`, `risk_index`, and\n`embeddings` (created by `EmbeddingStore` in the same file). Columns, indexes and the\nmigration history are in [schema.md](schema.md).\n\nNodes are identified by qualified name: the file path for File nodes, `path::name` for\ntop-level symbols and `path::Class.method` for members.\n\n## Parsing\n\nThe parser walks the Tree-sitter tree directly rather than using tree-sitter query files,\nwhich keeps it independent of query syntax differences between grammar versions. Per-language\nnode type tables (`_CLASS_TYPES`, `_FUNCTION_TYPES` and similar in `parser.py`) drive:\n\n1. Class, function and type extraction with names, parameters, return types and bases.\n2. Call detection inside function bodies.\n3. Import resolution to module paths, refined later by the post-build resolvers.\n\nLanguages without a grammar can be added through `.code-review-graph/languages.toml`\n(`docs/CUSTOM_LANGUAGES.md`). Some formats (notebooks, Vue and Svelte SFCs, SQL, Ansible,\nSpring configuration) use targeted parsers instead of Tree-sitter.\n\n## Visualisation\n\n`visualization.py` writes a self-contained HTML file with a D3.js force-directed graph of the\nnodes and edges, with filters by node and edge kind and a search box.\n","isInternal":false,"tokens":2255,"sizeBytes":10145},{"name":"SKILL.md","path":"skills/build-graph/SKILL.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/skills/build-graph/SKILL.md","title":"build-graph","category":"anthropic-skill","format":"markdown","content":"---\nname: build-graph\ndescription: Build or update the code review knowledge graph. Run this first to initialize, or let hooks keep it updated automatically.\nargument-hint: \"[full]\"\n---\n\n# Build Graph\n\nBuild or incrementally update the knowledge graph for this repository.\n\n## Steps\n\n1. Call `list_graph_stats_tool`. If `last_updated` is null, the graph has never been built.\n2. For a first build, or when the argument is `full`, call `build_or_update_graph_tool(full_rebuild=True)`. Otherwise call `build_or_update_graph_tool()` for an incremental update.\n3. Report the response: `status` (`ok`, `partial` or `error`) and `summary`.\n\n## When to Use\n\n- First set-up of a repository, or after a branch switch or large refactor.\n- When the graph looks stale. Hooks installed by `code-review-graph install` run an update after each edit and before each commit, so manual builds are rarely needed.\n\n## Notes\n\n- The database is `.code-review-graph/graph.db` in the repository root.\n- Binary files, dependency and build directories, and patterns in `.code-review-graphignore` are skipped.\n- For the list of supported languages call `get_docs_section_tool(section_name=\"languages\")`.\n","frontmatter":{"name":"build-graph","description":"Build or update the code review knowledge graph. Run this first to initialize, or let hooks keep it updated automatically.","argument-hint":"[full]"},"isInternal":false,"tokens":262,"sizeBytes":1177},{"name":"SKILL.md","path":"skills/debug-issue/SKILL.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/skills/debug-issue/SKILL.md","title":"debug-issue","category":"anthropic-skill","format":"markdown","content":"---\nname: debug-issue\ndescription: Systematically debug issues using graph-powered code navigation\n---\n\n## Debug Issue\n\nTrace a bug through the knowledge graph before reading source.\n\n### Steps\n\n1. Call `semantic_search_nodes_tool` to find code related to the issue.\n2. Call `query_graph_tool` with `callers_of` and `callees_of` to trace the call chain in both directions.\n3. Call `get_flow_tool` for the execution path that reaches the suspect code. Its entry point is where the bug is triggered.\n4. Call `detect_changes_tool` to check whether a recent change caused the issue.\n5. Call `get_impact_radius_tool` on the suspect files to see what a fix would affect.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","frontmatter":{"name":"debug-issue","description":"Systematically debug issues using graph-powered code navigation"},"isInternal":false,"tokens":259,"sizeBytes":1146},{"name":"SKILL.md","path":"skills/explore-codebase/SKILL.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/skills/explore-codebase/SKILL.md","title":"explore-codebase","category":"anthropic-skill","format":"markdown","content":"---\nname: explore-codebase\ndescription: Navigate and understand codebase structure using the knowledge graph\n---\n\n## Explore Codebase\n\nUse the code-review-graph MCP tools to find your way around the codebase.\n\n### Steps\n\n1. Call `get_architecture_overview_tool` for the community structure. Call `list_communities_tool`, then `get_community_tool`, only for the modules you need.\n2. Call `semantic_search_nodes_tool` to find a function or class by name or keyword.\n3. Call `query_graph_tool` with `callers_of`, `callees_of` or `imports_of` to trace relationships. `children_of` on a file lists its functions and classes.\n4. Call `list_flows_tool`, then `get_flow_tool` for one flow, to follow an execution path.\n5. Call `find_large_functions_tool` to find oversized functions.\n6. Call `list_graph_stats_tool` only when you need node, edge and language counts.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","frontmatter":{"name":"explore-codebase","description":"Navigate and understand codebase structure using the knowledge graph"},"isInternal":false,"tokens":309,"sizeBytes":1340},{"name":"SKILL.md","path":"skills/refactor-safely/SKILL.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/skills/refactor-safely/SKILL.md","title":"refactor-safely","category":"anthropic-skill","format":"markdown","content":"---\nname: refactor-safely\ndescription: Plan and execute safe refactoring using dependency analysis\n---\n\n## Refactor Safely\n\nPlan a refactor from the dependency graph and apply renames from a preview.\n\n### Steps\n\n1. Call `refactor_tool` with `mode=\"suggest\"` for refactoring candidates, or `mode=\"dead_code\"` for unreferenced code.\n2. For a rename, call `refactor_tool` with `mode=\"rename\"`, `old_name` and `new_name`. Check the returned edit list before applying.\n3. Call `apply_refactor_tool` with the returned `refactor_id` to apply the rename.\n4. Before a large refactor, call `get_impact_radius_tool` and `get_affected_flows_tool` to see the dependents and critical paths involved.\n5. Call `find_large_functions_tool` to find functions worth splitting.\n6. After the change, call `detect_changes_tool` to confirm the impact matches the plan.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","frontmatter":{"name":"refactor-safely","description":"Plan and execute safe refactoring using dependency analysis"},"isInternal":false,"tokens":311,"sizeBytes":1326},{"name":"SKILL.md","path":"skills/review-changes/SKILL.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/skills/review-changes/SKILL.md","title":"review-changes","category":"anthropic-skill","format":"markdown","content":"---\nname: review-changes\ndescription: Perform a structured code review using change detection and impact\n---\n\n## Review Changes\n\nReview a change set with risk scores and blast radius from the knowledge graph.\n\n### Steps\n\n1. Call `detect_changes_tool` for risk-scored changed functions, test gaps and affected flows.\n2. Call `get_affected_flows_tool` only when you need the steps of an affected flow.\n3. For each high-risk function, call `query_graph_tool` with `pattern=\"tests_for\"` to check test coverage.\n4. Call `get_impact_radius_tool` when the blast radius is not clear from step 1.\n5. Suggest specific test cases for untested changes.\n\n### Output Format\n\nGroup findings by risk level (high, medium, low). For each finding give what changed and why it matters, its test coverage, and the suggested fix. End with a merge recommendation.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n","frontmatter":{"name":"review-changes","description":"Perform a structured code review using change detection and impact"},"isInternal":false,"tokens":295,"sizeBytes":1322},{"name":"SKILL.md","path":"skills/review-delta/SKILL.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/skills/review-delta/SKILL.md","title":"review-delta","category":"anthropic-skill","format":"markdown","content":"---\nname: review-delta\ndescription: Review only changes since last commit using impact analysis. Token-efficient delta review with automatic blast-radius detection.\nargument-hint: \"[file or function name]\"\n---\n\n# Review Delta\n\nReview only the changed code and its blast radius.\n\n## Steps\n\n1. Call `get_minimal_context_tool(task=\"review changes\")`. If it returns `status: not_ready`, call `build_or_update_graph_tool()` and continue.\n2. Call `detect_changes_tool(detail_level=\"minimal\")` for risk-scored changed functions, test gaps and affected flows. Changes come from `git diff` against `HEAD~1`; if the argument names a file, pass it in `changed_files`.\n3. Call `get_review_context_tool(detail_level=\"minimal\")` when you need source snippets for the changed areas and `review_guidance` (untested functions, wide blast radius, inheritance changes).\n4. For each untested high-risk function, confirm with `query_graph_tool(pattern=\"tests_for\", target=\"<function>\")`.\n5. Use `detail_level=\"standard\"` only for a high-risk item the minimal output leaves unclear. Do not load whole files unless a snippet is not enough.\n\n## Report\n\n- Summary: one line\n- Risk: low, medium or high, from the blast radius\n- Issues: bugs, missing tests, style\n- Blast radius: impacted files and functions\n- Recommendations\n","frontmatter":{"name":"review-delta","description":"Review only changes since last commit using impact analysis. Token-efficient delta review with automatic blast-radius detection.","argument-hint":"[file or function name]"},"isInternal":false,"tokens":290,"sizeBytes":1300},{"name":"SKILL.md","path":"skills/review-pr/SKILL.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/skills/review-pr/SKILL.md","title":"review-pr","category":"anthropic-skill","format":"markdown","content":"---\nname: review-pr\ndescription: Review a PR or branch diff using the knowledge graph for full structural context. Outputs a structured review with blast-radius analysis.\nargument-hint: \"[PR number or branch name]\"\n---\n\n# Review PR\n\nReview all commits of a pull request or branch against its base branch.\n\n## Steps\n\n1. Identify the changes. With a branch name run `git diff --name-only main...<branch>`; otherwise diff the current branch against `main` (or `master`). Use that ref as `base` below.\n2. Call `get_minimal_context_tool(task=\"review PR\", base=\"main\")`. If it returns `status: not_ready`, call `build_or_update_graph_tool()` and continue.\n3. Call `detect_changes_tool(base=\"main\", detail_level=\"minimal\")` for risk-scored changed functions, test gaps and affected flows across the whole branch.\n4. For high-risk functions call `query_graph_tool(pattern=\"callers_of\", target=\"<function>\")` and `query_graph_tool(pattern=\"tests_for\", target=\"<function>\")`. Flag public API changes whose callers were not updated.\n5. Call `get_review_context_tool(base=\"main\")` for source snippets, or `get_impact_radius_tool(base=\"main\")` for the full dependent list, only when step 3 leaves a high-risk item unclear.\n6. Read the changed source of the highest-impact files first. Do not load whole files unless the change needs it.\n\n## Output\n\n```\n## PR Review: <title>\n\n### Summary\n<1-3 sentences>\n\n### Risk\n- Overall: Low / Medium / High\n- Blast radius: <n> files, <m> functions\n- Test coverage: <covered> of <changed> changed functions\n\n### Files\n#### <path>\n- Changes: <what>\n- Impact: <who depends on it>\n- Issues: <bugs, style, concerns>\n\n### Missing Tests\n- <function> in <file>\n\n### Recommendations\n1. <action>\n```\n\n## Tips\n\n- Use `semantic_search_nodes_tool` to find related code the PR may have missed.\n","frontmatter":{"name":"review-pr","description":"Review a PR or branch diff using the knowledge graph for full structural context. Outputs a structured review with blast-radius analysis.","argument-hint":"[PR number or branch name]"},"isInternal":false,"tokens":439,"sizeBytes":1805},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# CLAUDE.md - Project Context for Claude Code\n\n## Project Overview\n\ncode-review-graph is a local-first knowledge graph for code review. It parses a repository with Tree-sitter (plus targeted fallbacks), stores nodes and edges in SQLite, updates the graph incrementally from Git changes, and serves compact context over MCP and the CLI to AI coding tools. Supported platforms are the entries in `PLATFORMS` in `skills.py`: Claude Code, Codex, Cursor, Windsurf, Zed, Continue, OpenCode, Antigravity, Gemini CLI, Qwen Code, Kiro, Qoder, GitHub Copilot, GitHub Copilot CLI, Hermes Agent and CodeBuddy Code.\n\n## Graph Tool Usage (Token-Efficient)\n\nWhen using code-review-graph MCP tools:\n\n1. Call `get_minimal_context_tool(task=\"<description>\")` first. It costs about 100 tokens and gives the overview.\n2. Use `detail_level=\"minimal\"` on every later call unless that is not enough.\n3. Prefer `query_graph_tool` with a specific target over broad `list_*` calls.\n4. Follow the `next_tool_suggestions` field in each response.\n5. Target: at most 5 tool calls and 800 tokens of graph context per task.\n\nAll registered tool names end in `_tool`. The 30 tools are defined in `main.py`.\n\n## Architecture\n\nCore package `code_review_graph/` (Python 3.10+):\n\n- `main.py`: FastMCP server entry point. Registers 30 tools and 5 prompts.\n- `tools/`: tool implementations by domain: `build.py`, `query.py`, `review.py`, `context.py`, `flows_tools.py`, `community_tools.py`, `refactor_tools.py`, `docs.py`, `registry_tools.py`, `analysis_tools.py`; shared helpers in `_common.py`.\n- `prompts.py`: 5 MCP prompts (review_changes, architecture_map, debug_issue, onboard_developer, pre_merge_check).\n- `cli.py`: the `code-review-graph` command. `daemon.py` and `daemon_cli.py`: the `crg-daemon` multi-repo watch daemon.\n- `parser.py`: Tree-sitter multi-language parser with fallbacks for notebooks and other formats. `custom_languages.py`: languages defined in `.code-review-graph/languages.toml` (see docs/CUSTOM_LANGUAGES.md).\n- `graph.py`: SQLite graph store (nodes, edges, impact analysis). `migrations.py`: schema migrations; the current schema version is 13 and must equal `SUPPORTED_SCHEMA_VERSION` in the VS Code extension (CI checks this).\n- `incremental.py`: full build, Git/SVN change detection, incremental update, stale-file reconciliation, watch mode. `postprocessing.py`: shared post-build pipeline (signatures, flows, communities, FTS).\n- Post-build resolvers: `python_resolver.py`, `jedi_resolver.py` (optional `enrichment` extra), `spring_resolver.py`, `event_resolver.py`, `temporal_resolver.py`, `config_keys.py`, `scoped_resolver.py` (PHP, Rust, C#), `rescript_resolver.py`, `hcl_resolver.py`, `tsconfig_resolver.py` (tsconfig and jsconfig path aliases).\n- `flows.py`: execution flows and criticality. `communities.py`: Leiden via igraph (optional) or file-based grouping, plus the architecture overview. `analysis.py`: hub and bridge nodes, knowledge gaps, surprise scoring, suggested questions.\n- `search.py`: FTS5 keyword search combined with optional vector search. `embeddings.py`: providers for local sentence-transformers, OpenAI-compatible endpoints, Google Gemini, MiniMax and Voyage AI.\n- `changes.py`: risk-scored change analysis. `refactor.py`: rename preview, dead code, suggestions. `hints.py`: `next_tool_suggestions`. `uncertainty.py`: `confidence` notes on empty results. `context_savings.py`: estimated context-savings metadata.\n- `visualization.py`: D3.js HTML graph (D3 is bundled in `assets/`). `exports.py`: JSON, GraphML, Neo4j Cypher, Obsidian, SVG. `wiki.py`: Markdown wiki. `graph_diff.py`: snapshot diffing. `memory.py`: stored Q&A feedback.\n- `skills.py`: `install` (platform MCP configs, hooks, skills, instruction blocks). `_legacy_instructions.py`: instruction blocks shipped by earlier releases. `jsonc.py`: comment-preserving JSONC tokenising and splices, shared by install and uninstall so neither flattens a commented config. `uninstall.py`: reverses `install`. `enrich.py`: PreToolUse hook enrichment. `forget.py`: drops files from the graph. `registry.py`: multi-repo registry. `http_origin_guard.py`: Host/Origin checks for `serve --http`. `token_benchmark.py` and `eval/`: benchmarks. `constants.py`: shared constants.\n- `docs/LLM-OPTIMIZED-REFERENCE.md`: the reference served by `get_docs_section_tool`.\n\nVS Code extension: `code-review-graph-vscode/` (TypeScript, separate `package.json` and `tsconfig.json`). Reads `.code-review-graph/graph.db` directly.\n\nDatabase: `.code-review-graph/graph.db` (SQLite, WAL mode).\n\n## Key Commands\n\n```bash\n# Development\nuv run pytest tests/ --tb=short -q\nuv run ruff check code_review_graph/\nuv run mypy code_review_graph/ --ignore-missing-imports --no-strict-optional\n\n# Graph\nuv run code-review-graph build              # full build\nuv run code-review-graph update             # incremental update\nuv run code-review-graph status             # graph statistics\nuv run code-review-graph detect-changes     # risk-scored change analysis (read-only)\nuv run code-review-graph forget PATH        # drop files from the graph\nuv run code-review-graph serve              # MCP server (stdio; --http for localhost)\nuv run code-review-graph wiki               # Markdown wiki\nuv run code-review-graph register <path>    # add a repo to the multi-repo registry\nuv run code-review-graph eval               # benchmarks\nuv run code-review-graph --help             # full command list\n```\n\n## Code Conventions\n\n- Line length 100 (ruff). Python 3.10+.\n- SQL: parameterised queries with `?` placeholders. Never format values into SQL strings.\n- Errors: catch specific exceptions and log with `logger.warning` or `logger.error`.\n- Threads: `threading.Lock` around shared caches; SQLite opened with `check_same_thread=False`.\n- Node names: pass through `_sanitize_name()` before returning them to MCP clients.\n- File reads: read the bytes once, hash them, then parse the same bytes.\n\n## Security Invariants\n\n- No `eval()`, `exec()`, `pickle` or `yaml.unsafe_load()`.\n- No `shell=True` in subprocess calls.\n- `_validate_repo_root()` requires an existing directory containing `.git`, `.svn` or `.code-review-graph`, which blocks path traversal through `repo_root`.\n- `_sanitize_name()` strips control characters and caps names at 256 characters.\n- `escH()` in `visualization.py` escapes HTML entities including quotes and backticks; `</script>` is escaped inside embedded JSON.\n- D3.js is bundled and loaded with an SRI hash; the CDN fallback carries the same hash.\n- `http_origin_guard.py` validates Host and Origin for `serve --http`.\n- API keys come from environment variables only.\n\n## Test Structure\n\n`tests/` holds over 100 pytest modules. The main groups:\n\n- Core: `test_parser.py`, `test_graph.py`, `test_incremental.py`, `test_tools.py`, `test_main.py`, `test_cli*.py`.\n- Features: `test_flows.py`, `test_communities.py`, `test_changes.py`, `test_refactor.py`, `test_search.py`, `test_hints.py`, `test_prompts.py`, `test_wiki.py`, `test_embeddings.py`, `test_eval.py`, `test_registry.py`, `test_migrations.py`, `test_uncertainty.py`, `test_context_savings.py`, `test_token_budget.py` (per-tool token budgets).\n- Languages: `test_multilang.py`, `test_custom_languages.py`, `test_notebook.py`, plus per-language files such as `test_php_*.py`, `test_spring_*.py`, `test_kotlin_imports.py`, `test_go_embeddings.py`, `test_cpp_*.py`, `test_typescript_node_extensions.py`, `test_tsconfig_resolver.py`, `test_hcl_parser.py`, `test_dbt_parser.py`, `test_ansible_parser.py`.\n- Regression modules are named after the behaviour they pin, not the PR that produced them. The originating PR number goes in the module docstring.\n- Watch and daemon: `test_watch_*.py`, `test_daemon*.py`.\n- Install and platforms: `test_skills.py`, `test_cli_install.py`, `test_uninstall.py`, `test_git_hook_worktree.py`, `test_hermes_install.py`, `test_qoder_bundled_skills.py`, `test_installer_ownership.py` (what install may rewrite and what belongs to the user), `test_released_shapes.py` (reads the hooks and MCP entries every released tag wrote and requires them to still be recognised; needs tags, skips without them), `test_platform_lifecycle.py` (opt-in marker `platform_lifecycle`).\n- Windows: `test_windows_compat.py`, `test_windows_path_identity.py`.\n- Docs and GitHub Action: `test_documentation.py`, `test_action_render.py`.\n- Distribution gate: `test_packaging.py`, marked `packaging` and **skipped by default**. Builds a wheel and an sdist with `python -m build`, installs each into its own virtual environment, and drives the installed program with the checkout out of reach. Needs network and takes a couple of minutes. Run it before a release with `uv run --python 3.13 python -m pytest tests/test_packaging.py -m packaging`.\n- `tests/fixtures/`: sample files per supported language.\n\n## CI Pipeline\n\n`.github/workflows/ci.yml`:\n\n- lint: ruff on Python 3.10.\n- type-check: mypy.\n- security: bandit with the exemptions in `pyproject.toml`.\n- schema-sync: `LATEST_VERSION` in `migrations.py` must equal `SUPPORTED_SCHEMA_VERSION` in the VS Code extension.\n- test: pytest on Python 3.10, 3.11, 3.12 and 3.13; coverage must be at least 65%.\n- google-embeddings: constructs the Google provider with the `google-embeddings` and `all` extras.\n- windows-native: a subset of the suite on windows-latest.\n\n<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->\n## Beads Issue Tracker\n\nThis project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.\n\n### Quick Reference\n\n```bash\nbd ready              # Find available work\nbd show <id>          # View issue details\nbd update <id> --claim  # Claim work\nbd close <id>         # Complete work\n```\n\n### Rules\n\n- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists\n- Run `bd prime` for detailed command reference and session close protocol\n- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files\n\n## Branching Model\n\nThree long-lived branches, one direction: feature PR → `staging` (default) → `testing` → `main` → tag → PyPI.\nOpen every PR against `staging`. Never push to or open PRs against `testing` or `main`; those only\nreceive promotion PRs, always merged with a merge commit.\n\n`staging` → `testing` is automatic: `.github/workflows/auto-promote.yml` runs once a day and merges\nthe promotion PR when `staging` is ahead, every required check is green, and the promotion gate has\nnot failed on `testing`. The decision lives in `scripts/auto_promote.py`. It merges only a PR it\nopened itself — same repository, correctly aimed, labelled `auto-promotion`, pinned to the commit\nwhose checks were read — so a promotion PR you open by hand is left alone. It needs Settings →\nActions → General → Workflow permissions → *Allow GitHub Actions to create and approve pull\nrequests*. **Promotion to `main` is never automatic** — the maintainer opens and merges that PR by\nhand. Full rules in CONTRIBUTING.md \"Branching and promotion\".\n\n## Session Completion\n\n**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.\n\n**MANDATORY WORKFLOW:**\n\n1. **File issues for remaining work** - Create issues for anything that needs follow-up\n2. **Run quality gates** (if code changed) - Tests, linters, builds\n3. **Update issue status** - Close finished work, update in-progress items\n4. **PUSH TO REMOTE** - This is MANDATORY:\n   ```bash\n   git pull --rebase\n   bd dolt push\n   git push\n   git status  # MUST show \"up to date with origin\"\n   ```\n5. **Clean up** - Clear stashes, prune remote branches\n6. **Verify** - All changes committed AND pushed\n7. **Hand off** - Provide context for next session\n\n**CRITICAL RULES:**\n- Work is NOT complete until `git push` succeeds\n- NEVER stop before pushing - that leaves work stranded locally\n- NEVER say \"ready to push when you are\" - YOU must push\n- If push fails, resolve and retry until it succeeds\n<!-- END BEADS INTEGRATION -->\n\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","isInternal":false,"tokens":3471,"sizeBytes":14393},{"name":"GEMINI.md","path":"GEMINI.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/GEMINI.md","title":"Gemini Agent & Antigravity Instructions","category":"gemini-rule","format":"markdown","content":"# Gemini\n\nAgent rules for this repository live in [AGENTS.md](AGENTS.md). Project\ncontext (architecture, commands, conventions, tests) lives in\n[CLAUDE.md](CLAUDE.md). Both apply to Gemini CLI and Antigravity.\n\nThis file used to be a byte-identical copy of\n[.github/copilot-instructions.md](.github/copilot-instructions.md), which only\nexists because Copilot reads that exact path. Keeping a pointer here means the\ninstructions are maintained in one place.\n","isInternal":false,"tokens":111,"sizeBytes":457},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/tirth8205/code-review-graph/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n","isInternal":false,"tokens":528,"sizeBytes":2345}],"systemPromptSnippet":"<yakaai_skills repo=\"tirth8205/code-review-graph\">\n<!-- File: AGENTS.md (Tokens: ~1108 | Category: root-instruction) -->\n# Agent Instructions\n\nProject context (architecture, commands, conventions, tests) is in `CLAUDE.md`. This file holds the rules for every coding agent working in this repository.\n\n## Non-Interactive Shell Commands\n\n`cp`, `mv` and `rm` may be aliased with `-i` on some systems, which leaves an agent waiting for a y/n answer that never comes. Always pass the non-interactive flag:\n\n```bash\ncp -f source dest\nmv -f source dest\nrm -f file\nrm -rf directory\ncp -rf source dest\n```\n\nOther commands that may prompt: `scp` and `ssh` (`-o BatchMode=yes`), `apt-get` (`-y`), `brew` (`HOMEBREW_NO_AUTO_UPDATE=1`).\n\n<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->\n## Beads Issue Tracker\n\nThis project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.\n\n### Quick Reference\n\n```bash\nbd ready              # Find available work\nbd show <id>          # View issue details\nbd update <id> --claim  # Claim work\nbd close <id>         # Complete work\n```\n\n### Rules\n\n- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists\n- Run `bd prime` for detailed command reference and session close protocol\n- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files\n\n## Session Completion\n\n**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.\n\n**MANDATORY WORKFLOW:**\n\n1. **File issues for remaining work** - Create issues for anything that needs follow-up\n2. **Run quality gates** (if code changed) - Tests, linters, builds\n3. **Update issue status** - Close finished work, update in-progress items\n4. **PUSH TO REMOTE** - This is MANDATORY:\n   ```bash\n   git pull --rebase\n   bd dolt push\n   git push\n   git status  # MUST show \"up to date with origin\"\n   ```\n5. **Clean up** - Clear stashes, prune remote branches\n6. **Verify** - All changes committed AND pushed\n7. **Hand off** - Provide context for next session\n\n**CRITICAL RULES:**\n- Work is NOT complete until `git push` succeeds\n- NEVER stop before pushing - that leaves work stranded locally\n- NEVER say \"ready to push when you are\" - YOU must push\n- If push fails, resolve and retry until it succeeds\n<!-- END BEADS INTEGRATION -->\n\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n\n<!-- File: docs/architecture.md (Tokens: ~2255 | Category: project-spec) -->\n# Architecture\n\n## Overview\n\n`code-review-graph` keeps a persistent, incrementally updated graph of a codebase in SQLite\nand exposes it through a CLI and an MCP server. AI coding tools query the graph for\nstructural context (callers, dependents, tests, impact) instead of reading whole files.\nClaude Code is one supported client among several.\n\n## Components\n\n```text\n┌──────────────────────────────────────────────────────────────┐\n│                    AI coding clients / CLI                   │\n│                                                              │\n│  MCP clients              Hooks / watch mode                 │\n│  ├── Codex                └── incremental update             │\n│  ├── Claude Code, CodeBuddy Code                             │\n│  ├── Cursor, Windsurf, Zed, Continue                         │\n│  └── Gemini CLI, Qwen, Qoder, Copilot, OpenCode              │\n│          │                        │                          │\n│          ▼                        ▼                          │\n│  ┌────────────────────────────────────────────┐              │\n│  │      MCP Server (stdio or localhost HTTP)  │              │\n│  │                                            │              │\n│  │  30 MCP tools + 5 MCP prompts              │              │\n│  │  ├── Core: build, impact, query, review,   │              │\n│  │  │   search, traverse, embed, stats, docs  │              │\n│  │  ├── Flows: list, get, affected            │              │\n│  │  ├── Communities: list, get, architecture  │              │\n│  │  ├── Analysis: detect_changes, refactor,   │              │\n│  │  │   apply_refactor, hubs, bridges, gaps   │              │\n│  │  ├── Wiki: generate, get_page              │              │\n│  │  └── Multi-repo: list_repos, cross_search  │              │\n│  └────────────────┬───────────────────────────┘              │\n└───────────────────┼──────────────────────────────────────────┘\n                    │\n        ┌───────────┼───────────────┐\n        ▼           ▼               ▼\n   ┌─────────┐ ┌─────────┐  ┌─────────────┐\n   │ Parser  │ │  Graph  │  │ Incremental │\n   │         │ │  Store  │  │   Engine    │\n   └────┬────┘ └────┬────┘  └──────┬──────┘\n        │           │              │\n        ▼           ▼              ▼\n   Tree-sitter   SQLite DB      git/svn diff\n   grammars      (.code-review- subprocess\n                 graph/\n                 graph.db)\n```\n\n## Modules\n\nAll modules live in `code_review_graph/`.\n\n| Module | Role |\n|---|---|\n| `parser.py` | Tree-sitter multi-language parser plus targeted fallbacks; emits nodes and edges per file |\n| `custom_languages.py` | Config-driven languages from `.code-review-graph/languages.toml` |\n| `graph.py` | `GraphStore`: SQLite storage, queries, impact radius |\n| `migrations.py` | Versioned schema migrations, currently v11 (see `schema.md`) |\n| `incremental.py` | File collection and ignore rules, git/SVN change detection, full and incremental builds, post-build resolvers |\n| `postprocessing.py` | `run_post_processing()`: endpoint resolution, signatures, FTS sync, flows, communities, embedding refresh |\n| `python_resolver.py`, `jedi_resolver.py`, `tsconfig_resolver.py`, `spring_resolver.py`, `event_resolver.py`, `temporal_resolver.py`, `rescript_resolver.py`, `hcl_resolver.py`, `scoped_resolver.py` | Post-build cross-file resolution |\n| `flows.py` | Execution flow detection and criticality scoring |\n| `communities.py` | Leiden community detection (igraph) with a file-based fallback |\n| `search.py` | Hybrid search: FTS5 BM25 plus vector similarity |\n| `embeddings.py` | Embedding providers and the `embeddings` table |\n| `changes.py`, `refactor.py`, `analysis.py`, `hints.py`, `uncertainty.py`, `context_savings.py` | Change risk analysis, refactoring helpers, hub/bridge/gap analysis, response hints, empty-result markers, savings estimates |\n| `tools/` | MCP tool implementations, split by domain |\n| `main.py`, `prompts.py` | FastMCP server (30 tools, 5 prompts) |\n| `cli.py`, `daemon.py`, `daemon_cli.py` | CLI and the multi-repo watch daemon |\n| `visualization.py`, `exports.py`, `wiki.py`, `graph_diff.py`, `memory.py`, `forget.py` | HTML visualisation, export formats, wiki generation, snapshot diffing, Q&A memory, file removal |\n| `skills.py`, `uninstall.py`, `registry.py`, `enrich.py`, `http_origin_guard.py`, `config_keys.py`, `constants.py` | Platform install/uninstall, multi-repo registry, hook enrichment, HTTP Host/Origin checks, shared helpers |\n| `eval/`, `token_benchmark.py` | Evaluation framework and standalone token benchmark |\n\n## Data Flow\n\n### Full build (`incremental.full_build()`)\n1. `collect_all_files()` lists tracked files (`git ls-files` when git is available, so\n   untracked and gitignored files are skipped) and applies `.code-review-graphignore`.\n2. Each file is read once; the bytes are hashed (SHA-256) and passed to\n   `CodeParser.parse_bytes()`, which walks the Tree-sitter tree and emits nodes and edges.\n3. `GraphStore.store_file_nodes_edges()` (or `store_file_batch()`) replaces the file's rows\n   in one transaction, storing the hash for change detection.\n4. Metadata is written: `last_updated`, `last_build_type`, and the git or SVN head.\n5. Post-build resolvers qualify cross-file targets, then `run_post_processing()` computes\n   signatures, rebuilds the FTS index, traces flows, detects communities and refreshes\n   embeddings, unless skipped. An incremental update rewrites only the changed files'\n   FTS entries (`search.update_fts_index`); a full build rebuilds the index.\n\n### Incremental update (`incremental.incremental_update()`)\n1. `get_changed_files()` asks the VCS for changed paths (git diff by default; SVN is\n   supported).\n2. `find_dependents()` collects files with `IMPORTS_FROM`, `CALLS`, `INHERITS` or\n   `IMPLEMENTS` edges into the changed files, up to two hops and 500 files.\n3. Changed and dependent files whose hash differs from the stored one are re-parsed; the\n   rest are skipped.\n4. Only those files' rows are replaced, then post-processing runs as for a full build.\n\n### Review context (`tools/review.py: get_review_context()`)\n1. Changed files come from a git diff or an explicit list.\n2. `GraphStore.get_impact_radius()` finds the impacted nodes (see below).\n3. Source snippets are extracted for the changed regions only, within a file budget.\n4. `_generate_review_guidance()` adds warnings: changed functions without `TESTED_BY`\n   edges, more than 20 impacted nodes, and inheritance changes.\n5. `attach_context_savings()` adds an estimate of the tokens saved against reading the\n   files, labelled `estimated: true`.\n\nThe MCP entry points are `get_review_context_tool`, `get_impact_radius_tool` and\n`detect_changes_tool` in `main.py`.\n\n## Impact Analysis\n\n`GraphStore.get_impact_radius()` delegates to `get_impact_radius_sql()`, a bounded\nbest-score relaxation run inside SQLite. Setting `CRG_BFS_ENGINE=networkx` selects the older\nPython-side traversal instead.\n\n1. Seed with every node in the changed files.\n2. For each depth step (default 2, `CRG_MAX_IMPACT_DEPTH`), propagate along edges in the\n   direction set per edge kind in `constants.IMPACT_EDGE_DIRECTIONS`: dependency-shaped\n   edges such as `CALLS` and `IMPORTS_FROM` flow from target to source (callers and\n   importers of changed code), `TESTED_BY` flows from production code to its tests, and\n   `CONTAINS` is not expanded because the whole file is already seeded.\n3. Each reached node keeps its best score: previous score x edge weight\n   (`constants.IMPACT_EDGE_WEIGHTS`, default 0.5) x depth decay\n   (`CRG_IMPACT_DEPTH_DECAY`, default 0.6).\n4. Results are ordered by score and cut at `CRG_MAX_IMPACT_NODES` (default 500); the\n   response says whether it was truncated.\n\n## Storage\n\nOne SQLite database, `.code-review-graph/graph.db`, in WAL mode so readers are not blocked\nduring updates. Tables: `nodes`, `edges`, `metadata`, `flows`, `flow_memberships`,\n`communities`, `nodes_fts` (FTS5), `nodes_fts_state`, `community_summaries`,\n`flow_snapshots`, `risk_index`, and\n`embeddings` (created by `EmbeddingStore` in the same file). Columns, indexes and the\nmigration history are in [schema.md](schema.md).\n\nNodes are identified by qualified name: the file path for File nodes, `path::name` for\ntop-level symbols and `path::Class.method` for members.\n\n## Parsing\n\nThe parser walks the Tree-sitter tree directly rather than using tree-sitter query files,\nwhich keeps it independent of query syntax differences between grammar versions. Per-language\nnode type tables (`_CLASS_TYPES`, `_FUNCTION_TYPES` and similar in `parser.py`) drive:\n\n1. Class, function and type extraction with names, parameters, return types and bases.\n2. Call detection inside function bodies.\n3. Import resolution to module paths, refined later by the post-build resolvers.\n\nLanguages without a grammar can be added through `.code-review-graph/languages.toml`\n(`docs/CUSTOM_LANGUAGES.md`). Some formats (notebooks, Vue and Svelte SFCs, SQL, Ansible,\nSpring configuration) use targeted parsers instead of Tree-sitter.\n\n## Visualisation\n\n`visualization.py` writes a self-contained HTML file with a D3.js force-directed graph of the\nnodes and edges, with filters by node and edge kind and a search box.\n\n<!-- File: skills/build-graph/SKILL.md (Tokens: ~262 | Category: anthropic-skill) -->\n---\nname: build-graph\ndescription: Build or update the code review knowledge graph. Run this first to initialize, or let hooks keep it updated automatically.\nargument-hint: \"[full]\"\n---\n\n# Build Graph\n\nBuild or incrementally update the knowledge graph for this repository.\n\n## Steps\n\n1. Call `list_graph_stats_tool`. If `last_updated` is null, the graph has never been built.\n2. For a first build, or when the argument is `full`, call `build_or_update_graph_tool(full_rebuild=True)`. Otherwise call `build_or_update_graph_tool()` for an incremental update.\n3. Report the response: `status` (`ok`, `partial` or `error`) and `summary`.\n\n## When to Use\n\n- First set-up of a repository, or after a branch switch or large refactor.\n- When the graph looks stale. Hooks installed by `code-review-graph install` run an update after each edit and before each commit, so manual builds are rarely needed.\n\n## Notes\n\n- The database is `.code-review-graph/graph.db` in the repository root.\n- Binary files, dependency and build directories, and patterns in `.code-review-graphignore` are skipped.\n- For the list of supported languages call `get_docs_section_tool(section_name=\"languages\")`.\n\n<!-- File: skills/debug-issue/SKILL.md (Tokens: ~259 | Category: anthropic-skill) -->\n---\nname: debug-issue\ndescription: Systematically debug issues using graph-powered code navigation\n---\n\n## Debug Issue\n\nTrace a bug through the knowledge graph before reading source.\n\n### Steps\n\n1. Call `semantic_search_nodes_tool` to find code related to the issue.\n2. Call `query_graph_tool` with `callers_of` and `callees_of` to trace the call chain in both directions.\n3. Call `get_flow_tool` for the execution path that reaches the suspect code. Its entry point is where the bug is triggered.\n4. Call `detect_changes_tool` to check whether a recent change caused the issue.\n5. Call `get_impact_radius_tool` on the suspect files to see what a fix would affect.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n\n<!-- File: skills/explore-codebase/SKILL.md (Tokens: ~309 | Category: anthropic-skill) -->\n---\nname: explore-codebase\ndescription: Navigate and understand codebase structure using the knowledge graph\n---\n\n## Explore Codebase\n\nUse the code-review-graph MCP tools to find your way around the codebase.\n\n### Steps\n\n1. Call `get_architecture_overview_tool` for the community structure. Call `list_communities_tool`, then `get_community_tool`, only for the modules you need.\n2. Call `semantic_search_nodes_tool` to find a function or class by name or keyword.\n3. Call `query_graph_tool` with `callers_of`, `callees_of` or `imports_of` to trace relationships. `children_of` on a file lists its functions and classes.\n4. Call `list_flows_tool`, then `get_flow_tool` for one flow, to follow an execution path.\n5. Call `find_large_functions_tool` to find oversized functions.\n6. Call `list_graph_stats_tool` only when you need node, edge and language counts.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n\n<!-- File: skills/refactor-safely/SKILL.md (Tokens: ~311 | Category: anthropic-skill) -->\n---\nname: refactor-safely\ndescription: Plan and execute safe refactoring using dependency analysis\n---\n\n## Refactor Safely\n\nPlan a refactor from the dependency graph and apply renames from a preview.\n\n### Steps\n\n1. Call `refactor_tool` with `mode=\"suggest\"` for refactoring candidates, or `mode=\"dead_code\"` for unreferenced code.\n2. For a rename, call `refactor_tool` with `mode=\"rename\"`, `old_name` and `new_name`. Check the returned edit list before applying.\n3. Call `apply_refactor_tool` with the returned `refactor_id` to apply the rename.\n4. Before a large refactor, call `get_impact_radius_tool` and `get_affected_flows_tool` to see the dependents and critical paths involved.\n5. Call `find_large_functions_tool` to find functions worth splitting.\n6. After the change, call `detect_changes_tool` to confirm the impact matches the plan.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n\n<!-- File: skills/review-changes/SKILL.md (Tokens: ~295 | Category: anthropic-skill) -->\n---\nname: review-changes\ndescription: Perform a structured code review using change detection and impact\n---\n\n## Review Changes\n\nReview a change set with risk scores and blast radius from the knowledge graph.\n\n### Steps\n\n1. Call `detect_changes_tool` for risk-scored changed functions, test gaps and affected flows.\n2. Call `get_affected_flows_tool` only when you need the steps of an affected flow.\n3. For each high-risk function, call `query_graph_tool` with `pattern=\"tests_for\"` to check test coverage.\n4. Call `get_impact_radius_tool` when the blast radius is not clear from step 1.\n5. Suggest specific test cases for untested changes.\n\n### Output Format\n\nGroup findings by risk level (high, medium, low). For each finding give what changed and why it matters, its test coverage, and the suggested fix. End with a merge recommendation.\n\n## Token Efficiency Rules\n- Call `get_minimal_context_tool(task=\"<your task>\")` before any other graph tool.\n- Pass `detail_level=\"minimal\"` wherever a tool accepts it. Use \"standard\" only when minimal is not enough.\n- Prefer a targeted `query_graph_tool` call over a broad listing call.\n- Budget: about five tool calls and 800 tokens of graph output per task.\n- Read the implementation and its tests before changing code. The graph narrows scope; it does not replace the source.\n\n<!-- File: skills/review-delta/SKILL.md (Tokens: ~290 | Category: anthropic-skill) -->\n---\nname: review-delta\ndescription: Review only changes since last commit using impact analysis. Token-efficient delta review with automatic blast-radius detection.\nargument-hint: \"[file or function name]\"\n---\n\n# Review Delta\n\nReview only the changed code and its blast radius.\n\n## Steps\n\n1. Call `get_minimal_context_tool(task=\"review changes\")`. If it returns `status: not_ready`, call `build_or_update_graph_tool()` and continue.\n2. Call `detect_changes_tool(detail_level=\"minimal\")` for risk-scored changed functions, test gaps and affected flows. Changes come from `git diff` against `HEAD~1`; if the argument names a file, pass it in `changed_files`.\n3. Call `get_review_context_tool(detail_level=\"minimal\")` when you need source snippets for the changed areas and `review_guidance` (untested functions, wide blast radius, inheritance changes).\n4. For each untested high-risk function, confirm with `query_graph_tool(pattern=\"tests_for\", target=\"<function>\")`.\n5. Use `detail_level=\"standard\"` only for a high-risk item the minimal output leaves unclear. Do not load whole files unless a snippet is not enough.\n\n## Report\n\n- Summary: one line\n- Risk: low, medium or high, from the blast radius\n- Issues: bugs, missing tests, style\n- Blast radius: impacted files and functions\n- Recommendations\n\n<!-- File: skills/review-pr/SKILL.md (Tokens: ~439 | Category: anthropic-skill) -->\n---\nname: review-pr\ndescription: Review a PR or branch diff using the knowledge graph for full structural context. Outputs a structured review with blast-radius analysis.\nargument-hint: \"[PR number or branch name]\"\n---\n\n# Review PR\n\nReview all commits of a pull request or branch against its base branch.\n\n## Steps\n\n1. Identify the changes. With a branch name run `git diff --name-only main...<branch>`; otherwise diff the current branch against `main` (or `master`). Use that ref as `base` below.\n2. Call `get_minimal_context_tool(task=\"review PR\", base=\"main\")`. If it returns `status: not_ready`, call `build_or_update_graph_tool()` and continue.\n3. Call `detect_changes_tool(base=\"main\", detail_level=\"minimal\")` for risk-scored changed functions, test gaps and affected flows across the whole branch.\n4. For high-risk functions call `query_graph_tool(pattern=\"callers_of\", target=\"<function>\")` and `query_graph_tool(pattern=\"tests_for\", target=\"<function>\")`. Flag public API changes whose callers were not updated.\n5. Call `get_review_context_tool(base=\"main\")` for source snippets, or `get_impact_radius_tool(base=\"main\")` for the full dependent list, only when step 3 leaves a high-risk item unclear.\n6. Read the changed source of the highest-impact files first. Do not load whole files unless the change needs it.\n\n## Output\n\n```\n## PR Review: <title>\n\n### Summary\n<1-3 sentences>\n\n### Risk\n- Overall: Low / Medium / High\n- Blast radius: <n> files, <m> functions\n- Test coverage: <covered> of <changed> changed functions\n\n### Files\n#### <path>\n- Changes: <what>\n- Impact: <who depends on it>\n- Issues: <bugs, style, concerns>\n\n### Missing Tests\n- <function> in <file>\n\n### Recommendations\n1. <action>\n```\n\n## Tips\n\n- Use `semantic_search_nodes_tool` to find related code the PR may have missed.\n\n<!-- File: CLAUDE.md (Tokens: ~3471 | Category: claude-rule) -->\n# CLAUDE.md - Project Context for Claude Code\n\n## Project Overview\n\ncode-review-graph is a local-first knowledge graph for code review. It parses a repository with Tree-sitter (plus targeted fallbacks), stores nodes and edges in SQLite, updates the graph incrementally from Git changes, and serves compact context over MCP and the CLI to AI coding tools. Supported platforms are the entries in `PLATFORMS` in `skills.py`: Claude Code, Codex, Cursor, Windsurf, Zed, Continue, OpenCode, Antigravity, Gemini CLI, Qwen Code, Kiro, Qoder, GitHub Copilot, GitHub Copilot CLI, Hermes Agent and CodeBuddy Code.\n\n## Graph Tool Usage (Token-Efficient)\n\nWhen using code-review-graph MCP tools:\n\n1. Call `get_minimal_context_tool(task=\"<description>\")` first. It costs about 100 tokens and gives the overview.\n2. Use `detail_level=\"minimal\"` on every later call unless that is not enough.\n3. Prefer `query_graph_tool` with a specific target over broad `list_*` calls.\n4. Follow the `next_tool_suggestions` field in each response.\n5. Target: at most 5 tool calls and 800 tokens of graph context per task.\n\nAll registered tool names end in `_tool`. The 30 tools are defined in `main.py`.\n\n## Architecture\n\nCore package `code_review_graph/` (Python 3.10+):\n\n- `main.py`: FastMCP server entry point. Registers 30 tools and 5 prompts.\n- `tools/`: tool implementations by domain: `build.py`, `query.py`, `review.py`, `context.py`, `flows_tools.py`, `community_tools.py`, `refactor_tools.py`, `docs.py`, `registry_tools.py`, `analysis_tools.py`; shared helpers in `_common.py`.\n- `prompts.py`: 5 MCP prompts (review_changes, architecture_map, debug_issue, onboard_developer, pre_merge_check).\n- `cli.py`: the `code-review-graph` command. `daemon.py` and `daemon_cli.py`: the `crg-daemon` multi-repo watch daemon.\n- `parser.py`: Tree-sitter multi-language parser with fallbacks for notebooks and other formats. `custom_languages.py`: languages defined in `.code-review-graph/languages.toml` (see docs/CUSTOM_LANGUAGES.md).\n- `graph.py`: SQLite graph store (nodes, edges, impact analysis). `migrations.py`: schema migrations; the current schema version is 13 and must equal `SUPPORTED_SCHEMA_VERSION` in the VS Code extension (CI checks this).\n- `incremental.py`: full build, Git/SVN change detection, incremental update, stale-file reconciliation, watch mode. `postprocessing.py`: shared post-build pipeline (signatures, flows, communities, FTS).\n- Post-build resolvers: `python_resolver.py`, `jedi_resolver.py` (optional `enrichment` extra), `spring_resolver.py`, `event_resolver.py`, `temporal_resolver.py`, `config_keys.py`, `scoped_resolver.py` (PHP, Rust, C#), `rescript_resolver.py`, `hcl_resolver.py`, `tsconfig_resolver.py` (tsconfig and jsconfig path aliases).\n- `flows.py`: execution flows and criticality. `communities.py`: Leiden via igraph (optional) or file-based grouping, plus the architecture overview. `analysis.py`: hub and bridge nodes, knowledge gaps, surprise scoring, suggested questions.\n- `search.py`: FTS5 keyword search combined with optional vector search. `embeddings.py`: providers for local sentence-transformers, OpenAI-compatible endpoints, Google Gemini, MiniMax and Voyage AI.\n- `changes.py`: risk-scored change analysis. `refactor.py`: rename preview, dead code, suggestions. `hints.py`: `next_tool_suggestions`. `uncertainty.py`: `confidence` notes on empty results. `context_savings.py`: estimated context-savings metadata.\n- `visualization.py`: D3.js HTML graph (D3 is bundled in `assets/`). `exports.py`: JSON, GraphML, Neo4j Cypher, Obsidian, SVG. `wiki.py`: Markdown wiki. `graph_diff.py`: snapshot diffing. `memory.py`: stored Q&A feedback.\n- `skills.py`: `install` (platform MCP configs, hooks, skills, instruction blocks). `_legacy_instructions.py`: instruction blocks shipped by earlier releases. `jsonc.py`: comment-preserving JSONC tokenising and splices, shared by install and uninstall so neither flattens a commented config. `uninstall.py`: reverses `install`. `enrich.py`: PreToolUse hook enrichment. `forget.py`: drops files from the graph. `registry.py`: multi-repo registry. `http_origin_guard.py`: Host/Origin checks for `serve --http`. `token_benchmark.py` and `eval/`: benchmarks. `constants.py`: shared constants.\n- `docs/LLM-OPTIMIZED-REFERENCE.md`: the reference served by `get_docs_section_tool`.\n\nVS Code extension: `code-review-graph-vscode/` (TypeScript, separate `package.json` and `tsconfig.json`). Reads `.code-review-graph/graph.db` directly.\n\nDatabase: `.code-review-graph/graph.db` (SQLite, WAL mode).\n\n## Key Commands\n\n```bash\n# Development\nuv run pytest tests/ --tb=short -q\nuv run ruff check code_review_graph/\nuv run mypy code_review_graph/ --ignore-missing-imports --no-strict-optional\n\n# Graph\nuv run code-review-graph build              # full build\nuv run code-review-graph update             # incremental update\nuv run code-review-graph status             # graph statistics\nuv run code-review-graph detect-changes     # risk-scored change analysis (read-only)\nuv run code-review-graph forget PATH        # drop files from the graph\nuv run code-review-graph serve              # MCP server (stdio; --http for localhost)\nuv run code-review-graph wiki               # Markdown wiki\nuv run code-review-graph register <path>    # add a repo to the multi-repo registry\nuv run code-review-graph eval               # benchmarks\nuv run code-review-graph --help             # full command list\n```\n\n## Code Conventions\n\n- Line length 100 (ruff). Python 3.10+.\n- SQL: parameterised queries with `?` placeholders. Never format values into SQL strings.\n- Errors: catch specific exceptions and log with `logger.warning` or `logger.error`.\n- Threads: `threading.Lock` around shared caches; SQLite opened with `check_same_thread=False`.\n- Node names: pass through `_sanitize_name()` before returning them to MCP clients.\n- File reads: read the bytes once, hash them, then parse the same bytes.\n\n## Security Invariants\n\n- No `eval()`, `exec()`, `pickle` or `yaml.unsafe_load()`.\n- No `shell=True` in subprocess calls.\n- `_validate_repo_root()` requires an existing directory containing `.git`, `.svn` or `.code-review-graph`, which blocks path traversal through `repo_root`.\n- `_sanitize_name()` strips control characters and caps names at 256 characters.\n- `escH()` in `visualization.py` escapes HTML entities including quotes and backticks; `</script>` is escaped inside embedded JSON.\n- D3.js is bundled and loaded with an SRI hash; the CDN fallback carries the same hash.\n- `http_origin_guard.py` validates Host and Origin for `serve --http`.\n- API keys come from environment variables only.\n\n## Test Structure\n\n`tests/` holds over 100 pytest modules. The main groups:\n\n- Core: `test_parser.py`, `test_graph.py`, `test_incremental.py`, `test_tools.py`, `test_main.py`, `test_cli*.py`.\n- Features: `test_flows.py`, `test_communities.py`, `test_changes.py`, `test_refactor.py`, `test_search.py`, `test_hints.py`, `test_prompts.py`, `test_wiki.py`, `test_embeddings.py`, `test_eval.py`, `test_registry.py`, `test_migrations.py`, `test_uncertainty.py`, `test_context_savings.py`, `test_token_budget.py` (per-tool token budgets).\n- Languages: `test_multilang.py`, `test_custom_languages.py`, `test_notebook.py`, plus per-language files such as `test_php_*.py`, `test_spring_*.py`, `test_kotlin_imports.py`, `test_go_embeddings.py`, `test_cpp_*.py`, `test_typescript_node_extensions.py`, `test_tsconfig_resolver.py`, `test_hcl_parser.py`, `test_dbt_parser.py`, `test_ansible_parser.py`.\n- Regression modules are named after the behaviour they pin, not the PR that produced them. The originating PR number goes in the module docstring.\n- Watch and daemon: `test_watch_*.py`, `test_daemon*.py`.\n- Install and platforms: `test_skills.py`, `test_cli_install.py`, `test_uninstall.py`, `test_git_hook_worktree.py`, `test_hermes_install.py`, `test_qoder_bundled_skills.py`, `test_installer_ownership.py` (what install may rewrite and what belongs to the user), `test_released_shapes.py` (reads the hooks and MCP entries every released tag wrote and requires them to still be recognised; needs tags, skips without them), `test_platform_lifecycle.py` (opt-in marker `platform_lifecycle`).\n- Windows: `test_windows_compat.py`, `test_windows_path_identity.py`.\n- Docs and GitHub Action: `test_documentation.py`, `test_action_render.py`.\n- Distribution gate: `test_packaging.py`, marked `packaging` and **skipped by default**. Builds a wheel and an sdist with `python -m build`, installs each into its own virtual environment, and drives the installed program with the checkout out of reach. Needs network and takes a couple of minutes. Run it before a release with `uv run --python 3.13 python -m pytest tests/test_packaging.py -m packaging`.\n- `tests/fixtures/`: sample files per supported language.\n\n## CI Pipeline\n\n`.github/workflows/ci.yml`:\n\n- lint: ruff on Python 3.10.\n- type-check: mypy.\n- security: bandit with the exemptions in `pyproject.toml`.\n- schema-sync: `LATEST_VERSION` in `migrations.py` must equal `SUPPORTED_SCHEMA_VERSION` in the VS Code extension.\n- test: pytest on Python 3.10, 3.11, 3.12 and 3.13; coverage must be at least 65%.\n- google-embeddings: constructs the Google provider with the `google-embeddings` and `all` extras.\n- windows-native: a subset of the suite on windows-latest.\n\n<!-- BEGIN BEADS INTEGRATION v:1 profile:minimal hash:ca08a54f -->\n## Beads Issue Tracker\n\nThis project uses **bd (beads)** for issue tracking. Run `bd prime` to see full workflow context and commands.\n\n### Quick Reference\n\n```bash\nbd ready              # Find available work\nbd show <id>          # View issue details\nbd update <id> --claim  # Claim work\nbd close <id>         # Complete work\n```\n\n### Rules\n\n- Use `bd` for ALL task tracking — do NOT use TodoWrite, TaskCreate, or markdown TODO lists\n- Run `bd prime` for detailed command reference and session close protocol\n- Use `bd remember` for persistent knowledge — do NOT use MEMORY.md files\n\n## Branching Model\n\nThree long-lived branches, one direction: feature PR → `staging` (default) → `testing` → `main` → tag → PyPI.\nOpen every PR against `staging`. Never push to or open PRs against `testing` or `main`; those only\nreceive promotion PRs, always merged with a merge commit.\n\n`staging` → `testing` is automatic: `.github/workflows/auto-promote.yml` runs once a day and merges\nthe promotion PR when `staging` is ahead, every required check is green, and the promotion gate has\nnot failed on `testing`. The decision lives in `scripts/auto_promote.py`. It merges only a PR it\nopened itself — same repository, correctly aimed, labelled `auto-promotion`, pinned to the commit\nwhose checks were read — so a promotion PR you open by hand is left alone. It needs Settings →\nActions → General → Workflow permissions → *Allow GitHub Actions to create and approve pull\nrequests*. **Promotion to `main` is never automatic** — the maintainer opens and merges that PR by\nhand. Full rules in CONTRIBUTING.md \"Branching and promotion\".\n\n## Session Completion\n\n**When ending a work session**, you MUST complete ALL steps below. Work is NOT complete until `git push` succeeds.\n\n**MANDATORY WORKFLOW:**\n\n1. **File issues for remaining work** - Create issues for anything that needs follow-up\n2. **Run quality gates** (if code changed) - Tests, linters, builds\n3. **Update issue status** - Close finished work, update in-progress items\n4. **PUSH TO REMOTE** - This is MANDATORY:\n   ```bash\n   git pull --rebase\n   bd dolt push\n   git push\n   git status  # MUST show \"up to date with origin\"\n   ```\n5. **Clean up** - Clear stashes, prune remote branches\n6. **Verify** - All changes committed AND pushed\n7. **Hand off** - Provide context for next session\n\n**CRITICAL RULES:**\n- Work is NOT complete until `git push` succeeds\n- NEVER stop before pushing - that leaves work stranded locally\n- NEVER say \"ready to push when you are\" - YOU must push\n- If push fails, resolve and retry until it succeeds\n<!-- END BEADS INTEGRATION -->\n\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n\n<!-- File: GEMINI.md (Tokens: ~111 | Category: gemini-rule) -->\n# Gemini\n\nAgent rules for this repository live in [AGENTS.md](AGENTS.md). Project\ncontext (architecture, commands, conventions, tests) lives in\n[CLAUDE.md](CLAUDE.md). Both apply to Gemini CLI and Antigravity.\n\nThis file used to be a byte-identical copy of\n[.github/copilot-instructions.md](.github/copilot-instructions.md), which only\nexists because Copilot reads that exact path. Keeping a pointer here means the\ninstructions are maintained in one place.\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~528 | Category: copilot-instructions) -->\n<!-- code-review-graph MCP tools -->\n## MCP Tools: code-review-graph\n\n**This project has a knowledge graph. Start with the code-review-graph\nMCP tools to narrow scope, then read the source.** The graph is cheaper than scanning files and\ngives you structural context (callers, dependents, test coverage) that file search cannot.\n\n### When to use graph tools FIRST\n\n- **Exploring code**: `semantic_search_nodes_tool` or `query_graph_tool` instead of Grep\n- **Understanding impact**: `get_impact_radius_tool` instead of manually tracing imports\n- **Code review**: `detect_changes_tool` + `get_review_context_tool` instead of reading entire files\n- **Finding relationships**: `query_graph_tool` with callers_of/callees_of/imports_of/tests_for\n- **Architecture questions**: `get_architecture_overview_tool` + `list_communities_tool`\n\n### Verify in the source\n\n- Narrow scope with the graph, then read the source. Do not change code from graph output alone.\n- For any non-trivial change, read the implementation and the relevant tests before concluding.\n- Verify the exact source when touching behavior, database logic, migrations, retries, fallbacks,\n  recovery, or compatibility code.\n- When the graph and the source disagree, the source wins. The graph may be stale or may not\n  model that relationship.\n- An empty graph result can mean \"not indexed\" or \"not statically visible\", not \"does not exist\".\n\n### Key Tools\n\n| Tool | Use when |\n| ------ | ---------- |\n| `detect_changes_tool` | Reviewing code changes — gives risk-scored analysis |\n| `get_review_context_tool` | Need source snippets for review — token-efficient |\n| `get_impact_radius_tool` | Understanding blast radius of a change |\n| `get_affected_flows_tool` | Finding which execution paths are impacted |\n| `query_graph_tool` | Tracing callers, callees, imports, tests, dependencies |\n| `semantic_search_nodes_tool` | Finding functions/classes by name or keyword |\n| `get_architecture_overview_tool` | Understanding high-level codebase structure |\n| `refactor_tool` | Planning renames, finding dead code |\n\n### Workflow\n\n1. The graph auto-updates on file changes (via hooks).\n2. Use `detect_changes_tool` for code review.\n3. Use `get_affected_flows_tool` to understand impact.\n4. Use `query_graph_tool` pattern=\"tests_for\" to check coverage.\n<!-- /code-review-graph MCP tools -->\n</yakaai_skills>"}