* fix(ci): stop the review agent rejecting its own graph-backed reviews
The context-evidence gate only counted a `context` call when the call
itself passed `file_path` equal to a changed path. The review skill
teaches plain `context({name})`, so 17 of the 26 review-agent run
failures were complete, graph-backed reviews thrown away after full
model spend, with no log line saying which invariant failed.
Prove the evidence from the result instead: `status=found` plus a
`symbol.filePath` inside the repo-scoped changed-path set. Every other
check stays exactly as it was - strict JSON, orchestrator-only turns,
result ordering, duplicate tool-id rejection - and the `repo` argument
still selects the head or the merge-base path set.
Same failure inventory, smaller classes:
- rejection now logs why (in-scope, out-of-scope, sidechain, unresolved
and off-path counts plus up to three sanitized paths), and the
envelope error names the message count and first-message shape
- Glob/Grep leave the tool set: they were enabled through `--tools` but
never allow-listed, so every lane call was denied and burned turns
- both pinned `npm ci` installs retry three times; one registry
ECONNRESET killed a whole run
- the prompt matches the new contract and asks for the structured body
even when the analysis is incomplete
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(skills): mirror the review-skill tool-set change into the shipped copies
The npm package, Claude plugin, and Cursor integration ship byte-identical
copies of .claude/skills/gitnexus-review, and the drift guard compares them.
Dropping Glob/Grep from the lane frontmatter and the SKILL.md sentence only
landed in the canonical tree.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(ci): stop one junk context result discarding a proven review
Tri-review of this PR found that the previous commit fixed one spurious
rejection and created another. Widening evidence candidacy from "the call
that named a changed path" to "every orchestrator context call" also
widened the *strict-parse* surface: `contextResultProvesChangedPath`
throws rather than returning false, so a single malformed payload
anywhere in the transcript now discarded a review that an earlier call
had already proven. The MCP makes that reachable without any misbehaving
model - `GITNEXUS_MCP_DEFAULT_MAX_TOKENS=12000` truncates any context
payload over ~48 KB mid-JSON and appends a marker - and it also destroyed
docs-only runs that the `no_indexable_changed_symbols` mode exempts.
Reproduced by running the workflow's own embedded script on both trees:
a proving evidence call followed by one truncated exploratory call gave
`failure_code: null` on the base and `invalid_execution_transcript` on
the head; it is `null` again here.
- payload-shape failures are caught and counted (`malformedResults`)
instead of thrown; transcript-structural invariants (envelope, tool
shapes, duplicate ids, empty tool_result) still fail closed
- diagnostics gained the reasons they were blind to: errored results,
results that arrived out of order or via a sidechain, unanswered
in-scope calls, and malformed payloads. A rejection can no longer
print an in-scope call with every reason at zero
- a deletion-only PR no longer registers head-scoped candidates that can
never be satisfied: an empty eligible set is out of scope, not a result
"outside the changed paths"
- the mandatory-body prompt clause now pairs with a required `complete`
boolean. An incomplete analysis publishes its partial body labelled
`incomplete_analysis` instead of passing as an accepted review
- `Agent(a,b,c)` is split into six separate `Agent(x)` rules: the pinned
base action parses allowedTools with `.flatMap((v) => v.split(","))`
(parse-sdk-options.ts at 3553f843), which shattered the grouped rule
into `Agent(ci-correctness-lens`, four bare names, and
`ci-critic-lens)` before the SDK saw it. Pre-existing and unproven at
runtime, but the split form is correct under either reading and lets
the header's dispatch canary actually prove something
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(ci): require a line range for context evidence
The tri-review's adversarial lane executed `context({name: 'AGENTS.md'})`
and had the result accepted: the gate checked only that the resolved
filePath was in the changed set, so a bare File node passed for a review
of that file's contents. The trusted prescan already defines an indexable
symbol as one with startLine and endLine, so require the same here.
Pre-existing rather than introduced by this branch, but it is the same
"what counts as proof" surface the rest of this PR tightens.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(ci): close the remaining tri-review findings
Addresses every finding the tri-review left open after
|
||
|---|---|---|
| .. | ||
| hooks | ||
| skills | ||
| README.md | ||
GitNexus — Cursor integration
Static config that adds GitNexus knowledge-graph augmentation and skill files to Cursor.
Hooks require Cursor 2.4+. Earlier versions don't expose
postToolUseand the hook will silently no-op.
What you get
| Layer | What it does | How it's installed |
|---|---|---|
| MCP | gitnexus MCP server with 17 tools (query, context, impact, detect_changes, rename, …) |
npx gitnexus setup writes ~/.cursor/mcp.json automatically. |
| Skills | All bundled markdown skills (/gitnexus-exploring, /gitnexus-debugging, /gitnexus-impact-analysis, /gitnexus-refactoring, /gitnexus-guide, /gitnexus-cli, /gitnexus-review, /gitnexus-plan, /gitnexus-work, /gitnexus-lfg, /gitnexus-pdg-query, /gitnexus-taint-analysis) |
npx gitnexus setup copies them to ~/.cursor/skills/gitnexus/. |
| Hooks (this README) | postToolUse hook that enriches Shell / Read / Grep tool calls with graph context — same augmentation Claude Code gets |
Manual — copy the files described below into your project's .cursor/. |
Hook install
Cursor 2.4+ reads .cursor/hooks.json from the project root and runs hook commands with the project root as the working directory (docs).
From this repo's gitnexus-cursor-integration/hooks/, copy the files below into your project root:
<your-project>/
├── .cursor/
│ └── hooks.json ← from gitnexus-cursor-integration/hooks/hooks.json
└── hooks/
├── gitnexus-hook.cjs ← from gitnexus-cursor-integration/hooks/gitnexus-hook.cjs
└── hook-lock.cjs ← from gitnexus-cursor-integration/hooks/hook-lock.cjs
Equivalent shell commands (run from your project root, with $GITNEXUS_REPO pointing at a clone of this repo):
mkdir -p .cursor hooks
cp "$GITNEXUS_REPO/gitnexus-cursor-integration/hooks/hooks.json" .cursor/hooks.json
cp "$GITNEXUS_REPO/gitnexus-cursor-integration/hooks/gitnexus-hook.cjs" hooks/gitnexus-hook.cjs
cp "$GITNEXUS_REPO/gitnexus-cursor-integration/hooks/hook-lock.cjs" hooks/hook-lock.cjs
If you already have a .cursor/hooks.json, merge the hooks.postToolUse array rather than overwriting.
Verify
- Index the project:
npx gitnexus analyze(on npm 11.x,npxcan crash during install — usepnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyzeinstead; see #1939) - Reload the Cursor window so it picks up the new hook config.
- Ask the agent something that triggers
Read/Grep/Shell rg. You should see a[GitNexus]block appended to the tool result. - Diagnose silent no-ops by setting
GITNEXUS_DEBUG=1in your shell environment — the hook will write Cursor's raw event payload to stderr so you can verify field names.
What's installed manually vs. automated
| Step | Automated by gitnexus setup? |
|---|---|
~/.cursor/mcp.json |
✅ |
~/.cursor/skills/gitnexus/* |
✅ |
<project>/.cursor/hooks.json + <project>/hooks/gitnexus-hook.cjs + <project>/hooks/hook-lock.cjs |
❌ — copy manually (see above) |
Hook install is per-project (Cursor scopes hooks to a project root); skills and MCP config are global.
Hook contract
The hook receives a JSON event on stdin matching Cursor 2.4's postToolUse shape:
{
"tool_name": "Grep" | "Read" | "Shell",
"tool_input": { /* tool-specific */ },
"tool_output": { /* optional */ },
"cwd": "/absolute/path/to/project"
}
It writes augmentation context to stdout as:
{ "additional_context": "[GitNexus] …" }
Empty stdout means "no augmentation, continue normally" — the hook never blocks the tool.
Pattern extraction per tool
| Tool | Pattern source | Notes |
|---|---|---|
Grep |
tool_input.query (also pattern, regex, q, search, searchQuery) |
Last-resort fallback: longest string value in tool_input (≥ 3 chars). |
Read |
basename of tool_input.target_file (also file_path, filePath, path, file), stripped to identifier characters |
auth/handler.ts → handler. |
Shell |
First positional argument after rg / grep in tool_input.command |
Best-effort tokenizer; quoted multi-word patterns (rg "User Service") extract the first word only. |
Troubleshooting
- Nothing happens — Confirm Cursor is on 2.4+ and the project root has
.cursor/hooks.jsonplus both hook files athooks/gitnexus-hook.cjsandhooks/hook-lock.cjs. Thennpx gitnexus listto confirm the project is indexed. gitnexusnot found — The hook prefers a locally-resolvablegitnexus/dist/cli/index.jsand falls back tonpx -y gitnexus. Install globally withnpm i -g gitnexusto skip the npx cold-start latency.- Wrong pattern extracted — Set
GITNEXUS_DEBUG=1and run a tool call. The raw stdin payload is logged to stderr; use it to confirm Cursor's actualtool_inputfield names against the table above. If they differ, file an issue with the captured payload.