GitNexus Reindex

CLI ONLY — no MCP server exists. Never use readMcpResource with gitnexus:// URIs.

Re-index the current repository's GitNexus knowledge graph and verify the updated stats.

When to Use

• After significant refactors (5+ files changed)

• When staleness hook reports index is behind

• After merging a large PR

• "Refresh the knowledge graph"

Workflow

Step 0: Pre-flight — Ensure CLI Is Callable

The gitnexus binary is installed via npm/mise. The mise shim may fail if node isn't active in the current project. Run this pre-flight before any gitnexus command:

Test if gitnexus is actually callable (not just a broken shim)

gitnexus --version 2>/dev/null || mise use node@25.8.0

All commands below run from the repo root. If multiple repos are indexed in the workspace, add --repo <repo-name> to specify the target. Otherwise --repo is optional.

Step 1: Check Current Status

gitnexus status

If already current (lastCommit matches HEAD), report "Index is up to date" and stop.

Step 2: Run Indexer

gitnexus analyze

Use --force if the index appears corrupted or if a normal analyze doesn't pick up changes:

gitnexus analyze --force

This may take 30–120 seconds depending on codebase size.

Step 3: Verify New Index

gitnexus status

Step 4: Report Stats

Present the updated stats:

GitNexus Reindex Complete

Index is now current with HEAD.

Notes

• The analyze command runs locally — no network calls

• KuzuDB database is stored in .gitnexus/ at the repo root

• Large codebases (10k+ files) may take 2+ minutes

• The --force flag rebuilds from scratch; without it, incremental analysis is used