GitNexus

Imported from vcombey/GitNexus (AGENTS.md). Install upstream with npx skills add vcombey/GitNexus. Copyright stays with the author.

Last reviewed: 2026-03-24

Project: GitNexus · Environment: dev · Maintainer: repository maintainers (see GitHub)

This file uses a standard agent header (version, scope, model policy, reference docs, changelog), adapted for this TypeScript/JavaScript monorepo.

Scope

Model Configuration

• Primary: Pin in Cursor (Settings → model). Use a named model (e.g. GPT-5.2, Claude Sonnet 4.x). Avoid relying on Auto when reproducibility or audit trail matters.
• Fallback: As configured in Cursor or your organization (do not encode latest or wildcards in automation configs).
• Notes: The open-source GitNexus CLI indexer does not call an LLM. Optional Nexus AI in the web UI uses end-user provider keys and models.

Execution Sequence (complex tasks)

Long sessions dilute instructions. For multi-step work, state up front:

1. Which rules in this file and GUARDRAILS.md apply (and any relevant Signs).
2. Current Scope boundaries (Reads / Writes / Off-limits).
3. Which validation commands you will run (e.g. cd gitnexus && npm test, npx tsc --noEmit).

On very long threads, the human may add “Remember: apply all AGENTS.md rules” to re-weight rule tokens against context dilution.

Claude Code hooks

Hooks enforce gates that prompts cannot. In Claude Code, PreToolUse hooks can block tools such as git_commit until checks pass. Adapt to this repo: e.g. cd gitnexus && npm test before commit.

Context budget (Cursor / standards)

Generic “core standards” playbooks are often long and stack-specific. For this monorepo, commands and gotchas live under Cursor Cloud specific instructions below and in CONTRIBUTING.md. If always-on rules grow, split domain rules into .cursor/rules/*.mdc (globs). Cursor: project-wide rules live in .cursor/index.mdc (YAML frontmatter with alwaysApply: true). Claude Code: optionally load a STANDARDS.md only when needed (e.g. “When writing new code, read STANDARDS.md”) to save context.

Reference Documentation

• This repository: ARCHITECTURE.md, CONTRIBUTING.md, GUARDRAILS.md.
• Cursor: .cursor/index.mdc (always-on rules); optional .cursor/rules/*.mdc (glob-scoped). Legacy .cursorrules is deprecated — see .cursor/index.mdc.
• Optional local files: NOTES.md (short vendor-neutral project snapshot). For handoffs, keep notes local (e.g., a scratch file outside the repo) rather than committing HANDOFF.md.
• GitNexus: skills under .claude/skills/gitnexus/; machine-oriented rules in the gitnexus:start … gitnexus:end block below.

Changelog

GitNexus — Code Intelligence

This project is indexed by GitNexus as GitNexus (4048 symbols, 9822 relationships, 300 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.

If any GitNexus tool warns the index is stale, run npx gitnexus analyze in terminal first.

Always Do

• MUST run impact analysis before editing any symbol. Before modifying a function, class, or method, run gitnexus_impact({target: "symbolName", direction: "upstream"}) and report the blast radius (direct callers, affected processes, risk level) to the user.
• MUST run gitnexus_detect_changes() before committing to verify your changes only affect expected symbols and execution flows.
• MUST warn the user if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
• When exploring unfamiliar code, use gitnexus_query({query: "concept"}) to find execution flows instead of grepping. It returns process-grouped results ranked by relevance.
• When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use gitnexus_context({name: "symbolName"}).

When Debugging

1. gitnexus_query({query: "<error or symptom>"}) — find execution flows related to the issue
2. gitnexus_context({name: "<suspect function>"}) — see all callers, callees, and process participation
3. READ gitnexus://repo/GitNexus/process/{processName} — trace the full execution flow step by step
4. For regressions: gitnexus_detect_changes({scope: "compare", base_ref: "main"}) — see what your branch changed

When Refactoring

• Renaming: MUST use gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true}) first. Review the preview — graph edits are safe, text_search edits need manual review. Then run with dry_run: false.
• Extracting/Splitting: MUST run gitnexus_context({name: "target"}) to see all incoming/outgoing refs, then gitnexus_impact({target: "target", direction: "upstream"}) to find all external callers before moving code.
• After any refactor: run gitnexus_detect_changes({scope: "all"}) to verify only expected files changed.

Never Do

• NEVER edit a function, class, or method without first running gitnexus_impact on it.
• NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
• NEVER rename symbols with find-and-replace — use gitnexus_rename which understands the call graph.
• NEVER commit changes without running gitnexus_detect_changes() to check affected scope.

Tools Quick Reference

Impact Risk Levels

Resources

Self-Check Before Finishing

Before completing any code modification task, verify:

1. gitnexus_impact was run for all modified symbols
2. No HIGH/CRITICAL risk warnings were ignored
3. gitnexus_detect_changes() confirms changes match expected scope
4. All d=1 (WILL BREAK) dependents were updated

Keeping the Index Fresh

After committing code changes, the GitNexus index becomes stale. Re-run analyze to update it:

npx gitnexus analyze

If the index previously included embeddings, preserve them by adding --embeddings:

npx gitnexus analyze --embeddings

To check whether embeddings exist, inspect .gitnexus/meta.json — the stats.embeddings field shows the count (0 means no embeddings). Running analyze without --embeddings will delete any previously generated embeddings.

Claude Code users: A PostToolUse hook handles this automatically after git commit and git merge.

CLI

Cursor Cloud specific instructions

Repository structure

This is a monorepo with two main products and supporting config packages:

Running services

• CLI/Core: cd gitnexus && npm run dev (tsx watch mode) or npm run build && node dist/cli/index.js <command>
• Web UI: cd gitnexus-web && npm run dev (Vite on port 5173)
• Backend mode: cd <indexed-repo> && node /workspace/gitnexus/dist/cli/index.js serve (HTTP API on port 3741 by default)

Testing

CLI / Core (gitnexus/)

• Unit tests: cd gitnexus && npm test (vitest, ~2000 tests)
• Integration tests: cd gitnexus && npm run test:integration (vitest, ~1850 tests). Two LadybugDB file-locking tests (lbug-core-adapter, search-core) may fail in containerized environments due to /tmp locking limitations — this is a known environment issue, not a code bug.
• TypeScript check: cd gitnexus && npx tsc --noEmit

Web UI (gitnexus-web/)

• Unit tests: cd gitnexus-web && npm test (vitest, ~200 tests)
• E2E tests: cd gitnexus-web && E2E=1 npx playwright test (Playwright, 5 tests — requires gitnexus serve + npm run dev running)
• TypeScript check: cd gitnexus-web && npx tsc -b --noEmit

No separate lint command is configured; TypeScript strict checking serves as the primary static analysis.

Gotchas

• npm install in gitnexus/ triggers prepare (builds via tsc) and postinstall (patches tree-sitter-swift). Native tree-sitter bindings require python3, make, and g++ to be present.
• tree-sitter-kotlin and tree-sitter-swift are optional dependencies — install warnings for these are expected and non-blocking.
• The Web UI uses vite-plugin-wasm and requires Cross-Origin-Opener-Policy/Cross-Origin-Embedder-Policy headers for SharedArrayBuffer (handled automatically by Vite dev server).
• There is no ESLint/Prettier configuration in this repo.