GitNexus Tooling

GitNexus provides structural analysis, blast radius identification, and execution flow tracking within an indexed repository. It acts as the primary safety layer for assessing the impact of code changes before implementation. The tool exists as a set of Model Context Protocol (MCP) servers and a command-line interface (CLI) used for indexing and administrative tasks.

Sources: CLAUDE.md:218-223, README.md:144-152

Core Capabilities

GitNexus enables deep codebase exploration beyond raw text search. It focuses on the semantic relationship between symbols, identifying how a change in one module propagates through callers and callees.

Analysis Workflow

The GitNexus workflow follows a tiered approach to exploration. You use the fff MCP server for initial file and symbol discovery. You then switch to GitNexus to understand the meaning, architecture, and safety of the implementation.

The diagram above shows the progression from raw text discovery to semantic impact analysis.

Sources: CLAUDE.md:225-236

Search and Context Tools

GitNexus provides specialized tools via the MCP interface. These tools require a repo selector, which is derived from the repo-context-forge packet.

Sources: CLAUDE.md:220-222, CLAUDE.md:231-236

Integration in Production Workflow

GitNexus is a mandatory step in the repository production workflow. It validates the "packet-scoped" targets established during the bootstrap phase.

1. Workflow Step 3: GitNexus analysis fires after the repo-context-forge bootstrap.
2. Evidence Recording: The adapter records the resolved graph result as repo-context-forge evidence.
3. Impact Checks: You run mcp__gitnexus__impact with direction: upstream and includeTests: true before editing any symbol.
4. Verification: After structural changes, you reindex the repository to detect staleness.

This sequence shows how GitNexus graph results are recorded as workflow evidence.

Sources: skills/repo-production-workflow/SKILL.md:38-42, CLAUDE.md:255-257

Impact Analysis Doctrine

GitNexus enforces a specific safety doctrine when you modify code. You must assess both directions of impact to prevent regressions.

Upstream and Downstream Impact

• Upstream Impact: You run impact with direction: upstream to identify all callers that might break due to a modified contract.
• Downstream Impact: You run impact with direction: downstream when behavior is moved, consolidated, or hidden behind a new interface.
• Testing Surface: You must pass includeTests: true to reveal the regression surface required to keep the change "green."

Sources: CLAUDE.md:238-246

Shared State Analysis

When a change touches shared state (tables, rows, files, or transition helpers), you run mcp__gitnexus__context on every symbol that mutates that state. This identifies competing writers that a single upstream impact call might miss.

Sources: CLAUDE.md:250-254, skills/production-code/SKILL.md:144-149

Maintenance and Indexing

GitNexus relies on a local index of the source checkout. If structural changes occur or staleness is detected, you must force a reindex.

Indexing Command

Use the CLI to analyze the current top-level directory:

gitnexus analyze --force --skip-agents-md "$(git rev-parse --show-toplevel)"

Sources: CLAUDE.md:255-256, skills/diagnose/SKILL.md:144-148

Configuration

GitNexus configuration is stored in ~/.claude.json. The MCP server and CLI must point to the same build to ensure consistent results.

"gitnexus": {
  "type": "stdio",
  "command": "node",
  "args": ["/home/prop_/projects/GitNexus-pr1-review/gitnexus/dist/cli/index.js", "mcp"],
  "env": {}
}

Sources: README.md:166-173

Summary

GitNexus Tooling is the semantic engine of the claude-skills estate. It transforms raw codebase exploration into a governed impact assessment. By integrating structural analysis directly into the repo-production-workflow, it ensures that every code edit is preceded by a verified blast radius check and supported by recorded graph evidence.