{"owner":"abhigyanpatwari","repo":"GitNexus","hasSkills":true,"totalSkillsCount":133,"totalTokensCount":66030,"categories":["anthropic-skill","cursor-rule","windsurf-rule","root-instruction","project-spec","claude-rule","marketplace","mcp-config","subagent-persona","command-prompt","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"GitNexus":{"command":"npx","args":["-y","@modelcontextprotocol/server-GitNexus"]}}},"found":[".claude/skills/gitnexus-impact-analysis/SKILL.md",".claude/skills/gitnexus-lfg/SKILL.md",".claude/skills/gitnexus-review/SKILL.md",".claude/skills/gitnexus-exploring/SKILL.md",".claude/skills/gitnexus-cli/SKILL.md",".claude/skills/gitnexus-refactoring/SKILL.md",".claude/skills/gitnexus-debugging/SKILL.md",".claude/skills/gitnexus-work/SKILL.md",".claude/skills/gitnexus-guide/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-cli/SKILL.md",".claude/skills/gitnexus-plan/SKILL.md",".claude/skills/gitnexus-pr-swarm-review/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md","gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md","gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md","gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md","gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md","gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md","gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md","gitnexus/skills/gitnexus-lfg/SKILL.md","gitnexus/skills/gitnexus-plan/SKILL.md","gitnexus/skills/gitnexus-review/SKILL.md","gitnexus/skills/gitnexus-work/SKILL.md",".claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md",".claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md",".cursorrules",".windsurfrules","AGENTS.md","ARCHITECTURE.md","CLAUDE.md","llms.txt",".claude-plugin/marketplace.json",".factory-plugin/marketplace.json","gitnexus-factory-plugin/mcp.json",".agents/plugins/marketplace.json",".claude/agents/gitnexus-branch-hygiene-reviewer.md",".claude/agents/gitnexus-docs-dod-reviewer.md",".claude/agents/gitnexus-pr-facts-historian.md",".claude/agents/gitnexus-risk-architect.md",".claude/agents/gitnexus-security-boundary-reviewer.md",".claude/agents/gitnexus-synthesis-critic.md",".claude/agents/gitnexus-test-ci-verifier.md",".cursor/commands/gitnexus-pr-swarm-review.md",".cursor/rules/100-monorepo.mdc",".cursor/rules/200-eval.mdc","gitnexus-claude-plugin/.claude-plugin/plugin.json","gitnexus-claude-plugin/.codex-plugin/plugin.json","gitnexus-factory-plugin/.factory-plugin/plugin.json","gitnexus/skills/gitnexus-cli.md","gitnexus/skills/gitnexus-debugging.md","gitnexus/skills/gitnexus-exploring.md","gitnexus/skills/gitnexus-guide.md","gitnexus/skills/gitnexus-impact-analysis.md","gitnexus/skills/gitnexus-pdg-query.md","gitnexus/skills/gitnexus-refactoring.md","gitnexus/skills/gitnexus-taint-analysis.md",".claude/skills/gitnexus-lfg/README.md",".claude/skills/gitnexus-plan/README.md",".claude/skills/gitnexus-work/README.md","gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json","gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json","gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json","gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json","gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json","gitnexus-claude-plugin/skills/gitnexus-lfg/README.md","gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json","gitnexus-claude-plugin/skills/gitnexus-plan/README.md","gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json","gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json","gitnexus-claude-plugin/skills/gitnexus-review/mcp.json","gitnexus-claude-plugin/skills/gitnexus-work/README.md","gitnexus-claude-plugin/skills/gitnexus-work/mcp.json","gitnexus/skills/gitnexus-lfg/README.md","gitnexus/skills/gitnexus-plan/README.md","gitnexus/skills/gitnexus-work/README.md",".claude/skills/gitnexus-plan/references/context-ledger.md",".claude/skills/gitnexus-plan/references/context-pack.md",".claude/skills/gitnexus-plan/references/evidence-provenance.md",".claude/skills/gitnexus-plan/references/pdg-slice.md",".claude/skills/gitnexus-plan/references/plan-template.md",".claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs",".claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md",".claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md",".claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md",".claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md",".claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md",".claude/skills/gitnexus-review/ci-personas/ci-security-lens.md",".claude/skills/gitnexus-work/references/evidence-provenance.md",".claude/skills/gitnexus-work/scripts/evidence-provenance.mjs","gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md","gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md","gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md","gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md","gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md","gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md","gitnexus/skills/gitnexus-plan/references/context-ledger.md","gitnexus/skills/gitnexus-plan/references/context-pack.md","gitnexus/skills/gitnexus-plan/references/evidence-provenance.md","gitnexus/skills/gitnexus-plan/references/pdg-slice.md","gitnexus/skills/gitnexus-plan/references/plan-template.md","gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md","gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md","gitnexus/skills/gitnexus-work/references/evidence-provenance.md","gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml","gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json","gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json","gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json","gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json"],"skills":{".claude/skills/gitnexus-impact-analysis/SKILL.md":"---\nname: gitnexus-impact-analysis\ndescription: \"Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: \\\"Is it safe to change X?\\\", \\\"What depends on this?\\\", \\\"What will break?\\\"\"\n---\n\n# Impact Analysis with GitNexus\n\n## When to Use\n\n- \"Is it safe to change this function?\"\n- \"What will break if I modify X?\"\n- \"Show me the blast radius\"\n- \"Who uses this code?\"\n- Before making non-trivial code changes\n- Before committing — to understand what your changes affect\n\n## Bind the repository first\n\nImpact analysis is the gate that authorizes an edit, so it must answer for the\nrepository you are about to edit.\n\nCall `list_repos {}` before the first tool call. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask — every result below an ambiguous\nidentity inherits the ambiguity. `list_repos` is paginated, so page with\n`offset: pagination.nextOffset` until `hasMore` is false before concluding a\nrepository is absent.\n\n`detect_changes` takes `worktree` when your changes are in a linked worktree\nthe MCP server was not launched from. The server auto-detects a worktree only\nwhen it was launched from inside one; otherwise `git diff` runs in the wrong\ncheckout and reports zero changed symbols — a false clean check that carries\nnone of the degradation flags described below. In the CLI fallbacks, `--repo .`\nmeans the current checkout; pass the intended repository path instead when you\nare not standing in it.\n\nState the bound identity with your risk report:\n\n```\nRepository: () Worktree: Index: , behind HEAD\n```\n\n## Workflow\n\n```\n0. list_repos {} → Bind repo (and worktree)\n1. impact({target: \"X\", direction: \"upstream\"}) or `node .gitnexus/run.cjs impact \"X\" --direction upstream --repo .`\n2. READ gitnexus://repo/{name}/processes → Check affected execution flows\n3. detect_changes({scope: \"all\"}) or `node .gitnexus/run.cjs detect-changes --scope all --repo .`\n4. Assess risk and report to user, echoing repo/worktree/index identity\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n> If `.gitnexus/run.cjs` is missing, replace `node .gitnexus/run.cjs` with `npx gitnexus` in the fallback commands.\n\n## Checklist\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] impact({target, direction: \"upstream\"}) or CLI fallback to find dependents\n- [ ] Review d=1 items first (these WILL BREAK)\n- [ ] Check high-confidence (>0.8) dependencies\n- [ ] READ processes to check affected execution flows\n- [ ] detect_changes({scope: \"all\"}) or CLI fallback for pre-commit check\n- [ ] Confirm the checkout you edited is the checkout that was diffed\n- [ ] Assess risk level and report, stating repo/worktree/index identity\n```\n\n## Understanding Output\n\n| Depth | Risk Level | Meaning |\n| ----- | ---------------- | ------------------------ |\n| d=1 | **WILL BREAK** | Direct callers/importers |\n| d=2 | LIKELY AFFECTED | Indirect dependencies |\n| d=3 | MAY NEED TESTING | Transitive effects |\n\n## Risk Assessment\n\n| Affected | Risk |\n| ------------------------------ | -------- |\n| <5 symbols, few processes | LOW |\n| 5-15 symbols, 2-5 processes | MEDIUM |\n| >15 symbols or many processes | HIGH |\n| Critical path (auth, payments) | CRITICAL |\n| **Zero callers found** | **UNKNOWN** |\n\n`UNKNOWN` is not a low rung on this scale — it means the walk could not answer.\nAn empty caller set is equally consistent with \"genuinely unused\" and \"the\ncallers are not resolvable by the index\" (plain-object property access, dynamic\ndispatch, cross-language calls), so few-callers ⇒ LOW does **not** apply. The\nresult carries a `riskNote` saying so. Confirm with a text search before\ntreating the symbol as safe to change or delete.\n\n`risk` is the edit gate: warn on HIGH/CRITICAL and stop on UNKNOWN until the\nuncertainty is resolved. Within single-repo mode, compare File and symbol\ntargets with local `riskSharedAxes` (direct/total only). Within group mode,\ncompare only group results: their `riskSharedAxes` overlays resolved\ncross-repo crossings on that local value. Never use either field to waive the\nedit gate. Check `riskScale.unusedAxes` before comparing kinds: MCP File walks\nomit process/module axes, while web Graph-RAG expands File targets to in-file\nsymbols before enrichment.\n\n## Tools\n\n**impact** — the primary tool for symbol blast radius. If MCP is unavailable, use `node .gitnexus/run.cjs impact --direction upstream --repo .` instead:\n\n```\nimpact({\n target: \"validateUser\",\n repo: \"my-app\", // required once >1 repository is indexed\n direction: \"upstream\",\n minConfidence: 0.8,\n maxDepth: 3\n})\n\n→ d=1 (WILL BREAK):\n - loginHandler (src/auth/login.ts:42) [CALLS, 100%]\n - apiMiddleware (src/api/middleware.ts:15) [CALLS, 100%]\n\n→ d=2 (LIKELY AFFECTED):\n - authRouter (src/routes/auth.ts:22) [CALLS, 95%]\n```\n\n**detect_changes** — git-diff based impact analysis. If MCP is unavailable, use `node .gitnexus/run.cjs detect-changes --scope all --repo .` instead:\n\n```\ndetect_changes({scope: \"all\"})\n\n→ Changed: 5 symbols in 3 files\n→ Affected: LoginFlow, TokenRefresh, APIMiddlewarePipeline\n→ Risk: MEDIUM\n```\n\nAdd `repo` once more than one repository is indexed, and `worktree: \"\"` when your changes are in a linked worktree the server was not launched\nfrom.\n\n`partial: true` (a graph query failed) or `truncated: true` (the changed-symbol\nlisting was capped) means the result is short of the truth, and reads like\n`UNKNOWN` above: a zero there means unseen, not unaffected. Re-run it rather\nthan tick the pre-commit check.\n\nA wrong-worktree zero carries neither flag and is shape-identical to a genuine\nclean result, so confirm the checkout you edited is the one that was diffed\nbefore treating an empty change set as a passed check.\n\n## Example: \"What breaks if I change validateUser?\"\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly\n\n1. impact({target: \"validateUser\", repo: \"my-app\", direction: \"upstream\"}) or `node .gitnexus/run.cjs impact \"validateUser\" --direction upstream --repo .`\n → d=1: loginHandler, apiMiddleware (WILL BREAK)\n → d=2: authRouter, sessionManager (LIKELY AFFECTED)\n\n2. READ gitnexus://repo/my-app/processes\n → LoginFlow and TokenRefresh touch validateUser\n\n3. Risk: 2 direct callers, 2 processes = MEDIUM\n Repository: my-app (/abs/path/my-app) Worktree: same Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n",".claude/skills/gitnexus-lfg/SKILL.md":"---\nname: gitnexus-lfg\ndescription: \"Use when the user wants the GitNexus engineering pipeline run end-to-end on a task: gitnexus-plan (plan depth chosen up front), a blocking gate to execute with gitnexus-work or stop, finishing with a gitnexus-review of the result. Examples: \\\"/gitnexus-lfg Add retry support to the ingestion pipeline\\\", \\\"run the gitnexus pipeline on this\\\", \\\"plan, build and review this feature\\\".\"\n---\n\n# gitnexus-lfg — plan → gate → work → review\n\nThin orchestrator over three existing skills. It adds no engineering logic of\nits own — it sequences `gitnexus-plan`, `gitnexus-work`, and\n`gitnexus-review`, with the user deciding at the plan gate. Run every lane\nby actually invoking the named skill (read its SKILL.md and follow it);\nnever inline a summary of what the skill would have done.\n\n```\n/gitnexus-lfg \n/gitnexus-lfg docs/plans/.md # skip lane 1, start at the gate\n```\n\n## Lane 1 — Plan\n\n**Boundary triage first.** If the task is plainly below the planning\nboundary — trivial or small-bounded work an agent finishes in well under ~35\nturns (the measured regime where a planning pass costs more than it returns;\nmeasured in the GitNexus repository's `eval/workflow_bench/`) — say so and\noffer `gitnexus-work` direct mode as an alternative to the full pipeline\nbefore spending the plan lane. Honor the user's choice.\n\nThe threshold is a promoted benchmark policy measured offline, not a\ntimeless heuristic — never self-edit it from a live task. Its re-evaluation\ngovernance lives in this skill's README.\n\nOtherwise invoke `gitnexus-plan` with the task (knob overrides pass through\nverbatim; `gitnexus-plan` owns the up-front depth question — never ask it\nagain here). If the input is already a plan file path, skip to Lane 2. The\nplan lands in `docs/plans/` — record its path; every later lane consumes it.\n\n## Lane 2 — The plan gate (user choice, blocking)\n\nPresent the plan's chat summary (objective, proposed changes, sequence, top\nrisks, open questions, plan path), then ask the user — as a blocking\nquestion (`AskUserQuestion` in Claude Code; a numbered list in chat on CLIs\nwithout a blocking tool):\n\n1. **Proceed to work** — continue to Lane 3.\n2. **Stop here** — the plan file is the deliverable; end the pipeline.\n\nDepth was the user's up-front choice in Lane 1, so deepening is not offered\nby default — but honor an explicit request for it at the gate: run\n`gitnexus-plan` Deepen mode on the plan file and return here with the\nstrengthened plan, as many times as the user asks. Do not proceed past the\ngate without an explicit choice — the gate is the pipeline's only checkpoint\nand exists precisely because execution is expensive to unwind.\n\n**Headless / non-interactive runs:** no one can answer the gate, so end the\npipeline after Lane 1 — the plan file is the deliverable (gate option 2) —\nand say so in the final report. Never auto-proceed to execution.\n\n## Lane 3 — Work\n\nInvoke `gitnexus-work` with the plan path. It re-anchors the plan at HEAD,\nexecutes the Implementation Sequence as verified atomic commits, refreshes\nthe knowledge graph when done (its Phase 4), and reports deviations. If it routes back for re-planning (structural drift), run the\nDeepen pass and return to the Lane 2 gate rather than pushing through.\n\n## Lane 4 — Review\n\nInvoke `gitnexus-review` on the completed work. Pass an open PR URL/number\nwhen one exists; otherwise pass the current branch. The review skill owns\ntarget resolution, exact-SHA checkout/index alignment, and merge-base\nselection. Do not duplicate that logic here. If work left local changes,\npass `local` as a second, separately labeled review surface.\n\nSurface the review verdict and findings to the user. Findings the user\nwants fixed: those within `gitnexus-work`'s direct-mode bounds (1–2 files,\nno architectural decisions) → hand to `gitnexus-work` direct mode; anything\nlarger → offer the plan gate instead (Deepen the plan with the findings, or\nstop). Then re-run this lane's review once. On that re-run, do not start\nanother fix cycle even if findings remain — report them and point the user\nat `/gitnexus-work` (or the plan gate) to continue deliberately.\n\n## Final report\n\nOne message: plan path, deepen cycles run, commits produced, verification\nstatus, review verdict with unresolved findings, and what (if anything) was\nexplicitly left undone. The pipeline does not push or open a PR on its own —\noffer both as next steps.\n",".claude/skills/gitnexus-review/SKILL.md":"---\nname: gitnexus-review\ndescription: 'Review code changes with GitNexus from a GitHub PR URL or number, a branch/ref or commit range, or local staged, unstaged, and untracked changes. Use when the user asks for a code review, merge-risk assessment, regression hunt, missing-test analysis, or a verdict on whether a PR, branch, commit range, or local diff is safe.'\n---\n\n# GitNexus review\n\nReview the requested change surface without editing source, committing, pushing,\nposting, or resolving threads. A later explicit request may authorize those\nactions. Use GitNexus for structural evidence and source inspection for proof;\nneither substitutes for the other.\n\n## Resolve the target\n\nAccept these forms:\n\n| Input | Review surface |\n| ------------------------------------------------------ | --------------------------------------------------------------------------- |\n| PR URL, `owner/repo#42`, `#42`, or bare number | GitHub PR |\n| `base...head` | Merge-base range |\n| `base..head` | Exact two-dot range |\n| Branch, tag, or commit | Ref against the repository default branch |\n| `local`, `staged`, `unstaged`, or working-tree wording | Local changes |\n| No target | Current branch's open PR; otherwise local changes; otherwise current branch |\n\nAn explicit target always wins. Interpret a bare number as a PR only in a\nGitHub repository with working `gh` authentication; otherwise ask for a ref or\nURL. If implicit mode finds both branch commits and local changes, review them\nas two labeled surfaces rather than silently dropping or blending either one.\n\nRecord the resolved target kind, repository root, default branch, base SHA,\nhead SHA, merge-base when applicable, and included local states. Resolve the\ndefault branch from remote metadata (`refs/remotes//HEAD` or GitHub\nrepository metadata); use `main` or `master` only as an explicit fallback and\nsay when doing so.\n\n### PR\n\nUse `gh pr view`/`gh api` to pin the PR number, repository, title, URL, base\nref, base SHA, head ref, and head SHA. Fetch those exact commits without\nswitching the user's branch. Compute `git merge-base ` and use\nthat SHA as the review base: GitHub PR diffs are merge-base diffs, while\n`detect_changes(scope: \"compare\")` is a two-dot comparison.\n\nUse the local `git diff ` as the complete diff source of\ntruth; use GitHub metadata for PR facts and review state. For fork PRs, fetch\nthe pull ref or the contributor remote instead of assuming the head branch\nexists on `origin`.\n\n### Branch, ref, or range\n\nResolve every ref to a commit before reviewing. For a branch or `A...B`, use\nthe merge-base as the comparison base. For an explicit `A..B`, honor `A` as\nthe exact base. Do not compare a feature branch directly with a moving default\nbranch tip when merge-base semantics were intended.\n\n### Local changes\n\nInspect `git status --short`, the staged diff, the unstaged diff, and every\nuntracked file. Use `detect_changes` with `staged`, `unstaged`, or `all` as\nrequested. Untracked files are not guaranteed to appear in Git diff or graph\nmapping, so read them directly and list them in the review provenance.\n\n## Align the checkout and index\n\nThe graph and diff must describe the same head. Reuse an existing worktree only\nwhen it is at the exact target SHA. Otherwise create a temporary detached\nworktree for the PR/ref head, review there, and remove only that temporary\nworktree afterward. Never switch or reset the user's current worktree.\n\nCheck GitNexus status in the target worktree. If stale, run\n`node .gitnexus/run.cjs analyze --index-only` before trusting graph results\n(temporary worktrees never carry the gitignored `run.cjs` — fall back to the\ninstalled `gitnexus` CLI, then `npx gitnexus`), and include `--pdg` in that\nsame refresh when the diff plausibly touches trust or data-flow boundaries,\nso the taint pass below doesn't pay a second full analyze. Taint and\ndependence evidence needs that PDG layer: when the workflow's taint pass\nfinds it missing, rebuild with `analyze --pdg --index-only` and record the\nrebuild in provenance. For local changes, refresh the index so new or\nmodified source is represented.\nIf an exact target checkout/index cannot be established, state the limitation\nand do not claim a complete graph-backed review.\n\n## Review workflow\n\n1. Read the full diff and changed-file list. Separate generated files,\n dependency churn, tests, and behavior changes.\n2. Run `detect_changes` against the exact surface:\n - PR/branch/`...`: `scope: \"compare\"`, `base_ref: `.\n - Explicit `A..B`: `scope: \"compare\"`, `base_ref: ` from a worktree\n at `B`.\n - Local: `scope: \"staged\"`, `\"unstaged\"`, or `\"all\"`.\n Pass `worktree` when the MCP server is attached elsewhere.\n3. Run upstream `impact` with `includeTests: true` for each behaviorally changed\n symbol. Prioritize public contracts, shared types, control flow, persistence,\n security boundaries, and error handling; skip mechanical/generated changes.\n4. Inspect every direct (`d=1`) dependent that is outside the diff. A dependent\n outside the diff is a lead, not automatically a bug—verify the changed\n contract and caller behavior in source.\n5. Use `context` on key or ambiguous symbols and inspect affected execution\n flows. Read the surrounding implementation and tests at cited locations.\n6. **Taint and dependence pass.** For changed code on trust or data-flow\n boundaries — external input, persistence, process execution, network,\n auth — run `explain` on the changed files or symbols and judge its\n source→sink taint findings against the diff: a flow the change\n introduces, or a sanitizer/guard the change removes, is a finding; a\n pre-existing flow is context, not a defect of this change. When the\n change claims to guard or sanitize something, verify with `pdg_query`:\n what controls the changed statement, and where its values flow. This\n needs a `--pdg` index; if one cannot be built, state that the taint pass\n was skipped rather than implying coverage.\n7. Check whether tests exercise the changed behavior, boundary conditions, and\n affected flows. Run focused read-only validation when practical. When the\n diff refreshes a committed baseline, fingerprint, or golden, re-run the\n exact CI check command against the head instead of trusting the committed\n value — a stale artifact is invisible in the diff and fails only in CI.\n8. Reconcile graph evidence with the raw diff. New files, dynamic dispatch,\n configuration, reflection, and untracked content may require direct review\n even when graph results are empty. Version and invalidation constants are\n review surface: when the diff changes what gets emitted or persisted,\n verify every schema/version constant gating caches, incremental\n writebacks, and fingerprint baselines was bumped or regenerated — in\n GitNexus itself, for example: graph DDL needs no manual bump, because\n `SCHEMA_FINGERPRINT` (`gitnexus/src/core/lbug/schema.ts`) is derived\n from `NODE_SCHEMA_QUERIES` + `REL_SCHEMA_QUERIES` and moves on its own;\n the check there is whether the diff changed any string in those arrays,\n and, if it added a new DDL array, whether that array was folded into the\n fingerprint. Parser compatibility is also automatic: review the base/PDG\n ownership boundaries in `gitnexus/src/core/parse-cache-identity.ts`, the\n import/asset coverage audit, and real cold → warm replay tests. New parser\n dependencies outside those boundaries need explicit coverage; contributors\n do not allocate a semantic counter. Both benchmark fingerprint sets still\n need deliberate review before re-baselining: automatic invalidation does\n not establish semantic correctness. Other semantic changes that leave DDL\n untouched rely on the analyzer runner-identity receipt in index metadata.\n\n## Expert lenses\n\nDepth comes from matching reviewers to what actually changed, not from one\ngeneralist pass. After workflow step 2, group the changed files and symbols\nby the functional areas the graph already knows — the index's cluster\nlisting; `context` names each symbol's cluster — and give each touched area\nan expert lens: a reviewer charged with that domain's contracts, invariants,\nand failure modes, grounded in the repo's own material (architecture docs,\nagent rules, the domain's tests) before judging the diff. A lens verifies,\nnot just reads: when the changed code is a pure function reachable from the\nrepo's own toolchain — parsers, extractors, capture emitters, formatters —\nexecute it on the candidate failing shape (a scratch probe, deleted\nafterward) and cite the observed output. An empirical probe outranks source\nreading in the evidence hierarchy; role swaps, dead branches, and\nerror-recovery-dependent behavior repeatedly pass a reading and fail a\nten-line probe. The numbered\nworkflow runs exactly once; dispatch the lens passes after step 6, handing\neach lens the evidence already collected rather than letting lenses repeat\nthe `impact`, `context`, or taint calls. In GitNexus\nitself, for example: shared ingestion-pipeline changes get an ingestion\nexpert plus one language expert per changed language extractor; embeddings\nchanges an embeddings expert; LadybugDB/storage changes a Ladybug expert.\n\nFour cross-cutting lenses run regardless of domain:\n\n- **Architectural fit** — the change lands where the architecture says the\n concern lives, reuses existing seams, and adds no parallel structure.\n- **Language conformance** — the repo's own type/lint/test contract as\n configured (tsconfig strictness, lint rules, test conventions); in a\n strict TypeScript repo, for example: strictness intact, no `any`/`as any`\n escapes, module boundaries typed. Judge by the repo's contract, never a\n universal style bar.\n- **Definition of Done** — changed behavior has tests, docs the change makes\n stale are updated, and sync/drift guards (shipped copies, manifests,\n changelogs) still hold.\n- **Simplicity** — YAGNI and clear-code check: flag speculative abstraction,\n unused knobs, and overengineering; the smallest diff that meets the\n Definition of Done is the standard.\n\nScale effort to the surface: a single-domain change of a few files gets one\ncombined pass covering its domain lens plus the four cross-cutting checks;\na multi-domain change gets one lens per touched area — run as parallel\nsubagents where the harness supports them, each scoped to its own files\nplus the shared graph evidence, and as sequential passes otherwise. Never\nspawn a lens for a domain the diff does not touch. Merge lenses that ground\nin the same material — two lenses reading the same files pay twice for one\nread's coverage, so give one reviewer both charges. Where the harness\noffers model or effort tiers, run mechanical lenses (rename sweeps,\ndoc-consistency checks) on a cheaper tier and reserve the strongest engine\nfor adversarial judgment. Every lens reports\nthrough the Finding standard below; merge and dedup before the verdict,\ndropping anything without a concrete failing scenario.\n\n### Swarm lanes\n\nSix dispatchable lane definitions ship with this skill in `ci-personas/` —\nread-only reviewers restricted to file reads plus the safe graph tools. Five are finder lanes: `ci-correctness-lens`, `ci-security-lens`,\n`ci-blast-radius-lens`, `ci-coverage-lens`, and `ci-adversarial-lens`\n(which assumes the change is broken and constructs reachable failure\nscenarios the pattern checks miss). They carry the verification\ndimensions of the numbered workflow across every touched domain; domain\ngrouping and the four cross-cutting checks above remain the\norchestrator's charge. The sixth, `ci-critic-lens`, is a gate, not a\nfinder — it audits the finished draft.\n\nWhen the harness supports subagents and these lanes are registered as\nagents (the CI review workflow installs them from its trusted control\ncheckout; a local harness may register them by copying `ci-personas/*.md`\ninto `~/.claude/agents/` or the project's `.claude/agents/`), run the\nexpert-lens pass as follows. First establish your own graph evidence —\nmake at least one substantive context call on a changed symbol yourself,\nbefore dispatching any lane, since lane calls never satisfy the evidence\nthis skill or its runner requires. Then dispatch all five finder lanes in\nparallel in a single message. Give each lane the diff, the changed-file\nmanifest, the exact base and head identifiers, the checkout paths, and the\nslice of changed files matching its charge.\n\nTreat every lane report as an unverified claim: re-anchor each finding to\nthe diff, the source, or your own graph queries before it enters the\nreview; dedup across lanes; drop anything without a concrete failing\nscenario. Lane tool calls never substitute for evidence this skill or its\nrunner requires from the orchestrating conversation itself.\n\nAfter composing the complete draft review, dispatch `ci-critic-lens` with\nthe full draft body plus the same context. On `DEFECTS`, repair the draft\nand re-dispatch the critic once; if defects remain after the second pass,\nfix what you accept, note the unresolved critic objections in the\ncoverage section, and proceed — the critic hardens the review; it never\nblocks it. This fail-open is deliberate: the critic is bounded to two\npasses so it cannot deadlock or wedge the run, and the review is still\ngated by the runner's own evidence and schema checks. (This is distinct\nfrom the separate `gitnexus-pr-swarm-review` skill, whose interactive\nroster treats its critic as a hard gate that must clear before emission;\nthis CI lane must always emit a review or a clean failure.) If subagent\ndispatch is unavailable or any lane fails, run that lane's charge inline —\nthe lanes structure the work; they never gate it.\n\n## Finding standard\n\nReport a finding only when the reviewed change introduces a concrete defect,\nregression, security issue, compatibility break, material coverage gap, or a\nmaintainability cost with a concrete carrying scenario (a dead knob, a\nduplicated contract, a drift-prone copy).\nEach finding must include:\n\n- severity and a precise `path:line` anchor;\n- the failing scenario or contract;\n- GitNexus evidence (dependent symbol/process) when applicable;\n- why existing code or tests do not mitigate it;\n- a concise remediation or missing test.\n\nDo not report style preferences, pre-existing issues, raw risk counts, or\nspeculation as defects. Do not infer safety from zero graph hits. Calibrate\noverall risk from consequence, reachability, reversibility, and test evidence,\nnot from the number of changed symbols alone.\n\n## Output\n\nLead with findings in severity order. If there are none, say so explicitly.\nThen provide:\n\n```markdown\n## Review: \n\n### Findings\n\n- [HIGH|MEDIUM|LOW] `path:line` — \n\n### Change and blast-radius summary\n\n- Target/base/head/merge-base and local states reviewed\n- Changed symbols and affected execution flows\n\n### Coverage and residual risk\n\n- Tests present, tests missing, graph/diff limitations\n\n### Verdict\n\nAPPROVE | REQUEST CHANGES | NEEDS DISCUSSION\n```\n\nFor a branch or local review, use `READY`, `NOT READY`, or `NEEDS DISCUSSION`\ninstead of a PR approval action. Include the exact target SHAs so a later run\ncan tell whether the evidence is stale.\n",".claude/skills/gitnexus-exploring/SKILL.md":"---\nname: gitnexus-exploring\ndescription: \"Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: \\\"How does X work?\\\", \\\"What calls this function?\\\", \\\"Show me the auth flow\\\"\"\n---\n\n# Exploring Codebases with GitNexus\n\n## When to Use\n\n- \"How does authentication work?\"\n- \"What's the project structure?\"\n- \"Show me the main components\"\n- \"Where is the database logic?\"\n- Understanding code you haven't seen before\n\n## Bind the repository first\n\nBind once per session using a confirmed registry name/path or configured MCP\ndefault; reuse it. Call `list_repos {}` when the target is not yet known, not before\nevery question. Never guess the registry name from the checkout directory. With\none indexed repository, use the examples below as written. With more than one, pass `repo` on every call: an omitted `repo` normally errors,\nbut under an MCP policy with a configured default it resolves to that default\nsilently. If you cannot tell which repository is meant, stop and ask. Report\nthe bound repository and index freshness alongside your explanation.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\n## Workflow\n\n```\n1. Bind the repository once; use hot-tool staleness on subsequent calls\n2. If no symbol is known: query({search_query: \"\", limit: 3, max_symbols: 3})\n3. context({uid: \"\"}) → Inspect the selected symbol\n4. Read a process resource only when its full trace answers an unresolved question\n```\n\n> If the index is stale → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Ask for only the evidence needed\n\nUse options advertised by the connected server. `response_sections` and context\n`relationTypes` are opt-in views for a single repository, not `@group` routing.\nOn an older server, use the existing limits and content/chain options instead.\nUse filters when unwanted sections are bulky; their omission metadata can make\nan already-small response slightly larger.\nAim for 2–3 focused calls after repository binding; stop when the question is\nanswered, but expand if evidence or a required safety check is still missing.\n\n```text\nquery({search_query: \"payment retry\", repo: \"my-app\", limit: 3, max_symbols: 3,\n include_content: false, chain_depth: 0,\n response_sections: [\"process_symbols\", \"definitions\"]})\ncontext({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"incoming\", \"outgoing\"], relationTypes: [\"CALLS\"]})\n// Before editing, assess impact using the normal traversal and risk calculation:\nimpact({target: \"\", repo: \"my-app\", direction: \"upstream\", summaryOnly: true})\n```\n\nIf the symbol is already known, start with `context`; use `uid`, or `name` plus\n`file_path`/`kind`, to avoid ambiguous results. To answer only “who calls it?”,\nrequest `response_sections: [\"incoming\"]`, `relationTypes: [\"CALLS\"]` and leave\n`include_content` false. Keep `processes` in a query when the question is about\nflows, rather than requesting a symbols-only view.\n\nDo not request source and multi-hop chains for every search hit. Fetch source\nfor the selected symbol only; for a large class/file, prefer `read_file` with\na small 0-based `startLine`/`endLine` window (subtract 1 from graph line numbers),\nor `maxLines` for a whole-file read, if that tool is available. Use\n`trace` for a known A→B path instead of repeatedly expanding `context`.\n\nFilters retain requested sections/categories and hide the others; they do not prove other references\nare absent or make the existing bounded search exhaustive. Read `response_filter`,\n`warning`, `partial`, `truncated`, `epistemic` and `staleness`. Remove filters when\nbroader evidence is needed. `maxTokens` is a last-resort byte cutoff that can cut\nJSON: narrow the request rather than treating a cut response as complete. Never\nuse a filtered caller view to waive the required impact check or an UNKNOWN risk.\n\n## Checklist\n\n```\n- [ ] Once per session: bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] Check hot-tool staleness; read the overview only if needed\n- [ ] Query for the concept only if the relevant symbol is not already known\n- [ ] Review returned symbols; include processes when execution flow matters\n- [ ] context on selected symbols; request only relevant sections/relations\n- [ ] Read a process resource only if its full trace is needed\n- [ ] Read targeted source only when implementation details are needed\n- [ ] State the repository and index freshness with the explanation\n```\n\n## Resources\n\n| Resource | What you get |\n| --------------------------------------- | ------------------------------------------------------- |\n| `gitnexus://repo/{name}/context` | Stats, staleness warning (~150 tokens) |\n| `gitnexus://repo/{name}/clusters` | All functional areas with cohesion scores (~300 tokens) |\n| `gitnexus://repo/{name}/cluster/{name}` | Area members with file paths (~500 tokens) |\n| `gitnexus://repo/{name}/process/{name}` | Step-by-step execution trace (~200 tokens) |\n\n## Tools\n\n**query** — find execution flows related to a concept:\n\n```\nquery({search_query: \"payment processing\", repo: \"my-app\"})\n→ Processes: CheckoutFlow, RefundFlow, WebhookHandler\n→ Symbols grouped by flow with file locations\n```\n\n**context** — 360-degree view of a symbol:\n\n```\ncontext({name: \"validateUser\", repo: \"my-app\"})\n→ Incoming calls: loginHandler, apiMiddleware\n→ Outgoing calls: checkToken, getUserById\n→ Processes: LoginFlow (step 2/5), TokenRefresh (step 1/3)\n```\n\n`repo` is required once more than one repository is indexed, and may be omitted\nwith a single one.\n\n## Example: \"How does payment processing work?\"\n\nWith `my-app` already bound and the index current:\n\n```text\n1. query({search_query: \"payment processing\", repo: \"my-app\", limit: 3, max_symbols: 3})\n → CheckoutFlow and RefundFlow, with symbol IDs and locations\n2. context({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"outgoing\", \"processes\"]})\n → Selected source, callees, process participation and completeness diagnostics\n3. Answer from that evidence; read one process resource only if its trace is still needed\n```\n\nReport the repository and index freshness with the explanation. If `my-app`\nhad not yet been bound, discover it once with `list_repos` first.\n",".claude/skills/gitnexus-cli/SKILL.md":"---\nname: gitnexus-cli\ndescription: \"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \\\"Index this repo\\\", \\\"Reanalyze the codebase\\\", \\\"Generate a wiki\\\"\"\n---\n\n# GitNexus CLI Commands\n\nCommands below use `node .gitnexus/run.cjs ` — the project-local runner `gitnexus analyze` drops next to the index. It auto-selects an available runner at call time (global `gitnexus`, else `pnpm dlx`, else `bunx`, else `npx`), so no package-manager assumption and no global install is required — including on a bun-only machine, which has no npm, npx or pnpm at all.\n\n> **Not analyzed yet, or `node .gitnexus/run.cjs` reports `Cannot find module`** (the gitignored runner is absent — e.g. a fresh clone or `git clean`)? (Re)generate it with `npx gitnexus analyze` from the project root, or `bunx gitnexus@latest analyze` on a bun-only machine. On **npm 11.x**, if `npx` crashes during install (`node.target is null`), install once with `npm i -g gitnexus` (then `gitnexus analyze`), or use `bunx gitnexus@latest analyze`, or `pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze`. See [#1939](https://github.com/abhigyanpatwari/GitNexus/issues/1939).\n\n## Commands\n\n### analyze — Build or refresh the index\n\n```bash\nnode .gitnexus/run.cjs analyze\n```\n\nRun from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.\n\n| Flag | Effect |\n| -------------- | ---------------------------------------------------------------- |\n| `--watch` | Keep a Git repository index current with serialized refreshes |\n| `--debounce ` | Watch quiet period before refresh (default: 300 ms) |\n| `--force` | Force full re-index even if up to date |\n| `--embeddings` | Enable embedding generation for semantic search (off by default) |\n| `--drop-embeddings` | Drop existing embeddings on rebuild. By default, an `analyze` without `--embeddings` preserves them. |\n| `--pdg` | Build the program-dependence layers used by `explain` and `pdg_query` (taint, CDG, and REACHING_DEF). |\n| `--spring-actuator ` | Import opt-in Spring Boot Actuator mappings, beans, conditions, configprops, and env snapshots. Forces a full rebuild; unsupported with `--watch`. |\n| `--asyncapi-spec ` | Read opt-in AsyncAPI 3.x documents (directory or single file) and mint `Destination` nodes from their operations. 2.x is refused, not mapped. Unsupported with `--watch`. |\n\n**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook detects staleness after `git commit` and `git merge` and notifies the agent to run `analyze` — the hook does not run analyze itself, to avoid blocking the agent for up to 120s and risking KuzuDB corruption on timeout.\n\nFor Spring runtime enrichment, pass a JSON bundle, one endpoint JSON file, or a directory containing endpoint files. Route evidence is authoritative only when `runtimeConfirmed === true`; `runtimeSource` records provenance and may also accompany `handler-conflict`. Env/configprops values are never persisted.\n\n## Index storage and retention\n\nDefault location is `/.gitnexus/`. Override with environment variables (also documented in README):\n\n| Env | Effect |\n| --- | ------ |\n| `GITNEXUS_STORAGE_PATH` | One complete external index directory. Wins if both storage vars are set. |\n| `GITNEXUS_STORAGE_ROOT` | Absolute root; GitNexus creates an isolated `-<12-hex>/` slot per repository. |\n| `GITNEXUS_CONTENT_RETENTION` | `full` (default) keeps file text; `symbol` keeps snippets; `none` keeps the graph only. |\n\n`list_repos`, `gitnexus://repo/{name}/context`, and HTTP `GET /api/repos` / `GET /api/repo` expose `storagePath`, `contentRetention`, and `sourceAvailable`. HTTP `/api/file` and `/api/grep` return 410 unless retention is `full`. MCP `include_content` may still return symbol spans when retention is `symbol`.\n\nUse `node .gitnexus/run.cjs analyze --watch` for a long-lived local Git repository. It performs an initial analysis, queues scanner-admitted file changes, and retries intact failed batches with bounded backoff. Watch refreshes update only the graph: they skip AGENTS.md / CLAUDE.md injection and standard skill installation, so run a one-shot `analyze` when those generated files need updating. Watch rejects one-shot or context-output flags including `--force`, embedding flags, `--skills`, `--default-branch`, `--skip-agents-md`, `--skip-skills`, `--no-stats`, `--self-commit`, `--index-only`, and `--skip-git`. It never pulls remotes. Scheduled remote clone/pull is a different command: `gitnexus auto-sync`. Bare `gitnexus watch` is reserved and does not start either job. Running MCP and `serve` processes periodically check for a published replacement and reopen it without a restart. MCP checks are throttled to once every five seconds, so a tool call before the next check can briefly use the previous index.\n\n### status — Check index freshness\n\n```bash\nnode .gitnexus/run.cjs status\n```\n\nShows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.\n\n### clean — Delete the index\n\n```bash\nnode .gitnexus/run.cjs clean\n```\n\nDeletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.\n\n| Flag | Effect |\n| --------- | ------------------------------------------------- |\n| `--force` | Skip confirmation prompt |\n| `--all` | Clean all indexed repos, not just the current one |\n\n### wiki — Generate documentation from the graph\n\n```bash\nnode .gitnexus/run.cjs wiki\n```\n\nGenerates repository documentation from the knowledge graph using an LLM. HTTP providers require an API key (saved to `~/.gitnexus/config.json` on first use). Local CLI providers (`--provider cursor|claude|codex|opencode|grok`) use your existing CLI login.\n\n| Flag | Effect |\n| ------------------- | ----------------------------------------- |\n| `--force` | Force full regeneration, also required to re-generate an existing wiki in a different language |\n| `--provider ` | LLM provider: minimax, openai, openrouter, azure, custom, cursor, claude, codex, opencode, or grok (default: minimax). Local CLIs (`cursor`, `claude`, `codex`, `opencode`, `grok`) use your existing CLI login and skip `--api-key`. |\n| `--model ` | LLM model (default: MiniMax-M3) |\n| `--base-url ` | LLM API base URL |\n| `--api-key ` | LLM API key |\n| `--concurrency ` | Parallel LLM calls (default: 3) |\n| `--timeout ` | LLM request timeout in seconds (default: disabled) |\n| `--retries ` | Max LLM retry attempts per request (default: 3) |\n| `--lang ` | Output language for generated documentation (e.g. english, chinese, spanish, japanese) |\n| `--gist` | Publish wiki as a public GitHub Gist |\n\n### list — Show all indexed repos\n\n```bash\nnode .gitnexus/run.cjs list\n```\n\nLists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.\n\n## After Indexing\n\n1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded\n2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task\n\n## Troubleshooting\n\n- **\"Not inside a git repository\"**: Run from a directory inside a git repo\n- **Index is stale after re-analyzing**: Wait for the next MCP tool call to reopen the published index; this normally takes no more than five seconds\n- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding\n",".claude/skills/gitnexus-refactoring/SKILL.md":"---\nname: gitnexus-refactoring\ndescription: \"Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: \\\"Rename this function\\\", \\\"Extract this into a module\\\", \\\"Refactor this class\\\", \\\"Move this to a separate file\\\"\"\n---\n\n# Refactoring with GitNexus\n\n## When to Use\n\n- \"Rename this function safely\"\n- \"Extract this into a module\"\n- \"Split this service\"\n- \"Move this to a new file\"\n- Any task involving renaming, extracting, splitting, or restructuring code\n\n## Bind the repository first\n\nRefactoring writes to disk. `rename` with `dry_run: false` edits files in\nwhichever repository was resolved, so binding identity here is a safety gate,\nnot bookkeeping.\n\nCall `list_repos {}` before the first tool call. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask. Never run `rename` with\n`dry_run: false` until the preview in the same bound repository has been\nreviewed — its returned `file_path` values show which checkout is about to be\nwritten, so read them as a confirmation of identity.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\n`detect_changes` takes `worktree` when you are editing a linked worktree the\nMCP server was not launched from; otherwise `git diff` runs in the wrong\ncheckout and reports nothing changed, which reads as a verified refactor.\n\n## Workflow\n\n```\n0. list_repos {} → Bind repo (and worktree)\n1. impact({target: \"X\", direction: \"upstream\"}) → Map all dependents\n2. query({search_query: \"X\"}) → Find execution flows involving X\n3. context({name: \"X\"}) → See all incoming/outgoing refs\n4. Plan update order: interfaces → implementations → callers → tests\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Checklists\n\n### Rename Symbol\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] rename({symbol_name: \"oldName\", new_name: \"newName\", dry_run: true}) — preview semantic edits (omitting dry_run also previews)\n- [ ] Confirm the previewed file paths are in the bound repository/worktree\n- [ ] Review exact graph-backed semantic spans, coverage, and limitations\n- [ ] If satisfied: rename({..., dry_run: false, plan_token: \"\"}) — apply exactly the reviewed edits\n- [ ] detect_changes() — verify only expected files changed\n- [ ] Run tests for affected processes\n```\n\n### Extract Module\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] context({name: target}) — see all incoming/outgoing refs\n- [ ] impact({target, direction: \"upstream\"}) — find all external callers\n- [ ] Define new module interface\n- [ ] Extract code, update imports\n- [ ] detect_changes() — verify affected scope\n- [ ] Run tests for affected processes\n```\n\n### Split Function/Service\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] context({name: target}) — understand all callees\n- [ ] Group callees by responsibility\n- [ ] impact({target, direction: \"upstream\"}) — map callers to update\n- [ ] Create new functions/services\n- [ ] Update callers\n- [ ] detect_changes() — verify affected scope\n- [ ] Run tests for affected processes\n```\n\n## Tools\n\n**rename** — semantic rename; preview first, then apply:\n\n```\nrename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: true})\n→ 12 edits across 8 files\n→ semantic_edits: 12, coverage: {name: \"gitnexus-semantic\", scope: \"indexed-repository\", limitations: [...]}\n→ changes: [{file_path, edits: [{start, length, line, old_text, new_text, confidence: \"semantic\"}]}]\n```\n\n`dry_run` omitted or `true` previews and never writes; `dry_run: false` requires\nthe successful preview's `plan_token`. Keep the same repository, selected symbol,\nand destination name. Tokens are single-use, expire after 15 minutes or a server\nrestart, and may be evicted when retained previews reach 16 plans or 64 MiB.\nAny apply attempt consumes the token; request and review a fresh preview to retry.\nAn MCP server started with `GITNEXUS_MCP_READ_ONLY=1` still lists `rename`, but\nas preview-only: it rejects any `dry_run` other than omitted or `true`, so apply\nthrough a server that permits writes. Request and review a fresh preview there;\ntokens belong to the process that issued them.\n\nRename uses the indexed graph and GitNexus's own semantic layer. Language\nproviders resolve current source through scopes and bindings; no compiler or\nlanguage service is loaded. Unsupported syntax, ambiguous bindings, stale\ndeclarations, and incomplete occurrence coverage fail closed. Coverage describes\nindexed files accepted by the selected provider, including supported embedded sources,\nand excludes unindexed files and external consumers. All registered source-language\nproviders supply rename rules. Declaration and override families require complete\nsemantic evidence. Dynamic or computed references block a rename when the provider\ncannot resolve them or exclude them from the selected family. Provider-specific\nlimits, including class renames requiring a file move, remain explicit in results.\nThere is no regex fallback: legacy `graph_edits` and `text_search_edits` are zero.\nComments, strings, and unrelated same-spelled symbols are not replacements.\n\nPreview captures the exact semantic plan, source hashes and physical file targets.\nApply validates that plan and executes its edits without replanning. Changes to\nindexed targets, source bytes or paths (including newly added untracked source\nfiles) reject the plan before writing. Unindexed files remain outside semantic\ncoverage; analyze first when they need refactoring. Results use `result_version: 2`;\n`total_edits` counts occurrences, not matching lines. Exact replacements are shown in `new_text`.\nCheck `planning_status`, `application_status`, and `applied`. A completed apply\nhas `status: \"success\"`, `application_status: \"applied\"`, and `applied: true`.\nA successful preview has not written files. `rename` does not accept `branch`:\nit inspects the current checkout.\n\nRecover from a blocked or incomplete rename before applying again. A failed\nresult carries `code` and `error`; nothing was written unless the last row applies.\n\n| Result | Next step |\n| --- | --- |\n| `stale_graph` | Re-analyze the bound repository, then preview again with `rename` (`dry_run` omitted or `true`). |\n| `source_changed` | Preview again against the current source and review it. If it appears during an apply, see the `partial` row. |\n| `plan_required`, `invalid_plan`, `plan_mismatch` | Apply needs the successful preview's token and identical repository, symbol and new name. Expired, consumed or evicted plans require a fresh reviewed preview. |\n| `source_set_changed` | Source paths changed, including untracked files. Re-analyze and review a fresh preview. |\n| `plan_too_large` | The captured plan exceeds the 64 MiB retention budget. Narrow the indexed repository before previewing again. |\n| `unsupported_*` | Stop automated rename and inspect the reported limitation. Use a language-aware manual refactor if needed. |\n| Ambiguous target (`status: \"ambiguous\"` with candidates) | Inspect the returned candidates or `context`, then preview with the chosen `symbol_uid`. |\n| `ambiguous_reference`, `incomplete_semantics` | The planner could not prove a reference, import, or declaration is covered. Stop automated rename; resolve the named location by hand or pick a different symbol. |\n| `name_collision` | `new_name` would collide with, or change the identity of, another declaration or binding. Choose a different name and preview again. |\n| `invalid_name` | `new_name` is empty, equals the current name, or is not valid in the target language. Choose a valid, different identifier. |\n| `invalid_argument` | `dry_run` was sent but is not a boolean. Omit it or send `true` or `false`. |\n| `no_locations` | The planner produced no edits. Do not apply; re-check the target with `context` and pass `symbol_uid`. |\n| `overlapping_edits`, `invalid_edit` | The planned spans conflict or do not match the source text. The plan is rejected before any write; do not apply. Refactor manually or report the case. |\n| `duplicate_file`, `missing_snapshot`, `outside_repository` | A planner safety check failed (two paths resolve to one real file, a file has no source snapshot, or a path leaves the repository). Re-analyze and preview again; if it repeats, stop and report it. |\n| `source-unavailable` (`reason: \"content-retention\"` or `\"checkout-missing\"`) | The index was built without full source retention (`GITNEXUS_CONTENT_RETENTION`), or the checkout directory is missing. Re-analyze with full retention, or run against the checkout. |\n| `rename_failed` | An unexpected error while planning, before any write (`application_status: \"not_started\"`). Re-analyze and preview once more; if it repeats, stop and report the `error` text. |\n| `application_status: \"partial\"` or `\"failed\"` (`write_failed`, or `source_changed` mid-apply) | Writes are not transactional. Inspect landed `changes` (already written, with their counts), `failed_files` (the one file whose write or validation failed), and `unattempted_files` (later files never touched). Reconcile the current files, re-index, and review a fresh preview; never blindly retry the apply call. |\n\nRun the project validation suite after applying.\n\n**impact** — map all dependents first:\n\n```\nimpact({target: \"validateUser\", repo: \"my-app\", direction: \"upstream\"})\n→ d=1: loginHandler, apiMiddleware, testUtils\n→ Affected Processes: LoginFlow, TokenRefresh\n```\n\n**detect_changes** — verify your changes after refactoring:\n\n```\ndetect_changes({scope: \"all\"})\n→ Changed: 8 files, 12 symbols\n→ Affected processes: LoginFlow, TokenRefresh\n→ Risk: MEDIUM\n```\n\n`partial: true` (a graph query failed) or `truncated: true` (the changed-symbol\nlisting was capped) means the result is short of the truth: a short or empty\nlist is not proof that only the expected files changed. Re-run it rather than\ntreat the refactor as verified.\n\nA wrong-worktree zero carries neither flag and is indistinguishable from a\nclean verification, so confirm the diffed checkout is the one you edited.\n\n**cypher** — custom reference queries:\n\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"validateUser\"})\nRETURN caller.name, caller.filePath ORDER BY caller.filePath\n```\n\n## Risk Rules\n\n| Risk Factor | Mitigation |\n| ------------------- | ----------------------------------------- |\n| Many callers (>5) | Use rename for automated updates |\n| Cross-area refs | Use detect_changes after to verify scope |\n| String/dynamic refs | query to find them |\n| External/public API | Version and deprecate properly |\n| Same name in another indexed repo | Bind `repo`; verify previewed paths before applying |\n\n## Example: Rename `validateUser` to `authenticateUser`\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly\n\n1. rename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: true})\n → 12 semantic occurrences in the indexed repository's supported provider scope\n → Files: validator.ts, login.ts, middleware.ts...\n\n2. Review semantic spans and provider coverage; inspect dynamic references separately\n\n3. rename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: false, plan_token: \"\"})\n → Applied 12 edits across 8 files\n\n4. detect_changes({scope: \"all\", repo: \"my-app\"})\n → Affected: LoginFlow, TokenRefresh\n → Risk: MEDIUM — run tests for these flows\n Repository: my-app (/abs/path/my-app) Worktree: same Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n",".claude/skills/gitnexus-debugging/SKILL.md":"---\nname: gitnexus-debugging\ndescription: \"Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: \\\"Why is X failing?\\\", \\\"Where does this error come from?\\\", \\\"Trace this bug\\\"\"\n---\n\n# Debugging with GitNexus\n\n## When to Use\n\n- \"Why is this function failing?\"\n- \"Trace where this error comes from\"\n- \"Who calls this method?\"\n- \"This endpoint returns 500\"\n- Investigating bugs, errors, or unexpected behavior\n\n## Bind the repository first\n\nA root cause traced in the wrong repository is a wrong root cause.\n\nBind once using a confirmed registry name/path or configured MCP default. Call\n`list_repos {}` if the target is not yet known; reuse that binding across calls. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask. This matters most for `cypher`, whose\nstatement carries no in-band hint of which database it ran against.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\nA stale index describes the code from before your bug, so refresh before\ntrusting a trace, and state the repository and index freshness with the\ndiagnosis.\n\n## Workflow\n\n```\n0. Bind the repo once (list_repos only if not already known)\n1. If the suspect is unknown, query for the error/symptom with small result limits\n2. context({name: \"\"}) → See callers/callees/processes\n3. Read a process resource only if its trace resolves an open question\n4. cypher({statement: \"MATCH path...\"}) → Custom traces if needed\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Checklist\n\n```\n- [ ] Once per session: bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] Understand the symptom (error message, unexpected behavior)\n- [ ] query for error text or related code\n- [ ] Identify the suspect function from returned processes\n- [ ] context to see callers and callees\n- [ ] Trace execution flow via process resource if applicable\n- [ ] cypher for custom call chain traces if needed\n- [ ] Read source files to confirm root cause\n- [ ] State the repository and index freshness with the diagnosis\n```\n\n## Keep investigations focused\n\nStart with a known symbol's `context`, or a small `query` (`limit: 3`,\n`max_symbols: 3`, `include_content: false`, `chain_depth: 0`) to discover one.\nWhen the server advertises these single-repository filters, request only the\nneeded evidence:\n\n```text\ncontext({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"outgoing\"], relationTypes: [\"CALLS\"]})\ntrace({from_uid: \"\", to_uid: \"\", repo: \"my-app\"})\n```\n\n`symbol` and completeness/staleness diagnostics remain in a filtered context.\n`relationTypes` filters the returned incoming/outgoing categories only; it does\nnot expand their existing bounded window or filter an explicitly requested chain.\nFor callback registration, include `USES`; for imports or inheritance, request\nthose relation types or omit the filter. Omitted references are not absent\nreferences. Broaden when the hypothesis needs it, and preserve UNKNOWN/partial\nwarnings. Confirm source and tests before claiming a root cause. A useful 2–3\ncall investigation is a goal, not a reason to skip verification or pre-edit impact.\n\n## Debugging Patterns\n\n| Symptom | GitNexus Approach |\n| -------------------- | ---------------------------------------------------------- |\n| Error message | `query` for error text → `context` on throw sites |\n| Wrong return value | `context` on the function → trace callees for data flow |\n| Intermittent failure | `context` → look for external calls, async deps |\n| Performance issue | `context` → find symbols with many callers (hot paths) |\n| Recent regression | `detect_changes` to see what your changes affect — pass `worktree` for a linked worktree |\n| \"How does A reach B?\" | `trace` between the two symbols — shortest call chain in one call |\n\n## Tools\n\n**query** — find code related to error:\n\n```\nquery({search_query: \"payment validation error\", repo: \"my-app\"})\n→ Processes: CheckoutFlow, ErrorHandling\n→ Symbols: validatePayment, handlePaymentError, PaymentException\n```\n\n**context** — full context for a suspect:\n\n```\ncontext({name: \"validatePayment\", repo: \"my-app\"})\n→ Incoming calls: processCheckout, webhookHandler\n→ Outgoing calls: verifyCard, fetchRates (external API!)\n→ Processes: CheckoutFlow (step 3/7)\n```\n\n**cypher** — custom call chain traces. Pass `repo` alongside the statement; the\nCypher text itself names no repository, so the result is unattributable without\nit:\n\n```cypher\nMATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: \"validatePayment\"})\nRETURN [n IN nodes(path) | n.name] AS chain\n```\n\n**trace** — shortest call chain between two symbols (\"how does A reach B?\"), one call instead of chaining `context` hops:\n\n```\ntrace({ from: \"processCheckout\", to: \"fetchRates\", repo: \"my-app\" })\n→ status: ok, hopCount: 3\n→ hops: processCheckout → validatePayment → verifyCard → fetchRates\n→ edges: CALLS (1.0), CALLS (0.95), CALLS (1.0)\n```\n\nWhen no path exists, `trace` reports the furthest reachable node — exactly where the chain breaks (dynamic dispatch, reflection, or an external boundary).\n\n## Example: \"Payment endpoint returns 500 intermittently\"\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — bind my-app explicitly on every call\n\n1. query({search_query: \"payment error handling\", repo: \"my-app\"})\n → Processes: CheckoutFlow, ErrorHandling\n → Symbols: validatePayment, handlePaymentError\n\n2. context({name: \"validatePayment\", repo: \"my-app\"})\n → Outgoing calls: verifyCard, fetchRates (external API!)\n\n3. READ gitnexus://repo/my-app/process/CheckoutFlow\n → Step 3: validatePayment → calls fetchRates (external)\n\n4. Root cause: fetchRates calls external API without proper timeout\n Repository: my-app Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n",".claude/skills/gitnexus-work/SKILL.md":"---\nname: gitnexus-work\ndescription: 'Use when executing an engineering plan produced by gitnexus-plan (or a small bounded task directly) — implements step by step with GitNexus impact checks before every symbol edit, tests from the plan''s scenarios, and detect_changes gating every commit. Examples: \"/gitnexus-work docs/plans/2026-07-11-gitnexus-plan-ingestion-retry.md\", \"/gitnexus-work\" (latest plan), \"execute the plan\".'\n---\n\n# gitnexus-work — execute a gitnexus-plan\n\nExecute an implementation plan produced by `gitnexus-plan`, shipping it as a\nsequence of verified, atomic commits. The plan's section 11\n(`implementation_context` pack) is the primary machine-readable input; the\nprose sections are its rationale. This skill **does** edit code — it is the\nexecutor counterpart to the planning-only `gitnexus-plan`.\n\n```\n/gitnexus-work # execute this plan\n/gitnexus-work # newest docs/plans/*gitnexus-plan*.md here\n/gitnexus-work # direct mode, see Input triage\n```\n\n## Input triage\n\n- **Plan path** (or blank → the newest `docs/plans/*gitnexus-plan*.md` under\n the current repo root): the normal mode; continue to Phase 1. Schema-2\n plans have a normalized repo-relative\n `docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md`\n `generated_plan_path`. Resolve only a lexical candidate, then invoke\n `scripts/evidence-provenance.mjs read-plan --repo --generated-plan\n` and load only the exact bytes in its descriptor-anchored\n receipt. Require the receipt's canonical repo-relative path to equal the\n document's `generated_plan_path` byte-for-byte;\n reject an external, escaping, differently scoped, or mismatched value. A\n plan in another target repo may still be passed by explicit path. If Phase 1's\n pre-completed check finds every §7 step of the newest plan already landed,\n stop and ask instead of re-executing it.\n- **Bare task text**: trivial and bounded (1–2 files, no architectural\n decisions) → implement directly with the same discipline: `impact` before\n every symbol edit, minimal change, tests when behavior changes,\n verification commands taken from the repo's own scripts (package.json /\n CI), `detect_changes` before every commit, and the shared\n Build-current/index-current procedure before graph-dependent impact and\n final verification. Anything larger → recommend running\n `/gitnexus-plan` first; honor the user's choice if they decline.\n\n## Phase 1 — Load and re-anchor the plan\n\n1. Resolve the target repo and normalized plan candidate, then invoke this\n skill's descriptor-anchored `scripts/evidence-provenance.mjs read-plan`\n command exactly as\n specified in `references/evidence-provenance.md`. Reject a missing,\n external, escaping, symlinked, or differently scoped path. Decode and read\n the receipt's exact `plan_bytes_base64` completely; never read or reopen the\n lexical path directly. It is a decision artifact, not a script: scope\n boundaries and `avoid` entries bind you; exact code is yours to write.\n Retain the receipt's canonical `generated_plan_path` and `plan_digest` in\n session state. Never edit the plan body.\n2. Parse the §11 `implementation_context` pack: `acceptance_criteria`,\n `evidence_provenance`, `primary_symbols`, `related_symbols`,\n `files_to_modify`, `execution_path`, `pdg_constraints`,\n `architectural_patterns`, `tests`, `verification_commands`, `risks`,\n `assumptions`, `open_questions`, `avoid`. Compact plans carry the\n mini-pack subset — absent optional fields are empty, not errors.\n `evidence_provenance` is mandatory: absence or schema 1 means a legacy\n plan, not a clean tree. Before relying on it, require exact byte-for-byte\n equality between the read-plan receipt's canonical `generated_plan_path`\n and `evidence_provenance.generated_plan_path`.\n3. **Two-layer drift check — always recompute.** Even when current HEAD is the\n same HEAD as the plan pin, recompute both the canonical global dirty digest\n and the sorted cited-path manifest. Read\n `references/evidence-provenance.md`, then invoke this skill's\n `scripts/evidence-provenance.mjs` with the plan's exact\n `generated_plan_path`, every cited manifest path, and schema version 2.\n Never recreate its bytes in shell or prose. Schema 1 cannot be recomputed\n unambiguously and requires conservative re-anchoring. Include\n object kind plus HEAD/index/worktree/untracked layer digests, and classify\n `staged`, `unstaged`, `untracked`, `deleted`, `renamed`, `mixed`,\n and `absent` evidence. Honor the generated-plan exclusion exactly; do not\n exclude all plans.\n4. **Re-anchor on either mismatch.** Missing or legacy provenance, a HEAD\n mismatch, or a global dirty digest mismatch requires a conservative\n re-anchor before work:\n - Diff every cited-path manifest entry. Changed cited paths — including\n staged-only, unstaged-only, deleted, both rename endpoints, mixed\n staged+unstaged, and disappeared untracked paths — get their cited ranges\n re-read before reliance.\n - Compare the current whole-tree dirty set with the pinned global digest.\n New uncited dirty paths get a scope assessment: determine whether they\n overlap the plan, requirements, tests, or a key technical decision; do not\n silently ignore them merely because they are uncited.\n - Unreadable or unclassifiable cited evidence blocks every dependent step\n until it can be restored, read, or resolved with the user. Never substitute\n an invented digest or treat absence as an empty file.\n - Keep the re-anchor result in session state; never mutate the plan body.\n Use Deepen only if reconciliation invalidates scope, requirements, a key\n technical decision (KTD), or the planned implementation seam. Ordinary\n byte drift that leaves those decisions valid is re-verified locally.\n5. **Re-verify `assumptions` cheaply** (each one names what to check).\n A failed assumption is a stop-and-replan signal for the steps that\n depend on it, not something to code around silently.\n6. Note `open_questions` — if one blocks a step and the answer materially\n changes the work, ask the user before that step, not after.\n7. **Pre-completed check.** If commits for this plan already exist on the\n branch (a prior partial run, or a post-route-back Deepen cycle), verify\n which §7 steps have landed at HEAD: those are skipped and reported as\n pre-completed, and execution resumes at the first unlanded step. All\n steps landed → report that and stop.\n\n## Phase 2 — Environment\n\n- On the default branch → create a feature branch named from the plan slug.\n On a feature branch already → stay only if it is meaningful _for this\n plan_ (name matches the plan slug, or the user confirms); otherwise\n branch from here with the slug name.\n- If the plan document is not yet committed, commit it now\n (`docs(plans): add plan`) — the plan travels with the work it\n drives, and the final review diff then includes it.\n- Confirm the `verification_commands` from the pack actually run in this\n checkout (dependencies installed, builds present) before starting, not\n after the last step.\n\n### Build-current/index-current procedure\n\nThis is the single graph-freshness procedure owned by `gitnexus-work`; it\napplies in plan mode and direct mode. Before every graph-dependent `impact`\nquery, run the Build-current/index-current procedure. Before final graph\nverification, run the same Build-current/index-current procedure again.\n\n1. Capture current HEAD and working-tree provenance. Read\n `gitnexus://repo//context` and use its typed `index.commit` and\n `index.runner_identity` receipt — never infer analyzer identity from prose,\n timestamps, or a path alone. Compare `index.commit` with current HEAD. A\n current receipt has `schemaVersion: 4`, resolved runtime path/version, CLI\n version, invoked-artifact path/digest, build\n kind/root/canonicalization/digest, and dependency-runtime\n manifest/lockfile/canonicalization/package-count/artifact-count/digest. Its\n dependency canonicalization is\n `gitnexus-analyzer-dependency-runtime-v4`. The dependency-runtime digest\n covers resolved package metadata and complete loadable package payloads,\n including JavaScript, JSON, native, Wasm, and parser artifacts; schema-1,\n schema-2, and schema-3 receipts are legacy/stale (the MCP context labels\n them `runner_identity_schema_status: legacy-or-unknown`). Require MCP\n `index.incomplete_reasons: []`. Run the exact candidate CLI's\n `status --json` command and require `index.runnerIdentityStatus: current`,\n `index.incompleteReasons: []`, and top-level `status: up-to-date`. The\n status comparator checks every semantic field while deliberately excluding\n only diagnostic `invokedArtifact`; a worker-authored persisted receipt and\n the CLI's live receipt may therefore differ in that field without becoming\n stale. Missing, malformed, differently versioned, semantically unequal, or\n incomplete receipts are unknown/stale, not a match.\n2. Relationship-affecting committed and uncommitted edits invalidate\n freshness after the last successful procedure run. This includes staged,\n unstaged, untracked, deleted, or renamed analyzer/source/config changes\n that can alter symbols or edges. Any such edit between steps requires an\n inter-step refresh before the next graph query, even when HEAD did not move.\n3. If the typed runner receipt is stale or unknown in an analyzer-source\n checkout, build current local source using the verified package script. In\n this repo: `cd gitnexus && npm run build`. Resolve the package's `bin`\n target and run that exact artifact's `status --json` command to capture its\n current receipt. Source/build timestamps are a conservative rebuild\n trigger, not proof that an artifact is current.\n4. Invoke that exact freshly built local CLI from the target repo root with\n PDG layers enabled. In this repo:\n `node gitnexus/dist/cli/index.js analyze --index-only --pdg`.\n Add `--force` when the persisted receipt was absent, malformed,\n differently versioned, or unequal so an already-up-to-date fast path cannot\n leave legacy/stale provenance in place. The usual project-runner form,\n `node .gitnexus/run.cjs analyze`, is acceptable only when its proven runner\n identity resolves to that same freshly built artifact. Do not fall back to\n an older project runner, global install, or package download after\n resolving/building the local artifact.\n5. Re-read index context, rerun the exact invoked CLI's `status --json`, and\n prove the post-refresh `index.commit` equals current HEAD, MCP\n `index.incomplete_reasons` is empty, and its complete\n `index.runner_identity` equals status `index.runnerIdentity` (the persisted\n receipt). Require status `index.runnerIdentityStatus: current`, empty\n `index.incompleteReasons`, and top-level `status: up-to-date`; do not require\n raw equality with `current.runnerIdentity` because `invokedArtifact` is a\n diagnostic entrypoint deliberately excluded from semantic freshness.\n Record the dirty-state digest indexed in this procedure so same-HEAD\n uncommitted edits can invalidate it later.\n6. Any build, refresh, metadata-read, or identity-verification failure blocks\n graph-dependent impact work and final completion. Report the failing\n command and evidence; do not continue on an older graph.\n\n## Phase 3 — Execute the Implementation Sequence\n\nWork through plan §7 step by step, in order. For each step:\n\n1. **Fresh impact before editing.** Run the Build-current/index-current\n procedure immediately before every graph-dependent\n `impact {target, direction: \"upstream\"}` query. Then account for every\n direct (d=1) dependent. HIGH or CRITICAL risk → surface it to the user\n with the blast radius before proceeding (repo mandate — see AGENTS.md\n GitNexus rules).\n2. **Honor the constraints.** `pdg_constraints` entries state ordering and\n dependence facts the change must preserve; `avoid` entries are hard\n prohibitions; `architectural_patterns` name the shape to mirror (read the\n example location before inventing one).\n3. **Implement minimally.** The smallest change that completes the step,\n following the surrounding code's conventions.\n4. **Test from the plan's scenarios.** Each `tests[]` scenario (input →\n action → expected outcome) becomes a real test in the named file. Add\n coverage the plan missed if the step's behavior demands it; never delete\n or weaken an assertion to make a step pass. Prove a new regression test\n discriminates: when the failure mode is subtle, run it once against the\n pre-fix tree (write the test before the fix, or stash the fix) and watch\n it fail — a test that passes both ways pins nothing.\n5. **Verify.** Run the step-relevant `verification_commands` (they carry\n their build prerequisites; use them as written). If any part of the\n change executes from build output — worker entrypoints, dist-shipped\n CLIs, bundled assets — rebuild that output before every verification\n run: a pass or fail against outdated build output is noise, and \"the\n fix doesn't work\" is more often \"the fix never loaded\".\n6. **Commit atomically.** `detect_changes {scope: \"staged\"}` before every\n commit to confirm only the expected symbols and flows are affected\n (repo mandate); then one conventional commit per step. Run stage →\n `detect_changes` → commit as one unbroken sequence from the repository\n root — interleaving other work between the gate and the commit is how\n the gate gets skipped. Unexpected\n affected flows → investigate before committing, not after. A result\n flagged `partial` (a graph query failed) or `truncated` (the symbol\n listing was capped) blocks the commit the same way: the gate did not\n see every changed symbol, so re-run it rather than read it as clean.\n\nA relationship-affecting implementation edit or commit invalidates the\nprocedure's prior proof. The next step must perform the required inter-step\nrefresh before its impact query; final verification refreshes again after the\nlast edit.\n\nSteps are independently actionable: after any commit the tree is coherent.\nIf a step reveals the plan is wrong, stop that step, re-verify the affected\nclaims at HEAD, and either adapt (small, in-scope deviation — record it in\nthe commit message and final summary) or route back to `gitnexus-plan`\nDeepen mode (structural miss) — with a one-line ask to the user when the\nchoice isn't obvious.\n\n## Phase 4 — Finish\n\n1. Run the full `verification_commands` suite once, at the end, even if\n every step already passed individually.\n2. Walk plan §13 (Definition of Done) and the pack's `acceptance_criteria`\n item by item; anything unmet is either finished now or reported as\n explicitly unmet — never silently dropped.\n3. **Verify the final knowledge graph.** Before final graph verification, run\n the same Build-current/index-current procedure after the last edit, even\n when no commit landed or HEAD still equals the original pin. Then run\n `detect_changes {scope: \"all\"}` (or the repo's equivalent final graph\n check) against that proven-current index and account for every unexpected\n symbol or flow. A procedure failure blocks completion.\n4. Report: steps completed, commits made, deviations from the plan (with\n why), assumptions that failed re-verification, DoD status, final indexed\n commit and runner identity, and anything deferred. Test failures are\n reported with their output, not smoothed over.\n\n## Never\n\n- Skip the Phase 3 gates: no symbol edit without `impact`, no commit without\n `detect_changes`.\n- Expand scope beyond the plan — §12's deferred follow-ups stay deferred.\n- Mutate the plan body (committing the file verbatim in Phase 2 is not\n mutation), weaken failing tests, or present unverified work as verified.\n\n## Skill feedback (GitNexus repo only)\n\nIf this run exposed friction in this skill's own instructions — wrong or\nmissing guidance, a wasted tool budget, a phase that misrouted — and the repo\ncarries `eval/workflow_bench/`, append one JSON line to\n`eval/workflow_bench/learnings.jsonl` (create the file if absent):\n`{\"skill\": \"gitnexus-work\", \"date\": \"YYYY-MM-DD\", \"task\": \"\", \"friction\": \"\", \"suggestion\": \"\"}`.\nNever edit this skill file itself from a live task: improvements go through\nthe offline candidate loop (`eval/workflow_bench/README.md` § Prompt and\nskill evolution loop), where a candidate must beat the incumbent on the\npaired benchmark before a human merges it.\n",".claude/skills/gitnexus-guide/SKILL.md":"---\nname: gitnexus-guide\ndescription: \"Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: \\\"What GitNexus tools are available?\\\", \\\"How do I use GitNexus?\\\"\"\n---\n\n# GitNexus Guide\n\nQuick reference for all GitNexus MCP tools, resources, and the knowledge graph schema.\n\n## Always Start Here\n\nFor any task involving code understanding, debugging, impact analysis, or refactoring:\n\n1. **Bind the repository once** — use a confirmed registry name/path or configured default; call `list_repos` if unknown. Read hot-tool `staleness`; use `gitnexus://repo/{name}/context` when an overview is needed.\n2. **Match your task to a skill below** and **read that skill file**\n3. **Follow the skill's workflow and checklist**\n\n> If step 1 warns the index is stale, run `node .gitnexus/run.cjs analyze` in the terminal first.\n> On `query` / `context` / `impact` / `cypher`, read `staleness.status` and `staleness.branch`/`lastCommit` before using the answer. Re-analyze only for `behind` or `diverged`.\n\n## Skills\n\n| Task | Skill to read |\n| -------------------------------------------- | ------------------- |\n| Understand architecture / \"How does X work?\" | `gitnexus-exploring` |\n| Blast radius / \"What breaks if I change X?\" | `gitnexus-impact-analysis` |\n| Trace bugs / \"Why is X failing?\" | `gitnexus-debugging` |\n| Rename / extract / split / refactor | `gitnexus-refactoring` |\n| Tools, resources, schema reference | `gitnexus-guide` (this file) |\n| Index, status, clean, wiki CLI commands | `gitnexus-cli` |\n\n## Tools Reference\n\n| Tool | What it gives you |\n| ---------------- | ------------------------------------------------------------------------ |\n| `query` | Process-grouped code intelligence — execution flows related to a concept |\n| `context` | 360-degree symbol view — categorized refs, processes it participates in |\n| `impact` | Symbol blast radius — what breaks at depth 1/2/3 with confidence |\n| `trace` | Shortest path between two symbols — \"how does A reach B?\" in one call |\n| `detect_changes` | Git-diff impact — what do your current changes affect |\n| `rename` | Semantic rename: previews by default (`dry_run` omitted/true), applies with `dry_run: false` and the preview's `plan_token`; inspect application status and failures |\n| `cypher` | Raw graph queries (read `gitnexus://repo/{name}/schema` first) |\n| `explain` | Persisted taint findings — source→sink data flows (needs `analyze --pdg`) |\n| `pdg_query` | Control/data dependence — what gates X (CDG) / where Y flows (REACHING_DEF); needs `analyze --pdg` |\n| `check` | Check graph invariants such as circular imports |\n| `route_map` | API route map — which components/hooks fetch which endpoints, and the handler files that serve them |\n| `shape_check` | Response-shape drift — keys each route returns vs keys its consumers access (flags MISMATCH) |\n| `api_impact` | Pre-change report for an API route — consumers, middleware, shape mismatches, risk level |\n| `tool_map` | MCP/RPC tool definitions and the files that handle them |\n| `group_list` | List configured multi-repo groups, or one group's config |\n| `group_sync` | Rebuild a group's Contract Registry (cross-repo HTTP contract links); run after `group.yaml` changes or member re-index |\n| `list_repos` | Discover indexed repos (paginated — `limit`/`offset`) |\n\n### Choose a focused response\n\nUse the connected server's schema; older servers may not advertise the new\nfilters. All options below are explicit: omitting them preserves existing output.\nUse filters for bulky unwanted sections; on an already-small response, omission\nmetadata can outweigh the bytes saved.\n\n| Question | Options |\n| --- | --- |\n| Which symbols implement this? | `query`: `limit: 3`, `max_symbols: 3`, `include_content: false`, `chain_depth: 0`, `response_sections: [\"process_symbols\", \"definitions\"]` |\n| Which execution flows match? | `query`: keep `processes` in `response_sections`; join its `id` to `process_symbols[].process_id` |\n| Who calls this exact symbol? | `context`: `uid`, `response_sections: [\"incoming\"]`, `relationTypes: [\"CALLS\"]` |\n| What does it call, with source? | `context`: `uid`, `include_content: true`, `response_sections: [\"outgoing\"]`, `relationTypes: [\"CALLS\"]` |\n| What is the impact summary? | `impact`: `direction: \"upstream\"`, `summaryOnly: true`; risk calculation and totals are retained |\n| Which affected symbols need inspection? | `impact`: `limit: 10`, `offset: 0`; page as indicated by the response |\n| How does A reach B? | `trace`: `from_uid`, `to_uid` |\n\n`response_sections` selects data sections for single-repository MCP `query` or\n`context` (not `@group` routes). Query choices: `processes`, `process_symbols`,\n`definitions`. Context choices: `incoming`, `outgoing`, `processes`, `chain`,\n`routes`, `typed_properties`; the selected symbol always remains. Context\n`relationTypes` accepts uppercase relationship names advertised by its schema\nand filters only the existing incoming/outgoing categories. It does not change\nranking, traversal, source retention or the bounded candidate/reference windows.\n\nFilters add `response_filter` with the selection and omitted fields/categories.\nWarnings, ambiguity, staleness and completeness metadata always remain. An empty\nfiltered view is not proof of absence. Omit filters to expand, and never waive\nimpact checks because a selected category is empty. `maxTokens` is a byte cutoff,\nnot pagination: it can cut JSON. Prefer these filters, small result counts, and\nsource/chain expansion for a selected symbol rather than a large search result.\nStop once enough evidence answers the question; do not run every tool by default.\n\n### Paginating `list_repos`\n\n`list_repos` is paginated so a large registry is not truncated by MCP/LLM token limits. It takes optional `limit` (default **50**, max **200**) and `offset`, and returns:\n\n```jsonc\n{\n \"repositories\": [\n { \"name\": \"...\", \"path\": \"...\", \"indexedAt\": \"...\", \"lastCommit\": \"...\", \"stats\": { } }\n ],\n \"pagination\": {\n \"total\": 437,\n \"limit\": 50,\n \"offset\": 0,\n \"returned\": 50,\n \"hasMore\": true,\n \"nextOffset\": 50\n }\n}\n```\n\nTo enumerate **every** repository, keep calling with `offset` set to `pagination.nextOffset` until `hasMore` is `false`:\n\n```text\nlist_repos {} → repos 1–50, nextOffset 50, hasMore true\nlist_repos { offset: 50 } → repos 51–100, nextOffset 100, hasMore true\n…\nlist_repos { offset: 400 } → repos 401–437, hasMore false (done)\n```\n\nNotes: `offset` ≥ `total` returns an empty page (with `total` still reported). Out-of-range or malformed `limit`/`offset` (non-integer, `limit` outside `[1, 200]`, `offset < 0`) are rejected with a clear error — `limit` above the max is rejected, not silently capped. The order is deterministic (lower-cased name, then path), so paging never skips or duplicates an entry while the registry is unchanged.\n\n### Inline staleness signal (`query` / `context` / `impact` / `cypher`)\n\nThese four hot read tools attach a non-blocking `staleness` field to every response, in the shape `{ status, branch?, lastCommit, indexedAt, measuredAgainst, commitsBehind?, hint? }`. It answers two different questions at once: **which index answered** and **how fresh it is**. The identity half is why the field is present even when nothing is wrong — an answer computed from a branch-pinned index is otherwise indistinguishable from one computed from the default branch (#3291):\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"current\",\n \"branch\": \"feature/checkout-v2\",\n \"lastCommit\": \"4f2a1c9e8b7d6a5c4e3f2a1b0c9d8e7f6a5b4c3d\",\n \"indexedAt\": \"2026-09-15T07:12:00.000Z\",\n \"measuredAgainst\": \"HEAD\"\n }\n}\n```\n\n`status: \"current\"` here means *this index is at the HEAD of the clone it was built from* — not that it is current with the default branch. `measuredAgainst` names what `commitsBehind` is counted against: the checked-out HEAD of that clone, never the remote. `branch` is the branch the index represents; it is absent for a detached HEAD, a non-git folder, or a legacy index that never recorded one, so read `lastCommit` when you need an identifier that is always present.\n\nWhen the index is behind that HEAD, the count and hint ride along:\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"behind\", \"commitsBehind\": 3, \"branch\": \"main\",\n \"lastCommit\": \"a0c945022d06b8815f93ffd8838df9ed5c08cbc0\",\n \"indexedAt\": \"2026-09-04T20:45:47.481Z\", \"measuredAgainst\": \"HEAD\",\n \"hint\": \"⚠️ Index is 3 commits behind HEAD. Run analyze tool to update.\"\n }\n}\n```\n\n`commitsBehind` is present only when git counted the gap. When git could not count it but HEAD still resolves to a commit other than the indexed one — usually because the indexed commit is no longer in the clone's history — the index is provably not at HEAD with no countable gap, so no number is reported:\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"diverged\", \"branch\": \"main\",\n \"lastCommit\": \"a0c945022d06b8815f93ffd8838df9ed5c08cbc0\",\n \"indexedAt\": \"2026-09-04T20:45:47.481Z\", \"measuredAgainst\": \"HEAD\",\n \"hint\": \"⚠️ Index is not at HEAD and the commit gap could not be counted — the recorded commit may no longer be in this clone's history. Run analyze tool to update.\"\n }\n}\n```\n\nSo: **read `status` before using `commitsBehind`**, and read `branch`/`lastCommit` before assuming which ref the answer describes. `status: \"unknown\"` means the freshness check could not run at all (a `--skip-git` folder has no history to measure) — the ref is still reported, because which index answered is knowable even when its freshness is not. The field is only ever added to object results — raw-array `cypher` output and error envelopes are returned unchanged. `@group`-targeted calls do not carry it (multi-repo staleness is ill-defined). Re-run `analyze` only for `behind` or `diverged` — those mean the index is not at this clone's HEAD. `unknown` is unmeasurable, not stale; analyze cannot make it `current` unless git history exists.\n\n`list_repos` and the HTTP repo routes are unchanged: they omit `staleness` entirely for a current index and report the ref through their own top-level `branch` / `lastCommit` / `indexedAt` fields.\n\n### Taint findings (`explain`)\n\n`explain` returns taint findings recorded by `gitnexus analyze --pdg` — intra-procedural `TAINTED` edges plus cross-function `TAINT_PATH` hops where the interprocedural taint phase found a function-level source→sink chain. Each finding includes a sink category (command-injection, code-injection, path-traversal, sql-injection, xss), source/sink lines, and the ordered hop path with the variable carried on each hop.\n\n- `explain {}` — enumerate all findings for the repo (bounded by `limit`, deterministic order)\n- `explain { target: \"src/vuln.ts\" }` — findings in a file (suffix path match accepted)\n- `explain { target: \"runUserCommand\" }` — findings in a function (resolved like `context`; ambiguous names return ranked candidates)\n\nA repo indexed without `--pdg` returns a clear \"no taint layer\" note. Caveats: closure/callback, property/field, and implicit flows are not modeled, and interprocedural findings are function-level `TAINT_PATH` hops rather than statement-level path proof, so the absence of a finding is **not** proof of safety. `SANITIZES` (sanitizer-kill) edges are queryable via `cypher`.\n\n### Control & data dependence (`pdg_query`)\n\n`pdg_query` reads the control/data-dependence layers `gitnexus analyze --pdg` records (CDG + REACHING_DEF, basic-block granular) — the control/data analog of `explain`. It is **always anchored** (a `target` file path or symbol, resolved like `context`) and has two modes:\n\n- `pdg_query { mode: \"controls\", target: \"...\" }` — CDG: \"under what condition does X run?\". Each edge is a controlling predicate block → dependent block with the branch sense (`'T'`/`'F'`) in `reason`; an edge into an early `return`/`throw` is flagged `guard: true` (guard-clause discovery — the sense depends on the predicate, so don't filter guards by a fixed label).\n- `pdg_query { mode: \"flows\", target: \"...\", variable?: \"...\" }` — REACHING_DEF def→use edges within the function; pass `variable` to trace one binding.\n\nA repo indexed without `--pdg` returns a \"no PDG layer\" note (or \"status unknown\" when the layer can't be confirmed). Intra-procedural only — cross-function flow is taint's domain (`explain`). The raw CDG/REACHING_DEF edges are also queryable via `cypher`. See the `gitnexus-pdg-query` skill for the full query surface.\n\n### Shortest path between two symbols (`trace`)\n\n`trace` answers \"how does A reach B?\" in one call — the shortest directed path over `CALLS` (plus `HAS_METHOD`, so a class-rooted trace descends into its methods) instead of chaining 3–8 `context`/`impact` hops by hand.\n\n- `trace { from: \"validateUser\", to: \"executeQuery\" }` — shortest path between two symbols.\n- Disambiguate common names with `from_uid`/`to_uid` (zero-ambiguity) or `from_file`/`to_file`; an ambiguous name returns ranked candidates.\n- `maxDepth` (default 10, max 30) bounds the search; `includeTests` (default false) lets the traversal pass through test-file symbols.\n\nReturns ordered `hops` (each `{ name, filePath, startLine }`) and an aligned `edges[]` of `{ relType, confidence }`, so call hops and containment (`HAS_METHOD`) hops stay distinguishable. When no path exists it reports the **furthest** reachable node (where the chain breaks) and sets `truncated: true` if a traversal cap was hit first. Every result carries a `status`: `ok` / `no_path` / `ambiguous` / `not_found` / `error`.\n\nCross-repo (experimental): pass `repo: \"@groupName\"` to trace across a group's member repos — the path may cross **one** `ContractLink` boundary (reported as a `CONTRACT_LINK` hop with the bridged contract in `crossings[]`). Omit `to` entirely to follow `from`'s outgoing HTTP call to whatever provider endpoint it lands on. Groups are configured via `group_list` / `group_sync`.\n\n## Resources Reference\n\nLightweight reads (~100-500 tokens) for navigation:\n\n| Resource | Content |\n| ---------------------------------------------- | ----------------------------------------- |\n| `gitnexus://repo/{name}/context` | Stats, staleness check |\n| `gitnexus://repo/{name}/clusters` | All functional areas with cohesion scores |\n| `gitnexus://repo/{name}/cluster/{clusterName}` | Area members |\n| `gitnexus://repo/{name}/processes` | All execution flows |\n| `gitnexus://repo/{name}/process/{processName}` | Step-by-step trace |\n| `gitnexus://repo/{name}/schema` | Graph schema for Cypher |\n\n## Graph Schema\n\n**Nodes:** File, Folder, Function, Class, Interface, Method, CodeElement, Community, Process, Route, Tool, plus language-specific types (Struct, Enum, Trait, Impl, Namespace, Module, …) and BasicBlock (`--pdg` indexes only). The full node list lives in `gitnexus://repo/{name}/schema`.\n**Edges (via CodeRelation.type):** CALLS, IMPORTS, EXTENDS, IMPLEMENTS, DEFINES, CONTAINS, MEMBER_OF, HAS_METHOD, HAS_PROPERTY, ACCESSES, METHOD_OVERRIDES, METHOD_IMPLEMENTS, STEP_IN_PROCESS, HANDLES_ROUTE, FETCHES, HANDLES_TOOL, ENTRY_POINT_OF, WRAPS, QUERIES, INJECTS, plus `--pdg`-only types (CFG, REACHING_DEF, TAINTED, SANITIZES, TAINT_PATH, CDG — zero rows on a default index).\n\nRead `gitnexus://repo/{name}/schema` before writing Cypher — it is the authoritative schema for the indexed repo.\n\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"myFunc\"})\nRETURN caller.name, caller.filePath\n```\n","gitnexus-claude-plugin/skills/gitnexus-cli/SKILL.md":"---\nname: gitnexus-cli\ndescription: \"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \\\"Index this repo\\\", \\\"Reanalyze the codebase\\\", \\\"Generate a wiki\\\"\"\n---\n\n# GitNexus CLI Commands\n\nCommands below use `node .gitnexus/run.cjs ` — the project-local runner `gitnexus analyze` drops next to the index. It auto-selects an available runner at call time (global `gitnexus`, else `pnpm dlx`, else `bunx`, else `npx`), so no package-manager assumption and no global install is required — including on a bun-only machine, which has no npm, npx or pnpm at all.\n\n> **Not analyzed yet, or `node .gitnexus/run.cjs` reports `Cannot find module`** (the gitignored runner is absent — e.g. a fresh clone or `git clean`)? (Re)generate it with `npx gitnexus analyze` from the project root, or `bunx gitnexus@latest analyze` on a bun-only machine. On **npm 11.x**, if `npx` crashes during install (`node.target is null`), install once with `npm i -g gitnexus` (then `gitnexus analyze`), or use `bunx gitnexus@latest analyze`, or `pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze`. See [#1939](https://github.com/abhigyanpatwari/GitNexus/issues/1939).\n\n## Commands\n\n### analyze — Build or refresh the index\n\n```bash\nnode .gitnexus/run.cjs analyze\n```\n\nRun from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.\n\n| Flag | Effect |\n| -------------- | ---------------------------------------------------------------- |\n| `--watch` | Keep a Git repository index current with serialized refreshes |\n| `--debounce ` | Watch quiet period before refresh (default: 300 ms) |\n| `--force` | Force full re-index even if up to date |\n| `--embeddings` | Enable embedding generation for semantic search (off by default) |\n| `--drop-embeddings` | Drop existing embeddings on rebuild. By default, an `analyze` without `--embeddings` preserves them. |\n| `--pdg` | Build the program-dependence layers used by `explain` and `pdg_query` (taint, CDG, and REACHING_DEF). |\n| `--spring-actuator ` | Import opt-in Spring Boot Actuator mappings, beans, conditions, configprops, and env snapshots. Forces a full rebuild; unsupported with `--watch`. |\n| `--asyncapi-spec ` | Read opt-in AsyncAPI 3.x documents (directory or single file) and mint `Destination` nodes from their operations. 2.x is refused, not mapped. Unsupported with `--watch`. |\n\n**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook detects staleness after `git commit` and `git merge` and notifies the agent to run `analyze` — the hook does not run analyze itself, to avoid blocking the agent for up to 120s and risking KuzuDB corruption on timeout.\n\nFor Spring runtime enrichment, pass a JSON bundle, one endpoint JSON file, or a directory containing endpoint files. Route evidence is authoritative only when `runtimeConfirmed === true`; `runtimeSource` records provenance and may also accompany `handler-conflict`. Env/configprops values are never persisted.\n\n## Index storage and retention\n\nDefault location is `/.gitnexus/`. Override with environment variables (also documented in README):\n\n| Env | Effect |\n| --- | ------ |\n| `GITNEXUS_STORAGE_PATH` | One complete external index directory. Wins if both storage vars are set. |\n| `GITNEXUS_STORAGE_ROOT` | Absolute root; GitNexus creates an isolated `-<12-hex>/` slot per repository. |\n| `GITNEXUS_CONTENT_RETENTION` | `full` (default) keeps file text; `symbol` keeps snippets; `none` keeps the graph only. |\n\n`list_repos`, `gitnexus://repo/{name}/context`, and HTTP `GET /api/repos` / `GET /api/repo` expose `storagePath`, `contentRetention`, and `sourceAvailable`. HTTP `/api/file` and `/api/grep` return 410 unless retention is `full`. MCP `include_content` may still return symbol spans when retention is `symbol`.\n\nUse `node .gitnexus/run.cjs analyze --watch` for a long-lived local Git repository. It performs an initial analysis, queues scanner-admitted file changes, and retries intact failed batches with bounded backoff. Watch refreshes update only the graph: they skip AGENTS.md / CLAUDE.md injection and standard skill installation, so run a one-shot `analyze` when those generated files need updating. Watch rejects one-shot or context-output flags including `--force`, embedding flags, `--skills`, `--default-branch`, `--skip-agents-md`, `--skip-skills`, `--no-stats`, `--self-commit`, `--index-only`, and `--skip-git`. It never pulls remotes. Scheduled remote clone/pull is a different command: `gitnexus auto-sync`. Bare `gitnexus watch` is reserved and does not start either job. Running MCP and `serve` processes periodically check for a published replacement and reopen it without a restart. MCP checks are throttled to once every five seconds, so a tool call before the next check can briefly use the previous index.\n\n### status — Check index freshness\n\n```bash\nnode .gitnexus/run.cjs status\n```\n\nShows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.\n\n### clean — Delete the index\n\n```bash\nnode .gitnexus/run.cjs clean\n```\n\nDeletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.\n\n| Flag | Effect |\n| --------- | ------------------------------------------------- |\n| `--force` | Skip confirmation prompt |\n| `--all` | Clean all indexed repos, not just the current one |\n\n### wiki — Generate documentation from the graph\n\n```bash\nnode .gitnexus/run.cjs wiki\n```\n\nGenerates repository documentation from the knowledge graph using an LLM. HTTP providers require an API key (saved to `~/.gitnexus/config.json` on first use). Local CLI providers (`--provider cursor|claude|codex|opencode|grok`) use your existing CLI login.\n\n| Flag | Effect |\n| ------------------- | ----------------------------------------- |\n| `--force` | Force full regeneration, also required to re-generate an existing wiki in a different language |\n| `--provider ` | LLM provider: minimax, openai, openrouter, azure, custom, cursor, claude, codex, opencode, or grok (default: minimax). Local CLIs (`cursor`, `claude`, `codex`, `opencode`, `grok`) use your existing CLI login and skip `--api-key`. |\n| `--model ` | LLM model (default: MiniMax-M3) |\n| `--base-url ` | LLM API base URL |\n| `--api-key ` | LLM API key |\n| `--concurrency ` | Parallel LLM calls (default: 3) |\n| `--timeout ` | LLM request timeout in seconds (default: disabled) |\n| `--retries ` | Max LLM retry attempts per request (default: 3) |\n| `--lang ` | Output language for generated documentation (e.g. english, chinese, spanish, japanese) |\n| `--gist` | Publish wiki as a public GitHub Gist |\n\n### list — Show all indexed repos\n\n```bash\nnode .gitnexus/run.cjs list\n```\n\nLists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.\n\n## After Indexing\n\n1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded\n2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task\n\n## Troubleshooting\n\n- **\"Not inside a git repository\"**: Run from a directory inside a git repo\n- **Index is stale after re-analyzing**: Wait for the next MCP tool call to reopen the published index; this normally takes no more than five seconds\n- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding\n",".claude/skills/gitnexus-plan/SKILL.md":"---\nname: gitnexus-plan\ndescription: 'Use when you need a deep, implementation-ready engineering plan for a code change — built from GitNexus graph intelligence, statement-level PDG analysis, and targeted source verification, compact enough that an implementation agent can start without re-investigating. Also strengthens existing plans via Deepen mode. Examples: \"/gitnexus-plan Add retry support to the ingestion pipeline\", \"/gitnexus-plan deepen docs/plans/.md\", \"plan this change using the knowledge graph\".'\n---\n\n# gitnexus-plan — implementation-ready engineering plans\n\nProduce an implementation-ready plan for an engineering task. GitNexus is the\nnavigation layer (where to look), statement-level PDG is the constraint layer\n(what gates and feeds the behavior), and your native targeted source reads are\nthe verification layer (what is actually true right now). The output is a plan\ndocument plus a compact, machine-readable **implementation context pack**\nthat a follow-up implementation agent (`gitnexus-work`, or any executor) can\nconsume without repeating the investigation.\n\n```\n/gitnexus-plan \n/gitnexus-plan impact_depth:3 depth:deep # knob overrides, see Configuration\n```\n\n**This skill plans. It never implements.** Do not modify production code,\ntests, or configuration while running it. The only repository file it writes\nis the plan document (a working ledger kept outside the repo is fine). The\nonly other permitted state change is an index refresh via\n`analyze --index-only`, which writes only the `.gitnexus` index store. It\nmust not build analyzer `dist/` output and must not mutate source, tests,\nconfiguration, or evaluation data. Stale analyzer provenance is disclosed as\na source-weighted limitation, never repaired by a planning run.\n\n## Hard rules\n\n- **Ledger first.** Before every GitNexus call and every repo file read, check\n the context ledger. Never repeat a query or reread an unchanged range that\n already answered the same question (allowed repeats are defined in\n `references/context-ledger.md`; this skill's own reference files are exempt\n from ledger bookkeeping).\n- **Every graph query answers a named planning question.** Record the question\n and the conclusion in the ledger. No exploratory dredging.\n- **Source beats graph.** The graph navigates; current source is authoritative.\n Verify before asserting (see Phase 4). Comments are the weakest evidence —\n never stronger than executable code.\n- **No fabrication.** Never invent symbols, filenames, test names, tool\n results, or PDG edges. Unknowns go to _Assumptions and Open Questions_.\n- **No scope creep.** Adjacent refactors the task didn't ask for go to plan\n §12 as explicitly-deferred follow-ups, not into Proposed Changes.\n- **Pin working-tree evidence, not only HEAD.** Every plan form carries the\n versioned global dirty digest and sorted cited-path manifest defined in\n `references/context-ledger.md`. Generate it only with the portable helper\n and byte contract in `scripts/evidence-provenance.mjs` and\n `references/evidence-provenance.md`; never reimplement the digest.\n- **Write the plan only through the helper.** The generated-plan path is a\n normalized repo-relative\n `docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md` path. Compose the\n complete UTF-8 document in memory or in a scratchpad outside the target\n repo, then pass it on stdin to the helper's `write-plan` command. Never\n write the destination directly or fall back to an external output path when\n the safe writer fails.\n- **Read an existing plan only through the helper.** Deepen must invoke\n `scripts/evidence-provenance.mjs read-plan`, parse the exact decoded\n `plan_bytes_base64` from its descriptor-anchored receipt, and retain that\n receipt's canonical `generated_plan_path` and `plan_digest` as one binding.\n Never parse a direct lexical-path read or apply one plan's digest to another\n path.\n- **Stop when you have enough.** Sufficient evidence ends exploration; plans\n do not improve monotonically with tokens spent.\n\n## Phase 0 — Parse and classify\n\nRead `references/context-ledger.md` and open the ledger with the task:\noriginal request, interpreted goal, acceptance criteria. Classify the task:\n\n| Category | Posture (depth · plan form · tool-call budget · freshness) |\n| ------------------------------ | -------------------------------------------------------------------------------- |\n| Bug fix (local) | Narrow, 1–2 primary symbols, `impact_depth` 1 · compact · ~15 · accept |\n| Feature | Default knobs · compact · ~30 · accept |\n| Refactor / shared API change | Impact mandatory, `impact_depth` 3 · full · ~45 · strict |\n| Performance | Default + performance PDG mode (`references/pdg-slice.md`) · full · ~45 · strict |\n| Security | Default + security PDG mode + `explain` taint findings · full · ~45 · strict |\n| Dependency upgrade / migration | Impact + compatibility focus; PDG rarely needed · compact · ~20 · accept |\n| Concurrency / transactional | Control-flow + state-mutation PDG focus · full · ~45 · strict |\n| Test improvement / docs | Narrowest: usually no impact or PDG pass · compact · ~10 · accept |\n| Architecture change / spike | Widest: clusters + processes first · full · no cap · strict |\n\nThe category posture overrides the Configuration baseline; explicit `key:value`\ninvocation knobs override both. A task matching several rows combines them:\ntake the widest depth, union the focus areas.\n\n**Seeded evidence.** When a completed investigation already supplies\nverified findings — a finished review, a triage document with `path:line`\nanchors and named failing scenarios — open the ledger FROM it: cite the\nsource document as the opening ledger entries and plan directly against\nthem instead of re-running the graph ladder over ground it already covers.\nRe-deriving what the evidence proves is budget spent against the\nturn-economy rule. Phase 4 still source-verifies whatever Proposed Changes\nwill cite, at the pinned commit — seeding replaces exploration, never\nverification.\n\n**Depth is the user's decision, asked once, up front.** In an interactive\nsession, when the invocation carries no explicit depth signal (no `depth:`,\n`form:`, or `freshness:` knob, and not Deepen mode), ask one blocking\nquestion before Phase 1 — how deep should this plan go?\n\n1. **Quick** — `depth:narrow form:compact freshness:accept`. Fastest useful\n plan: 1–2 primary symbols, minimal graph work, core sections only.\n2. **Standard** — the category posture above, unchanged. Recommend this\n unless the classification argues otherwise.\n3. **Deep** — `depth:deep form:full freshness:strict`. All 13 sections,\n `impact_depth` 3, clusters/processes read, PDG slices for the central\n functions.\n\nThe answer sets the knobs exactly as if they had been typed in the\ninvocation; explicit knobs win and skip the question. Headless runs never\nask — the category posture applies unchanged. Asking up front replaces\noffering to deepen a finished plan afterwards: Deepen mode (below) remains\nthe mechanism for strengthening an existing plan document — a later session,\nreview findings, an executor route-back — not a default follow-up question.\n\n**Turn economy is a deliverable.** The plan is judged on decision quality per\ntoken, not thoroughness theater (measured: a 63-turn plan for a two-line\nchange — the GitNexus repo's `eval/workflow_bench/`). Stay within the category's tool-call\nbudget; when the budget runs out with questions still open, record them in\n§12 instead of digging further — the executor re-verifies cheaply anyway.\n\n## Phase 1 — Anchor and freshness\n\n1. Resolve the target repo: `list_repos` if in doubt, else the indexed repo\n covering the working directory. Pass `repo` explicitly on every call when\n more than one repo is indexed.\n2. Record the repo's current HEAD commit in the ledger — every line-number\n citation in the plan is pinned to it.\n3. **Resolve and record the analyzer runner** (used by every `analyze`\n command in this skill): `node .gitnexus/run.cjs analyze …` when the\n project has a runner (a previous analyze dropped it next to the index),\n else `gitnexus analyze …` (installed CLI — `npm install -g gitnexus`),\n else `npx gitnexus analyze …`. Record its path/version and any available\n source/build identity; do not manufacture provenance from timestamps.\n4. Read `gitnexus://repo/{name}/context` — codebase overview + staleness check.\n **Freshness gate.** Plans built on a stale graph make stale blast-radius\n claims — but a re-index is the largest fixed cost a planning session\n carries, so the gate is category-priced:\n - Compact-plan categories default to `freshness: accept`: plan on the\n current graph with source verification weighted higher — their plans\n cite little graph evidence. Escalate to a refresh mid-plan only when a\n graph claim becomes load-bearing (e.g. Proposed Changes rest on a d=1\n dependent list), and only then.\n - Full-plan categories default to `freshness: strict`, and under it:\n - **Analyzer provenance check — before any refresh.** Compare the resolved\n runner identity with the index metadata and, in an analyzer-source\n checkout, with current analyzer source. If identity is stale or unknown,\n do not build output and do not make that graph load-bearing. Record a\n **stale analyzer provenance — source-weighted limitation** in\n `index_refresh`, the plan header, and §12; rely on targeted source reads\n or hand execution to `gitnexus-work`, which owns the build-current gate.\n - Stale index → run `analyze --index-only` via the resolved runner\n (append `--pdg` when the task category will reach Phase 3) and re-read\n the context resource **only when runner provenance is known-current**.\n Refresh budget, stated once here: at most one `--index-only` refresh in\n Phase 1 **plus** at most one later `--pdg` upgrade in Phase 3 (only when\n Phase 1's refresh lacked `--pdg`) per planning session — a Deepen run is\n its own session. Record each command, runner identity, and outcome in the\n ledger's `index_refresh`.\n - Refresh failed or impractical (no write access to the index, prohibitive\n repo size), or `freshness: accept` was passed → proceed on the stale\n graph, weight source verification higher, and state the staleness and\n the skipped refresh in the plan header and Assumptions.\n - Resources unreadable but tools working → proceed on tools alone, treat\n freshness as unknown (weight source higher), and note it in the plan.\n - GitNexus unavailable entirely → switch to **Fallback mode** (below).\n5. For architecture-scale tasks only, also read\n `gitnexus://repo/{name}/clusters` and `.../processes`.\n\n## Phase 2 — Graph navigation ladder\n\nUse the narrowest operation that answers the current ledger question, in this\norder. Budgets: at most `max_primary_symbols` (5) primary symbols and\n`max_related_symbols` (20) related symbols active in the ledger.\n\n1. `query {search_query, task_context}` — locate concepts, execution flows,\n modules, and related tests for the task.\n2. `context {name}` — 360° view of each candidate primary symbol: callers,\n callees, categorized refs, processes. Promote to primary or discard. An\n `ambiguous` result (ranked candidates) is answered by one retry narrowed\n with `kind` / `file_path` / uid — that retry is an allowed repeat.\n3. `impact {target, direction}` — upstream/downstream blast radius for shared\n or high-connectivity symbols (`maxDepth` = `impact_depth`; `summaryOnly:\ntrue` first for hub symbols, then drill in — an allowed repeat). Record the\n d=1 items — the **direct (depth-1) dependents** — the plan must account\n for every one of them.\n4. `trace {from, to}` — when the task hinges on _how A reaches B_, one call\n instead of chained context hops.\n5. Statement-level PDG — Phase 3, for the functions the change centers on.\n6. `cypher` — last resort, only for a precise graph question the tools above\n cannot express. Read `gitnexus://repo/{name}/schema` first; anchor and\n LIMIT every query.\n7. `detect_changes {scope}` — only when planning against existing uncommitted\n or branch work.\n\nDo not run every tool by default. A local test fix may finish the ladder at\nstep 2.\n\n## Phase 3 — Statement-level PDG slice\n\nFor the 1–3 functions most central to the change, build a bounded **PDG\ncontext slice**. Read `references/pdg-slice.md` and follow it — it owns the\ntool calls, inclusion criteria, depth bounds, slice schema, the security and\nperformance modes, and the no-PDG-layer fallback.\n\n## Phase 4 — Targeted source verification\n\nGitNexus said where to look; now confirm what is there. Using ordinary file\nreads (exact line ranges, not whole files unless genuinely required):\n\n- Read every source range the plan will cite: signatures, branch conditions,\n state mutations, error paths, nearby comments that change behavior. Compact\n plans cite less — verify what they cite, don't expand the citation set to\n have more to verify.\n- Read the tests GitNexus associated with the primary symbols; never claim a\n test exists without having located it.\n- Verify the build/test commands the plan will name actually exist\n (package.json scripts / CI workflows), and prefer the script form that\n carries its prerequisites (pre-hooks) over invoking underlying binaries\n directly.\n- Check repo conventions that constrain the change (AGENTS.md, GUARDRAILS.md,\n lint/build config) — only the parts the change touches.\n- Mark each ledger symbol `source_verified: true` as you go. **A symbol that\n is named in Proposed Changes must be source-verified.**\n- On graph/source disagreement: trust source, record the discrepancy in the\n ledger and the plan, recommend re-indexing. Never present stale graph data\n as fact.\n- Immediately before composition, recompute the versioned\n `evidence_provenance` snapshot by invoking\n `scripts/evidence-provenance.mjs` exactly as specified in\n `references/evidence-provenance.md`: the\n canonical global dirty digest over all dirty paths and the sorted manifest\n of every cited path, including object kind and\n HEAD/index/worktree/untracked layer digests. Re-read any citation that\n changed during planning. Exclude only the generated plan path.\n\nEvidence hierarchy, strongest first: current source and config → current tests\nand executable behavior → compiler/build/lint output → GitNexus graph and PDG\n→ documentation and comments.\n\n## Phase 5 — Compose the plan\n\n1. Read `references/plan-template.md` and fill the category's form — compact\n (core sections, ≤80 lines excluding the pack) or full (all 13 sections) —\n from the ledger, tagging claims with the template's four classes —\n `[verified]`, `[graph]`, `[inferred]`, `[assumed]` — and routing open\n questions to §12.\n2. Build the implementation context pack per `references/context-pack.md`\n (this is section 11 of the plan), including mandatory\n `evidence_provenance` in compact and full forms.\n3. Set `generated_plan_path` to\n `docs/plans/YYYY-MM-DD-gitnexus-plan-.md` under the root of the repo\n being planned (the Phase 1 target repo, not necessarily the cwd); use a\n 3–5-word kebab-case slug and repo-relative paths inside the document.\n Compose the complete document without creating that destination, then\n pipe its exact UTF-8 bytes to `scripts/evidence-provenance.mjs write-plan`\n as specified in `references/evidence-provenance.md`. The helper safely\n creates missing parent directories. Initial planning must not pass\n `--replace`. A safe-write failure blocks plan publication: report it and\n do not write directly, choose an external destination, or weaken the\n repo-relative provenance contract. The snapshot and writer commands apply\n the same strict generated-plan filename/date validator; do not substitute a\n source, `.git`, or arbitrary `docs/plans/` path in either invocation.\n4. Present in chat: objective, proposed-changes summary, implementation\n sequence, top risks, open questions, and the plan file path. Do not paste\n the whole document into chat.\n\n## Deepen mode\n\n`/gitnexus-plan deepen ` strengthens an existing plan in place\ninstead of creating a new one:\n\n1. Resolve the target repository and normalized repo-relative plan candidate,\n then load it with `scripts/evidence-provenance.mjs read-plan --repo \n--generated-plan ` exactly as specified in\n `references/evidence-provenance.md`. Reject a missing, external, escaping,\n symlinked, or differently scoped path. Decode and parse only the receipt's\n exact `plan_bytes_base64`; retain its canonical `generated_plan_path` and\n `plan_digest` unchanged for the entire Deepen session.\n2. Re-run Phase 1 in full — analyzer provenance check and freshness gate (a\n Deepen run is its own session, with its own refresh budget).\n3. **Re-anchor before re-pinning.** Recompute the plan's global dirty digest\n and cited-path manifest as well as comparing its old HEAD pin with current\n HEAD. Changed, renamed, deleted, mixed, or newly absent cited paths get\n their ranges re-read — or the claim downgraded — _before_ the pin and\n provenance snapshot move. Moving only the commit pin silently launders\n dirty or stale claims as verified.\n4. Escalate to `depth: deep` (impact_depth 3, clusters/processes read)\n unless the invocation overrides knobs explicitly.\n5. Seed the ledger from the plan's §11 pack, then re-verify: every\n `[graph]`/`[inferred]` claim gets a targeted pass toward `[verified]`;\n every `[assumed]` claim is resolved or kept with its reason; direct\n (d=1) dependent accounting is re-checked against the refreshed graph;\n PDG slices are built or expanded for the central functions when the\n layer is present.\n6. **Reconcile execution state.** If `gitnexus-work` already landed commits\n for this plan (a mid-execution route-back), mark the §7 steps present at\n HEAD as completed and re-sequence the remainder — the rewritten plan must\n be executable from the top without redoing landed steps.\n7. Strengthen whatever the deeper pass showed thin — test scenarios, risks,\n Definition of Done — and carry claim-tag upgrades through the prose.\n8. Rewrite the **same canonical file** through\n `scripts/evidence-provenance.mjs write-plan --replace\n--expected-plan-path \n--expected-plan-digest `: same 13 sections,\n context pack kept in sync, evidence header updated. `--replace` is reserved\n for Deepen mode, and both expected values must come from the same read-plan\n receipt; any digest/path mismatch blocks publication. Retain the successful receipt's\n `prior_plan_backup_git_path`; it names the verified Git-admin backup of the\n displaced plan. Summarize the delta in chat: claims upgraded, claims that\n failed re-verification, sections changed, and that backup path.\n\n## Configuration\n\nBaseline defaults — the Phase 0 category posture overrides them, and inline\n`key:value` tokens before the task text override both (the repo has no\nskill-config file mechanism; invocation args are the mechanism):\n\n| Knob | Default | Meaning |\n| --------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `depth` | by category | `narrow` = `impact_depth` 1, PDG only if one function is clearly central; `default` = this table; `deep` = `impact_depth` 3 + clusters/processes read |\n| `form` | by category | `compact` (core sections + mini-pack, ≤80 lines excl. pack — see `references/plan-template.md`) or `full` (all 13 sections) |\n| `impact_depth` | 2 | `maxDepth` for `impact` |\n| `pdg_data_depth` | 2 | Data-dependence hops in the PDG slice |\n| `pdg_control_depth` | 2 | Control-dependence hops in the PDG slice |\n| `max_primary_symbols` | 5 | Ledger budget (active symbols; discards don't count) |\n| `max_related_symbols` | 20 | Ledger budget (active symbols; discards don't count) |\n| `max_snippet_lines` | 30 | Longest source excerpt quoted in the plan |\n| `freshness` | by category | `strict` (full-plan categories) = refresh a stale index (and a missing PDG layer) with `analyze --index-only [--pdg]` before relying on the graph; `accept` (compact categories) = plan on the current graph, source-weighted and labelled, refreshing only if a graph claim becomes load-bearing |\n\n## Fallback mode (GitNexus or PDG unavailable)\n\n1. Say so, first thing, in chat and in the plan.\n2. Use targeted repo exploration (grep/glob/reads) to approximate callers,\n dependencies, execution flow, state changes, and related tests.\n3. Label every such finding **source-derived** in the plan — never present it\n as graph-derived, and never fabricate statement-level edges.\n4. Recommend `analyze --index-only` (add `--pdg` for the PDG layers) via\n the resolved runner — `node .gitnexus/run.cjs`, installed `gitnexus`, or\n `npx gitnexus` — when it would materially raise confidence.\n\n## Skill feedback\n\nIf this run exposed friction in the instructions, include concise feedback in\nthe final response. Feedback is chat-only: do not append evaluation learnings,\nedit benchmark data, or modify this skill during a live planning task.\n",".claude/skills/gitnexus-pr-swarm-review/SKILL.md":"---\nname: gitnexus-pr-swarm-review\ndescription: \"Run a GitNexus production-readiness pull request review using a coordinated reviewer swarm.\"\n---\n\n# GitNexus PR Swarm Review (Claude Code adapter)\n\nUse this skill to review a GitNexus pull request and produce a production-readiness review.\n\n> This is the interactive, on-demand reviewer swarm. It is distinct from the CI\n> `gitnexus-review` skill's built-in \"Swarm lanes\" (`ci-personas/`), which the\n> review-agent workflow dispatches automatically inside a single review run.\n\n```\n/gitnexus-pr-swarm-review \n```\n\nYou are the **swarm coordinator**. The full review contract — lanes, dependencies,\nclassifications, output structure, finding format, hidden-Unicode checks, and behavior\nrules — is the canonical, CLI-neutral spec:\n\n**`pr-swarm-review/orchestration.md`** — read it now and follow it.\n\nThis adapter only pins the Claude Code specifics:\n\n- **Run in Swarm mode.** Dispatch each lane as its own subagent via the Agent tool. The\n seven subagents are the project agents named `gitnexus-*` (one per persona); each reads\n its canonical persona under `pr-swarm-review/personas/`. Run lanes 1–2 first, lanes 3–6\n in parallel after, and lane 7 last on the draft.\n- **Lane 7 is a hard gate.** Do not emit the final review while the synthesis critic's\n \"Required corrections before posting\" section is non-empty — revise and re-run it.\n- Stay **read-only**: investigate and report; never edit, commit, or post.\n\nDo not flatten the review into a generic checklist; delegate to the subagents and\nsynthesize per `orchestration.md`.\n","gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md":"# gitnexus-debugging\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md":"# gitnexus-exploring\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md":"# gitnexus-guide\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md":"# gitnexus-impact-analysis\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md":"# gitnexus-lfg\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md":"# gitnexus-pdg-query\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md":"# gitnexus-plan\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md":"# gitnexus-refactoring\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md":"# gitnexus-review\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md":"# gitnexus-taint-analysis\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md":"# gitnexus-work\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md":"# gitnexus-debugging\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md":"# gitnexus-exploring\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md":"# gitnexus-impact-analysis\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md":"# gitnexus-refactoring\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md":"# gitnexus-review\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md)","gitnexus/skills/gitnexus-lfg/SKILL.md":"# gitnexus-lfg\n\nPath: `gitnexus/skills/gitnexus-lfg/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-lfg/SKILL.md)","gitnexus/skills/gitnexus-plan/SKILL.md":"# gitnexus-plan\n\nPath: `gitnexus/skills/gitnexus-plan/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/SKILL.md)","gitnexus/skills/gitnexus-review/SKILL.md":"# gitnexus-review\n\nPath: `gitnexus/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/SKILL.md)","gitnexus/skills/gitnexus-work/SKILL.md":"# gitnexus-work\n\nPath: `gitnexus/skills/gitnexus-work/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/SKILL.md)",".claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md":"# gitnexus-pdg-query\n\nPath: `.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md)",".claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md":"# gitnexus-taint-analysis\n\nPath: `.claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md)",".cursorrules":"# Cursor IDE Native Rules\n\nPath: `.cursorrules`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursorrules)",".windsurfrules":"# Windsurf Cascade Agent Rules\n\nPath: `.windsurfrules`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.windsurfrules)","AGENTS.md":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/AGENTS.md)","ARCHITECTURE.md":"# System Architecture & Module Boundaries\n\nPath: `ARCHITECTURE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/ARCHITECTURE.md)","CLAUDE.md":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/CLAUDE.md)","llms.txt":"# LLM Index & Context Digest\n\nPath: `llms.txt`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/llms.txt)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude-plugin/marketplace.json)",".factory-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.factory-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.factory-plugin/marketplace.json)","gitnexus-factory-plugin/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `gitnexus-factory-plugin/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-factory-plugin/mcp.json)",".agents/plugins/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.agents/plugins/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.agents/plugins/marketplace.json)",".claude/agents/gitnexus-branch-hygiene-reviewer.md":"# Subagent: gitnexus-branch-hygiene-reviewer\n\nPath: `.claude/agents/gitnexus-branch-hygiene-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-branch-hygiene-reviewer.md)",".claude/agents/gitnexus-docs-dod-reviewer.md":"# Subagent: gitnexus-docs-dod-reviewer\n\nPath: `.claude/agents/gitnexus-docs-dod-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-docs-dod-reviewer.md)",".claude/agents/gitnexus-pr-facts-historian.md":"# Subagent: gitnexus-pr-facts-historian\n\nPath: `.claude/agents/gitnexus-pr-facts-historian.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-pr-facts-historian.md)",".claude/agents/gitnexus-risk-architect.md":"# Subagent: gitnexus-risk-architect\n\nPath: `.claude/agents/gitnexus-risk-architect.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-risk-architect.md)",".claude/agents/gitnexus-security-boundary-reviewer.md":"# Subagent: gitnexus-security-boundary-reviewer\n\nPath: `.claude/agents/gitnexus-security-boundary-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-security-boundary-reviewer.md)",".claude/agents/gitnexus-synthesis-critic.md":"# Subagent: gitnexus-synthesis-critic\n\nPath: `.claude/agents/gitnexus-synthesis-critic.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-synthesis-critic.md)",".claude/agents/gitnexus-test-ci-verifier.md":"# Subagent: gitnexus-test-ci-verifier\n\nPath: `.claude/agents/gitnexus-test-ci-verifier.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-test-ci-verifier.md)",".cursor/commands/gitnexus-pr-swarm-review.md":"# Command: /gitnexus-pr-swarm-review\n\nPath: `.cursor/commands/gitnexus-pr-swarm-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/commands/gitnexus-pr-swarm-review.md)",".cursor/rules/100-monorepo.mdc":"# Cursor Rule: 100-monorepo\n\nPath: `.cursor/rules/100-monorepo.mdc`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/rules/100-monorepo.mdc)",".cursor/rules/200-eval.mdc":"# Cursor Rule: 200-eval\n\nPath: `.cursor/rules/200-eval.mdc`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/rules/200-eval.mdc)","gitnexus-claude-plugin/.claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `gitnexus-claude-plugin/.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/.claude-plugin/plugin.json)","gitnexus-claude-plugin/.codex-plugin/plugin.json":"# codex-plugin Plugin Manifest\n\nPath: `gitnexus-claude-plugin/.codex-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/.codex-plugin/plugin.json)","gitnexus-factory-plugin/.factory-plugin/plugin.json":"# factory-plugin Plugin Manifest\n\nPath: `gitnexus-factory-plugin/.factory-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-factory-plugin/.factory-plugin/plugin.json)","gitnexus/skills/gitnexus-cli.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-cli.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-cli.md)","gitnexus/skills/gitnexus-debugging.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-debugging.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-debugging.md)","gitnexus/skills/gitnexus-exploring.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-exploring.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-exploring.md)","gitnexus/skills/gitnexus-guide.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-guide.md)","gitnexus/skills/gitnexus-impact-analysis.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-impact-analysis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-impact-analysis.md)","gitnexus/skills/gitnexus-pdg-query.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-pdg-query.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-pdg-query.md)","gitnexus/skills/gitnexus-refactoring.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-refactoring.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-refactoring.md)","gitnexus/skills/gitnexus-taint-analysis.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-taint-analysis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-taint-analysis.md)",".claude/skills/gitnexus-lfg/README.md":"# Gitnexus-lfg Skill\n\nPath: `.claude/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-lfg/README.md)",".claude/skills/gitnexus-plan/README.md":"# Gitnexus-plan Skill\n\nPath: `.claude/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/README.md)",".claude/skills/gitnexus-work/README.md":"# Gitnexus-work Skill\n\nPath: `.claude/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/README.md)","gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json":"# Gitnexus-cli Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json":"# Gitnexus-debugging Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json":"# Gitnexus-exploring Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json":"# Gitnexus-guide Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json":"# Gitnexus-impact-analysis Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-lfg/README.md":"# Gitnexus-lfg Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/README.md)","gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json":"# Gitnexus-lfg Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-plan/README.md":"# Gitnexus-plan Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/README.md)","gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json":"# Gitnexus-plan Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json":"# Gitnexus-refactoring Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-review/mcp.json":"# Gitnexus-review Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-work/README.md":"# Gitnexus-work Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/README.md)","gitnexus-claude-plugin/skills/gitnexus-work/mcp.json":"# Gitnexus-work Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/mcp.json)","gitnexus/skills/gitnexus-lfg/README.md":"# Gitnexus-lfg Skill\n\nPath: `gitnexus/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-lfg/README.md)","gitnexus/skills/gitnexus-plan/README.md":"# Gitnexus-plan Skill\n\nPath: `gitnexus/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/README.md)","gitnexus/skills/gitnexus-work/README.md":"# Gitnexus-work Skill\n\nPath: `gitnexus/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/README.md)",".claude/skills/gitnexus-plan/references/context-ledger.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-ledger.md)",".claude/skills/gitnexus-plan/references/context-pack.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-pack.md)",".claude/skills/gitnexus-plan/references/evidence-provenance.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/evidence-provenance.md)",".claude/skills/gitnexus-plan/references/pdg-slice.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/pdg-slice.md)",".claude/skills/gitnexus-plan/references/plan-template.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/plan-template.md)",".claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs":"# Claude Directive: evidence-provenance.mjs\n\nPath: `.claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs)",".claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-security-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md)",".claude/skills/gitnexus-work/references/evidence-provenance.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/references/evidence-provenance.md)",".claude/skills/gitnexus-work/scripts/evidence-provenance.mjs":"# Claude Directive: evidence-provenance.mjs\n\nPath: `.claude/skills/gitnexus-work/scripts/evidence-provenance.mjs`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/scripts/evidence-provenance.mjs)","gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md)","gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md)","gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md)","gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md)","gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md)","gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md)","gitnexus/skills/gitnexus-plan/references/context-ledger.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/context-ledger.md)","gitnexus/skills/gitnexus-plan/references/context-pack.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/context-pack.md)","gitnexus/skills/gitnexus-plan/references/evidence-provenance.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/evidence-provenance.md)","gitnexus/skills/gitnexus-plan/references/pdg-slice.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/pdg-slice.md)","gitnexus/skills/gitnexus-plan/references/plan-template.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/plan-template.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md)","gitnexus/skills/gitnexus-work/references/evidence-provenance.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/references/evidence-provenance.md)","gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml":"# Data Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml)","gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json":"# Barrel Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json)","gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json":"# Http Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json)","gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json":"# Inner Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json)","gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json":"# Utils Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json)"},"files":{".claude/skills/gitnexus-impact-analysis/SKILL.md":"---\nname: gitnexus-impact-analysis\ndescription: \"Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: \\\"Is it safe to change X?\\\", \\\"What depends on this?\\\", \\\"What will break?\\\"\"\n---\n\n# Impact Analysis with GitNexus\n\n## When to Use\n\n- \"Is it safe to change this function?\"\n- \"What will break if I modify X?\"\n- \"Show me the blast radius\"\n- \"Who uses this code?\"\n- Before making non-trivial code changes\n- Before committing — to understand what your changes affect\n\n## Bind the repository first\n\nImpact analysis is the gate that authorizes an edit, so it must answer for the\nrepository you are about to edit.\n\nCall `list_repos {}` before the first tool call. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask — every result below an ambiguous\nidentity inherits the ambiguity. `list_repos` is paginated, so page with\n`offset: pagination.nextOffset` until `hasMore` is false before concluding a\nrepository is absent.\n\n`detect_changes` takes `worktree` when your changes are in a linked worktree\nthe MCP server was not launched from. The server auto-detects a worktree only\nwhen it was launched from inside one; otherwise `git diff` runs in the wrong\ncheckout and reports zero changed symbols — a false clean check that carries\nnone of the degradation flags described below. In the CLI fallbacks, `--repo .`\nmeans the current checkout; pass the intended repository path instead when you\nare not standing in it.\n\nState the bound identity with your risk report:\n\n```\nRepository: () Worktree: Index: , behind HEAD\n```\n\n## Workflow\n\n```\n0. list_repos {} → Bind repo (and worktree)\n1. impact({target: \"X\", direction: \"upstream\"}) or `node .gitnexus/run.cjs impact \"X\" --direction upstream --repo .`\n2. READ gitnexus://repo/{name}/processes → Check affected execution flows\n3. detect_changes({scope: \"all\"}) or `node .gitnexus/run.cjs detect-changes --scope all --repo .`\n4. Assess risk and report to user, echoing repo/worktree/index identity\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n> If `.gitnexus/run.cjs` is missing, replace `node .gitnexus/run.cjs` with `npx gitnexus` in the fallback commands.\n\n## Checklist\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] impact({target, direction: \"upstream\"}) or CLI fallback to find dependents\n- [ ] Review d=1 items first (these WILL BREAK)\n- [ ] Check high-confidence (>0.8) dependencies\n- [ ] READ processes to check affected execution flows\n- [ ] detect_changes({scope: \"all\"}) or CLI fallback for pre-commit check\n- [ ] Confirm the checkout you edited is the checkout that was diffed\n- [ ] Assess risk level and report, stating repo/worktree/index identity\n```\n\n## Understanding Output\n\n| Depth | Risk Level | Meaning |\n| ----- | ---------------- | ------------------------ |\n| d=1 | **WILL BREAK** | Direct callers/importers |\n| d=2 | LIKELY AFFECTED | Indirect dependencies |\n| d=3 | MAY NEED TESTING | Transitive effects |\n\n## Risk Assessment\n\n| Affected | Risk |\n| ------------------------------ | -------- |\n| <5 symbols, few processes | LOW |\n| 5-15 symbols, 2-5 processes | MEDIUM |\n| >15 symbols or many processes | HIGH |\n| Critical path (auth, payments) | CRITICAL |\n| **Zero callers found** | **UNKNOWN** |\n\n`UNKNOWN` is not a low rung on this scale — it means the walk could not answer.\nAn empty caller set is equally consistent with \"genuinely unused\" and \"the\ncallers are not resolvable by the index\" (plain-object property access, dynamic\ndispatch, cross-language calls), so few-callers ⇒ LOW does **not** apply. The\nresult carries a `riskNote` saying so. Confirm with a text search before\ntreating the symbol as safe to change or delete.\n\n`risk` is the edit gate: warn on HIGH/CRITICAL and stop on UNKNOWN until the\nuncertainty is resolved. Within single-repo mode, compare File and symbol\ntargets with local `riskSharedAxes` (direct/total only). Within group mode,\ncompare only group results: their `riskSharedAxes` overlays resolved\ncross-repo crossings on that local value. Never use either field to waive the\nedit gate. Check `riskScale.unusedAxes` before comparing kinds: MCP File walks\nomit process/module axes, while web Graph-RAG expands File targets to in-file\nsymbols before enrichment.\n\n## Tools\n\n**impact** — the primary tool for symbol blast radius. If MCP is unavailable, use `node .gitnexus/run.cjs impact --direction upstream --repo .` instead:\n\n```\nimpact({\n target: \"validateUser\",\n repo: \"my-app\", // required once >1 repository is indexed\n direction: \"upstream\",\n minConfidence: 0.8,\n maxDepth: 3\n})\n\n→ d=1 (WILL BREAK):\n - loginHandler (src/auth/login.ts:42) [CALLS, 100%]\n - apiMiddleware (src/api/middleware.ts:15) [CALLS, 100%]\n\n→ d=2 (LIKELY AFFECTED):\n - authRouter (src/routes/auth.ts:22) [CALLS, 95%]\n```\n\n**detect_changes** — git-diff based impact analysis. If MCP is unavailable, use `node .gitnexus/run.cjs detect-changes --scope all --repo .` instead:\n\n```\ndetect_changes({scope: \"all\"})\n\n→ Changed: 5 symbols in 3 files\n→ Affected: LoginFlow, TokenRefresh, APIMiddlewarePipeline\n→ Risk: MEDIUM\n```\n\nAdd `repo` once more than one repository is indexed, and `worktree: \"\"` when your changes are in a linked worktree the server was not launched\nfrom.\n\n`partial: true` (a graph query failed) or `truncated: true` (the changed-symbol\nlisting was capped) means the result is short of the truth, and reads like\n`UNKNOWN` above: a zero there means unseen, not unaffected. Re-run it rather\nthan tick the pre-commit check.\n\nA wrong-worktree zero carries neither flag and is shape-identical to a genuine\nclean result, so confirm the checkout you edited is the one that was diffed\nbefore treating an empty change set as a passed check.\n\n## Example: \"What breaks if I change validateUser?\"\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly\n\n1. impact({target: \"validateUser\", repo: \"my-app\", direction: \"upstream\"}) or `node .gitnexus/run.cjs impact \"validateUser\" --direction upstream --repo .`\n → d=1: loginHandler, apiMiddleware (WILL BREAK)\n → d=2: authRouter, sessionManager (LIKELY AFFECTED)\n\n2. READ gitnexus://repo/my-app/processes\n → LoginFlow and TokenRefresh touch validateUser\n\n3. Risk: 2 direct callers, 2 processes = MEDIUM\n Repository: my-app (/abs/path/my-app) Worktree: same Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n",".claude/skills/gitnexus-lfg/SKILL.md":"---\nname: gitnexus-lfg\ndescription: \"Use when the user wants the GitNexus engineering pipeline run end-to-end on a task: gitnexus-plan (plan depth chosen up front), a blocking gate to execute with gitnexus-work or stop, finishing with a gitnexus-review of the result. Examples: \\\"/gitnexus-lfg Add retry support to the ingestion pipeline\\\", \\\"run the gitnexus pipeline on this\\\", \\\"plan, build and review this feature\\\".\"\n---\n\n# gitnexus-lfg — plan → gate → work → review\n\nThin orchestrator over three existing skills. It adds no engineering logic of\nits own — it sequences `gitnexus-plan`, `gitnexus-work`, and\n`gitnexus-review`, with the user deciding at the plan gate. Run every lane\nby actually invoking the named skill (read its SKILL.md and follow it);\nnever inline a summary of what the skill would have done.\n\n```\n/gitnexus-lfg \n/gitnexus-lfg docs/plans/.md # skip lane 1, start at the gate\n```\n\n## Lane 1 — Plan\n\n**Boundary triage first.** If the task is plainly below the planning\nboundary — trivial or small-bounded work an agent finishes in well under ~35\nturns (the measured regime where a planning pass costs more than it returns;\nmeasured in the GitNexus repository's `eval/workflow_bench/`) — say so and\noffer `gitnexus-work` direct mode as an alternative to the full pipeline\nbefore spending the plan lane. Honor the user's choice.\n\nThe threshold is a promoted benchmark policy measured offline, not a\ntimeless heuristic — never self-edit it from a live task. Its re-evaluation\ngovernance lives in this skill's README.\n\nOtherwise invoke `gitnexus-plan` with the task (knob overrides pass through\nverbatim; `gitnexus-plan` owns the up-front depth question — never ask it\nagain here). If the input is already a plan file path, skip to Lane 2. The\nplan lands in `docs/plans/` — record its path; every later lane consumes it.\n\n## Lane 2 — The plan gate (user choice, blocking)\n\nPresent the plan's chat summary (objective, proposed changes, sequence, top\nrisks, open questions, plan path), then ask the user — as a blocking\nquestion (`AskUserQuestion` in Claude Code; a numbered list in chat on CLIs\nwithout a blocking tool):\n\n1. **Proceed to work** — continue to Lane 3.\n2. **Stop here** — the plan file is the deliverable; end the pipeline.\n\nDepth was the user's up-front choice in Lane 1, so deepening is not offered\nby default — but honor an explicit request for it at the gate: run\n`gitnexus-plan` Deepen mode on the plan file and return here with the\nstrengthened plan, as many times as the user asks. Do not proceed past the\ngate without an explicit choice — the gate is the pipeline's only checkpoint\nand exists precisely because execution is expensive to unwind.\n\n**Headless / non-interactive runs:** no one can answer the gate, so end the\npipeline after Lane 1 — the plan file is the deliverable (gate option 2) —\nand say so in the final report. Never auto-proceed to execution.\n\n## Lane 3 — Work\n\nInvoke `gitnexus-work` with the plan path. It re-anchors the plan at HEAD,\nexecutes the Implementation Sequence as verified atomic commits, refreshes\nthe knowledge graph when done (its Phase 4), and reports deviations. If it routes back for re-planning (structural drift), run the\nDeepen pass and return to the Lane 2 gate rather than pushing through.\n\n## Lane 4 — Review\n\nInvoke `gitnexus-review` on the completed work. Pass an open PR URL/number\nwhen one exists; otherwise pass the current branch. The review skill owns\ntarget resolution, exact-SHA checkout/index alignment, and merge-base\nselection. Do not duplicate that logic here. If work left local changes,\npass `local` as a second, separately labeled review surface.\n\nSurface the review verdict and findings to the user. Findings the user\nwants fixed: those within `gitnexus-work`'s direct-mode bounds (1–2 files,\nno architectural decisions) → hand to `gitnexus-work` direct mode; anything\nlarger → offer the plan gate instead (Deepen the plan with the findings, or\nstop). Then re-run this lane's review once. On that re-run, do not start\nanother fix cycle even if findings remain — report them and point the user\nat `/gitnexus-work` (or the plan gate) to continue deliberately.\n\n## Final report\n\nOne message: plan path, deepen cycles run, commits produced, verification\nstatus, review verdict with unresolved findings, and what (if anything) was\nexplicitly left undone. The pipeline does not push or open a PR on its own —\noffer both as next steps.\n",".claude/skills/gitnexus-review/SKILL.md":"---\nname: gitnexus-review\ndescription: 'Review code changes with GitNexus from a GitHub PR URL or number, a branch/ref or commit range, or local staged, unstaged, and untracked changes. Use when the user asks for a code review, merge-risk assessment, regression hunt, missing-test analysis, or a verdict on whether a PR, branch, commit range, or local diff is safe.'\n---\n\n# GitNexus review\n\nReview the requested change surface without editing source, committing, pushing,\nposting, or resolving threads. A later explicit request may authorize those\nactions. Use GitNexus for structural evidence and source inspection for proof;\nneither substitutes for the other.\n\n## Resolve the target\n\nAccept these forms:\n\n| Input | Review surface |\n| ------------------------------------------------------ | --------------------------------------------------------------------------- |\n| PR URL, `owner/repo#42`, `#42`, or bare number | GitHub PR |\n| `base...head` | Merge-base range |\n| `base..head` | Exact two-dot range |\n| Branch, tag, or commit | Ref against the repository default branch |\n| `local`, `staged`, `unstaged`, or working-tree wording | Local changes |\n| No target | Current branch's open PR; otherwise local changes; otherwise current branch |\n\nAn explicit target always wins. Interpret a bare number as a PR only in a\nGitHub repository with working `gh` authentication; otherwise ask for a ref or\nURL. If implicit mode finds both branch commits and local changes, review them\nas two labeled surfaces rather than silently dropping or blending either one.\n\nRecord the resolved target kind, repository root, default branch, base SHA,\nhead SHA, merge-base when applicable, and included local states. Resolve the\ndefault branch from remote metadata (`refs/remotes//HEAD` or GitHub\nrepository metadata); use `main` or `master` only as an explicit fallback and\nsay when doing so.\n\n### PR\n\nUse `gh pr view`/`gh api` to pin the PR number, repository, title, URL, base\nref, base SHA, head ref, and head SHA. Fetch those exact commits without\nswitching the user's branch. Compute `git merge-base ` and use\nthat SHA as the review base: GitHub PR diffs are merge-base diffs, while\n`detect_changes(scope: \"compare\")` is a two-dot comparison.\n\nUse the local `git diff ` as the complete diff source of\ntruth; use GitHub metadata for PR facts and review state. For fork PRs, fetch\nthe pull ref or the contributor remote instead of assuming the head branch\nexists on `origin`.\n\n### Branch, ref, or range\n\nResolve every ref to a commit before reviewing. For a branch or `A...B`, use\nthe merge-base as the comparison base. For an explicit `A..B`, honor `A` as\nthe exact base. Do not compare a feature branch directly with a moving default\nbranch tip when merge-base semantics were intended.\n\n### Local changes\n\nInspect `git status --short`, the staged diff, the unstaged diff, and every\nuntracked file. Use `detect_changes` with `staged`, `unstaged`, or `all` as\nrequested. Untracked files are not guaranteed to appear in Git diff or graph\nmapping, so read them directly and list them in the review provenance.\n\n## Align the checkout and index\n\nThe graph and diff must describe the same head. Reuse an existing worktree only\nwhen it is at the exact target SHA. Otherwise create a temporary detached\nworktree for the PR/ref head, review there, and remove only that temporary\nworktree afterward. Never switch or reset the user's current worktree.\n\nCheck GitNexus status in the target worktree. If stale, run\n`node .gitnexus/run.cjs analyze --index-only` before trusting graph results\n(temporary worktrees never carry the gitignored `run.cjs` — fall back to the\ninstalled `gitnexus` CLI, then `npx gitnexus`), and include `--pdg` in that\nsame refresh when the diff plausibly touches trust or data-flow boundaries,\nso the taint pass below doesn't pay a second full analyze. Taint and\ndependence evidence needs that PDG layer: when the workflow's taint pass\nfinds it missing, rebuild with `analyze --pdg --index-only` and record the\nrebuild in provenance. For local changes, refresh the index so new or\nmodified source is represented.\nIf an exact target checkout/index cannot be established, state the limitation\nand do not claim a complete graph-backed review.\n\n## Review workflow\n\n1. Read the full diff and changed-file list. Separate generated files,\n dependency churn, tests, and behavior changes.\n2. Run `detect_changes` against the exact surface:\n - PR/branch/`...`: `scope: \"compare\"`, `base_ref: `.\n - Explicit `A..B`: `scope: \"compare\"`, `base_ref: ` from a worktree\n at `B`.\n - Local: `scope: \"staged\"`, `\"unstaged\"`, or `\"all\"`.\n Pass `worktree` when the MCP server is attached elsewhere.\n3. Run upstream `impact` with `includeTests: true` for each behaviorally changed\n symbol. Prioritize public contracts, shared types, control flow, persistence,\n security boundaries, and error handling; skip mechanical/generated changes.\n4. Inspect every direct (`d=1`) dependent that is outside the diff. A dependent\n outside the diff is a lead, not automatically a bug—verify the changed\n contract and caller behavior in source.\n5. Use `context` on key or ambiguous symbols and inspect affected execution\n flows. Read the surrounding implementation and tests at cited locations.\n6. **Taint and dependence pass.** For changed code on trust or data-flow\n boundaries — external input, persistence, process execution, network,\n auth — run `explain` on the changed files or symbols and judge its\n source→sink taint findings against the diff: a flow the change\n introduces, or a sanitizer/guard the change removes, is a finding; a\n pre-existing flow is context, not a defect of this change. When the\n change claims to guard or sanitize something, verify with `pdg_query`:\n what controls the changed statement, and where its values flow. This\n needs a `--pdg` index; if one cannot be built, state that the taint pass\n was skipped rather than implying coverage.\n7. Check whether tests exercise the changed behavior, boundary conditions, and\n affected flows. Run focused read-only validation when practical. When the\n diff refreshes a committed baseline, fingerprint, or golden, re-run the\n exact CI check command against the head instead of trusting the committed\n value — a stale artifact is invisible in the diff and fails only in CI.\n8. Reconcile graph evidence with the raw diff. New files, dynamic dispatch,\n configuration, reflection, and untracked content may require direct review\n even when graph results are empty. Version and invalidation constants are\n review surface: when the diff changes what gets emitted or persisted,\n verify every schema/version constant gating caches, incremental\n writebacks, and fingerprint baselines was bumped or regenerated — in\n GitNexus itself, for example: graph DDL needs no manual bump, because\n `SCHEMA_FINGERPRINT` (`gitnexus/src/core/lbug/schema.ts`) is derived\n from `NODE_SCHEMA_QUERIES` + `REL_SCHEMA_QUERIES` and moves on its own;\n the check there is whether the diff changed any string in those arrays,\n and, if it added a new DDL array, whether that array was folded into the\n fingerprint. Parser compatibility is also automatic: review the base/PDG\n ownership boundaries in `gitnexus/src/core/parse-cache-identity.ts`, the\n import/asset coverage audit, and real cold → warm replay tests. New parser\n dependencies outside those boundaries need explicit coverage; contributors\n do not allocate a semantic counter. Both benchmark fingerprint sets still\n need deliberate review before re-baselining: automatic invalidation does\n not establish semantic correctness. Other semantic changes that leave DDL\n untouched rely on the analyzer runner-identity receipt in index metadata.\n\n## Expert lenses\n\nDepth comes from matching reviewers to what actually changed, not from one\ngeneralist pass. After workflow step 2, group the changed files and symbols\nby the functional areas the graph already knows — the index's cluster\nlisting; `context` names each symbol's cluster — and give each touched area\nan expert lens: a reviewer charged with that domain's contracts, invariants,\nand failure modes, grounded in the repo's own material (architecture docs,\nagent rules, the domain's tests) before judging the diff. A lens verifies,\nnot just reads: when the changed code is a pure function reachable from the\nrepo's own toolchain — parsers, extractors, capture emitters, formatters —\nexecute it on the candidate failing shape (a scratch probe, deleted\nafterward) and cite the observed output. An empirical probe outranks source\nreading in the evidence hierarchy; role swaps, dead branches, and\nerror-recovery-dependent behavior repeatedly pass a reading and fail a\nten-line probe. The numbered\nworkflow runs exactly once; dispatch the lens passes after step 6, handing\neach lens the evidence already collected rather than letting lenses repeat\nthe `impact`, `context`, or taint calls. In GitNexus\nitself, for example: shared ingestion-pipeline changes get an ingestion\nexpert plus one language expert per changed language extractor; embeddings\nchanges an embeddings expert; LadybugDB/storage changes a Ladybug expert.\n\nFour cross-cutting lenses run regardless of domain:\n\n- **Architectural fit** — the change lands where the architecture says the\n concern lives, reuses existing seams, and adds no parallel structure.\n- **Language conformance** — the repo's own type/lint/test contract as\n configured (tsconfig strictness, lint rules, test conventions); in a\n strict TypeScript repo, for example: strictness intact, no `any`/`as any`\n escapes, module boundaries typed. Judge by the repo's contract, never a\n universal style bar.\n- **Definition of Done** — changed behavior has tests, docs the change makes\n stale are updated, and sync/drift guards (shipped copies, manifests,\n changelogs) still hold.\n- **Simplicity** — YAGNI and clear-code check: flag speculative abstraction,\n unused knobs, and overengineering; the smallest diff that meets the\n Definition of Done is the standard.\n\nScale effort to the surface: a single-domain change of a few files gets one\ncombined pass covering its domain lens plus the four cross-cutting checks;\na multi-domain change gets one lens per touched area — run as parallel\nsubagents where the harness supports them, each scoped to its own files\nplus the shared graph evidence, and as sequential passes otherwise. Never\nspawn a lens for a domain the diff does not touch. Merge lenses that ground\nin the same material — two lenses reading the same files pay twice for one\nread's coverage, so give one reviewer both charges. Where the harness\noffers model or effort tiers, run mechanical lenses (rename sweeps,\ndoc-consistency checks) on a cheaper tier and reserve the strongest engine\nfor adversarial judgment. Every lens reports\nthrough the Finding standard below; merge and dedup before the verdict,\ndropping anything without a concrete failing scenario.\n\n### Swarm lanes\n\nSix dispatchable lane definitions ship with this skill in `ci-personas/` —\nread-only reviewers restricted to file reads plus the safe graph tools. Five are finder lanes: `ci-correctness-lens`, `ci-security-lens`,\n`ci-blast-radius-lens`, `ci-coverage-lens`, and `ci-adversarial-lens`\n(which assumes the change is broken and constructs reachable failure\nscenarios the pattern checks miss). They carry the verification\ndimensions of the numbered workflow across every touched domain; domain\ngrouping and the four cross-cutting checks above remain the\norchestrator's charge. The sixth, `ci-critic-lens`, is a gate, not a\nfinder — it audits the finished draft.\n\nWhen the harness supports subagents and these lanes are registered as\nagents (the CI review workflow installs them from its trusted control\ncheckout; a local harness may register them by copying `ci-personas/*.md`\ninto `~/.claude/agents/` or the project's `.claude/agents/`), run the\nexpert-lens pass as follows. First establish your own graph evidence —\nmake at least one substantive context call on a changed symbol yourself,\nbefore dispatching any lane, since lane calls never satisfy the evidence\nthis skill or its runner requires. Then dispatch all five finder lanes in\nparallel in a single message. Give each lane the diff, the changed-file\nmanifest, the exact base and head identifiers, the checkout paths, and the\nslice of changed files matching its charge.\n\nTreat every lane report as an unverified claim: re-anchor each finding to\nthe diff, the source, or your own graph queries before it enters the\nreview; dedup across lanes; drop anything without a concrete failing\nscenario. Lane tool calls never substitute for evidence this skill or its\nrunner requires from the orchestrating conversation itself.\n\nAfter composing the complete draft review, dispatch `ci-critic-lens` with\nthe full draft body plus the same context. On `DEFECTS`, repair the draft\nand re-dispatch the critic once; if defects remain after the second pass,\nfix what you accept, note the unresolved critic objections in the\ncoverage section, and proceed — the critic hardens the review; it never\nblocks it. This fail-open is deliberate: the critic is bounded to two\npasses so it cannot deadlock or wedge the run, and the review is still\ngated by the runner's own evidence and schema checks. (This is distinct\nfrom the separate `gitnexus-pr-swarm-review` skill, whose interactive\nroster treats its critic as a hard gate that must clear before emission;\nthis CI lane must always emit a review or a clean failure.) If subagent\ndispatch is unavailable or any lane fails, run that lane's charge inline —\nthe lanes structure the work; they never gate it.\n\n## Finding standard\n\nReport a finding only when the reviewed change introduces a concrete defect,\nregression, security issue, compatibility break, material coverage gap, or a\nmaintainability cost with a concrete carrying scenario (a dead knob, a\nduplicated contract, a drift-prone copy).\nEach finding must include:\n\n- severity and a precise `path:line` anchor;\n- the failing scenario or contract;\n- GitNexus evidence (dependent symbol/process) when applicable;\n- why existing code or tests do not mitigate it;\n- a concise remediation or missing test.\n\nDo not report style preferences, pre-existing issues, raw risk counts, or\nspeculation as defects. Do not infer safety from zero graph hits. Calibrate\noverall risk from consequence, reachability, reversibility, and test evidence,\nnot from the number of changed symbols alone.\n\n## Output\n\nLead with findings in severity order. If there are none, say so explicitly.\nThen provide:\n\n```markdown\n## Review: \n\n### Findings\n\n- [HIGH|MEDIUM|LOW] `path:line` — \n\n### Change and blast-radius summary\n\n- Target/base/head/merge-base and local states reviewed\n- Changed symbols and affected execution flows\n\n### Coverage and residual risk\n\n- Tests present, tests missing, graph/diff limitations\n\n### Verdict\n\nAPPROVE | REQUEST CHANGES | NEEDS DISCUSSION\n```\n\nFor a branch or local review, use `READY`, `NOT READY`, or `NEEDS DISCUSSION`\ninstead of a PR approval action. Include the exact target SHAs so a later run\ncan tell whether the evidence is stale.\n",".claude/skills/gitnexus-exploring/SKILL.md":"---\nname: gitnexus-exploring\ndescription: \"Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: \\\"How does X work?\\\", \\\"What calls this function?\\\", \\\"Show me the auth flow\\\"\"\n---\n\n# Exploring Codebases with GitNexus\n\n## When to Use\n\n- \"How does authentication work?\"\n- \"What's the project structure?\"\n- \"Show me the main components\"\n- \"Where is the database logic?\"\n- Understanding code you haven't seen before\n\n## Bind the repository first\n\nBind once per session using a confirmed registry name/path or configured MCP\ndefault; reuse it. Call `list_repos {}` when the target is not yet known, not before\nevery question. Never guess the registry name from the checkout directory. With\none indexed repository, use the examples below as written. With more than one, pass `repo` on every call: an omitted `repo` normally errors,\nbut under an MCP policy with a configured default it resolves to that default\nsilently. If you cannot tell which repository is meant, stop and ask. Report\nthe bound repository and index freshness alongside your explanation.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\n## Workflow\n\n```\n1. Bind the repository once; use hot-tool staleness on subsequent calls\n2. If no symbol is known: query({search_query: \"\", limit: 3, max_symbols: 3})\n3. context({uid: \"\"}) → Inspect the selected symbol\n4. Read a process resource only when its full trace answers an unresolved question\n```\n\n> If the index is stale → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Ask for only the evidence needed\n\nUse options advertised by the connected server. `response_sections` and context\n`relationTypes` are opt-in views for a single repository, not `@group` routing.\nOn an older server, use the existing limits and content/chain options instead.\nUse filters when unwanted sections are bulky; their omission metadata can make\nan already-small response slightly larger.\nAim for 2–3 focused calls after repository binding; stop when the question is\nanswered, but expand if evidence or a required safety check is still missing.\n\n```text\nquery({search_query: \"payment retry\", repo: \"my-app\", limit: 3, max_symbols: 3,\n include_content: false, chain_depth: 0,\n response_sections: [\"process_symbols\", \"definitions\"]})\ncontext({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"incoming\", \"outgoing\"], relationTypes: [\"CALLS\"]})\n// Before editing, assess impact using the normal traversal and risk calculation:\nimpact({target: \"\", repo: \"my-app\", direction: \"upstream\", summaryOnly: true})\n```\n\nIf the symbol is already known, start with `context`; use `uid`, or `name` plus\n`file_path`/`kind`, to avoid ambiguous results. To answer only “who calls it?”,\nrequest `response_sections: [\"incoming\"]`, `relationTypes: [\"CALLS\"]` and leave\n`include_content` false. Keep `processes` in a query when the question is about\nflows, rather than requesting a symbols-only view.\n\nDo not request source and multi-hop chains for every search hit. Fetch source\nfor the selected symbol only; for a large class/file, prefer `read_file` with\na small 0-based `startLine`/`endLine` window (subtract 1 from graph line numbers),\nor `maxLines` for a whole-file read, if that tool is available. Use\n`trace` for a known A→B path instead of repeatedly expanding `context`.\n\nFilters retain requested sections/categories and hide the others; they do not prove other references\nare absent or make the existing bounded search exhaustive. Read `response_filter`,\n`warning`, `partial`, `truncated`, `epistemic` and `staleness`. Remove filters when\nbroader evidence is needed. `maxTokens` is a last-resort byte cutoff that can cut\nJSON: narrow the request rather than treating a cut response as complete. Never\nuse a filtered caller view to waive the required impact check or an UNKNOWN risk.\n\n## Checklist\n\n```\n- [ ] Once per session: bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] Check hot-tool staleness; read the overview only if needed\n- [ ] Query for the concept only if the relevant symbol is not already known\n- [ ] Review returned symbols; include processes when execution flow matters\n- [ ] context on selected symbols; request only relevant sections/relations\n- [ ] Read a process resource only if its full trace is needed\n- [ ] Read targeted source only when implementation details are needed\n- [ ] State the repository and index freshness with the explanation\n```\n\n## Resources\n\n| Resource | What you get |\n| --------------------------------------- | ------------------------------------------------------- |\n| `gitnexus://repo/{name}/context` | Stats, staleness warning (~150 tokens) |\n| `gitnexus://repo/{name}/clusters` | All functional areas with cohesion scores (~300 tokens) |\n| `gitnexus://repo/{name}/cluster/{name}` | Area members with file paths (~500 tokens) |\n| `gitnexus://repo/{name}/process/{name}` | Step-by-step execution trace (~200 tokens) |\n\n## Tools\n\n**query** — find execution flows related to a concept:\n\n```\nquery({search_query: \"payment processing\", repo: \"my-app\"})\n→ Processes: CheckoutFlow, RefundFlow, WebhookHandler\n→ Symbols grouped by flow with file locations\n```\n\n**context** — 360-degree view of a symbol:\n\n```\ncontext({name: \"validateUser\", repo: \"my-app\"})\n→ Incoming calls: loginHandler, apiMiddleware\n→ Outgoing calls: checkToken, getUserById\n→ Processes: LoginFlow (step 2/5), TokenRefresh (step 1/3)\n```\n\n`repo` is required once more than one repository is indexed, and may be omitted\nwith a single one.\n\n## Example: \"How does payment processing work?\"\n\nWith `my-app` already bound and the index current:\n\n```text\n1. query({search_query: \"payment processing\", repo: \"my-app\", limit: 3, max_symbols: 3})\n → CheckoutFlow and RefundFlow, with symbol IDs and locations\n2. context({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"outgoing\", \"processes\"]})\n → Selected source, callees, process participation and completeness diagnostics\n3. Answer from that evidence; read one process resource only if its trace is still needed\n```\n\nReport the repository and index freshness with the explanation. If `my-app`\nhad not yet been bound, discover it once with `list_repos` first.\n",".claude/skills/gitnexus-cli/SKILL.md":"---\nname: gitnexus-cli\ndescription: \"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \\\"Index this repo\\\", \\\"Reanalyze the codebase\\\", \\\"Generate a wiki\\\"\"\n---\n\n# GitNexus CLI Commands\n\nCommands below use `node .gitnexus/run.cjs ` — the project-local runner `gitnexus analyze` drops next to the index. It auto-selects an available runner at call time (global `gitnexus`, else `pnpm dlx`, else `bunx`, else `npx`), so no package-manager assumption and no global install is required — including on a bun-only machine, which has no npm, npx or pnpm at all.\n\n> **Not analyzed yet, or `node .gitnexus/run.cjs` reports `Cannot find module`** (the gitignored runner is absent — e.g. a fresh clone or `git clean`)? (Re)generate it with `npx gitnexus analyze` from the project root, or `bunx gitnexus@latest analyze` on a bun-only machine. On **npm 11.x**, if `npx` crashes during install (`node.target is null`), install once with `npm i -g gitnexus` (then `gitnexus analyze`), or use `bunx gitnexus@latest analyze`, or `pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze`. See [#1939](https://github.com/abhigyanpatwari/GitNexus/issues/1939).\n\n## Commands\n\n### analyze — Build or refresh the index\n\n```bash\nnode .gitnexus/run.cjs analyze\n```\n\nRun from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.\n\n| Flag | Effect |\n| -------------- | ---------------------------------------------------------------- |\n| `--watch` | Keep a Git repository index current with serialized refreshes |\n| `--debounce ` | Watch quiet period before refresh (default: 300 ms) |\n| `--force` | Force full re-index even if up to date |\n| `--embeddings` | Enable embedding generation for semantic search (off by default) |\n| `--drop-embeddings` | Drop existing embeddings on rebuild. By default, an `analyze` without `--embeddings` preserves them. |\n| `--pdg` | Build the program-dependence layers used by `explain` and `pdg_query` (taint, CDG, and REACHING_DEF). |\n| `--spring-actuator ` | Import opt-in Spring Boot Actuator mappings, beans, conditions, configprops, and env snapshots. Forces a full rebuild; unsupported with `--watch`. |\n| `--asyncapi-spec ` | Read opt-in AsyncAPI 3.x documents (directory or single file) and mint `Destination` nodes from their operations. 2.x is refused, not mapped. Unsupported with `--watch`. |\n\n**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook detects staleness after `git commit` and `git merge` and notifies the agent to run `analyze` — the hook does not run analyze itself, to avoid blocking the agent for up to 120s and risking KuzuDB corruption on timeout.\n\nFor Spring runtime enrichment, pass a JSON bundle, one endpoint JSON file, or a directory containing endpoint files. Route evidence is authoritative only when `runtimeConfirmed === true`; `runtimeSource` records provenance and may also accompany `handler-conflict`. Env/configprops values are never persisted.\n\n## Index storage and retention\n\nDefault location is `/.gitnexus/`. Override with environment variables (also documented in README):\n\n| Env | Effect |\n| --- | ------ |\n| `GITNEXUS_STORAGE_PATH` | One complete external index directory. Wins if both storage vars are set. |\n| `GITNEXUS_STORAGE_ROOT` | Absolute root; GitNexus creates an isolated `-<12-hex>/` slot per repository. |\n| `GITNEXUS_CONTENT_RETENTION` | `full` (default) keeps file text; `symbol` keeps snippets; `none` keeps the graph only. |\n\n`list_repos`, `gitnexus://repo/{name}/context`, and HTTP `GET /api/repos` / `GET /api/repo` expose `storagePath`, `contentRetention`, and `sourceAvailable`. HTTP `/api/file` and `/api/grep` return 410 unless retention is `full`. MCP `include_content` may still return symbol spans when retention is `symbol`.\n\nUse `node .gitnexus/run.cjs analyze --watch` for a long-lived local Git repository. It performs an initial analysis, queues scanner-admitted file changes, and retries intact failed batches with bounded backoff. Watch refreshes update only the graph: they skip AGENTS.md / CLAUDE.md injection and standard skill installation, so run a one-shot `analyze` when those generated files need updating. Watch rejects one-shot or context-output flags including `--force`, embedding flags, `--skills`, `--default-branch`, `--skip-agents-md`, `--skip-skills`, `--no-stats`, `--self-commit`, `--index-only`, and `--skip-git`. It never pulls remotes. Scheduled remote clone/pull is a different command: `gitnexus auto-sync`. Bare `gitnexus watch` is reserved and does not start either job. Running MCP and `serve` processes periodically check for a published replacement and reopen it without a restart. MCP checks are throttled to once every five seconds, so a tool call before the next check can briefly use the previous index.\n\n### status — Check index freshness\n\n```bash\nnode .gitnexus/run.cjs status\n```\n\nShows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.\n\n### clean — Delete the index\n\n```bash\nnode .gitnexus/run.cjs clean\n```\n\nDeletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.\n\n| Flag | Effect |\n| --------- | ------------------------------------------------- |\n| `--force` | Skip confirmation prompt |\n| `--all` | Clean all indexed repos, not just the current one |\n\n### wiki — Generate documentation from the graph\n\n```bash\nnode .gitnexus/run.cjs wiki\n```\n\nGenerates repository documentation from the knowledge graph using an LLM. HTTP providers require an API key (saved to `~/.gitnexus/config.json` on first use). Local CLI providers (`--provider cursor|claude|codex|opencode|grok`) use your existing CLI login.\n\n| Flag | Effect |\n| ------------------- | ----------------------------------------- |\n| `--force` | Force full regeneration, also required to re-generate an existing wiki in a different language |\n| `--provider ` | LLM provider: minimax, openai, openrouter, azure, custom, cursor, claude, codex, opencode, or grok (default: minimax). Local CLIs (`cursor`, `claude`, `codex`, `opencode`, `grok`) use your existing CLI login and skip `--api-key`. |\n| `--model ` | LLM model (default: MiniMax-M3) |\n| `--base-url ` | LLM API base URL |\n| `--api-key ` | LLM API key |\n| `--concurrency ` | Parallel LLM calls (default: 3) |\n| `--timeout ` | LLM request timeout in seconds (default: disabled) |\n| `--retries ` | Max LLM retry attempts per request (default: 3) |\n| `--lang ` | Output language for generated documentation (e.g. english, chinese, spanish, japanese) |\n| `--gist` | Publish wiki as a public GitHub Gist |\n\n### list — Show all indexed repos\n\n```bash\nnode .gitnexus/run.cjs list\n```\n\nLists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.\n\n## After Indexing\n\n1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded\n2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task\n\n## Troubleshooting\n\n- **\"Not inside a git repository\"**: Run from a directory inside a git repo\n- **Index is stale after re-analyzing**: Wait for the next MCP tool call to reopen the published index; this normally takes no more than five seconds\n- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding\n",".claude/skills/gitnexus-refactoring/SKILL.md":"---\nname: gitnexus-refactoring\ndescription: \"Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: \\\"Rename this function\\\", \\\"Extract this into a module\\\", \\\"Refactor this class\\\", \\\"Move this to a separate file\\\"\"\n---\n\n# Refactoring with GitNexus\n\n## When to Use\n\n- \"Rename this function safely\"\n- \"Extract this into a module\"\n- \"Split this service\"\n- \"Move this to a new file\"\n- Any task involving renaming, extracting, splitting, or restructuring code\n\n## Bind the repository first\n\nRefactoring writes to disk. `rename` with `dry_run: false` edits files in\nwhichever repository was resolved, so binding identity here is a safety gate,\nnot bookkeeping.\n\nCall `list_repos {}` before the first tool call. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask. Never run `rename` with\n`dry_run: false` until the preview in the same bound repository has been\nreviewed — its returned `file_path` values show which checkout is about to be\nwritten, so read them as a confirmation of identity.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\n`detect_changes` takes `worktree` when you are editing a linked worktree the\nMCP server was not launched from; otherwise `git diff` runs in the wrong\ncheckout and reports nothing changed, which reads as a verified refactor.\n\n## Workflow\n\n```\n0. list_repos {} → Bind repo (and worktree)\n1. impact({target: \"X\", direction: \"upstream\"}) → Map all dependents\n2. query({search_query: \"X\"}) → Find execution flows involving X\n3. context({name: \"X\"}) → See all incoming/outgoing refs\n4. Plan update order: interfaces → implementations → callers → tests\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Checklists\n\n### Rename Symbol\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] rename({symbol_name: \"oldName\", new_name: \"newName\", dry_run: true}) — preview semantic edits (omitting dry_run also previews)\n- [ ] Confirm the previewed file paths are in the bound repository/worktree\n- [ ] Review exact graph-backed semantic spans, coverage, and limitations\n- [ ] If satisfied: rename({..., dry_run: false, plan_token: \"\"}) — apply exactly the reviewed edits\n- [ ] detect_changes() — verify only expected files changed\n- [ ] Run tests for affected processes\n```\n\n### Extract Module\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] context({name: target}) — see all incoming/outgoing refs\n- [ ] impact({target, direction: \"upstream\"}) — find all external callers\n- [ ] Define new module interface\n- [ ] Extract code, update imports\n- [ ] detect_changes() — verify affected scope\n- [ ] Run tests for affected processes\n```\n\n### Split Function/Service\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] context({name: target}) — understand all callees\n- [ ] Group callees by responsibility\n- [ ] impact({target, direction: \"upstream\"}) — map callers to update\n- [ ] Create new functions/services\n- [ ] Update callers\n- [ ] detect_changes() — verify affected scope\n- [ ] Run tests for affected processes\n```\n\n## Tools\n\n**rename** — semantic rename; preview first, then apply:\n\n```\nrename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: true})\n→ 12 edits across 8 files\n→ semantic_edits: 12, coverage: {name: \"gitnexus-semantic\", scope: \"indexed-repository\", limitations: [...]}\n→ changes: [{file_path, edits: [{start, length, line, old_text, new_text, confidence: \"semantic\"}]}]\n```\n\n`dry_run` omitted or `true` previews and never writes; `dry_run: false` requires\nthe successful preview's `plan_token`. Keep the same repository, selected symbol,\nand destination name. Tokens are single-use, expire after 15 minutes or a server\nrestart, and may be evicted when retained previews reach 16 plans or 64 MiB.\nAny apply attempt consumes the token; request and review a fresh preview to retry.\nAn MCP server started with `GITNEXUS_MCP_READ_ONLY=1` still lists `rename`, but\nas preview-only: it rejects any `dry_run` other than omitted or `true`, so apply\nthrough a server that permits writes. Request and review a fresh preview there;\ntokens belong to the process that issued them.\n\nRename uses the indexed graph and GitNexus's own semantic layer. Language\nproviders resolve current source through scopes and bindings; no compiler or\nlanguage service is loaded. Unsupported syntax, ambiguous bindings, stale\ndeclarations, and incomplete occurrence coverage fail closed. Coverage describes\nindexed files accepted by the selected provider, including supported embedded sources,\nand excludes unindexed files and external consumers. All registered source-language\nproviders supply rename rules. Declaration and override families require complete\nsemantic evidence. Dynamic or computed references block a rename when the provider\ncannot resolve them or exclude them from the selected family. Provider-specific\nlimits, including class renames requiring a file move, remain explicit in results.\nThere is no regex fallback: legacy `graph_edits` and `text_search_edits` are zero.\nComments, strings, and unrelated same-spelled symbols are not replacements.\n\nPreview captures the exact semantic plan, source hashes and physical file targets.\nApply validates that plan and executes its edits without replanning. Changes to\nindexed targets, source bytes or paths (including newly added untracked source\nfiles) reject the plan before writing. Unindexed files remain outside semantic\ncoverage; analyze first when they need refactoring. Results use `result_version: 2`;\n`total_edits` counts occurrences, not matching lines. Exact replacements are shown in `new_text`.\nCheck `planning_status`, `application_status`, and `applied`. A completed apply\nhas `status: \"success\"`, `application_status: \"applied\"`, and `applied: true`.\nA successful preview has not written files. `rename` does not accept `branch`:\nit inspects the current checkout.\n\nRecover from a blocked or incomplete rename before applying again. A failed\nresult carries `code` and `error`; nothing was written unless the last row applies.\n\n| Result | Next step |\n| --- | --- |\n| `stale_graph` | Re-analyze the bound repository, then preview again with `rename` (`dry_run` omitted or `true`). |\n| `source_changed` | Preview again against the current source and review it. If it appears during an apply, see the `partial` row. |\n| `plan_required`, `invalid_plan`, `plan_mismatch` | Apply needs the successful preview's token and identical repository, symbol and new name. Expired, consumed or evicted plans require a fresh reviewed preview. |\n| `source_set_changed` | Source paths changed, including untracked files. Re-analyze and review a fresh preview. |\n| `plan_too_large` | The captured plan exceeds the 64 MiB retention budget. Narrow the indexed repository before previewing again. |\n| `unsupported_*` | Stop automated rename and inspect the reported limitation. Use a language-aware manual refactor if needed. |\n| Ambiguous target (`status: \"ambiguous\"` with candidates) | Inspect the returned candidates or `context`, then preview with the chosen `symbol_uid`. |\n| `ambiguous_reference`, `incomplete_semantics` | The planner could not prove a reference, import, or declaration is covered. Stop automated rename; resolve the named location by hand or pick a different symbol. |\n| `name_collision` | `new_name` would collide with, or change the identity of, another declaration or binding. Choose a different name and preview again. |\n| `invalid_name` | `new_name` is empty, equals the current name, or is not valid in the target language. Choose a valid, different identifier. |\n| `invalid_argument` | `dry_run` was sent but is not a boolean. Omit it or send `true` or `false`. |\n| `no_locations` | The planner produced no edits. Do not apply; re-check the target with `context` and pass `symbol_uid`. |\n| `overlapping_edits`, `invalid_edit` | The planned spans conflict or do not match the source text. The plan is rejected before any write; do not apply. Refactor manually or report the case. |\n| `duplicate_file`, `missing_snapshot`, `outside_repository` | A planner safety check failed (two paths resolve to one real file, a file has no source snapshot, or a path leaves the repository). Re-analyze and preview again; if it repeats, stop and report it. |\n| `source-unavailable` (`reason: \"content-retention\"` or `\"checkout-missing\"`) | The index was built without full source retention (`GITNEXUS_CONTENT_RETENTION`), or the checkout directory is missing. Re-analyze with full retention, or run against the checkout. |\n| `rename_failed` | An unexpected error while planning, before any write (`application_status: \"not_started\"`). Re-analyze and preview once more; if it repeats, stop and report the `error` text. |\n| `application_status: \"partial\"` or `\"failed\"` (`write_failed`, or `source_changed` mid-apply) | Writes are not transactional. Inspect landed `changes` (already written, with their counts), `failed_files` (the one file whose write or validation failed), and `unattempted_files` (later files never touched). Reconcile the current files, re-index, and review a fresh preview; never blindly retry the apply call. |\n\nRun the project validation suite after applying.\n\n**impact** — map all dependents first:\n\n```\nimpact({target: \"validateUser\", repo: \"my-app\", direction: \"upstream\"})\n→ d=1: loginHandler, apiMiddleware, testUtils\n→ Affected Processes: LoginFlow, TokenRefresh\n```\n\n**detect_changes** — verify your changes after refactoring:\n\n```\ndetect_changes({scope: \"all\"})\n→ Changed: 8 files, 12 symbols\n→ Affected processes: LoginFlow, TokenRefresh\n→ Risk: MEDIUM\n```\n\n`partial: true` (a graph query failed) or `truncated: true` (the changed-symbol\nlisting was capped) means the result is short of the truth: a short or empty\nlist is not proof that only the expected files changed. Re-run it rather than\ntreat the refactor as verified.\n\nA wrong-worktree zero carries neither flag and is indistinguishable from a\nclean verification, so confirm the diffed checkout is the one you edited.\n\n**cypher** — custom reference queries:\n\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"validateUser\"})\nRETURN caller.name, caller.filePath ORDER BY caller.filePath\n```\n\n## Risk Rules\n\n| Risk Factor | Mitigation |\n| ------------------- | ----------------------------------------- |\n| Many callers (>5) | Use rename for automated updates |\n| Cross-area refs | Use detect_changes after to verify scope |\n| String/dynamic refs | query to find them |\n| External/public API | Version and deprecate properly |\n| Same name in another indexed repo | Bind `repo`; verify previewed paths before applying |\n\n## Example: Rename `validateUser` to `authenticateUser`\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly\n\n1. rename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: true})\n → 12 semantic occurrences in the indexed repository's supported provider scope\n → Files: validator.ts, login.ts, middleware.ts...\n\n2. Review semantic spans and provider coverage; inspect dynamic references separately\n\n3. rename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: false, plan_token: \"\"})\n → Applied 12 edits across 8 files\n\n4. detect_changes({scope: \"all\", repo: \"my-app\"})\n → Affected: LoginFlow, TokenRefresh\n → Risk: MEDIUM — run tests for these flows\n Repository: my-app (/abs/path/my-app) Worktree: same Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n",".claude/skills/gitnexus-debugging/SKILL.md":"---\nname: gitnexus-debugging\ndescription: \"Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: \\\"Why is X failing?\\\", \\\"Where does this error come from?\\\", \\\"Trace this bug\\\"\"\n---\n\n# Debugging with GitNexus\n\n## When to Use\n\n- \"Why is this function failing?\"\n- \"Trace where this error comes from\"\n- \"Who calls this method?\"\n- \"This endpoint returns 500\"\n- Investigating bugs, errors, or unexpected behavior\n\n## Bind the repository first\n\nA root cause traced in the wrong repository is a wrong root cause.\n\nBind once using a confirmed registry name/path or configured MCP default. Call\n`list_repos {}` if the target is not yet known; reuse that binding across calls. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask. This matters most for `cypher`, whose\nstatement carries no in-band hint of which database it ran against.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\nA stale index describes the code from before your bug, so refresh before\ntrusting a trace, and state the repository and index freshness with the\ndiagnosis.\n\n## Workflow\n\n```\n0. Bind the repo once (list_repos only if not already known)\n1. If the suspect is unknown, query for the error/symptom with small result limits\n2. context({name: \"\"}) → See callers/callees/processes\n3. Read a process resource only if its trace resolves an open question\n4. cypher({statement: \"MATCH path...\"}) → Custom traces if needed\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Checklist\n\n```\n- [ ] Once per session: bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] Understand the symptom (error message, unexpected behavior)\n- [ ] query for error text or related code\n- [ ] Identify the suspect function from returned processes\n- [ ] context to see callers and callees\n- [ ] Trace execution flow via process resource if applicable\n- [ ] cypher for custom call chain traces if needed\n- [ ] Read source files to confirm root cause\n- [ ] State the repository and index freshness with the diagnosis\n```\n\n## Keep investigations focused\n\nStart with a known symbol's `context`, or a small `query` (`limit: 3`,\n`max_symbols: 3`, `include_content: false`, `chain_depth: 0`) to discover one.\nWhen the server advertises these single-repository filters, request only the\nneeded evidence:\n\n```text\ncontext({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"outgoing\"], relationTypes: [\"CALLS\"]})\ntrace({from_uid: \"\", to_uid: \"\", repo: \"my-app\"})\n```\n\n`symbol` and completeness/staleness diagnostics remain in a filtered context.\n`relationTypes` filters the returned incoming/outgoing categories only; it does\nnot expand their existing bounded window or filter an explicitly requested chain.\nFor callback registration, include `USES`; for imports or inheritance, request\nthose relation types or omit the filter. Omitted references are not absent\nreferences. Broaden when the hypothesis needs it, and preserve UNKNOWN/partial\nwarnings. Confirm source and tests before claiming a root cause. A useful 2–3\ncall investigation is a goal, not a reason to skip verification or pre-edit impact.\n\n## Debugging Patterns\n\n| Symptom | GitNexus Approach |\n| -------------------- | ---------------------------------------------------------- |\n| Error message | `query` for error text → `context` on throw sites |\n| Wrong return value | `context` on the function → trace callees for data flow |\n| Intermittent failure | `context` → look for external calls, async deps |\n| Performance issue | `context` → find symbols with many callers (hot paths) |\n| Recent regression | `detect_changes` to see what your changes affect — pass `worktree` for a linked worktree |\n| \"How does A reach B?\" | `trace` between the two symbols — shortest call chain in one call |\n\n## Tools\n\n**query** — find code related to error:\n\n```\nquery({search_query: \"payment validation error\", repo: \"my-app\"})\n→ Processes: CheckoutFlow, ErrorHandling\n→ Symbols: validatePayment, handlePaymentError, PaymentException\n```\n\n**context** — full context for a suspect:\n\n```\ncontext({name: \"validatePayment\", repo: \"my-app\"})\n→ Incoming calls: processCheckout, webhookHandler\n→ Outgoing calls: verifyCard, fetchRates (external API!)\n→ Processes: CheckoutFlow (step 3/7)\n```\n\n**cypher** — custom call chain traces. Pass `repo` alongside the statement; the\nCypher text itself names no repository, so the result is unattributable without\nit:\n\n```cypher\nMATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: \"validatePayment\"})\nRETURN [n IN nodes(path) | n.name] AS chain\n```\n\n**trace** — shortest call chain between two symbols (\"how does A reach B?\"), one call instead of chaining `context` hops:\n\n```\ntrace({ from: \"processCheckout\", to: \"fetchRates\", repo: \"my-app\" })\n→ status: ok, hopCount: 3\n→ hops: processCheckout → validatePayment → verifyCard → fetchRates\n→ edges: CALLS (1.0), CALLS (0.95), CALLS (1.0)\n```\n\nWhen no path exists, `trace` reports the furthest reachable node — exactly where the chain breaks (dynamic dispatch, reflection, or an external boundary).\n\n## Example: \"Payment endpoint returns 500 intermittently\"\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — bind my-app explicitly on every call\n\n1. query({search_query: \"payment error handling\", repo: \"my-app\"})\n → Processes: CheckoutFlow, ErrorHandling\n → Symbols: validatePayment, handlePaymentError\n\n2. context({name: \"validatePayment\", repo: \"my-app\"})\n → Outgoing calls: verifyCard, fetchRates (external API!)\n\n3. READ gitnexus://repo/my-app/process/CheckoutFlow\n → Step 3: validatePayment → calls fetchRates (external)\n\n4. Root cause: fetchRates calls external API without proper timeout\n Repository: my-app Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n",".claude/skills/gitnexus-work/SKILL.md":"---\nname: gitnexus-work\ndescription: 'Use when executing an engineering plan produced by gitnexus-plan (or a small bounded task directly) — implements step by step with GitNexus impact checks before every symbol edit, tests from the plan''s scenarios, and detect_changes gating every commit. Examples: \"/gitnexus-work docs/plans/2026-07-11-gitnexus-plan-ingestion-retry.md\", \"/gitnexus-work\" (latest plan), \"execute the plan\".'\n---\n\n# gitnexus-work — execute a gitnexus-plan\n\nExecute an implementation plan produced by `gitnexus-plan`, shipping it as a\nsequence of verified, atomic commits. The plan's section 11\n(`implementation_context` pack) is the primary machine-readable input; the\nprose sections are its rationale. This skill **does** edit code — it is the\nexecutor counterpart to the planning-only `gitnexus-plan`.\n\n```\n/gitnexus-work # execute this plan\n/gitnexus-work # newest docs/plans/*gitnexus-plan*.md here\n/gitnexus-work # direct mode, see Input triage\n```\n\n## Input triage\n\n- **Plan path** (or blank → the newest `docs/plans/*gitnexus-plan*.md` under\n the current repo root): the normal mode; continue to Phase 1. Schema-2\n plans have a normalized repo-relative\n `docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md`\n `generated_plan_path`. Resolve only a lexical candidate, then invoke\n `scripts/evidence-provenance.mjs read-plan --repo --generated-plan\n` and load only the exact bytes in its descriptor-anchored\n receipt. Require the receipt's canonical repo-relative path to equal the\n document's `generated_plan_path` byte-for-byte;\n reject an external, escaping, differently scoped, or mismatched value. A\n plan in another target repo may still be passed by explicit path. If Phase 1's\n pre-completed check finds every §7 step of the newest plan already landed,\n stop and ask instead of re-executing it.\n- **Bare task text**: trivial and bounded (1–2 files, no architectural\n decisions) → implement directly with the same discipline: `impact` before\n every symbol edit, minimal change, tests when behavior changes,\n verification commands taken from the repo's own scripts (package.json /\n CI), `detect_changes` before every commit, and the shared\n Build-current/index-current procedure before graph-dependent impact and\n final verification. Anything larger → recommend running\n `/gitnexus-plan` first; honor the user's choice if they decline.\n\n## Phase 1 — Load and re-anchor the plan\n\n1. Resolve the target repo and normalized plan candidate, then invoke this\n skill's descriptor-anchored `scripts/evidence-provenance.mjs read-plan`\n command exactly as\n specified in `references/evidence-provenance.md`. Reject a missing,\n external, escaping, symlinked, or differently scoped path. Decode and read\n the receipt's exact `plan_bytes_base64` completely; never read or reopen the\n lexical path directly. It is a decision artifact, not a script: scope\n boundaries and `avoid` entries bind you; exact code is yours to write.\n Retain the receipt's canonical `generated_plan_path` and `plan_digest` in\n session state. Never edit the plan body.\n2. Parse the §11 `implementation_context` pack: `acceptance_criteria`,\n `evidence_provenance`, `primary_symbols`, `related_symbols`,\n `files_to_modify`, `execution_path`, `pdg_constraints`,\n `architectural_patterns`, `tests`, `verification_commands`, `risks`,\n `assumptions`, `open_questions`, `avoid`. Compact plans carry the\n mini-pack subset — absent optional fields are empty, not errors.\n `evidence_provenance` is mandatory: absence or schema 1 means a legacy\n plan, not a clean tree. Before relying on it, require exact byte-for-byte\n equality between the read-plan receipt's canonical `generated_plan_path`\n and `evidence_provenance.generated_plan_path`.\n3. **Two-layer drift check — always recompute.** Even when current HEAD is the\n same HEAD as the plan pin, recompute both the canonical global dirty digest\n and the sorted cited-path manifest. Read\n `references/evidence-provenance.md`, then invoke this skill's\n `scripts/evidence-provenance.mjs` with the plan's exact\n `generated_plan_path`, every cited manifest path, and schema version 2.\n Never recreate its bytes in shell or prose. Schema 1 cannot be recomputed\n unambiguously and requires conservative re-anchoring. Include\n object kind plus HEAD/index/worktree/untracked layer digests, and classify\n `staged`, `unstaged`, `untracked`, `deleted`, `renamed`, `mixed`,\n and `absent` evidence. Honor the generated-plan exclusion exactly; do not\n exclude all plans.\n4. **Re-anchor on either mismatch.** Missing or legacy provenance, a HEAD\n mismatch, or a global dirty digest mismatch requires a conservative\n re-anchor before work:\n - Diff every cited-path manifest entry. Changed cited paths — including\n staged-only, unstaged-only, deleted, both rename endpoints, mixed\n staged+unstaged, and disappeared untracked paths — get their cited ranges\n re-read before reliance.\n - Compare the current whole-tree dirty set with the pinned global digest.\n New uncited dirty paths get a scope assessment: determine whether they\n overlap the plan, requirements, tests, or a key technical decision; do not\n silently ignore them merely because they are uncited.\n - Unreadable or unclassifiable cited evidence blocks every dependent step\n until it can be restored, read, or resolved with the user. Never substitute\n an invented digest or treat absence as an empty file.\n - Keep the re-anchor result in session state; never mutate the plan body.\n Use Deepen only if reconciliation invalidates scope, requirements, a key\n technical decision (KTD), or the planned implementation seam. Ordinary\n byte drift that leaves those decisions valid is re-verified locally.\n5. **Re-verify `assumptions` cheaply** (each one names what to check).\n A failed assumption is a stop-and-replan signal for the steps that\n depend on it, not something to code around silently.\n6. Note `open_questions` — if one blocks a step and the answer materially\n changes the work, ask the user before that step, not after.\n7. **Pre-completed check.** If commits for this plan already exist on the\n branch (a prior partial run, or a post-route-back Deepen cycle), verify\n which §7 steps have landed at HEAD: those are skipped and reported as\n pre-completed, and execution resumes at the first unlanded step. All\n steps landed → report that and stop.\n\n## Phase 2 — Environment\n\n- On the default branch → create a feature branch named from the plan slug.\n On a feature branch already → stay only if it is meaningful _for this\n plan_ (name matches the plan slug, or the user confirms); otherwise\n branch from here with the slug name.\n- If the plan document is not yet committed, commit it now\n (`docs(plans): add plan`) — the plan travels with the work it\n drives, and the final review diff then includes it.\n- Confirm the `verification_commands` from the pack actually run in this\n checkout (dependencies installed, builds present) before starting, not\n after the last step.\n\n### Build-current/index-current procedure\n\nThis is the single graph-freshness procedure owned by `gitnexus-work`; it\napplies in plan mode and direct mode. Before every graph-dependent `impact`\nquery, run the Build-current/index-current procedure. Before final graph\nverification, run the same Build-current/index-current procedure again.\n\n1. Capture current HEAD and working-tree provenance. Read\n `gitnexus://repo//context` and use its typed `index.commit` and\n `index.runner_identity` receipt — never infer analyzer identity from prose,\n timestamps, or a path alone. Compare `index.commit` with current HEAD. A\n current receipt has `schemaVersion: 4`, resolved runtime path/version, CLI\n version, invoked-artifact path/digest, build\n kind/root/canonicalization/digest, and dependency-runtime\n manifest/lockfile/canonicalization/package-count/artifact-count/digest. Its\n dependency canonicalization is\n `gitnexus-analyzer-dependency-runtime-v4`. The dependency-runtime digest\n covers resolved package metadata and complete loadable package payloads,\n including JavaScript, JSON, native, Wasm, and parser artifacts; schema-1,\n schema-2, and schema-3 receipts are legacy/stale (the MCP context labels\n them `runner_identity_schema_status: legacy-or-unknown`). Require MCP\n `index.incomplete_reasons: []`. Run the exact candidate CLI's\n `status --json` command and require `index.runnerIdentityStatus: current`,\n `index.incompleteReasons: []`, and top-level `status: up-to-date`. The\n status comparator checks every semantic field while deliberately excluding\n only diagnostic `invokedArtifact`; a worker-authored persisted receipt and\n the CLI's live receipt may therefore differ in that field without becoming\n stale. Missing, malformed, differently versioned, semantically unequal, or\n incomplete receipts are unknown/stale, not a match.\n2. Relationship-affecting committed and uncommitted edits invalidate\n freshness after the last successful procedure run. This includes staged,\n unstaged, untracked, deleted, or renamed analyzer/source/config changes\n that can alter symbols or edges. Any such edit between steps requires an\n inter-step refresh before the next graph query, even when HEAD did not move.\n3. If the typed runner receipt is stale or unknown in an analyzer-source\n checkout, build current local source using the verified package script. In\n this repo: `cd gitnexus && npm run build`. Resolve the package's `bin`\n target and run that exact artifact's `status --json` command to capture its\n current receipt. Source/build timestamps are a conservative rebuild\n trigger, not proof that an artifact is current.\n4. Invoke that exact freshly built local CLI from the target repo root with\n PDG layers enabled. In this repo:\n `node gitnexus/dist/cli/index.js analyze --index-only --pdg`.\n Add `--force` when the persisted receipt was absent, malformed,\n differently versioned, or unequal so an already-up-to-date fast path cannot\n leave legacy/stale provenance in place. The usual project-runner form,\n `node .gitnexus/run.cjs analyze`, is acceptable only when its proven runner\n identity resolves to that same freshly built artifact. Do not fall back to\n an older project runner, global install, or package download after\n resolving/building the local artifact.\n5. Re-read index context, rerun the exact invoked CLI's `status --json`, and\n prove the post-refresh `index.commit` equals current HEAD, MCP\n `index.incomplete_reasons` is empty, and its complete\n `index.runner_identity` equals status `index.runnerIdentity` (the persisted\n receipt). Require status `index.runnerIdentityStatus: current`, empty\n `index.incompleteReasons`, and top-level `status: up-to-date`; do not require\n raw equality with `current.runnerIdentity` because `invokedArtifact` is a\n diagnostic entrypoint deliberately excluded from semantic freshness.\n Record the dirty-state digest indexed in this procedure so same-HEAD\n uncommitted edits can invalidate it later.\n6. Any build, refresh, metadata-read, or identity-verification failure blocks\n graph-dependent impact work and final completion. Report the failing\n command and evidence; do not continue on an older graph.\n\n## Phase 3 — Execute the Implementation Sequence\n\nWork through plan §7 step by step, in order. For each step:\n\n1. **Fresh impact before editing.** Run the Build-current/index-current\n procedure immediately before every graph-dependent\n `impact {target, direction: \"upstream\"}` query. Then account for every\n direct (d=1) dependent. HIGH or CRITICAL risk → surface it to the user\n with the blast radius before proceeding (repo mandate — see AGENTS.md\n GitNexus rules).\n2. **Honor the constraints.** `pdg_constraints` entries state ordering and\n dependence facts the change must preserve; `avoid` entries are hard\n prohibitions; `architectural_patterns` name the shape to mirror (read the\n example location before inventing one).\n3. **Implement minimally.** The smallest change that completes the step,\n following the surrounding code's conventions.\n4. **Test from the plan's scenarios.** Each `tests[]` scenario (input →\n action → expected outcome) becomes a real test in the named file. Add\n coverage the plan missed if the step's behavior demands it; never delete\n or weaken an assertion to make a step pass. Prove a new regression test\n discriminates: when the failure mode is subtle, run it once against the\n pre-fix tree (write the test before the fix, or stash the fix) and watch\n it fail — a test that passes both ways pins nothing.\n5. **Verify.** Run the step-relevant `verification_commands` (they carry\n their build prerequisites; use them as written). If any part of the\n change executes from build output — worker entrypoints, dist-shipped\n CLIs, bundled assets — rebuild that output before every verification\n run: a pass or fail against outdated build output is noise, and \"the\n fix doesn't work\" is more often \"the fix never loaded\".\n6. **Commit atomically.** `detect_changes {scope: \"staged\"}` before every\n commit to confirm only the expected symbols and flows are affected\n (repo mandate); then one conventional commit per step. Run stage →\n `detect_changes` → commit as one unbroken sequence from the repository\n root — interleaving other work between the gate and the commit is how\n the gate gets skipped. Unexpected\n affected flows → investigate before committing, not after. A result\n flagged `partial` (a graph query failed) or `truncated` (the symbol\n listing was capped) blocks the commit the same way: the gate did not\n see every changed symbol, so re-run it rather than read it as clean.\n\nA relationship-affecting implementation edit or commit invalidates the\nprocedure's prior proof. The next step must perform the required inter-step\nrefresh before its impact query; final verification refreshes again after the\nlast edit.\n\nSteps are independently actionable: after any commit the tree is coherent.\nIf a step reveals the plan is wrong, stop that step, re-verify the affected\nclaims at HEAD, and either adapt (small, in-scope deviation — record it in\nthe commit message and final summary) or route back to `gitnexus-plan`\nDeepen mode (structural miss) — with a one-line ask to the user when the\nchoice isn't obvious.\n\n## Phase 4 — Finish\n\n1. Run the full `verification_commands` suite once, at the end, even if\n every step already passed individually.\n2. Walk plan §13 (Definition of Done) and the pack's `acceptance_criteria`\n item by item; anything unmet is either finished now or reported as\n explicitly unmet — never silently dropped.\n3. **Verify the final knowledge graph.** Before final graph verification, run\n the same Build-current/index-current procedure after the last edit, even\n when no commit landed or HEAD still equals the original pin. Then run\n `detect_changes {scope: \"all\"}` (or the repo's equivalent final graph\n check) against that proven-current index and account for every unexpected\n symbol or flow. A procedure failure blocks completion.\n4. Report: steps completed, commits made, deviations from the plan (with\n why), assumptions that failed re-verification, DoD status, final indexed\n commit and runner identity, and anything deferred. Test failures are\n reported with their output, not smoothed over.\n\n## Never\n\n- Skip the Phase 3 gates: no symbol edit without `impact`, no commit without\n `detect_changes`.\n- Expand scope beyond the plan — §12's deferred follow-ups stay deferred.\n- Mutate the plan body (committing the file verbatim in Phase 2 is not\n mutation), weaken failing tests, or present unverified work as verified.\n\n## Skill feedback (GitNexus repo only)\n\nIf this run exposed friction in this skill's own instructions — wrong or\nmissing guidance, a wasted tool budget, a phase that misrouted — and the repo\ncarries `eval/workflow_bench/`, append one JSON line to\n`eval/workflow_bench/learnings.jsonl` (create the file if absent):\n`{\"skill\": \"gitnexus-work\", \"date\": \"YYYY-MM-DD\", \"task\": \"\", \"friction\": \"\", \"suggestion\": \"\"}`.\nNever edit this skill file itself from a live task: improvements go through\nthe offline candidate loop (`eval/workflow_bench/README.md` § Prompt and\nskill evolution loop), where a candidate must beat the incumbent on the\npaired benchmark before a human merges it.\n",".claude/skills/gitnexus-guide/SKILL.md":"---\nname: gitnexus-guide\ndescription: \"Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: \\\"What GitNexus tools are available?\\\", \\\"How do I use GitNexus?\\\"\"\n---\n\n# GitNexus Guide\n\nQuick reference for all GitNexus MCP tools, resources, and the knowledge graph schema.\n\n## Always Start Here\n\nFor any task involving code understanding, debugging, impact analysis, or refactoring:\n\n1. **Bind the repository once** — use a confirmed registry name/path or configured default; call `list_repos` if unknown. Read hot-tool `staleness`; use `gitnexus://repo/{name}/context` when an overview is needed.\n2. **Match your task to a skill below** and **read that skill file**\n3. **Follow the skill's workflow and checklist**\n\n> If step 1 warns the index is stale, run `node .gitnexus/run.cjs analyze` in the terminal first.\n> On `query` / `context` / `impact` / `cypher`, read `staleness.status` and `staleness.branch`/`lastCommit` before using the answer. Re-analyze only for `behind` or `diverged`.\n\n## Skills\n\n| Task | Skill to read |\n| -------------------------------------------- | ------------------- |\n| Understand architecture / \"How does X work?\" | `gitnexus-exploring` |\n| Blast radius / \"What breaks if I change X?\" | `gitnexus-impact-analysis` |\n| Trace bugs / \"Why is X failing?\" | `gitnexus-debugging` |\n| Rename / extract / split / refactor | `gitnexus-refactoring` |\n| Tools, resources, schema reference | `gitnexus-guide` (this file) |\n| Index, status, clean, wiki CLI commands | `gitnexus-cli` |\n\n## Tools Reference\n\n| Tool | What it gives you |\n| ---------------- | ------------------------------------------------------------------------ |\n| `query` | Process-grouped code intelligence — execution flows related to a concept |\n| `context` | 360-degree symbol view — categorized refs, processes it participates in |\n| `impact` | Symbol blast radius — what breaks at depth 1/2/3 with confidence |\n| `trace` | Shortest path between two symbols — \"how does A reach B?\" in one call |\n| `detect_changes` | Git-diff impact — what do your current changes affect |\n| `rename` | Semantic rename: previews by default (`dry_run` omitted/true), applies with `dry_run: false` and the preview's `plan_token`; inspect application status and failures |\n| `cypher` | Raw graph queries (read `gitnexus://repo/{name}/schema` first) |\n| `explain` | Persisted taint findings — source→sink data flows (needs `analyze --pdg`) |\n| `pdg_query` | Control/data dependence — what gates X (CDG) / where Y flows (REACHING_DEF); needs `analyze --pdg` |\n| `check` | Check graph invariants such as circular imports |\n| `route_map` | API route map — which components/hooks fetch which endpoints, and the handler files that serve them |\n| `shape_check` | Response-shape drift — keys each route returns vs keys its consumers access (flags MISMATCH) |\n| `api_impact` | Pre-change report for an API route — consumers, middleware, shape mismatches, risk level |\n| `tool_map` | MCP/RPC tool definitions and the files that handle them |\n| `group_list` | List configured multi-repo groups, or one group's config |\n| `group_sync` | Rebuild a group's Contract Registry (cross-repo HTTP contract links); run after `group.yaml` changes or member re-index |\n| `list_repos` | Discover indexed repos (paginated — `limit`/`offset`) |\n\n### Choose a focused response\n\nUse the connected server's schema; older servers may not advertise the new\nfilters. All options below are explicit: omitting them preserves existing output.\nUse filters for bulky unwanted sections; on an already-small response, omission\nmetadata can outweigh the bytes saved.\n\n| Question | Options |\n| --- | --- |\n| Which symbols implement this? | `query`: `limit: 3`, `max_symbols: 3`, `include_content: false`, `chain_depth: 0`, `response_sections: [\"process_symbols\", \"definitions\"]` |\n| Which execution flows match? | `query`: keep `processes` in `response_sections`; join its `id` to `process_symbols[].process_id` |\n| Who calls this exact symbol? | `context`: `uid`, `response_sections: [\"incoming\"]`, `relationTypes: [\"CALLS\"]` |\n| What does it call, with source? | `context`: `uid`, `include_content: true`, `response_sections: [\"outgoing\"]`, `relationTypes: [\"CALLS\"]` |\n| What is the impact summary? | `impact`: `direction: \"upstream\"`, `summaryOnly: true`; risk calculation and totals are retained |\n| Which affected symbols need inspection? | `impact`: `limit: 10`, `offset: 0`; page as indicated by the response |\n| How does A reach B? | `trace`: `from_uid`, `to_uid` |\n\n`response_sections` selects data sections for single-repository MCP `query` or\n`context` (not `@group` routes). Query choices: `processes`, `process_symbols`,\n`definitions`. Context choices: `incoming`, `outgoing`, `processes`, `chain`,\n`routes`, `typed_properties`; the selected symbol always remains. Context\n`relationTypes` accepts uppercase relationship names advertised by its schema\nand filters only the existing incoming/outgoing categories. It does not change\nranking, traversal, source retention or the bounded candidate/reference windows.\n\nFilters add `response_filter` with the selection and omitted fields/categories.\nWarnings, ambiguity, staleness and completeness metadata always remain. An empty\nfiltered view is not proof of absence. Omit filters to expand, and never waive\nimpact checks because a selected category is empty. `maxTokens` is a byte cutoff,\nnot pagination: it can cut JSON. Prefer these filters, small result counts, and\nsource/chain expansion for a selected symbol rather than a large search result.\nStop once enough evidence answers the question; do not run every tool by default.\n\n### Paginating `list_repos`\n\n`list_repos` is paginated so a large registry is not truncated by MCP/LLM token limits. It takes optional `limit` (default **50**, max **200**) and `offset`, and returns:\n\n```jsonc\n{\n \"repositories\": [\n { \"name\": \"...\", \"path\": \"...\", \"indexedAt\": \"...\", \"lastCommit\": \"...\", \"stats\": { } }\n ],\n \"pagination\": {\n \"total\": 437,\n \"limit\": 50,\n \"offset\": 0,\n \"returned\": 50,\n \"hasMore\": true,\n \"nextOffset\": 50\n }\n}\n```\n\nTo enumerate **every** repository, keep calling with `offset` set to `pagination.nextOffset` until `hasMore` is `false`:\n\n```text\nlist_repos {} → repos 1–50, nextOffset 50, hasMore true\nlist_repos { offset: 50 } → repos 51–100, nextOffset 100, hasMore true\n…\nlist_repos { offset: 400 } → repos 401–437, hasMore false (done)\n```\n\nNotes: `offset` ≥ `total` returns an empty page (with `total` still reported). Out-of-range or malformed `limit`/`offset` (non-integer, `limit` outside `[1, 200]`, `offset < 0`) are rejected with a clear error — `limit` above the max is rejected, not silently capped. The order is deterministic (lower-cased name, then path), so paging never skips or duplicates an entry while the registry is unchanged.\n\n### Inline staleness signal (`query` / `context` / `impact` / `cypher`)\n\nThese four hot read tools attach a non-blocking `staleness` field to every response, in the shape `{ status, branch?, lastCommit, indexedAt, measuredAgainst, commitsBehind?, hint? }`. It answers two different questions at once: **which index answered** and **how fresh it is**. The identity half is why the field is present even when nothing is wrong — an answer computed from a branch-pinned index is otherwise indistinguishable from one computed from the default branch (#3291):\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"current\",\n \"branch\": \"feature/checkout-v2\",\n \"lastCommit\": \"4f2a1c9e8b7d6a5c4e3f2a1b0c9d8e7f6a5b4c3d\",\n \"indexedAt\": \"2026-09-15T07:12:00.000Z\",\n \"measuredAgainst\": \"HEAD\"\n }\n}\n```\n\n`status: \"current\"` here means *this index is at the HEAD of the clone it was built from* — not that it is current with the default branch. `measuredAgainst` names what `commitsBehind` is counted against: the checked-out HEAD of that clone, never the remote. `branch` is the branch the index represents; it is absent for a detached HEAD, a non-git folder, or a legacy index that never recorded one, so read `lastCommit` when you need an identifier that is always present.\n\nWhen the index is behind that HEAD, the count and hint ride along:\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"behind\", \"commitsBehind\": 3, \"branch\": \"main\",\n \"lastCommit\": \"a0c945022d06b8815f93ffd8838df9ed5c08cbc0\",\n \"indexedAt\": \"2026-09-04T20:45:47.481Z\", \"measuredAgainst\": \"HEAD\",\n \"hint\": \"⚠️ Index is 3 commits behind HEAD. Run analyze tool to update.\"\n }\n}\n```\n\n`commitsBehind` is present only when git counted the gap. When git could not count it but HEAD still resolves to a commit other than the indexed one — usually because the indexed commit is no longer in the clone's history — the index is provably not at HEAD with no countable gap, so no number is reported:\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"diverged\", \"branch\": \"main\",\n \"lastCommit\": \"a0c945022d06b8815f93ffd8838df9ed5c08cbc0\",\n \"indexedAt\": \"2026-09-04T20:45:47.481Z\", \"measuredAgainst\": \"HEAD\",\n \"hint\": \"⚠️ Index is not at HEAD and the commit gap could not be counted — the recorded commit may no longer be in this clone's history. Run analyze tool to update.\"\n }\n}\n```\n\nSo: **read `status` before using `commitsBehind`**, and read `branch`/`lastCommit` before assuming which ref the answer describes. `status: \"unknown\"` means the freshness check could not run at all (a `--skip-git` folder has no history to measure) — the ref is still reported, because which index answered is knowable even when its freshness is not. The field is only ever added to object results — raw-array `cypher` output and error envelopes are returned unchanged. `@group`-targeted calls do not carry it (multi-repo staleness is ill-defined). Re-run `analyze` only for `behind` or `diverged` — those mean the index is not at this clone's HEAD. `unknown` is unmeasurable, not stale; analyze cannot make it `current` unless git history exists.\n\n`list_repos` and the HTTP repo routes are unchanged: they omit `staleness` entirely for a current index and report the ref through their own top-level `branch` / `lastCommit` / `indexedAt` fields.\n\n### Taint findings (`explain`)\n\n`explain` returns taint findings recorded by `gitnexus analyze --pdg` — intra-procedural `TAINTED` edges plus cross-function `TAINT_PATH` hops where the interprocedural taint phase found a function-level source→sink chain. Each finding includes a sink category (command-injection, code-injection, path-traversal, sql-injection, xss), source/sink lines, and the ordered hop path with the variable carried on each hop.\n\n- `explain {}` — enumerate all findings for the repo (bounded by `limit`, deterministic order)\n- `explain { target: \"src/vuln.ts\" }` — findings in a file (suffix path match accepted)\n- `explain { target: \"runUserCommand\" }` — findings in a function (resolved like `context`; ambiguous names return ranked candidates)\n\nA repo indexed without `--pdg` returns a clear \"no taint layer\" note. Caveats: closure/callback, property/field, and implicit flows are not modeled, and interprocedural findings are function-level `TAINT_PATH` hops rather than statement-level path proof, so the absence of a finding is **not** proof of safety. `SANITIZES` (sanitizer-kill) edges are queryable via `cypher`.\n\n### Control & data dependence (`pdg_query`)\n\n`pdg_query` reads the control/data-dependence layers `gitnexus analyze --pdg` records (CDG + REACHING_DEF, basic-block granular) — the control/data analog of `explain`. It is **always anchored** (a `target` file path or symbol, resolved like `context`) and has two modes:\n\n- `pdg_query { mode: \"controls\", target: \"...\" }` — CDG: \"under what condition does X run?\". Each edge is a controlling predicate block → dependent block with the branch sense (`'T'`/`'F'`) in `reason`; an edge into an early `return`/`throw` is flagged `guard: true` (guard-clause discovery — the sense depends on the predicate, so don't filter guards by a fixed label).\n- `pdg_query { mode: \"flows\", target: \"...\", variable?: \"...\" }` — REACHING_DEF def→use edges within the function; pass `variable` to trace one binding.\n\nA repo indexed without `--pdg` returns a \"no PDG layer\" note (or \"status unknown\" when the layer can't be confirmed). Intra-procedural only — cross-function flow is taint's domain (`explain`). The raw CDG/REACHING_DEF edges are also queryable via `cypher`. See the `gitnexus-pdg-query` skill for the full query surface.\n\n### Shortest path between two symbols (`trace`)\n\n`trace` answers \"how does A reach B?\" in one call — the shortest directed path over `CALLS` (plus `HAS_METHOD`, so a class-rooted trace descends into its methods) instead of chaining 3–8 `context`/`impact` hops by hand.\n\n- `trace { from: \"validateUser\", to: \"executeQuery\" }` — shortest path between two symbols.\n- Disambiguate common names with `from_uid`/`to_uid` (zero-ambiguity) or `from_file`/`to_file`; an ambiguous name returns ranked candidates.\n- `maxDepth` (default 10, max 30) bounds the search; `includeTests` (default false) lets the traversal pass through test-file symbols.\n\nReturns ordered `hops` (each `{ name, filePath, startLine }`) and an aligned `edges[]` of `{ relType, confidence }`, so call hops and containment (`HAS_METHOD`) hops stay distinguishable. When no path exists it reports the **furthest** reachable node (where the chain breaks) and sets `truncated: true` if a traversal cap was hit first. Every result carries a `status`: `ok` / `no_path` / `ambiguous` / `not_found` / `error`.\n\nCross-repo (experimental): pass `repo: \"@groupName\"` to trace across a group's member repos — the path may cross **one** `ContractLink` boundary (reported as a `CONTRACT_LINK` hop with the bridged contract in `crossings[]`). Omit `to` entirely to follow `from`'s outgoing HTTP call to whatever provider endpoint it lands on. Groups are configured via `group_list` / `group_sync`.\n\n## Resources Reference\n\nLightweight reads (~100-500 tokens) for navigation:\n\n| Resource | Content |\n| ---------------------------------------------- | ----------------------------------------- |\n| `gitnexus://repo/{name}/context` | Stats, staleness check |\n| `gitnexus://repo/{name}/clusters` | All functional areas with cohesion scores |\n| `gitnexus://repo/{name}/cluster/{clusterName}` | Area members |\n| `gitnexus://repo/{name}/processes` | All execution flows |\n| `gitnexus://repo/{name}/process/{processName}` | Step-by-step trace |\n| `gitnexus://repo/{name}/schema` | Graph schema for Cypher |\n\n## Graph Schema\n\n**Nodes:** File, Folder, Function, Class, Interface, Method, CodeElement, Community, Process, Route, Tool, plus language-specific types (Struct, Enum, Trait, Impl, Namespace, Module, …) and BasicBlock (`--pdg` indexes only). The full node list lives in `gitnexus://repo/{name}/schema`.\n**Edges (via CodeRelation.type):** CALLS, IMPORTS, EXTENDS, IMPLEMENTS, DEFINES, CONTAINS, MEMBER_OF, HAS_METHOD, HAS_PROPERTY, ACCESSES, METHOD_OVERRIDES, METHOD_IMPLEMENTS, STEP_IN_PROCESS, HANDLES_ROUTE, FETCHES, HANDLES_TOOL, ENTRY_POINT_OF, WRAPS, QUERIES, INJECTS, plus `--pdg`-only types (CFG, REACHING_DEF, TAINTED, SANITIZES, TAINT_PATH, CDG — zero rows on a default index).\n\nRead `gitnexus://repo/{name}/schema` before writing Cypher — it is the authoritative schema for the indexed repo.\n\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"myFunc\"})\nRETURN caller.name, caller.filePath\n```\n","gitnexus-claude-plugin/skills/gitnexus-cli/SKILL.md":"---\nname: gitnexus-cli\ndescription: \"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \\\"Index this repo\\\", \\\"Reanalyze the codebase\\\", \\\"Generate a wiki\\\"\"\n---\n\n# GitNexus CLI Commands\n\nCommands below use `node .gitnexus/run.cjs ` — the project-local runner `gitnexus analyze` drops next to the index. It auto-selects an available runner at call time (global `gitnexus`, else `pnpm dlx`, else `bunx`, else `npx`), so no package-manager assumption and no global install is required — including on a bun-only machine, which has no npm, npx or pnpm at all.\n\n> **Not analyzed yet, or `node .gitnexus/run.cjs` reports `Cannot find module`** (the gitignored runner is absent — e.g. a fresh clone or `git clean`)? (Re)generate it with `npx gitnexus analyze` from the project root, or `bunx gitnexus@latest analyze` on a bun-only machine. On **npm 11.x**, if `npx` crashes during install (`node.target is null`), install once with `npm i -g gitnexus` (then `gitnexus analyze`), or use `bunx gitnexus@latest analyze`, or `pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze`. See [#1939](https://github.com/abhigyanpatwari/GitNexus/issues/1939).\n\n## Commands\n\n### analyze — Build or refresh the index\n\n```bash\nnode .gitnexus/run.cjs analyze\n```\n\nRun from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.\n\n| Flag | Effect |\n| -------------- | ---------------------------------------------------------------- |\n| `--watch` | Keep a Git repository index current with serialized refreshes |\n| `--debounce ` | Watch quiet period before refresh (default: 300 ms) |\n| `--force` | Force full re-index even if up to date |\n| `--embeddings` | Enable embedding generation for semantic search (off by default) |\n| `--drop-embeddings` | Drop existing embeddings on rebuild. By default, an `analyze` without `--embeddings` preserves them. |\n| `--pdg` | Build the program-dependence layers used by `explain` and `pdg_query` (taint, CDG, and REACHING_DEF). |\n| `--spring-actuator ` | Import opt-in Spring Boot Actuator mappings, beans, conditions, configprops, and env snapshots. Forces a full rebuild; unsupported with `--watch`. |\n| `--asyncapi-spec ` | Read opt-in AsyncAPI 3.x documents (directory or single file) and mint `Destination` nodes from their operations. 2.x is refused, not mapped. Unsupported with `--watch`. |\n\n**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook detects staleness after `git commit` and `git merge` and notifies the agent to run `analyze` — the hook does not run analyze itself, to avoid blocking the agent for up to 120s and risking KuzuDB corruption on timeout.\n\nFor Spring runtime enrichment, pass a JSON bundle, one endpoint JSON file, or a directory containing endpoint files. Route evidence is authoritative only when `runtimeConfirmed === true`; `runtimeSource` records provenance and may also accompany `handler-conflict`. Env/configprops values are never persisted.\n\n## Index storage and retention\n\nDefault location is `/.gitnexus/`. Override with environment variables (also documented in README):\n\n| Env | Effect |\n| --- | ------ |\n| `GITNEXUS_STORAGE_PATH` | One complete external index directory. Wins if both storage vars are set. |\n| `GITNEXUS_STORAGE_ROOT` | Absolute root; GitNexus creates an isolated `-<12-hex>/` slot per repository. |\n| `GITNEXUS_CONTENT_RETENTION` | `full` (default) keeps file text; `symbol` keeps snippets; `none` keeps the graph only. |\n\n`list_repos`, `gitnexus://repo/{name}/context`, and HTTP `GET /api/repos` / `GET /api/repo` expose `storagePath`, `contentRetention`, and `sourceAvailable`. HTTP `/api/file` and `/api/grep` return 410 unless retention is `full`. MCP `include_content` may still return symbol spans when retention is `symbol`.\n\nUse `node .gitnexus/run.cjs analyze --watch` for a long-lived local Git repository. It performs an initial analysis, queues scanner-admitted file changes, and retries intact failed batches with bounded backoff. Watch refreshes update only the graph: they skip AGENTS.md / CLAUDE.md injection and standard skill installation, so run a one-shot `analyze` when those generated files need updating. Watch rejects one-shot or context-output flags including `--force`, embedding flags, `--skills`, `--default-branch`, `--skip-agents-md`, `--skip-skills`, `--no-stats`, `--self-commit`, `--index-only`, and `--skip-git`. It never pulls remotes. Scheduled remote clone/pull is a different command: `gitnexus auto-sync`. Bare `gitnexus watch` is reserved and does not start either job. Running MCP and `serve` processes periodically check for a published replacement and reopen it without a restart. MCP checks are throttled to once every five seconds, so a tool call before the next check can briefly use the previous index.\n\n### status — Check index freshness\n\n```bash\nnode .gitnexus/run.cjs status\n```\n\nShows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.\n\n### clean — Delete the index\n\n```bash\nnode .gitnexus/run.cjs clean\n```\n\nDeletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.\n\n| Flag | Effect |\n| --------- | ------------------------------------------------- |\n| `--force` | Skip confirmation prompt |\n| `--all` | Clean all indexed repos, not just the current one |\n\n### wiki — Generate documentation from the graph\n\n```bash\nnode .gitnexus/run.cjs wiki\n```\n\nGenerates repository documentation from the knowledge graph using an LLM. HTTP providers require an API key (saved to `~/.gitnexus/config.json` on first use). Local CLI providers (`--provider cursor|claude|codex|opencode|grok`) use your existing CLI login.\n\n| Flag | Effect |\n| ------------------- | ----------------------------------------- |\n| `--force` | Force full regeneration, also required to re-generate an existing wiki in a different language |\n| `--provider ` | LLM provider: minimax, openai, openrouter, azure, custom, cursor, claude, codex, opencode, or grok (default: minimax). Local CLIs (`cursor`, `claude`, `codex`, `opencode`, `grok`) use your existing CLI login and skip `--api-key`. |\n| `--model ` | LLM model (default: MiniMax-M3) |\n| `--base-url ` | LLM API base URL |\n| `--api-key ` | LLM API key |\n| `--concurrency ` | Parallel LLM calls (default: 3) |\n| `--timeout ` | LLM request timeout in seconds (default: disabled) |\n| `--retries ` | Max LLM retry attempts per request (default: 3) |\n| `--lang ` | Output language for generated documentation (e.g. english, chinese, spanish, japanese) |\n| `--gist` | Publish wiki as a public GitHub Gist |\n\n### list — Show all indexed repos\n\n```bash\nnode .gitnexus/run.cjs list\n```\n\nLists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.\n\n## After Indexing\n\n1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded\n2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task\n\n## Troubleshooting\n\n- **\"Not inside a git repository\"**: Run from a directory inside a git repo\n- **Index is stale after re-analyzing**: Wait for the next MCP tool call to reopen the published index; this normally takes no more than five seconds\n- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding\n",".claude/skills/gitnexus-plan/SKILL.md":"---\nname: gitnexus-plan\ndescription: 'Use when you need a deep, implementation-ready engineering plan for a code change — built from GitNexus graph intelligence, statement-level PDG analysis, and targeted source verification, compact enough that an implementation agent can start without re-investigating. Also strengthens existing plans via Deepen mode. Examples: \"/gitnexus-plan Add retry support to the ingestion pipeline\", \"/gitnexus-plan deepen docs/plans/.md\", \"plan this change using the knowledge graph\".'\n---\n\n# gitnexus-plan — implementation-ready engineering plans\n\nProduce an implementation-ready plan for an engineering task. GitNexus is the\nnavigation layer (where to look), statement-level PDG is the constraint layer\n(what gates and feeds the behavior), and your native targeted source reads are\nthe verification layer (what is actually true right now). The output is a plan\ndocument plus a compact, machine-readable **implementation context pack**\nthat a follow-up implementation agent (`gitnexus-work`, or any executor) can\nconsume without repeating the investigation.\n\n```\n/gitnexus-plan \n/gitnexus-plan impact_depth:3 depth:deep # knob overrides, see Configuration\n```\n\n**This skill plans. It never implements.** Do not modify production code,\ntests, or configuration while running it. The only repository file it writes\nis the plan document (a working ledger kept outside the repo is fine). The\nonly other permitted state change is an index refresh via\n`analyze --index-only`, which writes only the `.gitnexus` index store. It\nmust not build analyzer `dist/` output and must not mutate source, tests,\nconfiguration, or evaluation data. Stale analyzer provenance is disclosed as\na source-weighted limitation, never repaired by a planning run.\n\n## Hard rules\n\n- **Ledger first.** Before every GitNexus call and every repo file read, check\n the context ledger. Never repeat a query or reread an unchanged range that\n already answered the same question (allowed repeats are defined in\n `references/context-ledger.md`; this skill's own reference files are exempt\n from ledger bookkeeping).\n- **Every graph query answers a named planning question.** Record the question\n and the conclusion in the ledger. No exploratory dredging.\n- **Source beats graph.** The graph navigates; current source is authoritative.\n Verify before asserting (see Phase 4). Comments are the weakest evidence —\n never stronger than executable code.\n- **No fabrication.** Never invent symbols, filenames, test names, tool\n results, or PDG edges. Unknowns go to _Assumptions and Open Questions_.\n- **No scope creep.** Adjacent refactors the task didn't ask for go to plan\n §12 as explicitly-deferred follow-ups, not into Proposed Changes.\n- **Pin working-tree evidence, not only HEAD.** Every plan form carries the\n versioned global dirty digest and sorted cited-path manifest defined in\n `references/context-ledger.md`. Generate it only with the portable helper\n and byte contract in `scripts/evidence-provenance.mjs` and\n `references/evidence-provenance.md`; never reimplement the digest.\n- **Write the plan only through the helper.** The generated-plan path is a\n normalized repo-relative\n `docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md` path. Compose the\n complete UTF-8 document in memory or in a scratchpad outside the target\n repo, then pass it on stdin to the helper's `write-plan` command. Never\n write the destination directly or fall back to an external output path when\n the safe writer fails.\n- **Read an existing plan only through the helper.** Deepen must invoke\n `scripts/evidence-provenance.mjs read-plan`, parse the exact decoded\n `plan_bytes_base64` from its descriptor-anchored receipt, and retain that\n receipt's canonical `generated_plan_path` and `plan_digest` as one binding.\n Never parse a direct lexical-path read or apply one plan's digest to another\n path.\n- **Stop when you have enough.** Sufficient evidence ends exploration; plans\n do not improve monotonically with tokens spent.\n\n## Phase 0 — Parse and classify\n\nRead `references/context-ledger.md` and open the ledger with the task:\noriginal request, interpreted goal, acceptance criteria. Classify the task:\n\n| Category | Posture (depth · plan form · tool-call budget · freshness) |\n| ------------------------------ | -------------------------------------------------------------------------------- |\n| Bug fix (local) | Narrow, 1–2 primary symbols, `impact_depth` 1 · compact · ~15 · accept |\n| Feature | Default knobs · compact · ~30 · accept |\n| Refactor / shared API change | Impact mandatory, `impact_depth` 3 · full · ~45 · strict |\n| Performance | Default + performance PDG mode (`references/pdg-slice.md`) · full · ~45 · strict |\n| Security | Default + security PDG mode + `explain` taint findings · full · ~45 · strict |\n| Dependency upgrade / migration | Impact + compatibility focus; PDG rarely needed · compact · ~20 · accept |\n| Concurrency / transactional | Control-flow + state-mutation PDG focus · full · ~45 · strict |\n| Test improvement / docs | Narrowest: usually no impact or PDG pass · compact · ~10 · accept |\n| Architecture change / spike | Widest: clusters + processes first · full · no cap · strict |\n\nThe category posture overrides the Configuration baseline; explicit `key:value`\ninvocation knobs override both. A task matching several rows combines them:\ntake the widest depth, union the focus areas.\n\n**Seeded evidence.** When a completed investigation already supplies\nverified findings — a finished review, a triage document with `path:line`\nanchors and named failing scenarios — open the ledger FROM it: cite the\nsource document as the opening ledger entries and plan directly against\nthem instead of re-running the graph ladder over ground it already covers.\nRe-deriving what the evidence proves is budget spent against the\nturn-economy rule. Phase 4 still source-verifies whatever Proposed Changes\nwill cite, at the pinned commit — seeding replaces exploration, never\nverification.\n\n**Depth is the user's decision, asked once, up front.** In an interactive\nsession, when the invocation carries no explicit depth signal (no `depth:`,\n`form:`, or `freshness:` knob, and not Deepen mode), ask one blocking\nquestion before Phase 1 — how deep should this plan go?\n\n1. **Quick** — `depth:narrow form:compact freshness:accept`. Fastest useful\n plan: 1–2 primary symbols, minimal graph work, core sections only.\n2. **Standard** — the category posture above, unchanged. Recommend this\n unless the classification argues otherwise.\n3. **Deep** — `depth:deep form:full freshness:strict`. All 13 sections,\n `impact_depth` 3, clusters/processes read, PDG slices for the central\n functions.\n\nThe answer sets the knobs exactly as if they had been typed in the\ninvocation; explicit knobs win and skip the question. Headless runs never\nask — the category posture applies unchanged. Asking up front replaces\noffering to deepen a finished plan afterwards: Deepen mode (below) remains\nthe mechanism for strengthening an existing plan document — a later session,\nreview findings, an executor route-back — not a default follow-up question.\n\n**Turn economy is a deliverable.** The plan is judged on decision quality per\ntoken, not thoroughness theater (measured: a 63-turn plan for a two-line\nchange — the GitNexus repo's `eval/workflow_bench/`). Stay within the category's tool-call\nbudget; when the budget runs out with questions still open, record them in\n§12 instead of digging further — the executor re-verifies cheaply anyway.\n\n## Phase 1 — Anchor and freshness\n\n1. Resolve the target repo: `list_repos` if in doubt, else the indexed repo\n covering the working directory. Pass `repo` explicitly on every call when\n more than one repo is indexed.\n2. Record the repo's current HEAD commit in the ledger — every line-number\n citation in the plan is pinned to it.\n3. **Resolve and record the analyzer runner** (used by every `analyze`\n command in this skill): `node .gitnexus/run.cjs analyze …` when the\n project has a runner (a previous analyze dropped it next to the index),\n else `gitnexus analyze …` (installed CLI — `npm install -g gitnexus`),\n else `npx gitnexus analyze …`. Record its path/version and any available\n source/build identity; do not manufacture provenance from timestamps.\n4. Read `gitnexus://repo/{name}/context` — codebase overview + staleness check.\n **Freshness gate.** Plans built on a stale graph make stale blast-radius\n claims — but a re-index is the largest fixed cost a planning session\n carries, so the gate is category-priced:\n - Compact-plan categories default to `freshness: accept`: plan on the\n current graph with source verification weighted higher — their plans\n cite little graph evidence. Escalate to a refresh mid-plan only when a\n graph claim becomes load-bearing (e.g. Proposed Changes rest on a d=1\n dependent list), and only then.\n - Full-plan categories default to `freshness: strict`, and under it:\n - **Analyzer provenance check — before any refresh.** Compare the resolved\n runner identity with the index metadata and, in an analyzer-source\n checkout, with current analyzer source. If identity is stale or unknown,\n do not build output and do not make that graph load-bearing. Record a\n **stale analyzer provenance — source-weighted limitation** in\n `index_refresh`, the plan header, and §12; rely on targeted source reads\n or hand execution to `gitnexus-work`, which owns the build-current gate.\n - Stale index → run `analyze --index-only` via the resolved runner\n (append `--pdg` when the task category will reach Phase 3) and re-read\n the context resource **only when runner provenance is known-current**.\n Refresh budget, stated once here: at most one `--index-only` refresh in\n Phase 1 **plus** at most one later `--pdg` upgrade in Phase 3 (only when\n Phase 1's refresh lacked `--pdg`) per planning session — a Deepen run is\n its own session. Record each command, runner identity, and outcome in the\n ledger's `index_refresh`.\n - Refresh failed or impractical (no write access to the index, prohibitive\n repo size), or `freshness: accept` was passed → proceed on the stale\n graph, weight source verification higher, and state the staleness and\n the skipped refresh in the plan header and Assumptions.\n - Resources unreadable but tools working → proceed on tools alone, treat\n freshness as unknown (weight source higher), and note it in the plan.\n - GitNexus unavailable entirely → switch to **Fallback mode** (below).\n5. For architecture-scale tasks only, also read\n `gitnexus://repo/{name}/clusters` and `.../processes`.\n\n## Phase 2 — Graph navigation ladder\n\nUse the narrowest operation that answers the current ledger question, in this\norder. Budgets: at most `max_primary_symbols` (5) primary symbols and\n`max_related_symbols` (20) related symbols active in the ledger.\n\n1. `query {search_query, task_context}` — locate concepts, execution flows,\n modules, and related tests for the task.\n2. `context {name}` — 360° view of each candidate primary symbol: callers,\n callees, categorized refs, processes. Promote to primary or discard. An\n `ambiguous` result (ranked candidates) is answered by one retry narrowed\n with `kind` / `file_path` / uid — that retry is an allowed repeat.\n3. `impact {target, direction}` — upstream/downstream blast radius for shared\n or high-connectivity symbols (`maxDepth` = `impact_depth`; `summaryOnly:\ntrue` first for hub symbols, then drill in — an allowed repeat). Record the\n d=1 items — the **direct (depth-1) dependents** — the plan must account\n for every one of them.\n4. `trace {from, to}` — when the task hinges on _how A reaches B_, one call\n instead of chained context hops.\n5. Statement-level PDG — Phase 3, for the functions the change centers on.\n6. `cypher` — last resort, only for a precise graph question the tools above\n cannot express. Read `gitnexus://repo/{name}/schema` first; anchor and\n LIMIT every query.\n7. `detect_changes {scope}` — only when planning against existing uncommitted\n or branch work.\n\nDo not run every tool by default. A local test fix may finish the ladder at\nstep 2.\n\n## Phase 3 — Statement-level PDG slice\n\nFor the 1–3 functions most central to the change, build a bounded **PDG\ncontext slice**. Read `references/pdg-slice.md` and follow it — it owns the\ntool calls, inclusion criteria, depth bounds, slice schema, the security and\nperformance modes, and the no-PDG-layer fallback.\n\n## Phase 4 — Targeted source verification\n\nGitNexus said where to look; now confirm what is there. Using ordinary file\nreads (exact line ranges, not whole files unless genuinely required):\n\n- Read every source range the plan will cite: signatures, branch conditions,\n state mutations, error paths, nearby comments that change behavior. Compact\n plans cite less — verify what they cite, don't expand the citation set to\n have more to verify.\n- Read the tests GitNexus associated with the primary symbols; never claim a\n test exists without having located it.\n- Verify the build/test commands the plan will name actually exist\n (package.json scripts / CI workflows), and prefer the script form that\n carries its prerequisites (pre-hooks) over invoking underlying binaries\n directly.\n- Check repo conventions that constrain the change (AGENTS.md, GUARDRAILS.md,\n lint/build config) — only the parts the change touches.\n- Mark each ledger symbol `source_verified: true` as you go. **A symbol that\n is named in Proposed Changes must be source-verified.**\n- On graph/source disagreement: trust source, record the discrepancy in the\n ledger and the plan, recommend re-indexing. Never present stale graph data\n as fact.\n- Immediately before composition, recompute the versioned\n `evidence_provenance` snapshot by invoking\n `scripts/evidence-provenance.mjs` exactly as specified in\n `references/evidence-provenance.md`: the\n canonical global dirty digest over all dirty paths and the sorted manifest\n of every cited path, including object kind and\n HEAD/index/worktree/untracked layer digests. Re-read any citation that\n changed during planning. Exclude only the generated plan path.\n\nEvidence hierarchy, strongest first: current source and config → current tests\nand executable behavior → compiler/build/lint output → GitNexus graph and PDG\n→ documentation and comments.\n\n## Phase 5 — Compose the plan\n\n1. Read `references/plan-template.md` and fill the category's form — compact\n (core sections, ≤80 lines excluding the pack) or full (all 13 sections) —\n from the ledger, tagging claims with the template's four classes —\n `[verified]`, `[graph]`, `[inferred]`, `[assumed]` — and routing open\n questions to §12.\n2. Build the implementation context pack per `references/context-pack.md`\n (this is section 11 of the plan), including mandatory\n `evidence_provenance` in compact and full forms.\n3. Set `generated_plan_path` to\n `docs/plans/YYYY-MM-DD-gitnexus-plan-.md` under the root of the repo\n being planned (the Phase 1 target repo, not necessarily the cwd); use a\n 3–5-word kebab-case slug and repo-relative paths inside the document.\n Compose the complete document without creating that destination, then\n pipe its exact UTF-8 bytes to `scripts/evidence-provenance.mjs write-plan`\n as specified in `references/evidence-provenance.md`. The helper safely\n creates missing parent directories. Initial planning must not pass\n `--replace`. A safe-write failure blocks plan publication: report it and\n do not write directly, choose an external destination, or weaken the\n repo-relative provenance contract. The snapshot and writer commands apply\n the same strict generated-plan filename/date validator; do not substitute a\n source, `.git`, or arbitrary `docs/plans/` path in either invocation.\n4. Present in chat: objective, proposed-changes summary, implementation\n sequence, top risks, open questions, and the plan file path. Do not paste\n the whole document into chat.\n\n## Deepen mode\n\n`/gitnexus-plan deepen ` strengthens an existing plan in place\ninstead of creating a new one:\n\n1. Resolve the target repository and normalized repo-relative plan candidate,\n then load it with `scripts/evidence-provenance.mjs read-plan --repo \n--generated-plan ` exactly as specified in\n `references/evidence-provenance.md`. Reject a missing, external, escaping,\n symlinked, or differently scoped path. Decode and parse only the receipt's\n exact `plan_bytes_base64`; retain its canonical `generated_plan_path` and\n `plan_digest` unchanged for the entire Deepen session.\n2. Re-run Phase 1 in full — analyzer provenance check and freshness gate (a\n Deepen run is its own session, with its own refresh budget).\n3. **Re-anchor before re-pinning.** Recompute the plan's global dirty digest\n and cited-path manifest as well as comparing its old HEAD pin with current\n HEAD. Changed, renamed, deleted, mixed, or newly absent cited paths get\n their ranges re-read — or the claim downgraded — _before_ the pin and\n provenance snapshot move. Moving only the commit pin silently launders\n dirty or stale claims as verified.\n4. Escalate to `depth: deep` (impact_depth 3, clusters/processes read)\n unless the invocation overrides knobs explicitly.\n5. Seed the ledger from the plan's §11 pack, then re-verify: every\n `[graph]`/`[inferred]` claim gets a targeted pass toward `[verified]`;\n every `[assumed]` claim is resolved or kept with its reason; direct\n (d=1) dependent accounting is re-checked against the refreshed graph;\n PDG slices are built or expanded for the central functions when the\n layer is present.\n6. **Reconcile execution state.** If `gitnexus-work` already landed commits\n for this plan (a mid-execution route-back), mark the §7 steps present at\n HEAD as completed and re-sequence the remainder — the rewritten plan must\n be executable from the top without redoing landed steps.\n7. Strengthen whatever the deeper pass showed thin — test scenarios, risks,\n Definition of Done — and carry claim-tag upgrades through the prose.\n8. Rewrite the **same canonical file** through\n `scripts/evidence-provenance.mjs write-plan --replace\n--expected-plan-path \n--expected-plan-digest `: same 13 sections,\n context pack kept in sync, evidence header updated. `--replace` is reserved\n for Deepen mode, and both expected values must come from the same read-plan\n receipt; any digest/path mismatch blocks publication. Retain the successful receipt's\n `prior_plan_backup_git_path`; it names the verified Git-admin backup of the\n displaced plan. Summarize the delta in chat: claims upgraded, claims that\n failed re-verification, sections changed, and that backup path.\n\n## Configuration\n\nBaseline defaults — the Phase 0 category posture overrides them, and inline\n`key:value` tokens before the task text override both (the repo has no\nskill-config file mechanism; invocation args are the mechanism):\n\n| Knob | Default | Meaning |\n| --------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `depth` | by category | `narrow` = `impact_depth` 1, PDG only if one function is clearly central; `default` = this table; `deep` = `impact_depth` 3 + clusters/processes read |\n| `form` | by category | `compact` (core sections + mini-pack, ≤80 lines excl. pack — see `references/plan-template.md`) or `full` (all 13 sections) |\n| `impact_depth` | 2 | `maxDepth` for `impact` |\n| `pdg_data_depth` | 2 | Data-dependence hops in the PDG slice |\n| `pdg_control_depth` | 2 | Control-dependence hops in the PDG slice |\n| `max_primary_symbols` | 5 | Ledger budget (active symbols; discards don't count) |\n| `max_related_symbols` | 20 | Ledger budget (active symbols; discards don't count) |\n| `max_snippet_lines` | 30 | Longest source excerpt quoted in the plan |\n| `freshness` | by category | `strict` (full-plan categories) = refresh a stale index (and a missing PDG layer) with `analyze --index-only [--pdg]` before relying on the graph; `accept` (compact categories) = plan on the current graph, source-weighted and labelled, refreshing only if a graph claim becomes load-bearing |\n\n## Fallback mode (GitNexus or PDG unavailable)\n\n1. Say so, first thing, in chat and in the plan.\n2. Use targeted repo exploration (grep/glob/reads) to approximate callers,\n dependencies, execution flow, state changes, and related tests.\n3. Label every such finding **source-derived** in the plan — never present it\n as graph-derived, and never fabricate statement-level edges.\n4. Recommend `analyze --index-only` (add `--pdg` for the PDG layers) via\n the resolved runner — `node .gitnexus/run.cjs`, installed `gitnexus`, or\n `npx gitnexus` — when it would materially raise confidence.\n\n## Skill feedback\n\nIf this run exposed friction in the instructions, include concise feedback in\nthe final response. Feedback is chat-only: do not append evaluation learnings,\nedit benchmark data, or modify this skill during a live planning task.\n",".claude/skills/gitnexus-pr-swarm-review/SKILL.md":"---\nname: gitnexus-pr-swarm-review\ndescription: \"Run a GitNexus production-readiness pull request review using a coordinated reviewer swarm.\"\n---\n\n# GitNexus PR Swarm Review (Claude Code adapter)\n\nUse this skill to review a GitNexus pull request and produce a production-readiness review.\n\n> This is the interactive, on-demand reviewer swarm. It is distinct from the CI\n> `gitnexus-review` skill's built-in \"Swarm lanes\" (`ci-personas/`), which the\n> review-agent workflow dispatches automatically inside a single review run.\n\n```\n/gitnexus-pr-swarm-review \n```\n\nYou are the **swarm coordinator**. The full review contract — lanes, dependencies,\nclassifications, output structure, finding format, hidden-Unicode checks, and behavior\nrules — is the canonical, CLI-neutral spec:\n\n**`pr-swarm-review/orchestration.md`** — read it now and follow it.\n\nThis adapter only pins the Claude Code specifics:\n\n- **Run in Swarm mode.** Dispatch each lane as its own subagent via the Agent tool. The\n seven subagents are the project agents named `gitnexus-*` (one per persona); each reads\n its canonical persona under `pr-swarm-review/personas/`. Run lanes 1–2 first, lanes 3–6\n in parallel after, and lane 7 last on the draft.\n- **Lane 7 is a hard gate.** Do not emit the final review while the synthesis critic's\n \"Required corrections before posting\" section is non-empty — revise and re-run it.\n- Stay **read-only**: investigate and report; never edit, commit, or post.\n\nDo not flatten the review into a generic checklist; delegate to the subagents and\nsynthesize per `orchestration.md`.\n","gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md":"# gitnexus-debugging\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md":"# gitnexus-exploring\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md":"# gitnexus-guide\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md":"# gitnexus-impact-analysis\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md":"# gitnexus-lfg\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md":"# gitnexus-pdg-query\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md":"# gitnexus-plan\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md":"# gitnexus-refactoring\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md":"# gitnexus-review\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md":"# gitnexus-taint-analysis\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md)","gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md":"# gitnexus-work\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md":"# gitnexus-debugging\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md":"# gitnexus-exploring\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md":"# gitnexus-impact-analysis\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md":"# gitnexus-refactoring\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md)","gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md":"# gitnexus-review\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md)","gitnexus/skills/gitnexus-lfg/SKILL.md":"# gitnexus-lfg\n\nPath: `gitnexus/skills/gitnexus-lfg/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-lfg/SKILL.md)","gitnexus/skills/gitnexus-plan/SKILL.md":"# gitnexus-plan\n\nPath: `gitnexus/skills/gitnexus-plan/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/SKILL.md)","gitnexus/skills/gitnexus-review/SKILL.md":"# gitnexus-review\n\nPath: `gitnexus/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/SKILL.md)","gitnexus/skills/gitnexus-work/SKILL.md":"# gitnexus-work\n\nPath: `gitnexus/skills/gitnexus-work/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/SKILL.md)",".claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md":"# gitnexus-pdg-query\n\nPath: `.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md)",".claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md":"# gitnexus-taint-analysis\n\nPath: `.claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md)",".cursorrules":"# Cursor IDE Native Rules\n\nPath: `.cursorrules`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursorrules)",".windsurfrules":"# Windsurf Cascade Agent Rules\n\nPath: `.windsurfrules`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.windsurfrules)","AGENTS.md":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/AGENTS.md)","ARCHITECTURE.md":"# System Architecture & Module Boundaries\n\nPath: `ARCHITECTURE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/ARCHITECTURE.md)","CLAUDE.md":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/CLAUDE.md)","llms.txt":"# LLM Index & Context Digest\n\nPath: `llms.txt`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/llms.txt)",".claude-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude-plugin/marketplace.json)",".factory-plugin/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.factory-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.factory-plugin/marketplace.json)","gitnexus-factory-plugin/mcp.json":"# Model Context Protocol (MCP) Configuration\n\nPath: `gitnexus-factory-plugin/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-factory-plugin/mcp.json)",".agents/plugins/marketplace.json":"# Claude Plugin Marketplace Catalog\n\nPath: `.agents/plugins/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.agents/plugins/marketplace.json)",".claude/agents/gitnexus-branch-hygiene-reviewer.md":"# Subagent: gitnexus-branch-hygiene-reviewer\n\nPath: `.claude/agents/gitnexus-branch-hygiene-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-branch-hygiene-reviewer.md)",".claude/agents/gitnexus-docs-dod-reviewer.md":"# Subagent: gitnexus-docs-dod-reviewer\n\nPath: `.claude/agents/gitnexus-docs-dod-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-docs-dod-reviewer.md)",".claude/agents/gitnexus-pr-facts-historian.md":"# Subagent: gitnexus-pr-facts-historian\n\nPath: `.claude/agents/gitnexus-pr-facts-historian.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-pr-facts-historian.md)",".claude/agents/gitnexus-risk-architect.md":"# Subagent: gitnexus-risk-architect\n\nPath: `.claude/agents/gitnexus-risk-architect.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-risk-architect.md)",".claude/agents/gitnexus-security-boundary-reviewer.md":"# Subagent: gitnexus-security-boundary-reviewer\n\nPath: `.claude/agents/gitnexus-security-boundary-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-security-boundary-reviewer.md)",".claude/agents/gitnexus-synthesis-critic.md":"# Subagent: gitnexus-synthesis-critic\n\nPath: `.claude/agents/gitnexus-synthesis-critic.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-synthesis-critic.md)",".claude/agents/gitnexus-test-ci-verifier.md":"# Subagent: gitnexus-test-ci-verifier\n\nPath: `.claude/agents/gitnexus-test-ci-verifier.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-test-ci-verifier.md)",".cursor/commands/gitnexus-pr-swarm-review.md":"# Command: /gitnexus-pr-swarm-review\n\nPath: `.cursor/commands/gitnexus-pr-swarm-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/commands/gitnexus-pr-swarm-review.md)",".cursor/rules/100-monorepo.mdc":"# Cursor Rule: 100-monorepo\n\nPath: `.cursor/rules/100-monorepo.mdc`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/rules/100-monorepo.mdc)",".cursor/rules/200-eval.mdc":"# Cursor Rule: 200-eval\n\nPath: `.cursor/rules/200-eval.mdc`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/rules/200-eval.mdc)","gitnexus-claude-plugin/.claude-plugin/plugin.json":"# claude-plugin Plugin Manifest\n\nPath: `gitnexus-claude-plugin/.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/.claude-plugin/plugin.json)","gitnexus-claude-plugin/.codex-plugin/plugin.json":"# codex-plugin Plugin Manifest\n\nPath: `gitnexus-claude-plugin/.codex-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/.codex-plugin/plugin.json)","gitnexus-factory-plugin/.factory-plugin/plugin.json":"# factory-plugin Plugin Manifest\n\nPath: `gitnexus-factory-plugin/.factory-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-factory-plugin/.factory-plugin/plugin.json)","gitnexus/skills/gitnexus-cli.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-cli.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-cli.md)","gitnexus/skills/gitnexus-debugging.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-debugging.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-debugging.md)","gitnexus/skills/gitnexus-exploring.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-exploring.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-exploring.md)","gitnexus/skills/gitnexus-guide.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-guide.md)","gitnexus/skills/gitnexus-impact-analysis.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-impact-analysis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-impact-analysis.md)","gitnexus/skills/gitnexus-pdg-query.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-pdg-query.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-pdg-query.md)","gitnexus/skills/gitnexus-refactoring.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-refactoring.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-refactoring.md)","gitnexus/skills/gitnexus-taint-analysis.md":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-taint-analysis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-taint-analysis.md)",".claude/skills/gitnexus-lfg/README.md":"# Gitnexus-lfg Skill\n\nPath: `.claude/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-lfg/README.md)",".claude/skills/gitnexus-plan/README.md":"# Gitnexus-plan Skill\n\nPath: `.claude/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/README.md)",".claude/skills/gitnexus-work/README.md":"# Gitnexus-work Skill\n\nPath: `.claude/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/README.md)","gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json":"# Gitnexus-cli Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json":"# Gitnexus-debugging Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json":"# Gitnexus-exploring Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json":"# Gitnexus-guide Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json":"# Gitnexus-impact-analysis Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-lfg/README.md":"# Gitnexus-lfg Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/README.md)","gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json":"# Gitnexus-lfg Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-plan/README.md":"# Gitnexus-plan Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/README.md)","gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json":"# Gitnexus-plan Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json":"# Gitnexus-refactoring Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-review/mcp.json":"# Gitnexus-review Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/mcp.json)","gitnexus-claude-plugin/skills/gitnexus-work/README.md":"# Gitnexus-work Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/README.md)","gitnexus-claude-plugin/skills/gitnexus-work/mcp.json":"# Gitnexus-work Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/mcp.json)","gitnexus/skills/gitnexus-lfg/README.md":"# Gitnexus-lfg Skill\n\nPath: `gitnexus/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-lfg/README.md)","gitnexus/skills/gitnexus-plan/README.md":"# Gitnexus-plan Skill\n\nPath: `gitnexus/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/README.md)","gitnexus/skills/gitnexus-work/README.md":"# Gitnexus-work Skill\n\nPath: `gitnexus/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/README.md)",".claude/skills/gitnexus-plan/references/context-ledger.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-ledger.md)",".claude/skills/gitnexus-plan/references/context-pack.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-pack.md)",".claude/skills/gitnexus-plan/references/evidence-provenance.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/evidence-provenance.md)",".claude/skills/gitnexus-plan/references/pdg-slice.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/pdg-slice.md)",".claude/skills/gitnexus-plan/references/plan-template.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/plan-template.md)",".claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs":"# Claude Directive: evidence-provenance.mjs\n\nPath: `.claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs)",".claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md)",".claude/skills/gitnexus-review/ci-personas/ci-security-lens.md":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md)",".claude/skills/gitnexus-work/references/evidence-provenance.md":"# References Skill\n\nPath: `.claude/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/references/evidence-provenance.md)",".claude/skills/gitnexus-work/scripts/evidence-provenance.mjs":"# Claude Directive: evidence-provenance.mjs\n\nPath: `.claude/skills/gitnexus-work/scripts/evidence-provenance.mjs`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/scripts/evidence-provenance.mjs)","gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md)","gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md)","gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md)","gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md)","gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md)","gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md)","gitnexus/skills/gitnexus-plan/references/context-ledger.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/context-ledger.md)","gitnexus/skills/gitnexus-plan/references/context-pack.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/context-pack.md)","gitnexus/skills/gitnexus-plan/references/evidence-provenance.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/evidence-provenance.md)","gitnexus/skills/gitnexus-plan/references/pdg-slice.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/pdg-slice.md)","gitnexus/skills/gitnexus-plan/references/plan-template.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/plan-template.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md)","gitnexus/skills/gitnexus-work/references/evidence-provenance.md":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/references/evidence-provenance.md)","gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml":"# Data Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml)","gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json":"# Barrel Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json)","gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json":"# Http Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json)","gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json":"# Inner Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json)","gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json":"# Utils Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json)"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/AGENTS.md)","tokens":300,"sizeBytes":158},{"name":"llms.txt","path":"llms.txt","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/llms.txt","title":"LLM Index & Context Digest","category":"root-instruction","format":"text","content":"# LLM Index & Context Digest\n\nPath: `llms.txt`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/llms.txt)","tokens":300,"sizeBytes":150},{"name":"ARCHITECTURE.md","path":"ARCHITECTURE.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/ARCHITECTURE.md","title":"System Architecture & Module Boundaries","category":"project-spec","format":"markdown","content":"# System Architecture & Module Boundaries\n\nPath: `ARCHITECTURE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/ARCHITECTURE.md)","tokens":300,"sizeBytes":177},{"name":"SKILL.md","path":".claude/skills/gitnexus-cli/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-cli/SKILL.md","title":"gitnexus-cli","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-cli\ndescription: \"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \\\"Index this repo\\\", \\\"Reanalyze the codebase\\\", \\\"Generate a wiki\\\"\"\n---\n\n# GitNexus CLI Commands\n\nCommands below use `node .gitnexus/run.cjs ` — the project-local runner `gitnexus analyze` drops next to the index. It auto-selects an available runner at call time (global `gitnexus`, else `pnpm dlx`, else `bunx`, else `npx`), so no package-manager assumption and no global install is required — including on a bun-only machine, which has no npm, npx or pnpm at all.\n\n> **Not analyzed yet, or `node .gitnexus/run.cjs` reports `Cannot find module`** (the gitignored runner is absent — e.g. a fresh clone or `git clean`)? (Re)generate it with `npx gitnexus analyze` from the project root, or `bunx gitnexus@latest analyze` on a bun-only machine. On **npm 11.x**, if `npx` crashes during install (`node.target is null`), install once with `npm i -g gitnexus` (then `gitnexus analyze`), or use `bunx gitnexus@latest analyze`, or `pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze`. See [#1939](https://github.com/abhigyanpatwari/GitNexus/issues/1939).\n\n## Commands\n\n### analyze — Build or refresh the index\n\n```bash\nnode .gitnexus/run.cjs analyze\n```\n\nRun from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.\n\n| Flag | Effect |\n| -------------- | ---------------------------------------------------------------- |\n| `--watch` | Keep a Git repository index current with serialized refreshes |\n| `--debounce ` | Watch quiet period before refresh (default: 300 ms) |\n| `--force` | Force full re-index even if up to date |\n| `--embeddings` | Enable embedding generation for semantic search (off by default) |\n| `--drop-embeddings` | Drop existing embeddings on rebuild. By default, an `analyze` without `--embeddings` preserves them. |\n| `--pdg` | Build the program-dependence layers used by `explain` and `pdg_query` (taint, CDG, and REACHING_DEF). |\n| `--spring-actuator ` | Import opt-in Spring Boot Actuator mappings, beans, conditions, configprops, and env snapshots. Forces a full rebuild; unsupported with `--watch`. |\n| `--asyncapi-spec ` | Read opt-in AsyncAPI 3.x documents (directory or single file) and mint `Destination` nodes from their operations. 2.x is refused, not mapped. Unsupported with `--watch`. |\n\n**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook detects staleness after `git commit` and `git merge` and notifies the agent to run `analyze` — the hook does not run analyze itself, to avoid blocking the agent for up to 120s and risking KuzuDB corruption on timeout.\n\nFor Spring runtime enrichment, pass a JSON bundle, one endpoint JSON file, or a directory containing endpoint files. Route evidence is authoritative only when `runtimeConfirmed === true`; `runtimeSource` records provenance and may also accompany `handler-conflict`. Env/configprops values are never persisted.\n\n## Index storage and retention\n\nDefault location is `/.gitnexus/`. Override with environment variables (also documented in README):\n\n| Env | Effect |\n| --- | ------ |\n| `GITNEXUS_STORAGE_PATH` | One complete external index directory. Wins if both storage vars are set. |\n| `GITNEXUS_STORAGE_ROOT` | Absolute root; GitNexus creates an isolated `-<12-hex>/` slot per repository. |\n| `GITNEXUS_CONTENT_RETENTION` | `full` (default) keeps file text; `symbol` keeps snippets; `none` keeps the graph only. |\n\n`list_repos`, `gitnexus://repo/{name}/context`, and HTTP `GET /api/repos` / `GET /api/repo` expose `storagePath`, `contentRetention`, and `sourceAvailable`. HTTP `/api/file` and `/api/grep` return 410 unless retention is `full`. MCP `include_content` may still return symbol spans when retention is `symbol`.\n\nUse `node .gitnexus/run.cjs analyze --watch` for a long-lived local Git repository. It performs an initial analysis, queues scanner-admitted file changes, and retries intact failed batches with bounded backoff. Watch refreshes update only the graph: they skip AGENTS.md / CLAUDE.md injection and standard skill installation, so run a one-shot `analyze` when those generated files need updating. Watch rejects one-shot or context-output flags including `--force`, embedding flags, `--skills`, `--default-branch`, `--skip-agents-md`, `--skip-skills`, `--no-stats`, `--self-commit`, `--index-only`, and `--skip-git`. It never pulls remotes. Scheduled remote clone/pull is a different command: `gitnexus auto-sync`. Bare `gitnexus watch` is reserved and does not start either job. Running MCP and `serve` processes periodically check for a published replacement and reopen it without a restart. MCP checks are throttled to once every five seconds, so a tool call before the next check can briefly use the previous index.\n\n### status — Check index freshness\n\n```bash\nnode .gitnexus/run.cjs status\n```\n\nShows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.\n\n### clean — Delete the index\n\n```bash\nnode .gitnexus/run.cjs clean\n```\n\nDeletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.\n\n| Flag | Effect |\n| --------- | ------------------------------------------------- |\n| `--force` | Skip confirmation prompt |\n| `--all` | Clean all indexed repos, not just the current one |\n\n### wiki — Generate documentation from the graph\n\n```bash\nnode .gitnexus/run.cjs wiki\n```\n\nGenerates repository documentation from the knowledge graph using an LLM. HTTP providers require an API key (saved to `~/.gitnexus/config.json` on first use). Local CLI providers (`--provider cursor|claude|codex|opencode|grok`) use your existing CLI login.\n\n| Flag | Effect |\n| ------------------- | ----------------------------------------- |\n| `--force` | Force full regeneration, also required to re-generate an existing wiki in a different language |\n| `--provider ` | LLM provider: minimax, openai, openrouter, azure, custom, cursor, claude, codex, opencode, or grok (default: minimax). Local CLIs (`cursor`, `claude`, `codex`, `opencode`, `grok`) use your existing CLI login and skip `--api-key`. |\n| `--model ` | LLM model (default: MiniMax-M3) |\n| `--base-url ` | LLM API base URL |\n| `--api-key ` | LLM API key |\n| `--concurrency ` | Parallel LLM calls (default: 3) |\n| `--timeout ` | LLM request timeout in seconds (default: disabled) |\n| `--retries ` | Max LLM retry attempts per request (default: 3) |\n| `--lang ` | Output language for generated documentation (e.g. english, chinese, spanish, japanese) |\n| `--gist` | Publish wiki as a public GitHub Gist |\n\n### list — Show all indexed repos\n\n```bash\nnode .gitnexus/run.cjs list\n```\n\nLists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.\n\n## After Indexing\n\n1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded\n2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task\n\n## Troubleshooting\n\n- **\"Not inside a git repository\"**: Run from a directory inside a git repo\n- **Index is stale after re-analyzing**: Wait for the next MCP tool call to reopen the published index; this normally takes no more than five seconds\n- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding\n","frontmatter":{"name":"gitnexus-cli","description":"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \"Index this repo\", \"Reanalyze the codebase\", \"Generate a wiki\""},"isInternal":false,"tokens":2017,"sizeBytes":8280},{"name":"SKILL.md","path":".claude/skills/gitnexus-debugging/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-debugging/SKILL.md","title":"gitnexus-debugging","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-debugging\ndescription: \"Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: \\\"Why is X failing?\\\", \\\"Where does this error come from?\\\", \\\"Trace this bug\\\"\"\n---\n\n# Debugging with GitNexus\n\n## When to Use\n\n- \"Why is this function failing?\"\n- \"Trace where this error comes from\"\n- \"Who calls this method?\"\n- \"This endpoint returns 500\"\n- Investigating bugs, errors, or unexpected behavior\n\n## Bind the repository first\n\nA root cause traced in the wrong repository is a wrong root cause.\n\nBind once using a confirmed registry name/path or configured MCP default. Call\n`list_repos {}` if the target is not yet known; reuse that binding across calls. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask. This matters most for `cypher`, whose\nstatement carries no in-band hint of which database it ran against.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\nA stale index describes the code from before your bug, so refresh before\ntrusting a trace, and state the repository and index freshness with the\ndiagnosis.\n\n## Workflow\n\n```\n0. Bind the repo once (list_repos only if not already known)\n1. If the suspect is unknown, query for the error/symptom with small result limits\n2. context({name: \"\"}) → See callers/callees/processes\n3. Read a process resource only if its trace resolves an open question\n4. cypher({statement: \"MATCH path...\"}) → Custom traces if needed\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Checklist\n\n```\n- [ ] Once per session: bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] Understand the symptom (error message, unexpected behavior)\n- [ ] query for error text or related code\n- [ ] Identify the suspect function from returned processes\n- [ ] context to see callers and callees\n- [ ] Trace execution flow via process resource if applicable\n- [ ] cypher for custom call chain traces if needed\n- [ ] Read source files to confirm root cause\n- [ ] State the repository and index freshness with the diagnosis\n```\n\n## Keep investigations focused\n\nStart with a known symbol's `context`, or a small `query` (`limit: 3`,\n`max_symbols: 3`, `include_content: false`, `chain_depth: 0`) to discover one.\nWhen the server advertises these single-repository filters, request only the\nneeded evidence:\n\n```text\ncontext({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"outgoing\"], relationTypes: [\"CALLS\"]})\ntrace({from_uid: \"\", to_uid: \"\", repo: \"my-app\"})\n```\n\n`symbol` and completeness/staleness diagnostics remain in a filtered context.\n`relationTypes` filters the returned incoming/outgoing categories only; it does\nnot expand their existing bounded window or filter an explicitly requested chain.\nFor callback registration, include `USES`; for imports or inheritance, request\nthose relation types or omit the filter. Omitted references are not absent\nreferences. Broaden when the hypothesis needs it, and preserve UNKNOWN/partial\nwarnings. Confirm source and tests before claiming a root cause. A useful 2–3\ncall investigation is a goal, not a reason to skip verification or pre-edit impact.\n\n## Debugging Patterns\n\n| Symptom | GitNexus Approach |\n| -------------------- | ---------------------------------------------------------- |\n| Error message | `query` for error text → `context` on throw sites |\n| Wrong return value | `context` on the function → trace callees for data flow |\n| Intermittent failure | `context` → look for external calls, async deps |\n| Performance issue | `context` → find symbols with many callers (hot paths) |\n| Recent regression | `detect_changes` to see what your changes affect — pass `worktree` for a linked worktree |\n| \"How does A reach B?\" | `trace` between the two symbols — shortest call chain in one call |\n\n## Tools\n\n**query** — find code related to error:\n\n```\nquery({search_query: \"payment validation error\", repo: \"my-app\"})\n→ Processes: CheckoutFlow, ErrorHandling\n→ Symbols: validatePayment, handlePaymentError, PaymentException\n```\n\n**context** — full context for a suspect:\n\n```\ncontext({name: \"validatePayment\", repo: \"my-app\"})\n→ Incoming calls: processCheckout, webhookHandler\n→ Outgoing calls: verifyCard, fetchRates (external API!)\n→ Processes: CheckoutFlow (step 3/7)\n```\n\n**cypher** — custom call chain traces. Pass `repo` alongside the statement; the\nCypher text itself names no repository, so the result is unattributable without\nit:\n\n```cypher\nMATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: \"validatePayment\"})\nRETURN [n IN nodes(path) | n.name] AS chain\n```\n\n**trace** — shortest call chain between two symbols (\"how does A reach B?\"), one call instead of chaining `context` hops:\n\n```\ntrace({ from: \"processCheckout\", to: \"fetchRates\", repo: \"my-app\" })\n→ status: ok, hopCount: 3\n→ hops: processCheckout → validatePayment → verifyCard → fetchRates\n→ edges: CALLS (1.0), CALLS (0.95), CALLS (1.0)\n```\n\nWhen no path exists, `trace` reports the furthest reachable node — exactly where the chain breaks (dynamic dispatch, reflection, or an external boundary).\n\n## Example: \"Payment endpoint returns 500 intermittently\"\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — bind my-app explicitly on every call\n\n1. query({search_query: \"payment error handling\", repo: \"my-app\"})\n → Processes: CheckoutFlow, ErrorHandling\n → Symbols: validatePayment, handlePaymentError\n\n2. context({name: \"validatePayment\", repo: \"my-app\"})\n → Outgoing calls: verifyCard, fetchRates (external API!)\n\n3. READ gitnexus://repo/my-app/process/CheckoutFlow\n → Step 3: validatePayment → calls fetchRates (external)\n\n4. Root cause: fetchRates calls external API without proper timeout\n Repository: my-app Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n","frontmatter":{"name":"gitnexus-debugging","description":"Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: \"Why is X failing?\", \"Where does this error come from?\", \"Trace this bug\""},"isInternal":false,"tokens":1575,"sizeBytes":6642},{"name":"SKILL.md","path":".claude/skills/gitnexus-exploring/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-exploring/SKILL.md","title":"gitnexus-exploring","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-exploring\ndescription: \"Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: \\\"How does X work?\\\", \\\"What calls this function?\\\", \\\"Show me the auth flow\\\"\"\n---\n\n# Exploring Codebases with GitNexus\n\n## When to Use\n\n- \"How does authentication work?\"\n- \"What's the project structure?\"\n- \"Show me the main components\"\n- \"Where is the database logic?\"\n- Understanding code you haven't seen before\n\n## Bind the repository first\n\nBind once per session using a confirmed registry name/path or configured MCP\ndefault; reuse it. Call `list_repos {}` when the target is not yet known, not before\nevery question. Never guess the registry name from the checkout directory. With\none indexed repository, use the examples below as written. With more than one, pass `repo` on every call: an omitted `repo` normally errors,\nbut under an MCP policy with a configured default it resolves to that default\nsilently. If you cannot tell which repository is meant, stop and ask. Report\nthe bound repository and index freshness alongside your explanation.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\n## Workflow\n\n```\n1. Bind the repository once; use hot-tool staleness on subsequent calls\n2. If no symbol is known: query({search_query: \"\", limit: 3, max_symbols: 3})\n3. context({uid: \"\"}) → Inspect the selected symbol\n4. Read a process resource only when its full trace answers an unresolved question\n```\n\n> If the index is stale → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Ask for only the evidence needed\n\nUse options advertised by the connected server. `response_sections` and context\n`relationTypes` are opt-in views for a single repository, not `@group` routing.\nOn an older server, use the existing limits and content/chain options instead.\nUse filters when unwanted sections are bulky; their omission metadata can make\nan already-small response slightly larger.\nAim for 2–3 focused calls after repository binding; stop when the question is\nanswered, but expand if evidence or a required safety check is still missing.\n\n```text\nquery({search_query: \"payment retry\", repo: \"my-app\", limit: 3, max_symbols: 3,\n include_content: false, chain_depth: 0,\n response_sections: [\"process_symbols\", \"definitions\"]})\ncontext({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"incoming\", \"outgoing\"], relationTypes: [\"CALLS\"]})\n// Before editing, assess impact using the normal traversal and risk calculation:\nimpact({target: \"\", repo: \"my-app\", direction: \"upstream\", summaryOnly: true})\n```\n\nIf the symbol is already known, start with `context`; use `uid`, or `name` plus\n`file_path`/`kind`, to avoid ambiguous results. To answer only “who calls it?”,\nrequest `response_sections: [\"incoming\"]`, `relationTypes: [\"CALLS\"]` and leave\n`include_content` false. Keep `processes` in a query when the question is about\nflows, rather than requesting a symbols-only view.\n\nDo not request source and multi-hop chains for every search hit. Fetch source\nfor the selected symbol only; for a large class/file, prefer `read_file` with\na small 0-based `startLine`/`endLine` window (subtract 1 from graph line numbers),\nor `maxLines` for a whole-file read, if that tool is available. Use\n`trace` for a known A→B path instead of repeatedly expanding `context`.\n\nFilters retain requested sections/categories and hide the others; they do not prove other references\nare absent or make the existing bounded search exhaustive. Read `response_filter`,\n`warning`, `partial`, `truncated`, `epistemic` and `staleness`. Remove filters when\nbroader evidence is needed. `maxTokens` is a last-resort byte cutoff that can cut\nJSON: narrow the request rather than treating a cut response as complete. Never\nuse a filtered caller view to waive the required impact check or an UNKNOWN risk.\n\n## Checklist\n\n```\n- [ ] Once per session: bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] Check hot-tool staleness; read the overview only if needed\n- [ ] Query for the concept only if the relevant symbol is not already known\n- [ ] Review returned symbols; include processes when execution flow matters\n- [ ] context on selected symbols; request only relevant sections/relations\n- [ ] Read a process resource only if its full trace is needed\n- [ ] Read targeted source only when implementation details are needed\n- [ ] State the repository and index freshness with the explanation\n```\n\n## Resources\n\n| Resource | What you get |\n| --------------------------------------- | ------------------------------------------------------- |\n| `gitnexus://repo/{name}/context` | Stats, staleness warning (~150 tokens) |\n| `gitnexus://repo/{name}/clusters` | All functional areas with cohesion scores (~300 tokens) |\n| `gitnexus://repo/{name}/cluster/{name}` | Area members with file paths (~500 tokens) |\n| `gitnexus://repo/{name}/process/{name}` | Step-by-step execution trace (~200 tokens) |\n\n## Tools\n\n**query** — find execution flows related to a concept:\n\n```\nquery({search_query: \"payment processing\", repo: \"my-app\"})\n→ Processes: CheckoutFlow, RefundFlow, WebhookHandler\n→ Symbols grouped by flow with file locations\n```\n\n**context** — 360-degree view of a symbol:\n\n```\ncontext({name: \"validateUser\", repo: \"my-app\"})\n→ Incoming calls: loginHandler, apiMiddleware\n→ Outgoing calls: checkToken, getUserById\n→ Processes: LoginFlow (step 2/5), TokenRefresh (step 1/3)\n```\n\n`repo` is required once more than one repository is indexed, and may be omitted\nwith a single one.\n\n## Example: \"How does payment processing work?\"\n\nWith `my-app` already bound and the index current:\n\n```text\n1. query({search_query: \"payment processing\", repo: \"my-app\", limit: 3, max_symbols: 3})\n → CheckoutFlow and RefundFlow, with symbol IDs and locations\n2. context({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"outgoing\", \"processes\"]})\n → Selected source, callees, process participation and completeness diagnostics\n3. Answer from that evidence; read one process resource only if its trace is still needed\n```\n\nReport the repository and index freshness with the explanation. If `my-app`\nhad not yet been bound, discover it once with `list_repos` first.\n","frontmatter":{"name":"gitnexus-exploring","description":"Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: \"How does X work?\", \"What calls this function?\", \"Show me the auth flow\""},"isInternal":false,"tokens":1572,"sizeBytes":6821},{"name":"SKILL.md","path":".claude/skills/gitnexus-guide/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-guide/SKILL.md","title":"gitnexus-guide","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-guide\ndescription: \"Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: \\\"What GitNexus tools are available?\\\", \\\"How do I use GitNexus?\\\"\"\n---\n\n# GitNexus Guide\n\nQuick reference for all GitNexus MCP tools, resources, and the knowledge graph schema.\n\n## Always Start Here\n\nFor any task involving code understanding, debugging, impact analysis, or refactoring:\n\n1. **Bind the repository once** — use a confirmed registry name/path or configured default; call `list_repos` if unknown. Read hot-tool `staleness`; use `gitnexus://repo/{name}/context` when an overview is needed.\n2. **Match your task to a skill below** and **read that skill file**\n3. **Follow the skill's workflow and checklist**\n\n> If step 1 warns the index is stale, run `node .gitnexus/run.cjs analyze` in the terminal first.\n> On `query` / `context` / `impact` / `cypher`, read `staleness.status` and `staleness.branch`/`lastCommit` before using the answer. Re-analyze only for `behind` or `diverged`.\n\n## Skills\n\n| Task | Skill to read |\n| -------------------------------------------- | ------------------- |\n| Understand architecture / \"How does X work?\" | `gitnexus-exploring` |\n| Blast radius / \"What breaks if I change X?\" | `gitnexus-impact-analysis` |\n| Trace bugs / \"Why is X failing?\" | `gitnexus-debugging` |\n| Rename / extract / split / refactor | `gitnexus-refactoring` |\n| Tools, resources, schema reference | `gitnexus-guide` (this file) |\n| Index, status, clean, wiki CLI commands | `gitnexus-cli` |\n\n## Tools Reference\n\n| Tool | What it gives you |\n| ---------------- | ------------------------------------------------------------------------ |\n| `query` | Process-grouped code intelligence — execution flows related to a concept |\n| `context` | 360-degree symbol view — categorized refs, processes it participates in |\n| `impact` | Symbol blast radius — what breaks at depth 1/2/3 with confidence |\n| `trace` | Shortest path between two symbols — \"how does A reach B?\" in one call |\n| `detect_changes` | Git-diff impact — what do your current changes affect |\n| `rename` | Semantic rename: previews by default (`dry_run` omitted/true), applies with `dry_run: false` and the preview's `plan_token`; inspect application status and failures |\n| `cypher` | Raw graph queries (read `gitnexus://repo/{name}/schema` first) |\n| `explain` | Persisted taint findings — source→sink data flows (needs `analyze --pdg`) |\n| `pdg_query` | Control/data dependence — what gates X (CDG) / where Y flows (REACHING_DEF); needs `analyze --pdg` |\n| `check` | Check graph invariants such as circular imports |\n| `route_map` | API route map — which components/hooks fetch which endpoints, and the handler files that serve them |\n| `shape_check` | Response-shape drift — keys each route returns vs keys its consumers access (flags MISMATCH) |\n| `api_impact` | Pre-change report for an API route — consumers, middleware, shape mismatches, risk level |\n| `tool_map` | MCP/RPC tool definitions and the files that handle them |\n| `group_list` | List configured multi-repo groups, or one group's config |\n| `group_sync` | Rebuild a group's Contract Registry (cross-repo HTTP contract links); run after `group.yaml` changes or member re-index |\n| `list_repos` | Discover indexed repos (paginated — `limit`/`offset`) |\n\n### Choose a focused response\n\nUse the connected server's schema; older servers may not advertise the new\nfilters. All options below are explicit: omitting them preserves existing output.\nUse filters for bulky unwanted sections; on an already-small response, omission\nmetadata can outweigh the bytes saved.\n\n| Question | Options |\n| --- | --- |\n| Which symbols implement this? | `query`: `limit: 3`, `max_symbols: 3`, `include_content: false`, `chain_depth: 0`, `response_sections: [\"process_symbols\", \"definitions\"]` |\n| Which execution flows match? | `query`: keep `processes` in `response_sections`; join its `id` to `process_symbols[].process_id` |\n| Who calls this exact symbol? | `context`: `uid`, `response_sections: [\"incoming\"]`, `relationTypes: [\"CALLS\"]` |\n| What does it call, with source? | `context`: `uid`, `include_content: true`, `response_sections: [\"outgoing\"]`, `relationTypes: [\"CALLS\"]` |\n| What is the impact summary? | `impact`: `direction: \"upstream\"`, `summaryOnly: true`; risk calculation and totals are retained |\n| Which affected symbols need inspection? | `impact`: `limit: 10`, `offset: 0`; page as indicated by the response |\n| How does A reach B? | `trace`: `from_uid`, `to_uid` |\n\n`response_sections` selects data sections for single-repository MCP `query` or\n`context` (not `@group` routes). Query choices: `processes`, `process_symbols`,\n`definitions`. Context choices: `incoming`, `outgoing`, `processes`, `chain`,\n`routes`, `typed_properties`; the selected symbol always remains. Context\n`relationTypes` accepts uppercase relationship names advertised by its schema\nand filters only the existing incoming/outgoing categories. It does not change\nranking, traversal, source retention or the bounded candidate/reference windows.\n\nFilters add `response_filter` with the selection and omitted fields/categories.\nWarnings, ambiguity, staleness and completeness metadata always remain. An empty\nfiltered view is not proof of absence. Omit filters to expand, and never waive\nimpact checks because a selected category is empty. `maxTokens` is a byte cutoff,\nnot pagination: it can cut JSON. Prefer these filters, small result counts, and\nsource/chain expansion for a selected symbol rather than a large search result.\nStop once enough evidence answers the question; do not run every tool by default.\n\n### Paginating `list_repos`\n\n`list_repos` is paginated so a large registry is not truncated by MCP/LLM token limits. It takes optional `limit` (default **50**, max **200**) and `offset`, and returns:\n\n```jsonc\n{\n \"repositories\": [\n { \"name\": \"...\", \"path\": \"...\", \"indexedAt\": \"...\", \"lastCommit\": \"...\", \"stats\": { } }\n ],\n \"pagination\": {\n \"total\": 437,\n \"limit\": 50,\n \"offset\": 0,\n \"returned\": 50,\n \"hasMore\": true,\n \"nextOffset\": 50\n }\n}\n```\n\nTo enumerate **every** repository, keep calling with `offset` set to `pagination.nextOffset` until `hasMore` is `false`:\n\n```text\nlist_repos {} → repos 1–50, nextOffset 50, hasMore true\nlist_repos { offset: 50 } → repos 51–100, nextOffset 100, hasMore true\n…\nlist_repos { offset: 400 } → repos 401–437, hasMore false (done)\n```\n\nNotes: `offset` ≥ `total` returns an empty page (with `total` still reported). Out-of-range or malformed `limit`/`offset` (non-integer, `limit` outside `[1, 200]`, `offset < 0`) are rejected with a clear error — `limit` above the max is rejected, not silently capped. The order is deterministic (lower-cased name, then path), so paging never skips or duplicates an entry while the registry is unchanged.\n\n### Inline staleness signal (`query` / `context` / `impact` / `cypher`)\n\nThese four hot read tools attach a non-blocking `staleness` field to every response, in the shape `{ status, branch?, lastCommit, indexedAt, measuredAgainst, commitsBehind?, hint? }`. It answers two different questions at once: **which index answered** and **how fresh it is**. The identity half is why the field is present even when nothing is wrong — an answer computed from a branch-pinned index is otherwise indistinguishable from one computed from the default branch (#3291):\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"current\",\n \"branch\": \"feature/checkout-v2\",\n \"lastCommit\": \"4f2a1c9e8b7d6a5c4e3f2a1b0c9d8e7f6a5b4c3d\",\n \"indexedAt\": \"2026-09-15T07:12:00.000Z\",\n \"measuredAgainst\": \"HEAD\"\n }\n}\n```\n\n`status: \"current\"` here means *this index is at the HEAD of the clone it was built from* — not that it is current with the default branch. `measuredAgainst` names what `commitsBehind` is counted against: the checked-out HEAD of that clone, never the remote. `branch` is the branch the index represents; it is absent for a detached HEAD, a non-git folder, or a legacy index that never recorded one, so read `lastCommit` when you need an identifier that is always present.\n\nWhen the index is behind that HEAD, the count and hint ride along:\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"behind\", \"commitsBehind\": 3, \"branch\": \"main\",\n \"lastCommit\": \"a0c945022d06b8815f93ffd8838df9ed5c08cbc0\",\n \"indexedAt\": \"2026-09-04T20:45:47.481Z\", \"measuredAgainst\": \"HEAD\",\n \"hint\": \"⚠️ Index is 3 commits behind HEAD. Run analyze tool to update.\"\n }\n}\n```\n\n`commitsBehind` is present only when git counted the gap. When git could not count it but HEAD still resolves to a commit other than the indexed one — usually because the indexed commit is no longer in the clone's history — the index is provably not at HEAD with no countable gap, so no number is reported:\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"diverged\", \"branch\": \"main\",\n \"lastCommit\": \"a0c945022d06b8815f93ffd8838df9ed5c08cbc0\",\n \"indexedAt\": \"2026-09-04T20:45:47.481Z\", \"measuredAgainst\": \"HEAD\",\n \"hint\": \"⚠️ Index is not at HEAD and the commit gap could not be counted — the recorded commit may no longer be in this clone's history. Run analyze tool to update.\"\n }\n}\n```\n\nSo: **read `status` before using `commitsBehind`**, and read `branch`/`lastCommit` before assuming which ref the answer describes. `status: \"unknown\"` means the freshness check could not run at all (a `--skip-git` folder has no history to measure) — the ref is still reported, because which index answered is knowable even when its freshness is not. The field is only ever added to object results — raw-array `cypher` output and error envelopes are returned unchanged. `@group`-targeted calls do not carry it (multi-repo staleness is ill-defined). Re-run `analyze` only for `behind` or `diverged` — those mean the index is not at this clone's HEAD. `unknown` is unmeasurable, not stale; analyze cannot make it `current` unless git history exists.\n\n`list_repos` and the HTTP repo routes are unchanged: they omit `staleness` entirely for a current index and report the ref through their own top-level `branch` / `lastCommit` / `indexedAt` fields.\n\n### Taint findings (`explain`)\n\n`explain` returns taint findings recorded by `gitnexus analyze --pdg` — intra-procedural `TAINTED` edges plus cross-function `TAINT_PATH` hops where the interprocedural taint phase found a function-level source→sink chain. Each finding includes a sink category (command-injection, code-injection, path-traversal, sql-injection, xss), source/sink lines, and the ordered hop path with the variable carried on each hop.\n\n- `explain {}` — enumerate all findings for the repo (bounded by `limit`, deterministic order)\n- `explain { target: \"src/vuln.ts\" }` — findings in a file (suffix path match accepted)\n- `explain { target: \"runUserCommand\" }` — findings in a function (resolved like `context`; ambiguous names return ranked candidates)\n\nA repo indexed without `--pdg` returns a clear \"no taint layer\" note. Caveats: closure/callback, property/field, and implicit flows are not modeled, and interprocedural findings are function-level `TAINT_PATH` hops rather than statement-level path proof, so the absence of a finding is **not** proof of safety. `SANITIZES` (sanitizer-kill) edges are queryable via `cypher`.\n\n### Control & data dependence (`pdg_query`)\n\n`pdg_query` reads the control/data-dependence layers `gitnexus analyze --pdg` records (CDG + REACHING_DEF, basic-block granular) — the control/data analog of `explain`. It is **always anchored** (a `target` file path or symbol, resolved like `context`) and has two modes:\n\n- `pdg_query { mode: \"controls\", target: \"...\" }` — CDG: \"under what condition does X run?\". Each edge is a controlling predicate block → dependent block with the branch sense (`'T'`/`'F'`) in `reason`; an edge into an early `return`/`throw` is flagged `guard: true` (guard-clause discovery — the sense depends on the predicate, so don't filter guards by a fixed label).\n- `pdg_query { mode: \"flows\", target: \"...\", variable?: \"...\" }` — REACHING_DEF def→use edges within the function; pass `variable` to trace one binding.\n\nA repo indexed without `--pdg` returns a \"no PDG layer\" note (or \"status unknown\" when the layer can't be confirmed). Intra-procedural only — cross-function flow is taint's domain (`explain`). The raw CDG/REACHING_DEF edges are also queryable via `cypher`. See the `gitnexus-pdg-query` skill for the full query surface.\n\n### Shortest path between two symbols (`trace`)\n\n`trace` answers \"how does A reach B?\" in one call — the shortest directed path over `CALLS` (plus `HAS_METHOD`, so a class-rooted trace descends into its methods) instead of chaining 3–8 `context`/`impact` hops by hand.\n\n- `trace { from: \"validateUser\", to: \"executeQuery\" }` — shortest path between two symbols.\n- Disambiguate common names with `from_uid`/`to_uid` (zero-ambiguity) or `from_file`/`to_file`; an ambiguous name returns ranked candidates.\n- `maxDepth` (default 10, max 30) bounds the search; `includeTests` (default false) lets the traversal pass through test-file symbols.\n\nReturns ordered `hops` (each `{ name, filePath, startLine }`) and an aligned `edges[]` of `{ relType, confidence }`, so call hops and containment (`HAS_METHOD`) hops stay distinguishable. When no path exists it reports the **furthest** reachable node (where the chain breaks) and sets `truncated: true` if a traversal cap was hit first. Every result carries a `status`: `ok` / `no_path` / `ambiguous` / `not_found` / `error`.\n\nCross-repo (experimental): pass `repo: \"@groupName\"` to trace across a group's member repos — the path may cross **one** `ContractLink` boundary (reported as a `CONTRACT_LINK` hop with the bridged contract in `crossings[]`). Omit `to` entirely to follow `from`'s outgoing HTTP call to whatever provider endpoint it lands on. Groups are configured via `group_list` / `group_sync`.\n\n## Resources Reference\n\nLightweight reads (~100-500 tokens) for navigation:\n\n| Resource | Content |\n| ---------------------------------------------- | ----------------------------------------- |\n| `gitnexus://repo/{name}/context` | Stats, staleness check |\n| `gitnexus://repo/{name}/clusters` | All functional areas with cohesion scores |\n| `gitnexus://repo/{name}/cluster/{clusterName}` | Area members |\n| `gitnexus://repo/{name}/processes` | All execution flows |\n| `gitnexus://repo/{name}/process/{processName}` | Step-by-step trace |\n| `gitnexus://repo/{name}/schema` | Graph schema for Cypher |\n\n## Graph Schema\n\n**Nodes:** File, Folder, Function, Class, Interface, Method, CodeElement, Community, Process, Route, Tool, plus language-specific types (Struct, Enum, Trait, Impl, Namespace, Module, …) and BasicBlock (`--pdg` indexes only). The full node list lives in `gitnexus://repo/{name}/schema`.\n**Edges (via CodeRelation.type):** CALLS, IMPORTS, EXTENDS, IMPLEMENTS, DEFINES, CONTAINS, MEMBER_OF, HAS_METHOD, HAS_PROPERTY, ACCESSES, METHOD_OVERRIDES, METHOD_IMPLEMENTS, STEP_IN_PROCESS, HANDLES_ROUTE, FETCHES, HANDLES_TOOL, ENTRY_POINT_OF, WRAPS, QUERIES, INJECTS, plus `--pdg`-only types (CFG, REACHING_DEF, TAINTED, SANITIZES, TAINT_PATH, CDG — zero rows on a default index).\n\nRead `gitnexus://repo/{name}/schema` before writing Cypher — it is the authoritative schema for the indexed repo.\n\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"myFunc\"})\nRETURN caller.name, caller.filePath\n```\n","frontmatter":{"name":"gitnexus-guide","description":"Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: \"What GitNexus tools are available?\", \"How do I use GitNexus?\""},"isInternal":false,"tokens":4097,"sizeBytes":16411},{"name":"SKILL.md","path":".claude/skills/gitnexus-impact-analysis/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-impact-analysis/SKILL.md","title":"gitnexus-impact-analysis","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-impact-analysis\ndescription: \"Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: \\\"Is it safe to change X?\\\", \\\"What depends on this?\\\", \\\"What will break?\\\"\"\n---\n\n# Impact Analysis with GitNexus\n\n## When to Use\n\n- \"Is it safe to change this function?\"\n- \"What will break if I modify X?\"\n- \"Show me the blast radius\"\n- \"Who uses this code?\"\n- Before making non-trivial code changes\n- Before committing — to understand what your changes affect\n\n## Bind the repository first\n\nImpact analysis is the gate that authorizes an edit, so it must answer for the\nrepository you are about to edit.\n\nCall `list_repos {}` before the first tool call. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask — every result below an ambiguous\nidentity inherits the ambiguity. `list_repos` is paginated, so page with\n`offset: pagination.nextOffset` until `hasMore` is false before concluding a\nrepository is absent.\n\n`detect_changes` takes `worktree` when your changes are in a linked worktree\nthe MCP server was not launched from. The server auto-detects a worktree only\nwhen it was launched from inside one; otherwise `git diff` runs in the wrong\ncheckout and reports zero changed symbols — a false clean check that carries\nnone of the degradation flags described below. In the CLI fallbacks, `--repo .`\nmeans the current checkout; pass the intended repository path instead when you\nare not standing in it.\n\nState the bound identity with your risk report:\n\n```\nRepository: () Worktree: Index: , behind HEAD\n```\n\n## Workflow\n\n```\n0. list_repos {} → Bind repo (and worktree)\n1. impact({target: \"X\", direction: \"upstream\"}) or `node .gitnexus/run.cjs impact \"X\" --direction upstream --repo .`\n2. READ gitnexus://repo/{name}/processes → Check affected execution flows\n3. detect_changes({scope: \"all\"}) or `node .gitnexus/run.cjs detect-changes --scope all --repo .`\n4. Assess risk and report to user, echoing repo/worktree/index identity\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n> If `.gitnexus/run.cjs` is missing, replace `node .gitnexus/run.cjs` with `npx gitnexus` in the fallback commands.\n\n## Checklist\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] impact({target, direction: \"upstream\"}) or CLI fallback to find dependents\n- [ ] Review d=1 items first (these WILL BREAK)\n- [ ] Check high-confidence (>0.8) dependencies\n- [ ] READ processes to check affected execution flows\n- [ ] detect_changes({scope: \"all\"}) or CLI fallback for pre-commit check\n- [ ] Confirm the checkout you edited is the checkout that was diffed\n- [ ] Assess risk level and report, stating repo/worktree/index identity\n```\n\n## Understanding Output\n\n| Depth | Risk Level | Meaning |\n| ----- | ---------------- | ------------------------ |\n| d=1 | **WILL BREAK** | Direct callers/importers |\n| d=2 | LIKELY AFFECTED | Indirect dependencies |\n| d=3 | MAY NEED TESTING | Transitive effects |\n\n## Risk Assessment\n\n| Affected | Risk |\n| ------------------------------ | -------- |\n| <5 symbols, few processes | LOW |\n| 5-15 symbols, 2-5 processes | MEDIUM |\n| >15 symbols or many processes | HIGH |\n| Critical path (auth, payments) | CRITICAL |\n| **Zero callers found** | **UNKNOWN** |\n\n`UNKNOWN` is not a low rung on this scale — it means the walk could not answer.\nAn empty caller set is equally consistent with \"genuinely unused\" and \"the\ncallers are not resolvable by the index\" (plain-object property access, dynamic\ndispatch, cross-language calls), so few-callers ⇒ LOW does **not** apply. The\nresult carries a `riskNote` saying so. Confirm with a text search before\ntreating the symbol as safe to change or delete.\n\n`risk` is the edit gate: warn on HIGH/CRITICAL and stop on UNKNOWN until the\nuncertainty is resolved. Within single-repo mode, compare File and symbol\ntargets with local `riskSharedAxes` (direct/total only). Within group mode,\ncompare only group results: their `riskSharedAxes` overlays resolved\ncross-repo crossings on that local value. Never use either field to waive the\nedit gate. Check `riskScale.unusedAxes` before comparing kinds: MCP File walks\nomit process/module axes, while web Graph-RAG expands File targets to in-file\nsymbols before enrichment.\n\n## Tools\n\n**impact** — the primary tool for symbol blast radius. If MCP is unavailable, use `node .gitnexus/run.cjs impact --direction upstream --repo .` instead:\n\n```\nimpact({\n target: \"validateUser\",\n repo: \"my-app\", // required once >1 repository is indexed\n direction: \"upstream\",\n minConfidence: 0.8,\n maxDepth: 3\n})\n\n→ d=1 (WILL BREAK):\n - loginHandler (src/auth/login.ts:42) [CALLS, 100%]\n - apiMiddleware (src/api/middleware.ts:15) [CALLS, 100%]\n\n→ d=2 (LIKELY AFFECTED):\n - authRouter (src/routes/auth.ts:22) [CALLS, 95%]\n```\n\n**detect_changes** — git-diff based impact analysis. If MCP is unavailable, use `node .gitnexus/run.cjs detect-changes --scope all --repo .` instead:\n\n```\ndetect_changes({scope: \"all\"})\n\n→ Changed: 5 symbols in 3 files\n→ Affected: LoginFlow, TokenRefresh, APIMiddlewarePipeline\n→ Risk: MEDIUM\n```\n\nAdd `repo` once more than one repository is indexed, and `worktree: \"\"` when your changes are in a linked worktree the server was not launched\nfrom.\n\n`partial: true` (a graph query failed) or `truncated: true` (the changed-symbol\nlisting was capped) means the result is short of the truth, and reads like\n`UNKNOWN` above: a zero there means unseen, not unaffected. Re-run it rather\nthan tick the pre-commit check.\n\nA wrong-worktree zero carries neither flag and is shape-identical to a genuine\nclean result, so confirm the checkout you edited is the one that was diffed\nbefore treating an empty change set as a passed check.\n\n## Example: \"What breaks if I change validateUser?\"\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly\n\n1. impact({target: \"validateUser\", repo: \"my-app\", direction: \"upstream\"}) or `node .gitnexus/run.cjs impact \"validateUser\" --direction upstream --repo .`\n → d=1: loginHandler, apiMiddleware (WILL BREAK)\n → d=2: authRouter, sessionManager (LIKELY AFFECTED)\n\n2. READ gitnexus://repo/my-app/processes\n → LoginFlow and TokenRefresh touch validateUser\n\n3. Risk: 2 direct callers, 2 processes = MEDIUM\n Repository: my-app (/abs/path/my-app) Worktree: same Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n","frontmatter":{"name":"gitnexus-impact-analysis","description":"Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: \"Is it safe to change X?\", \"What depends on this?\", \"What will break?\""},"isInternal":false,"tokens":1829,"sizeBytes":7241},{"name":"README.md","path":".claude/skills/gitnexus-lfg/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-lfg/README.md","title":"Gitnexus-lfg Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-lfg Skill\n\nPath: `.claude/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-lfg/README.md)","tokens":300,"sizeBytes":200},{"name":"SKILL.md","path":".claude/skills/gitnexus-lfg/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-lfg/SKILL.md","title":"gitnexus-lfg","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-lfg\ndescription: \"Use when the user wants the GitNexus engineering pipeline run end-to-end on a task: gitnexus-plan (plan depth chosen up front), a blocking gate to execute with gitnexus-work or stop, finishing with a gitnexus-review of the result. Examples: \\\"/gitnexus-lfg Add retry support to the ingestion pipeline\\\", \\\"run the gitnexus pipeline on this\\\", \\\"plan, build and review this feature\\\".\"\n---\n\n# gitnexus-lfg — plan → gate → work → review\n\nThin orchestrator over three existing skills. It adds no engineering logic of\nits own — it sequences `gitnexus-plan`, `gitnexus-work`, and\n`gitnexus-review`, with the user deciding at the plan gate. Run every lane\nby actually invoking the named skill (read its SKILL.md and follow it);\nnever inline a summary of what the skill would have done.\n\n```\n/gitnexus-lfg \n/gitnexus-lfg docs/plans/.md # skip lane 1, start at the gate\n```\n\n## Lane 1 — Plan\n\n**Boundary triage first.** If the task is plainly below the planning\nboundary — trivial or small-bounded work an agent finishes in well under ~35\nturns (the measured regime where a planning pass costs more than it returns;\nmeasured in the GitNexus repository's `eval/workflow_bench/`) — say so and\noffer `gitnexus-work` direct mode as an alternative to the full pipeline\nbefore spending the plan lane. Honor the user's choice.\n\nThe threshold is a promoted benchmark policy measured offline, not a\ntimeless heuristic — never self-edit it from a live task. Its re-evaluation\ngovernance lives in this skill's README.\n\nOtherwise invoke `gitnexus-plan` with the task (knob overrides pass through\nverbatim; `gitnexus-plan` owns the up-front depth question — never ask it\nagain here). If the input is already a plan file path, skip to Lane 2. The\nplan lands in `docs/plans/` — record its path; every later lane consumes it.\n\n## Lane 2 — The plan gate (user choice, blocking)\n\nPresent the plan's chat summary (objective, proposed changes, sequence, top\nrisks, open questions, plan path), then ask the user — as a blocking\nquestion (`AskUserQuestion` in Claude Code; a numbered list in chat on CLIs\nwithout a blocking tool):\n\n1. **Proceed to work** — continue to Lane 3.\n2. **Stop here** — the plan file is the deliverable; end the pipeline.\n\nDepth was the user's up-front choice in Lane 1, so deepening is not offered\nby default — but honor an explicit request for it at the gate: run\n`gitnexus-plan` Deepen mode on the plan file and return here with the\nstrengthened plan, as many times as the user asks. Do not proceed past the\ngate without an explicit choice — the gate is the pipeline's only checkpoint\nand exists precisely because execution is expensive to unwind.\n\n**Headless / non-interactive runs:** no one can answer the gate, so end the\npipeline after Lane 1 — the plan file is the deliverable (gate option 2) —\nand say so in the final report. Never auto-proceed to execution.\n\n## Lane 3 — Work\n\nInvoke `gitnexus-work` with the plan path. It re-anchors the plan at HEAD,\nexecutes the Implementation Sequence as verified atomic commits, refreshes\nthe knowledge graph when done (its Phase 4), and reports deviations. If it routes back for re-planning (structural drift), run the\nDeepen pass and return to the Lane 2 gate rather than pushing through.\n\n## Lane 4 — Review\n\nInvoke `gitnexus-review` on the completed work. Pass an open PR URL/number\nwhen one exists; otherwise pass the current branch. The review skill owns\ntarget resolution, exact-SHA checkout/index alignment, and merge-base\nselection. Do not duplicate that logic here. If work left local changes,\npass `local` as a second, separately labeled review surface.\n\nSurface the review verdict and findings to the user. Findings the user\nwants fixed: those within `gitnexus-work`'s direct-mode bounds (1–2 files,\nno architectural decisions) → hand to `gitnexus-work` direct mode; anything\nlarger → offer the plan gate instead (Deepen the plan with the findings, or\nstop). Then re-run this lane's review once. On that re-run, do not start\nanother fix cycle even if findings remain — report them and point the user\nat `/gitnexus-work` (or the plan gate) to continue deliberately.\n\n## Final report\n\nOne message: plan path, deepen cycles run, commits produced, verification\nstatus, review verdict with unresolved findings, and what (if anything) was\nexplicitly left undone. The pipeline does not push or open a PR on its own —\noffer both as next steps.\n","frontmatter":{"name":"gitnexus-lfg","description":"Use when the user wants the GitNexus engineering pipeline run end-to-end on a task: gitnexus-plan (plan depth chosen up front), a blocking gate to execute with gitnexus-work or stop, finishing with a gitnexus-review of the result. Examples: \"/gitnexus-lfg Add retry support to the ingestion pipeline\", \"run the gitnexus pipeline on this\", \"plan, build and review this feature\"."},"isInternal":false,"tokens":1082,"sizeBytes":4517},{"name":"README.md","path":".claude/skills/gitnexus-plan/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/README.md","title":"Gitnexus-plan Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-plan Skill\n\nPath: `.claude/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/README.md)","tokens":300,"sizeBytes":203},{"name":"context-ledger.md","path":".claude/skills/gitnexus-plan/references/context-ledger.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-ledger.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-ledger.md)","tokens":300,"sizeBytes":238},{"name":"context-pack.md","path":".claude/skills/gitnexus-plan/references/context-pack.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-pack.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-pack.md)","tokens":300,"sizeBytes":234},{"name":"evidence-provenance.md","path":".claude/skills/gitnexus-plan/references/evidence-provenance.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/evidence-provenance.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/evidence-provenance.md)","tokens":300,"sizeBytes":248},{"name":"pdg-slice.md","path":".claude/skills/gitnexus-plan/references/pdg-slice.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/pdg-slice.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/pdg-slice.md)","tokens":300,"sizeBytes":228},{"name":"plan-template.md","path":".claude/skills/gitnexus-plan/references/plan-template.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/plan-template.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/plan-template.md)","tokens":300,"sizeBytes":236},{"name":"SKILL.md","path":".claude/skills/gitnexus-plan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/SKILL.md","title":"gitnexus-plan","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-plan\ndescription: 'Use when you need a deep, implementation-ready engineering plan for a code change — built from GitNexus graph intelligence, statement-level PDG analysis, and targeted source verification, compact enough that an implementation agent can start without re-investigating. Also strengthens existing plans via Deepen mode. Examples: \"/gitnexus-plan Add retry support to the ingestion pipeline\", \"/gitnexus-plan deepen docs/plans/.md\", \"plan this change using the knowledge graph\".'\n---\n\n# gitnexus-plan — implementation-ready engineering plans\n\nProduce an implementation-ready plan for an engineering task. GitNexus is the\nnavigation layer (where to look), statement-level PDG is the constraint layer\n(what gates and feeds the behavior), and your native targeted source reads are\nthe verification layer (what is actually true right now). The output is a plan\ndocument plus a compact, machine-readable **implementation context pack**\nthat a follow-up implementation agent (`gitnexus-work`, or any executor) can\nconsume without repeating the investigation.\n\n```\n/gitnexus-plan \n/gitnexus-plan impact_depth:3 depth:deep # knob overrides, see Configuration\n```\n\n**This skill plans. It never implements.** Do not modify production code,\ntests, or configuration while running it. The only repository file it writes\nis the plan document (a working ledger kept outside the repo is fine). The\nonly other permitted state change is an index refresh via\n`analyze --index-only`, which writes only the `.gitnexus` index store. It\nmust not build analyzer `dist/` output and must not mutate source, tests,\nconfiguration, or evaluation data. Stale analyzer provenance is disclosed as\na source-weighted limitation, never repaired by a planning run.\n\n## Hard rules\n\n- **Ledger first.** Before every GitNexus call and every repo file read, check\n the context ledger. Never repeat a query or reread an unchanged range that\n already answered the same question (allowed repeats are defined in\n `references/context-ledger.md`; this skill's own reference files are exempt\n from ledger bookkeeping).\n- **Every graph query answers a named planning question.** Record the question\n and the conclusion in the ledger. No exploratory dredging.\n- **Source beats graph.** The graph navigates; current source is authoritative.\n Verify before asserting (see Phase 4). Comments are the weakest evidence —\n never stronger than executable code.\n- **No fabrication.** Never invent symbols, filenames, test names, tool\n results, or PDG edges. Unknowns go to _Assumptions and Open Questions_.\n- **No scope creep.** Adjacent refactors the task didn't ask for go to plan\n §12 as explicitly-deferred follow-ups, not into Proposed Changes.\n- **Pin working-tree evidence, not only HEAD.** Every plan form carries the\n versioned global dirty digest and sorted cited-path manifest defined in\n `references/context-ledger.md`. Generate it only with the portable helper\n and byte contract in `scripts/evidence-provenance.mjs` and\n `references/evidence-provenance.md`; never reimplement the digest.\n- **Write the plan only through the helper.** The generated-plan path is a\n normalized repo-relative\n `docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md` path. Compose the\n complete UTF-8 document in memory or in a scratchpad outside the target\n repo, then pass it on stdin to the helper's `write-plan` command. Never\n write the destination directly or fall back to an external output path when\n the safe writer fails.\n- **Read an existing plan only through the helper.** Deepen must invoke\n `scripts/evidence-provenance.mjs read-plan`, parse the exact decoded\n `plan_bytes_base64` from its descriptor-anchored receipt, and retain that\n receipt's canonical `generated_plan_path` and `plan_digest` as one binding.\n Never parse a direct lexical-path read or apply one plan's digest to another\n path.\n- **Stop when you have enough.** Sufficient evidence ends exploration; plans\n do not improve monotonically with tokens spent.\n\n## Phase 0 — Parse and classify\n\nRead `references/context-ledger.md` and open the ledger with the task:\noriginal request, interpreted goal, acceptance criteria. Classify the task:\n\n| Category | Posture (depth · plan form · tool-call budget · freshness) |\n| ------------------------------ | -------------------------------------------------------------------------------- |\n| Bug fix (local) | Narrow, 1–2 primary symbols, `impact_depth` 1 · compact · ~15 · accept |\n| Feature | Default knobs · compact · ~30 · accept |\n| Refactor / shared API change | Impact mandatory, `impact_depth` 3 · full · ~45 · strict |\n| Performance | Default + performance PDG mode (`references/pdg-slice.md`) · full · ~45 · strict |\n| Security | Default + security PDG mode + `explain` taint findings · full · ~45 · strict |\n| Dependency upgrade / migration | Impact + compatibility focus; PDG rarely needed · compact · ~20 · accept |\n| Concurrency / transactional | Control-flow + state-mutation PDG focus · full · ~45 · strict |\n| Test improvement / docs | Narrowest: usually no impact or PDG pass · compact · ~10 · accept |\n| Architecture change / spike | Widest: clusters + processes first · full · no cap · strict |\n\nThe category posture overrides the Configuration baseline; explicit `key:value`\ninvocation knobs override both. A task matching several rows combines them:\ntake the widest depth, union the focus areas.\n\n**Seeded evidence.** When a completed investigation already supplies\nverified findings — a finished review, a triage document with `path:line`\nanchors and named failing scenarios — open the ledger FROM it: cite the\nsource document as the opening ledger entries and plan directly against\nthem instead of re-running the graph ladder over ground it already covers.\nRe-deriving what the evidence proves is budget spent against the\nturn-economy rule. Phase 4 still source-verifies whatever Proposed Changes\nwill cite, at the pinned commit — seeding replaces exploration, never\nverification.\n\n**Depth is the user's decision, asked once, up front.** In an interactive\nsession, when the invocation carries no explicit depth signal (no `depth:`,\n`form:`, or `freshness:` knob, and not Deepen mode), ask one blocking\nquestion before Phase 1 — how deep should this plan go?\n\n1. **Quick** — `depth:narrow form:compact freshness:accept`. Fastest useful\n plan: 1–2 primary symbols, minimal graph work, core sections only.\n2. **Standard** — the category posture above, unchanged. Recommend this\n unless the classification argues otherwise.\n3. **Deep** — `depth:deep form:full freshness:strict`. All 13 sections,\n `impact_depth` 3, clusters/processes read, PDG slices for the central\n functions.\n\nThe answer sets the knobs exactly as if they had been typed in the\ninvocation; explicit knobs win and skip the question. Headless runs never\nask — the category posture applies unchanged. Asking up front replaces\noffering to deepen a finished plan afterwards: Deepen mode (below) remains\nthe mechanism for strengthening an existing plan document — a later session,\nreview findings, an executor route-back — not a default follow-up question.\n\n**Turn economy is a deliverable.** The plan is judged on decision quality per\ntoken, not thoroughness theater (measured: a 63-turn plan for a two-line\nchange — the GitNexus repo's `eval/workflow_bench/`). Stay within the category's tool-call\nbudget; when the budget runs out with questions still open, record them in\n§12 instead of digging further — the executor re-verifies cheaply anyway.\n\n## Phase 1 — Anchor and freshness\n\n1. Resolve the target repo: `list_repos` if in doubt, else the indexed repo\n covering the working directory. Pass `repo` explicitly on every call when\n more than one repo is indexed.\n2. Record the repo's current HEAD commit in the ledger — every line-number\n citation in the plan is pinned to it.\n3. **Resolve and record the analyzer runner** (used by every `analyze`\n command in this skill): `node .gitnexus/run.cjs analyze …` when the\n project has a runner (a previous analyze dropped it next to the index),\n else `gitnexus analyze …` (installed CLI — `npm install -g gitnexus`),\n else `npx gitnexus analyze …`. Record its path/version and any available\n source/build identity; do not manufacture provenance from timestamps.\n4. Read `gitnexus://repo/{name}/context` — codebase overview + staleness check.\n **Freshness gate.** Plans built on a stale graph make stale blast-radius\n claims — but a re-index is the largest fixed cost a planning session\n carries, so the gate is category-priced:\n - Compact-plan categories default to `freshness: accept`: plan on the\n current graph with source verification weighted higher — their plans\n cite little graph evidence. Escalate to a refresh mid-plan only when a\n graph claim becomes load-bearing (e.g. Proposed Changes rest on a d=1\n dependent list), and only then.\n - Full-plan categories default to `freshness: strict`, and under it:\n - **Analyzer provenance check — before any refresh.** Compare the resolved\n runner identity with the index metadata and, in an analyzer-source\n checkout, with current analyzer source. If identity is stale or unknown,\n do not build output and do not make that graph load-bearing. Record a\n **stale analyzer provenance — source-weighted limitation** in\n `index_refresh`, the plan header, and §12; rely on targeted source reads\n or hand execution to `gitnexus-work`, which owns the build-current gate.\n - Stale index → run `analyze --index-only` via the resolved runner\n (append `--pdg` when the task category will reach Phase 3) and re-read\n the context resource **only when runner provenance is known-current**.\n Refresh budget, stated once here: at most one `--index-only` refresh in\n Phase 1 **plus** at most one later `--pdg` upgrade in Phase 3 (only when\n Phase 1's refresh lacked `--pdg`) per planning session — a Deepen run is\n its own session. Record each command, runner identity, and outcome in the\n ledger's `index_refresh`.\n - Refresh failed or impractical (no write access to the index, prohibitive\n repo size), or `freshness: accept` was passed → proceed on the stale\n graph, weight source verification higher, and state the staleness and\n the skipped refresh in the plan header and Assumptions.\n - Resources unreadable but tools working → proceed on tools alone, treat\n freshness as unknown (weight source higher), and note it in the plan.\n - GitNexus unavailable entirely → switch to **Fallback mode** (below).\n5. For architecture-scale tasks only, also read\n `gitnexus://repo/{name}/clusters` and `.../processes`.\n\n## Phase 2 — Graph navigation ladder\n\nUse the narrowest operation that answers the current ledger question, in this\norder. Budgets: at most `max_primary_symbols` (5) primary symbols and\n`max_related_symbols` (20) related symbols active in the ledger.\n\n1. `query {search_query, task_context}` — locate concepts, execution flows,\n modules, and related tests for the task.\n2. `context {name}` — 360° view of each candidate primary symbol: callers,\n callees, categorized refs, processes. Promote to primary or discard. An\n `ambiguous` result (ranked candidates) is answered by one retry narrowed\n with `kind` / `file_path` / uid — that retry is an allowed repeat.\n3. `impact {target, direction}` — upstream/downstream blast radius for shared\n or high-connectivity symbols (`maxDepth` = `impact_depth`; `summaryOnly:\ntrue` first for hub symbols, then drill in — an allowed repeat). Record the\n d=1 items — the **direct (depth-1) dependents** — the plan must account\n for every one of them.\n4. `trace {from, to}` — when the task hinges on _how A reaches B_, one call\n instead of chained context hops.\n5. Statement-level PDG — Phase 3, for the functions the change centers on.\n6. `cypher` — last resort, only for a precise graph question the tools above\n cannot express. Read `gitnexus://repo/{name}/schema` first; anchor and\n LIMIT every query.\n7. `detect_changes {scope}` — only when planning against existing uncommitted\n or branch work.\n\nDo not run every tool by default. A local test fix may finish the ladder at\nstep 2.\n\n## Phase 3 — Statement-level PDG slice\n\nFor the 1–3 functions most central to the change, build a bounded **PDG\ncontext slice**. Read `references/pdg-slice.md` and follow it — it owns the\ntool calls, inclusion criteria, depth bounds, slice schema, the security and\nperformance modes, and the no-PDG-layer fallback.\n\n## Phase 4 — Targeted source verification\n\nGitNexus said where to look; now confirm what is there. Using ordinary file\nreads (exact line ranges, not whole files unless genuinely required):\n\n- Read every source range the plan will cite: signatures, branch conditions,\n state mutations, error paths, nearby comments that change behavior. Compact\n plans cite less — verify what they cite, don't expand the citation set to\n have more to verify.\n- Read the tests GitNexus associated with the primary symbols; never claim a\n test exists without having located it.\n- Verify the build/test commands the plan will name actually exist\n (package.json scripts / CI workflows), and prefer the script form that\n carries its prerequisites (pre-hooks) over invoking underlying binaries\n directly.\n- Check repo conventions that constrain the change (AGENTS.md, GUARDRAILS.md,\n lint/build config) — only the parts the change touches.\n- Mark each ledger symbol `source_verified: true` as you go. **A symbol that\n is named in Proposed Changes must be source-verified.**\n- On graph/source disagreement: trust source, record the discrepancy in the\n ledger and the plan, recommend re-indexing. Never present stale graph data\n as fact.\n- Immediately before composition, recompute the versioned\n `evidence_provenance` snapshot by invoking\n `scripts/evidence-provenance.mjs` exactly as specified in\n `references/evidence-provenance.md`: the\n canonical global dirty digest over all dirty paths and the sorted manifest\n of every cited path, including object kind and\n HEAD/index/worktree/untracked layer digests. Re-read any citation that\n changed during planning. Exclude only the generated plan path.\n\nEvidence hierarchy, strongest first: current source and config → current tests\nand executable behavior → compiler/build/lint output → GitNexus graph and PDG\n→ documentation and comments.\n\n## Phase 5 — Compose the plan\n\n1. Read `references/plan-template.md` and fill the category's form — compact\n (core sections, ≤80 lines excluding the pack) or full (all 13 sections) —\n from the ledger, tagging claims with the template's four classes —\n `[verified]`, `[graph]`, `[inferred]`, `[assumed]` — and routing open\n questions to §12.\n2. Build the implementation context pack per `references/context-pack.md`\n (this is section 11 of the plan), including mandatory\n `evidence_provenance` in compact and full forms.\n3. Set `generated_plan_path` to\n `docs/plans/YYYY-MM-DD-gitnexus-plan-.md` under the root of the repo\n being planned (the Phase 1 target repo, not necessarily the cwd); use a\n 3–5-word kebab-case slug and repo-relative paths inside the document.\n Compose the complete document without creating that destination, then\n pipe its exact UTF-8 bytes to `scripts/evidence-provenance.mjs write-plan`\n as specified in `references/evidence-provenance.md`. The helper safely\n creates missing parent directories. Initial planning must not pass\n `--replace`. A safe-write failure blocks plan publication: report it and\n do not write directly, choose an external destination, or weaken the\n repo-relative provenance contract. The snapshot and writer commands apply\n the same strict generated-plan filename/date validator; do not substitute a\n source, `.git`, or arbitrary `docs/plans/` path in either invocation.\n4. Present in chat: objective, proposed-changes summary, implementation\n sequence, top risks, open questions, and the plan file path. Do not paste\n the whole document into chat.\n\n## Deepen mode\n\n`/gitnexus-plan deepen ` strengthens an existing plan in place\ninstead of creating a new one:\n\n1. Resolve the target repository and normalized repo-relative plan candidate,\n then load it with `scripts/evidence-provenance.mjs read-plan --repo \n--generated-plan ` exactly as specified in\n `references/evidence-provenance.md`. Reject a missing, external, escaping,\n symlinked, or differently scoped path. Decode and parse only the receipt's\n exact `plan_bytes_base64`; retain its canonical `generated_plan_path` and\n `plan_digest` unchanged for the entire Deepen session.\n2. Re-run Phase 1 in full — analyzer provenance check and freshness gate (a\n Deepen run is its own session, with its own refresh budget).\n3. **Re-anchor before re-pinning.** Recompute the plan's global dirty digest\n and cited-path manifest as well as comparing its old HEAD pin with current\n HEAD. Changed, renamed, deleted, mixed, or newly absent cited paths get\n their ranges re-read — or the claim downgraded — _before_ the pin and\n provenance snapshot move. Moving only the commit pin silently launders\n dirty or stale claims as verified.\n4. Escalate to `depth: deep` (impact_depth 3, clusters/processes read)\n unless the invocation overrides knobs explicitly.\n5. Seed the ledger from the plan's §11 pack, then re-verify: every\n `[graph]`/`[inferred]` claim gets a targeted pass toward `[verified]`;\n every `[assumed]` claim is resolved or kept with its reason; direct\n (d=1) dependent accounting is re-checked against the refreshed graph;\n PDG slices are built or expanded for the central functions when the\n layer is present.\n6. **Reconcile execution state.** If `gitnexus-work` already landed commits\n for this plan (a mid-execution route-back), mark the §7 steps present at\n HEAD as completed and re-sequence the remainder — the rewritten plan must\n be executable from the top without redoing landed steps.\n7. Strengthen whatever the deeper pass showed thin — test scenarios, risks,\n Definition of Done — and carry claim-tag upgrades through the prose.\n8. Rewrite the **same canonical file** through\n `scripts/evidence-provenance.mjs write-plan --replace\n--expected-plan-path \n--expected-plan-digest `: same 13 sections,\n context pack kept in sync, evidence header updated. `--replace` is reserved\n for Deepen mode, and both expected values must come from the same read-plan\n receipt; any digest/path mismatch blocks publication. Retain the successful receipt's\n `prior_plan_backup_git_path`; it names the verified Git-admin backup of the\n displaced plan. Summarize the delta in chat: claims upgraded, claims that\n failed re-verification, sections changed, and that backup path.\n\n## Configuration\n\nBaseline defaults — the Phase 0 category posture overrides them, and inline\n`key:value` tokens before the task text override both (the repo has no\nskill-config file mechanism; invocation args are the mechanism):\n\n| Knob | Default | Meaning |\n| --------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `depth` | by category | `narrow` = `impact_depth` 1, PDG only if one function is clearly central; `default` = this table; `deep` = `impact_depth` 3 + clusters/processes read |\n| `form` | by category | `compact` (core sections + mini-pack, ≤80 lines excl. pack — see `references/plan-template.md`) or `full` (all 13 sections) |\n| `impact_depth` | 2 | `maxDepth` for `impact` |\n| `pdg_data_depth` | 2 | Data-dependence hops in the PDG slice |\n| `pdg_control_depth` | 2 | Control-dependence hops in the PDG slice |\n| `max_primary_symbols` | 5 | Ledger budget (active symbols; discards don't count) |\n| `max_related_symbols` | 20 | Ledger budget (active symbols; discards don't count) |\n| `max_snippet_lines` | 30 | Longest source excerpt quoted in the plan |\n| `freshness` | by category | `strict` (full-plan categories) = refresh a stale index (and a missing PDG layer) with `analyze --index-only [--pdg]` before relying on the graph; `accept` (compact categories) = plan on the current graph, source-weighted and labelled, refreshing only if a graph claim becomes load-bearing |\n\n## Fallback mode (GitNexus or PDG unavailable)\n\n1. Say so, first thing, in chat and in the plan.\n2. Use targeted repo exploration (grep/glob/reads) to approximate callers,\n dependencies, execution flow, state changes, and related tests.\n3. Label every such finding **source-derived** in the plan — never present it\n as graph-derived, and never fabricate statement-level edges.\n4. Recommend `analyze --index-only` (add `--pdg` for the PDG layers) via\n the resolved runner — `node .gitnexus/run.cjs`, installed `gitnexus`, or\n `npx gitnexus` — when it would materially raise confidence.\n\n## Skill feedback\n\nIf this run exposed friction in the instructions, include concise feedback in\nthe final response. Feedback is chat-only: do not append evaluation learnings,\nedit benchmark data, or modify this skill during a live planning task.\n","frontmatter":{"name":"gitnexus-plan","description":"Use when you need a deep, implementation-ready engineering plan for a code change — built from GitNexus graph intelligence, statement-level PDG analysis, and targeted source verification, compact enough that an implementation agent can start without re-investigating. Also strengthens existing plans via Deepen mode. Examples: \"/gitnexus-plan Add retry support to the ingestion pipeline\", \"/gitnexus-plan deepen docs/plans/.md\", \"plan this change using the knowledge graph\"."},"isInternal":false,"tokens":5003,"sizeBytes":24158},{"name":"SKILL.md","path":".claude/skills/gitnexus-pr-swarm-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-pr-swarm-review/SKILL.md","title":"gitnexus-pr-swarm-review","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-pr-swarm-review\ndescription: \"Run a GitNexus production-readiness pull request review using a coordinated reviewer swarm.\"\n---\n\n# GitNexus PR Swarm Review (Claude Code adapter)\n\nUse this skill to review a GitNexus pull request and produce a production-readiness review.\n\n> This is the interactive, on-demand reviewer swarm. It is distinct from the CI\n> `gitnexus-review` skill's built-in \"Swarm lanes\" (`ci-personas/`), which the\n> review-agent workflow dispatches automatically inside a single review run.\n\n```\n/gitnexus-pr-swarm-review \n```\n\nYou are the **swarm coordinator**. The full review contract — lanes, dependencies,\nclassifications, output structure, finding format, hidden-Unicode checks, and behavior\nrules — is the canonical, CLI-neutral spec:\n\n**`pr-swarm-review/orchestration.md`** — read it now and follow it.\n\nThis adapter only pins the Claude Code specifics:\n\n- **Run in Swarm mode.** Dispatch each lane as its own subagent via the Agent tool. The\n seven subagents are the project agents named `gitnexus-*` (one per persona); each reads\n its canonical persona under `pr-swarm-review/personas/`. Run lanes 1–2 first, lanes 3–6\n in parallel after, and lane 7 last on the draft.\n- **Lane 7 is a hard gate.** Do not emit the final review while the synthesis critic's\n \"Required corrections before posting\" section is non-empty — revise and re-run it.\n- Stay **read-only**: investigate and report; never edit, commit, or post.\n\nDo not flatten the review into a generic checklist; delegate to the subagents and\nsynthesize per `orchestration.md`.\n","frontmatter":{"name":"gitnexus-pr-swarm-review","description":"Run a GitNexus production-readiness pull request review using a coordinated reviewer swarm."},"isInternal":false,"tokens":385,"sizeBytes":1615},{"name":"SKILL.md","path":".claude/skills/gitnexus-refactoring/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-refactoring/SKILL.md","title":"gitnexus-refactoring","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-refactoring\ndescription: \"Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: \\\"Rename this function\\\", \\\"Extract this into a module\\\", \\\"Refactor this class\\\", \\\"Move this to a separate file\\\"\"\n---\n\n# Refactoring with GitNexus\n\n## When to Use\n\n- \"Rename this function safely\"\n- \"Extract this into a module\"\n- \"Split this service\"\n- \"Move this to a new file\"\n- Any task involving renaming, extracting, splitting, or restructuring code\n\n## Bind the repository first\n\nRefactoring writes to disk. `rename` with `dry_run: false` edits files in\nwhichever repository was resolved, so binding identity here is a safety gate,\nnot bookkeeping.\n\nCall `list_repos {}` before the first tool call. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask. Never run `rename` with\n`dry_run: false` until the preview in the same bound repository has been\nreviewed — its returned `file_path` values show which checkout is about to be\nwritten, so read them as a confirmation of identity.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\n`detect_changes` takes `worktree` when you are editing a linked worktree the\nMCP server was not launched from; otherwise `git diff` runs in the wrong\ncheckout and reports nothing changed, which reads as a verified refactor.\n\n## Workflow\n\n```\n0. list_repos {} → Bind repo (and worktree)\n1. impact({target: \"X\", direction: \"upstream\"}) → Map all dependents\n2. query({search_query: \"X\"}) → Find execution flows involving X\n3. context({name: \"X\"}) → See all incoming/outgoing refs\n4. Plan update order: interfaces → implementations → callers → tests\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Checklists\n\n### Rename Symbol\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] rename({symbol_name: \"oldName\", new_name: \"newName\", dry_run: true}) — preview semantic edits (omitting dry_run also previews)\n- [ ] Confirm the previewed file paths are in the bound repository/worktree\n- [ ] Review exact graph-backed semantic spans, coverage, and limitations\n- [ ] If satisfied: rename({..., dry_run: false, plan_token: \"\"}) — apply exactly the reviewed edits\n- [ ] detect_changes() — verify only expected files changed\n- [ ] Run tests for affected processes\n```\n\n### Extract Module\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] context({name: target}) — see all incoming/outgoing refs\n- [ ] impact({target, direction: \"upstream\"}) — find all external callers\n- [ ] Define new module interface\n- [ ] Extract code, update imports\n- [ ] detect_changes() — verify affected scope\n- [ ] Run tests for affected processes\n```\n\n### Split Function/Service\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] context({name: target}) — understand all callees\n- [ ] Group callees by responsibility\n- [ ] impact({target, direction: \"upstream\"}) — map callers to update\n- [ ] Create new functions/services\n- [ ] Update callers\n- [ ] detect_changes() — verify affected scope\n- [ ] Run tests for affected processes\n```\n\n## Tools\n\n**rename** — semantic rename; preview first, then apply:\n\n```\nrename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: true})\n→ 12 edits across 8 files\n→ semantic_edits: 12, coverage: {name: \"gitnexus-semantic\", scope: \"indexed-repository\", limitations: [...]}\n→ changes: [{file_path, edits: [{start, length, line, old_text, new_text, confidence: \"semantic\"}]}]\n```\n\n`dry_run` omitted or `true` previews and never writes; `dry_run: false` requires\nthe successful preview's `plan_token`. Keep the same repository, selected symbol,\nand destination name. Tokens are single-use, expire after 15 minutes or a server\nrestart, and may be evicted when retained previews reach 16 plans or 64 MiB.\nAny apply attempt consumes the token; request and review a fresh preview to retry.\nAn MCP server started with `GITNEXUS_MCP_READ_ONLY=1` still lists `rename`, but\nas preview-only: it rejects any `dry_run` other than omitted or `true`, so apply\nthrough a server that permits writes. Request and review a fresh preview there;\ntokens belong to the process that issued them.\n\nRename uses the indexed graph and GitNexus's own semantic layer. Language\nproviders resolve current source through scopes and bindings; no compiler or\nlanguage service is loaded. Unsupported syntax, ambiguous bindings, stale\ndeclarations, and incomplete occurrence coverage fail closed. Coverage describes\nindexed files accepted by the selected provider, including supported embedded sources,\nand excludes unindexed files and external consumers. All registered source-language\nproviders supply rename rules. Declaration and override families require complete\nsemantic evidence. Dynamic or computed references block a rename when the provider\ncannot resolve them or exclude them from the selected family. Provider-specific\nlimits, including class renames requiring a file move, remain explicit in results.\nThere is no regex fallback: legacy `graph_edits` and `text_search_edits` are zero.\nComments, strings, and unrelated same-spelled symbols are not replacements.\n\nPreview captures the exact semantic plan, source hashes and physical file targets.\nApply validates that plan and executes its edits without replanning. Changes to\nindexed targets, source bytes or paths (including newly added untracked source\nfiles) reject the plan before writing. Unindexed files remain outside semantic\ncoverage; analyze first when they need refactoring. Results use `result_version: 2`;\n`total_edits` counts occurrences, not matching lines. Exact replacements are shown in `new_text`.\nCheck `planning_status`, `application_status`, and `applied`. A completed apply\nhas `status: \"success\"`, `application_status: \"applied\"`, and `applied: true`.\nA successful preview has not written files. `rename` does not accept `branch`:\nit inspects the current checkout.\n\nRecover from a blocked or incomplete rename before applying again. A failed\nresult carries `code` and `error`; nothing was written unless the last row applies.\n\n| Result | Next step |\n| --- | --- |\n| `stale_graph` | Re-analyze the bound repository, then preview again with `rename` (`dry_run` omitted or `true`). |\n| `source_changed` | Preview again against the current source and review it. If it appears during an apply, see the `partial` row. |\n| `plan_required`, `invalid_plan`, `plan_mismatch` | Apply needs the successful preview's token and identical repository, symbol and new name. Expired, consumed or evicted plans require a fresh reviewed preview. |\n| `source_set_changed` | Source paths changed, including untracked files. Re-analyze and review a fresh preview. |\n| `plan_too_large` | The captured plan exceeds the 64 MiB retention budget. Narrow the indexed repository before previewing again. |\n| `unsupported_*` | Stop automated rename and inspect the reported limitation. Use a language-aware manual refactor if needed. |\n| Ambiguous target (`status: \"ambiguous\"` with candidates) | Inspect the returned candidates or `context`, then preview with the chosen `symbol_uid`. |\n| `ambiguous_reference`, `incomplete_semantics` | The planner could not prove a reference, import, or declaration is covered. Stop automated rename; resolve the named location by hand or pick a different symbol. |\n| `name_collision` | `new_name` would collide with, or change the identity of, another declaration or binding. Choose a different name and preview again. |\n| `invalid_name` | `new_name` is empty, equals the current name, or is not valid in the target language. Choose a valid, different identifier. |\n| `invalid_argument` | `dry_run` was sent but is not a boolean. Omit it or send `true` or `false`. |\n| `no_locations` | The planner produced no edits. Do not apply; re-check the target with `context` and pass `symbol_uid`. |\n| `overlapping_edits`, `invalid_edit` | The planned spans conflict or do not match the source text. The plan is rejected before any write; do not apply. Refactor manually or report the case. |\n| `duplicate_file`, `missing_snapshot`, `outside_repository` | A planner safety check failed (two paths resolve to one real file, a file has no source snapshot, or a path leaves the repository). Re-analyze and preview again; if it repeats, stop and report it. |\n| `source-unavailable` (`reason: \"content-retention\"` or `\"checkout-missing\"`) | The index was built without full source retention (`GITNEXUS_CONTENT_RETENTION`), or the checkout directory is missing. Re-analyze with full retention, or run against the checkout. |\n| `rename_failed` | An unexpected error while planning, before any write (`application_status: \"not_started\"`). Re-analyze and preview once more; if it repeats, stop and report the `error` text. |\n| `application_status: \"partial\"` or `\"failed\"` (`write_failed`, or `source_changed` mid-apply) | Writes are not transactional. Inspect landed `changes` (already written, with their counts), `failed_files` (the one file whose write or validation failed), and `unattempted_files` (later files never touched). Reconcile the current files, re-index, and review a fresh preview; never blindly retry the apply call. |\n\nRun the project validation suite after applying.\n\n**impact** — map all dependents first:\n\n```\nimpact({target: \"validateUser\", repo: \"my-app\", direction: \"upstream\"})\n→ d=1: loginHandler, apiMiddleware, testUtils\n→ Affected Processes: LoginFlow, TokenRefresh\n```\n\n**detect_changes** — verify your changes after refactoring:\n\n```\ndetect_changes({scope: \"all\"})\n→ Changed: 8 files, 12 symbols\n→ Affected processes: LoginFlow, TokenRefresh\n→ Risk: MEDIUM\n```\n\n`partial: true` (a graph query failed) or `truncated: true` (the changed-symbol\nlisting was capped) means the result is short of the truth: a short or empty\nlist is not proof that only the expected files changed. Re-run it rather than\ntreat the refactor as verified.\n\nA wrong-worktree zero carries neither flag and is indistinguishable from a\nclean verification, so confirm the diffed checkout is the one you edited.\n\n**cypher** — custom reference queries:\n\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"validateUser\"})\nRETURN caller.name, caller.filePath ORDER BY caller.filePath\n```\n\n## Risk Rules\n\n| Risk Factor | Mitigation |\n| ------------------- | ----------------------------------------- |\n| Many callers (>5) | Use rename for automated updates |\n| Cross-area refs | Use detect_changes after to verify scope |\n| String/dynamic refs | query to find them |\n| External/public API | Version and deprecate properly |\n| Same name in another indexed repo | Bind `repo`; verify previewed paths before applying |\n\n## Example: Rename `validateUser` to `authenticateUser`\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly\n\n1. rename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: true})\n → 12 semantic occurrences in the indexed repository's supported provider scope\n → Files: validator.ts, login.ts, middleware.ts...\n\n2. Review semantic spans and provider coverage; inspect dynamic references separately\n\n3. rename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: false, plan_token: \"\"})\n → Applied 12 edits across 8 files\n\n4. detect_changes({scope: \"all\", repo: \"my-app\"})\n → Affected: LoginFlow, TokenRefresh\n → Risk: MEDIUM — run tests for these flows\n Repository: my-app (/abs/path/my-app) Worktree: same Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n","frontmatter":{"name":"gitnexus-refactoring","description":"Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: \"Rename this function\", \"Extract this into a module\", \"Refactor this class\", \"Move this to a separate file\""},"isInternal":false,"tokens":2904,"sizeBytes":12532},{"name":"ci-adversarial-lens.md","path":".claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","tokens":300,"sizeBytes":255},{"name":"ci-blast-radius-lens.md","path":".claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","tokens":300,"sizeBytes":257},{"name":"ci-correctness-lens.md","path":".claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","tokens":300,"sizeBytes":255},{"name":"ci-coverage-lens.md","path":".claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","tokens":300,"sizeBytes":249},{"name":"ci-critic-lens.md","path":".claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","tokens":300,"sizeBytes":245},{"name":"ci-security-lens.md","path":".claude/skills/gitnexus-review/ci-personas/ci-security-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md)","tokens":300,"sizeBytes":249},{"name":"SKILL.md","path":".claude/skills/gitnexus-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/SKILL.md","title":"gitnexus-review","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-review\ndescription: 'Review code changes with GitNexus from a GitHub PR URL or number, a branch/ref or commit range, or local staged, unstaged, and untracked changes. Use when the user asks for a code review, merge-risk assessment, regression hunt, missing-test analysis, or a verdict on whether a PR, branch, commit range, or local diff is safe.'\n---\n\n# GitNexus review\n\nReview the requested change surface without editing source, committing, pushing,\nposting, or resolving threads. A later explicit request may authorize those\nactions. Use GitNexus for structural evidence and source inspection for proof;\nneither substitutes for the other.\n\n## Resolve the target\n\nAccept these forms:\n\n| Input | Review surface |\n| ------------------------------------------------------ | --------------------------------------------------------------------------- |\n| PR URL, `owner/repo#42`, `#42`, or bare number | GitHub PR |\n| `base...head` | Merge-base range |\n| `base..head` | Exact two-dot range |\n| Branch, tag, or commit | Ref against the repository default branch |\n| `local`, `staged`, `unstaged`, or working-tree wording | Local changes |\n| No target | Current branch's open PR; otherwise local changes; otherwise current branch |\n\nAn explicit target always wins. Interpret a bare number as a PR only in a\nGitHub repository with working `gh` authentication; otherwise ask for a ref or\nURL. If implicit mode finds both branch commits and local changes, review them\nas two labeled surfaces rather than silently dropping or blending either one.\n\nRecord the resolved target kind, repository root, default branch, base SHA,\nhead SHA, merge-base when applicable, and included local states. Resolve the\ndefault branch from remote metadata (`refs/remotes//HEAD` or GitHub\nrepository metadata); use `main` or `master` only as an explicit fallback and\nsay when doing so.\n\n### PR\n\nUse `gh pr view`/`gh api` to pin the PR number, repository, title, URL, base\nref, base SHA, head ref, and head SHA. Fetch those exact commits without\nswitching the user's branch. Compute `git merge-base ` and use\nthat SHA as the review base: GitHub PR diffs are merge-base diffs, while\n`detect_changes(scope: \"compare\")` is a two-dot comparison.\n\nUse the local `git diff ` as the complete diff source of\ntruth; use GitHub metadata for PR facts and review state. For fork PRs, fetch\nthe pull ref or the contributor remote instead of assuming the head branch\nexists on `origin`.\n\n### Branch, ref, or range\n\nResolve every ref to a commit before reviewing. For a branch or `A...B`, use\nthe merge-base as the comparison base. For an explicit `A..B`, honor `A` as\nthe exact base. Do not compare a feature branch directly with a moving default\nbranch tip when merge-base semantics were intended.\n\n### Local changes\n\nInspect `git status --short`, the staged diff, the unstaged diff, and every\nuntracked file. Use `detect_changes` with `staged`, `unstaged`, or `all` as\nrequested. Untracked files are not guaranteed to appear in Git diff or graph\nmapping, so read them directly and list them in the review provenance.\n\n## Align the checkout and index\n\nThe graph and diff must describe the same head. Reuse an existing worktree only\nwhen it is at the exact target SHA. Otherwise create a temporary detached\nworktree for the PR/ref head, review there, and remove only that temporary\nworktree afterward. Never switch or reset the user's current worktree.\n\nCheck GitNexus status in the target worktree. If stale, run\n`node .gitnexus/run.cjs analyze --index-only` before trusting graph results\n(temporary worktrees never carry the gitignored `run.cjs` — fall back to the\ninstalled `gitnexus` CLI, then `npx gitnexus`), and include `--pdg` in that\nsame refresh when the diff plausibly touches trust or data-flow boundaries,\nso the taint pass below doesn't pay a second full analyze. Taint and\ndependence evidence needs that PDG layer: when the workflow's taint pass\nfinds it missing, rebuild with `analyze --pdg --index-only` and record the\nrebuild in provenance. For local changes, refresh the index so new or\nmodified source is represented.\nIf an exact target checkout/index cannot be established, state the limitation\nand do not claim a complete graph-backed review.\n\n## Review workflow\n\n1. Read the full diff and changed-file list. Separate generated files,\n dependency churn, tests, and behavior changes.\n2. Run `detect_changes` against the exact surface:\n - PR/branch/`...`: `scope: \"compare\"`, `base_ref: `.\n - Explicit `A..B`: `scope: \"compare\"`, `base_ref: ` from a worktree\n at `B`.\n - Local: `scope: \"staged\"`, `\"unstaged\"`, or `\"all\"`.\n Pass `worktree` when the MCP server is attached elsewhere.\n3. Run upstream `impact` with `includeTests: true` for each behaviorally changed\n symbol. Prioritize public contracts, shared types, control flow, persistence,\n security boundaries, and error handling; skip mechanical/generated changes.\n4. Inspect every direct (`d=1`) dependent that is outside the diff. A dependent\n outside the diff is a lead, not automatically a bug—verify the changed\n contract and caller behavior in source.\n5. Use `context` on key or ambiguous symbols and inspect affected execution\n flows. Read the surrounding implementation and tests at cited locations.\n6. **Taint and dependence pass.** For changed code on trust or data-flow\n boundaries — external input, persistence, process execution, network,\n auth — run `explain` on the changed files or symbols and judge its\n source→sink taint findings against the diff: a flow the change\n introduces, or a sanitizer/guard the change removes, is a finding; a\n pre-existing flow is context, not a defect of this change. When the\n change claims to guard or sanitize something, verify with `pdg_query`:\n what controls the changed statement, and where its values flow. This\n needs a `--pdg` index; if one cannot be built, state that the taint pass\n was skipped rather than implying coverage.\n7. Check whether tests exercise the changed behavior, boundary conditions, and\n affected flows. Run focused read-only validation when practical. When the\n diff refreshes a committed baseline, fingerprint, or golden, re-run the\n exact CI check command against the head instead of trusting the committed\n value — a stale artifact is invisible in the diff and fails only in CI.\n8. Reconcile graph evidence with the raw diff. New files, dynamic dispatch,\n configuration, reflection, and untracked content may require direct review\n even when graph results are empty. Version and invalidation constants are\n review surface: when the diff changes what gets emitted or persisted,\n verify every schema/version constant gating caches, incremental\n writebacks, and fingerprint baselines was bumped or regenerated — in\n GitNexus itself, for example: graph DDL needs no manual bump, because\n `SCHEMA_FINGERPRINT` (`gitnexus/src/core/lbug/schema.ts`) is derived\n from `NODE_SCHEMA_QUERIES` + `REL_SCHEMA_QUERIES` and moves on its own;\n the check there is whether the diff changed any string in those arrays,\n and, if it added a new DDL array, whether that array was folded into the\n fingerprint. Parser compatibility is also automatic: review the base/PDG\n ownership boundaries in `gitnexus/src/core/parse-cache-identity.ts`, the\n import/asset coverage audit, and real cold → warm replay tests. New parser\n dependencies outside those boundaries need explicit coverage; contributors\n do not allocate a semantic counter. Both benchmark fingerprint sets still\n need deliberate review before re-baselining: automatic invalidation does\n not establish semantic correctness. Other semantic changes that leave DDL\n untouched rely on the analyzer runner-identity receipt in index metadata.\n\n## Expert lenses\n\nDepth comes from matching reviewers to what actually changed, not from one\ngeneralist pass. After workflow step 2, group the changed files and symbols\nby the functional areas the graph already knows — the index's cluster\nlisting; `context` names each symbol's cluster — and give each touched area\nan expert lens: a reviewer charged with that domain's contracts, invariants,\nand failure modes, grounded in the repo's own material (architecture docs,\nagent rules, the domain's tests) before judging the diff. A lens verifies,\nnot just reads: when the changed code is a pure function reachable from the\nrepo's own toolchain — parsers, extractors, capture emitters, formatters —\nexecute it on the candidate failing shape (a scratch probe, deleted\nafterward) and cite the observed output. An empirical probe outranks source\nreading in the evidence hierarchy; role swaps, dead branches, and\nerror-recovery-dependent behavior repeatedly pass a reading and fail a\nten-line probe. The numbered\nworkflow runs exactly once; dispatch the lens passes after step 6, handing\neach lens the evidence already collected rather than letting lenses repeat\nthe `impact`, `context`, or taint calls. In GitNexus\nitself, for example: shared ingestion-pipeline changes get an ingestion\nexpert plus one language expert per changed language extractor; embeddings\nchanges an embeddings expert; LadybugDB/storage changes a Ladybug expert.\n\nFour cross-cutting lenses run regardless of domain:\n\n- **Architectural fit** — the change lands where the architecture says the\n concern lives, reuses existing seams, and adds no parallel structure.\n- **Language conformance** — the repo's own type/lint/test contract as\n configured (tsconfig strictness, lint rules, test conventions); in a\n strict TypeScript repo, for example: strictness intact, no `any`/`as any`\n escapes, module boundaries typed. Judge by the repo's contract, never a\n universal style bar.\n- **Definition of Done** — changed behavior has tests, docs the change makes\n stale are updated, and sync/drift guards (shipped copies, manifests,\n changelogs) still hold.\n- **Simplicity** — YAGNI and clear-code check: flag speculative abstraction,\n unused knobs, and overengineering; the smallest diff that meets the\n Definition of Done is the standard.\n\nScale effort to the surface: a single-domain change of a few files gets one\ncombined pass covering its domain lens plus the four cross-cutting checks;\na multi-domain change gets one lens per touched area — run as parallel\nsubagents where the harness supports them, each scoped to its own files\nplus the shared graph evidence, and as sequential passes otherwise. Never\nspawn a lens for a domain the diff does not touch. Merge lenses that ground\nin the same material — two lenses reading the same files pay twice for one\nread's coverage, so give one reviewer both charges. Where the harness\noffers model or effort tiers, run mechanical lenses (rename sweeps,\ndoc-consistency checks) on a cheaper tier and reserve the strongest engine\nfor adversarial judgment. Every lens reports\nthrough the Finding standard below; merge and dedup before the verdict,\ndropping anything without a concrete failing scenario.\n\n### Swarm lanes\n\nSix dispatchable lane definitions ship with this skill in `ci-personas/` —\nread-only reviewers restricted to file reads plus the safe graph tools. Five are finder lanes: `ci-correctness-lens`, `ci-security-lens`,\n`ci-blast-radius-lens`, `ci-coverage-lens`, and `ci-adversarial-lens`\n(which assumes the change is broken and constructs reachable failure\nscenarios the pattern checks miss). They carry the verification\ndimensions of the numbered workflow across every touched domain; domain\ngrouping and the four cross-cutting checks above remain the\norchestrator's charge. The sixth, `ci-critic-lens`, is a gate, not a\nfinder — it audits the finished draft.\n\nWhen the harness supports subagents and these lanes are registered as\nagents (the CI review workflow installs them from its trusted control\ncheckout; a local harness may register them by copying `ci-personas/*.md`\ninto `~/.claude/agents/` or the project's `.claude/agents/`), run the\nexpert-lens pass as follows. First establish your own graph evidence —\nmake at least one substantive context call on a changed symbol yourself,\nbefore dispatching any lane, since lane calls never satisfy the evidence\nthis skill or its runner requires. Then dispatch all five finder lanes in\nparallel in a single message. Give each lane the diff, the changed-file\nmanifest, the exact base and head identifiers, the checkout paths, and the\nslice of changed files matching its charge.\n\nTreat every lane report as an unverified claim: re-anchor each finding to\nthe diff, the source, or your own graph queries before it enters the\nreview; dedup across lanes; drop anything without a concrete failing\nscenario. Lane tool calls never substitute for evidence this skill or its\nrunner requires from the orchestrating conversation itself.\n\nAfter composing the complete draft review, dispatch `ci-critic-lens` with\nthe full draft body plus the same context. On `DEFECTS`, repair the draft\nand re-dispatch the critic once; if defects remain after the second pass,\nfix what you accept, note the unresolved critic objections in the\ncoverage section, and proceed — the critic hardens the review; it never\nblocks it. This fail-open is deliberate: the critic is bounded to two\npasses so it cannot deadlock or wedge the run, and the review is still\ngated by the runner's own evidence and schema checks. (This is distinct\nfrom the separate `gitnexus-pr-swarm-review` skill, whose interactive\nroster treats its critic as a hard gate that must clear before emission;\nthis CI lane must always emit a review or a clean failure.) If subagent\ndispatch is unavailable or any lane fails, run that lane's charge inline —\nthe lanes structure the work; they never gate it.\n\n## Finding standard\n\nReport a finding only when the reviewed change introduces a concrete defect,\nregression, security issue, compatibility break, material coverage gap, or a\nmaintainability cost with a concrete carrying scenario (a dead knob, a\nduplicated contract, a drift-prone copy).\nEach finding must include:\n\n- severity and a precise `path:line` anchor;\n- the failing scenario or contract;\n- GitNexus evidence (dependent symbol/process) when applicable;\n- why existing code or tests do not mitigate it;\n- a concise remediation or missing test.\n\nDo not report style preferences, pre-existing issues, raw risk counts, or\nspeculation as defects. Do not infer safety from zero graph hits. Calibrate\noverall risk from consequence, reachability, reversibility, and test evidence,\nnot from the number of changed symbols alone.\n\n## Output\n\nLead with findings in severity order. If there are none, say so explicitly.\nThen provide:\n\n```markdown\n## Review: \n\n### Findings\n\n- [HIGH|MEDIUM|LOW] `path:line` — \n\n### Change and blast-radius summary\n\n- Target/base/head/merge-base and local states reviewed\n- Changed symbols and affected execution flows\n\n### Coverage and residual risk\n\n- Tests present, tests missing, graph/diff limitations\n\n### Verdict\n\nAPPROVE | REQUEST CHANGES | NEEDS DISCUSSION\n```\n\nFor a branch or local review, use `READY`, `NOT READY`, or `NEEDS DISCUSSION`\ninstead of a PR approval action. Include the exact target SHAs so a later run\ncan tell whether the evidence is stale.\n","frontmatter":{"name":"gitnexus-review","description":"Review code changes with GitNexus from a GitHub PR URL or number, a branch/ref or commit range, or local staged, unstaged, and untracked changes. Use when the user asks for a code review, merge-risk assessment, regression hunt, missing-test analysis, or a verdict on whether a PR, branch, commit range, or local diff is safe."},"isInternal":false,"tokens":3427,"sizeBytes":15909},{"name":"README.md","path":".claude/skills/gitnexus-work/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/README.md","title":"Gitnexus-work Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-work Skill\n\nPath: `.claude/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/README.md)","tokens":300,"sizeBytes":203},{"name":"evidence-provenance.md","path":".claude/skills/gitnexus-work/references/evidence-provenance.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/references/evidence-provenance.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `.claude/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/references/evidence-provenance.md)","tokens":300,"sizeBytes":248},{"name":"SKILL.md","path":".claude/skills/gitnexus-work/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/SKILL.md","title":"gitnexus-work","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-work\ndescription: 'Use when executing an engineering plan produced by gitnexus-plan (or a small bounded task directly) — implements step by step with GitNexus impact checks before every symbol edit, tests from the plan''s scenarios, and detect_changes gating every commit. Examples: \"/gitnexus-work docs/plans/2026-07-11-gitnexus-plan-ingestion-retry.md\", \"/gitnexus-work\" (latest plan), \"execute the plan\".'\n---\n\n# gitnexus-work — execute a gitnexus-plan\n\nExecute an implementation plan produced by `gitnexus-plan`, shipping it as a\nsequence of verified, atomic commits. The plan's section 11\n(`implementation_context` pack) is the primary machine-readable input; the\nprose sections are its rationale. This skill **does** edit code — it is the\nexecutor counterpart to the planning-only `gitnexus-plan`.\n\n```\n/gitnexus-work # execute this plan\n/gitnexus-work # newest docs/plans/*gitnexus-plan*.md here\n/gitnexus-work # direct mode, see Input triage\n```\n\n## Input triage\n\n- **Plan path** (or blank → the newest `docs/plans/*gitnexus-plan*.md` under\n the current repo root): the normal mode; continue to Phase 1. Schema-2\n plans have a normalized repo-relative\n `docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md`\n `generated_plan_path`. Resolve only a lexical candidate, then invoke\n `scripts/evidence-provenance.mjs read-plan --repo --generated-plan\n` and load only the exact bytes in its descriptor-anchored\n receipt. Require the receipt's canonical repo-relative path to equal the\n document's `generated_plan_path` byte-for-byte;\n reject an external, escaping, differently scoped, or mismatched value. A\n plan in another target repo may still be passed by explicit path. If Phase 1's\n pre-completed check finds every §7 step of the newest plan already landed,\n stop and ask instead of re-executing it.\n- **Bare task text**: trivial and bounded (1–2 files, no architectural\n decisions) → implement directly with the same discipline: `impact` before\n every symbol edit, minimal change, tests when behavior changes,\n verification commands taken from the repo's own scripts (package.json /\n CI), `detect_changes` before every commit, and the shared\n Build-current/index-current procedure before graph-dependent impact and\n final verification. Anything larger → recommend running\n `/gitnexus-plan` first; honor the user's choice if they decline.\n\n## Phase 1 — Load and re-anchor the plan\n\n1. Resolve the target repo and normalized plan candidate, then invoke this\n skill's descriptor-anchored `scripts/evidence-provenance.mjs read-plan`\n command exactly as\n specified in `references/evidence-provenance.md`. Reject a missing,\n external, escaping, symlinked, or differently scoped path. Decode and read\n the receipt's exact `plan_bytes_base64` completely; never read or reopen the\n lexical path directly. It is a decision artifact, not a script: scope\n boundaries and `avoid` entries bind you; exact code is yours to write.\n Retain the receipt's canonical `generated_plan_path` and `plan_digest` in\n session state. Never edit the plan body.\n2. Parse the §11 `implementation_context` pack: `acceptance_criteria`,\n `evidence_provenance`, `primary_symbols`, `related_symbols`,\n `files_to_modify`, `execution_path`, `pdg_constraints`,\n `architectural_patterns`, `tests`, `verification_commands`, `risks`,\n `assumptions`, `open_questions`, `avoid`. Compact plans carry the\n mini-pack subset — absent optional fields are empty, not errors.\n `evidence_provenance` is mandatory: absence or schema 1 means a legacy\n plan, not a clean tree. Before relying on it, require exact byte-for-byte\n equality between the read-plan receipt's canonical `generated_plan_path`\n and `evidence_provenance.generated_plan_path`.\n3. **Two-layer drift check — always recompute.** Even when current HEAD is the\n same HEAD as the plan pin, recompute both the canonical global dirty digest\n and the sorted cited-path manifest. Read\n `references/evidence-provenance.md`, then invoke this skill's\n `scripts/evidence-provenance.mjs` with the plan's exact\n `generated_plan_path`, every cited manifest path, and schema version 2.\n Never recreate its bytes in shell or prose. Schema 1 cannot be recomputed\n unambiguously and requires conservative re-anchoring. Include\n object kind plus HEAD/index/worktree/untracked layer digests, and classify\n `staged`, `unstaged`, `untracked`, `deleted`, `renamed`, `mixed`,\n and `absent` evidence. Honor the generated-plan exclusion exactly; do not\n exclude all plans.\n4. **Re-anchor on either mismatch.** Missing or legacy provenance, a HEAD\n mismatch, or a global dirty digest mismatch requires a conservative\n re-anchor before work:\n - Diff every cited-path manifest entry. Changed cited paths — including\n staged-only, unstaged-only, deleted, both rename endpoints, mixed\n staged+unstaged, and disappeared untracked paths — get their cited ranges\n re-read before reliance.\n - Compare the current whole-tree dirty set with the pinned global digest.\n New uncited dirty paths get a scope assessment: determine whether they\n overlap the plan, requirements, tests, or a key technical decision; do not\n silently ignore them merely because they are uncited.\n - Unreadable or unclassifiable cited evidence blocks every dependent step\n until it can be restored, read, or resolved with the user. Never substitute\n an invented digest or treat absence as an empty file.\n - Keep the re-anchor result in session state; never mutate the plan body.\n Use Deepen only if reconciliation invalidates scope, requirements, a key\n technical decision (KTD), or the planned implementation seam. Ordinary\n byte drift that leaves those decisions valid is re-verified locally.\n5. **Re-verify `assumptions` cheaply** (each one names what to check).\n A failed assumption is a stop-and-replan signal for the steps that\n depend on it, not something to code around silently.\n6. Note `open_questions` — if one blocks a step and the answer materially\n changes the work, ask the user before that step, not after.\n7. **Pre-completed check.** If commits for this plan already exist on the\n branch (a prior partial run, or a post-route-back Deepen cycle), verify\n which §7 steps have landed at HEAD: those are skipped and reported as\n pre-completed, and execution resumes at the first unlanded step. All\n steps landed → report that and stop.\n\n## Phase 2 — Environment\n\n- On the default branch → create a feature branch named from the plan slug.\n On a feature branch already → stay only if it is meaningful _for this\n plan_ (name matches the plan slug, or the user confirms); otherwise\n branch from here with the slug name.\n- If the plan document is not yet committed, commit it now\n (`docs(plans): add plan`) — the plan travels with the work it\n drives, and the final review diff then includes it.\n- Confirm the `verification_commands` from the pack actually run in this\n checkout (dependencies installed, builds present) before starting, not\n after the last step.\n\n### Build-current/index-current procedure\n\nThis is the single graph-freshness procedure owned by `gitnexus-work`; it\napplies in plan mode and direct mode. Before every graph-dependent `impact`\nquery, run the Build-current/index-current procedure. Before final graph\nverification, run the same Build-current/index-current procedure again.\n\n1. Capture current HEAD and working-tree provenance. Read\n `gitnexus://repo//context` and use its typed `index.commit` and\n `index.runner_identity` receipt — never infer analyzer identity from prose,\n timestamps, or a path alone. Compare `index.commit` with current HEAD. A\n current receipt has `schemaVersion: 4`, resolved runtime path/version, CLI\n version, invoked-artifact path/digest, build\n kind/root/canonicalization/digest, and dependency-runtime\n manifest/lockfile/canonicalization/package-count/artifact-count/digest. Its\n dependency canonicalization is\n `gitnexus-analyzer-dependency-runtime-v4`. The dependency-runtime digest\n covers resolved package metadata and complete loadable package payloads,\n including JavaScript, JSON, native, Wasm, and parser artifacts; schema-1,\n schema-2, and schema-3 receipts are legacy/stale (the MCP context labels\n them `runner_identity_schema_status: legacy-or-unknown`). Require MCP\n `index.incomplete_reasons: []`. Run the exact candidate CLI's\n `status --json` command and require `index.runnerIdentityStatus: current`,\n `index.incompleteReasons: []`, and top-level `status: up-to-date`. The\n status comparator checks every semantic field while deliberately excluding\n only diagnostic `invokedArtifact`; a worker-authored persisted receipt and\n the CLI's live receipt may therefore differ in that field without becoming\n stale. Missing, malformed, differently versioned, semantically unequal, or\n incomplete receipts are unknown/stale, not a match.\n2. Relationship-affecting committed and uncommitted edits invalidate\n freshness after the last successful procedure run. This includes staged,\n unstaged, untracked, deleted, or renamed analyzer/source/config changes\n that can alter symbols or edges. Any such edit between steps requires an\n inter-step refresh before the next graph query, even when HEAD did not move.\n3. If the typed runner receipt is stale or unknown in an analyzer-source\n checkout, build current local source using the verified package script. In\n this repo: `cd gitnexus && npm run build`. Resolve the package's `bin`\n target and run that exact artifact's `status --json` command to capture its\n current receipt. Source/build timestamps are a conservative rebuild\n trigger, not proof that an artifact is current.\n4. Invoke that exact freshly built local CLI from the target repo root with\n PDG layers enabled. In this repo:\n `node gitnexus/dist/cli/index.js analyze --index-only --pdg`.\n Add `--force` when the persisted receipt was absent, malformed,\n differently versioned, or unequal so an already-up-to-date fast path cannot\n leave legacy/stale provenance in place. The usual project-runner form,\n `node .gitnexus/run.cjs analyze`, is acceptable only when its proven runner\n identity resolves to that same freshly built artifact. Do not fall back to\n an older project runner, global install, or package download after\n resolving/building the local artifact.\n5. Re-read index context, rerun the exact invoked CLI's `status --json`, and\n prove the post-refresh `index.commit` equals current HEAD, MCP\n `index.incomplete_reasons` is empty, and its complete\n `index.runner_identity` equals status `index.runnerIdentity` (the persisted\n receipt). Require status `index.runnerIdentityStatus: current`, empty\n `index.incompleteReasons`, and top-level `status: up-to-date`; do not require\n raw equality with `current.runnerIdentity` because `invokedArtifact` is a\n diagnostic entrypoint deliberately excluded from semantic freshness.\n Record the dirty-state digest indexed in this procedure so same-HEAD\n uncommitted edits can invalidate it later.\n6. Any build, refresh, metadata-read, or identity-verification failure blocks\n graph-dependent impact work and final completion. Report the failing\n command and evidence; do not continue on an older graph.\n\n## Phase 3 — Execute the Implementation Sequence\n\nWork through plan §7 step by step, in order. For each step:\n\n1. **Fresh impact before editing.** Run the Build-current/index-current\n procedure immediately before every graph-dependent\n `impact {target, direction: \"upstream\"}` query. Then account for every\n direct (d=1) dependent. HIGH or CRITICAL risk → surface it to the user\n with the blast radius before proceeding (repo mandate — see AGENTS.md\n GitNexus rules).\n2. **Honor the constraints.** `pdg_constraints` entries state ordering and\n dependence facts the change must preserve; `avoid` entries are hard\n prohibitions; `architectural_patterns` name the shape to mirror (read the\n example location before inventing one).\n3. **Implement minimally.** The smallest change that completes the step,\n following the surrounding code's conventions.\n4. **Test from the plan's scenarios.** Each `tests[]` scenario (input →\n action → expected outcome) becomes a real test in the named file. Add\n coverage the plan missed if the step's behavior demands it; never delete\n or weaken an assertion to make a step pass. Prove a new regression test\n discriminates: when the failure mode is subtle, run it once against the\n pre-fix tree (write the test before the fix, or stash the fix) and watch\n it fail — a test that passes both ways pins nothing.\n5. **Verify.** Run the step-relevant `verification_commands` (they carry\n their build prerequisites; use them as written). If any part of the\n change executes from build output — worker entrypoints, dist-shipped\n CLIs, bundled assets — rebuild that output before every verification\n run: a pass or fail against outdated build output is noise, and \"the\n fix doesn't work\" is more often \"the fix never loaded\".\n6. **Commit atomically.** `detect_changes {scope: \"staged\"}` before every\n commit to confirm only the expected symbols and flows are affected\n (repo mandate); then one conventional commit per step. Run stage →\n `detect_changes` → commit as one unbroken sequence from the repository\n root — interleaving other work between the gate and the commit is how\n the gate gets skipped. Unexpected\n affected flows → investigate before committing, not after. A result\n flagged `partial` (a graph query failed) or `truncated` (the symbol\n listing was capped) blocks the commit the same way: the gate did not\n see every changed symbol, so re-run it rather than read it as clean.\n\nA relationship-affecting implementation edit or commit invalidates the\nprocedure's prior proof. The next step must perform the required inter-step\nrefresh before its impact query; final verification refreshes again after the\nlast edit.\n\nSteps are independently actionable: after any commit the tree is coherent.\nIf a step reveals the plan is wrong, stop that step, re-verify the affected\nclaims at HEAD, and either adapt (small, in-scope deviation — record it in\nthe commit message and final summary) or route back to `gitnexus-plan`\nDeepen mode (structural miss) — with a one-line ask to the user when the\nchoice isn't obvious.\n\n## Phase 4 — Finish\n\n1. Run the full `verification_commands` suite once, at the end, even if\n every step already passed individually.\n2. Walk plan §13 (Definition of Done) and the pack's `acceptance_criteria`\n item by item; anything unmet is either finished now or reported as\n explicitly unmet — never silently dropped.\n3. **Verify the final knowledge graph.** Before final graph verification, run\n the same Build-current/index-current procedure after the last edit, even\n when no commit landed or HEAD still equals the original pin. Then run\n `detect_changes {scope: \"all\"}` (or the repo's equivalent final graph\n check) against that proven-current index and account for every unexpected\n symbol or flow. A procedure failure blocks completion.\n4. Report: steps completed, commits made, deviations from the plan (with\n why), assumptions that failed re-verification, DoD status, final indexed\n commit and runner identity, and anything deferred. Test failures are\n reported with their output, not smoothed over.\n\n## Never\n\n- Skip the Phase 3 gates: no symbol edit without `impact`, no commit without\n `detect_changes`.\n- Expand scope beyond the plan — §12's deferred follow-ups stay deferred.\n- Mutate the plan body (committing the file verbatim in Phase 2 is not\n mutation), weaken failing tests, or present unverified work as verified.\n\n## Skill feedback (GitNexus repo only)\n\nIf this run exposed friction in this skill's own instructions — wrong or\nmissing guidance, a wasted tool budget, a phase that misrouted — and the repo\ncarries `eval/workflow_bench/`, append one JSON line to\n`eval/workflow_bench/learnings.jsonl` (create the file if absent):\n`{\"skill\": \"gitnexus-work\", \"date\": \"YYYY-MM-DD\", \"task\": \"\", \"friction\": \"\", \"suggestion\": \"\"}`.\nNever edit this skill file itself from a live task: improvements go through\nthe offline candidate loop (`eval/workflow_bench/README.md` § Prompt and\nskill evolution loop), where a candidate must beat the incumbent on the\npaired benchmark before a human merges it.\n","frontmatter":{"name":"gitnexus-work","description":"Use when executing an engineering plan produced by gitnexus-plan (or a small bounded task directly) — implements step by step with GitNexus impact checks before every symbol edit, tests from the plan's scenarios, and detect_changes gating every commit. Examples: \"/gitnexus-work docs/plans/2026-07-11-gitnexus-plan-ingestion-retry.md\", \"/gitnexus-work\" (latest plan), \"execute the plan\"."},"isInternal":false,"tokens":3822,"sizeBytes":16709},{"name":"SKILL.md","path":".claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md","title":"gitnexus-pdg-query","category":"anthropic-skill","format":"markdown","content":"# gitnexus-pdg-query\n\nPath: `.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md)","tokens":300,"sizeBytes":228},{"name":"SKILL.md","path":".claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md","title":"gitnexus-taint-analysis","category":"anthropic-skill","format":"markdown","content":"# gitnexus-taint-analysis\n\nPath: `.claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-taint-analysis/SKILL.md)","tokens":300,"sizeBytes":243},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json","title":"Gitnexus-cli Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-cli Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-cli/mcp.json)","tokens":300,"sizeBytes":228},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-cli/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-cli/SKILL.md","title":"gitnexus-cli","category":"anthropic-skill","format":"markdown","content":"---\nname: gitnexus-cli\ndescription: \"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \\\"Index this repo\\\", \\\"Reanalyze the codebase\\\", \\\"Generate a wiki\\\"\"\n---\n\n# GitNexus CLI Commands\n\nCommands below use `node .gitnexus/run.cjs ` — the project-local runner `gitnexus analyze` drops next to the index. It auto-selects an available runner at call time (global `gitnexus`, else `pnpm dlx`, else `bunx`, else `npx`), so no package-manager assumption and no global install is required — including on a bun-only machine, which has no npm, npx or pnpm at all.\n\n> **Not analyzed yet, or `node .gitnexus/run.cjs` reports `Cannot find module`** (the gitignored runner is absent — e.g. a fresh clone or `git clean`)? (Re)generate it with `npx gitnexus analyze` from the project root, or `bunx gitnexus@latest analyze` on a bun-only machine. On **npm 11.x**, if `npx` crashes during install (`node.target is null`), install once with `npm i -g gitnexus` (then `gitnexus analyze`), or use `bunx gitnexus@latest analyze`, or `pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze`. See [#1939](https://github.com/abhigyanpatwari/GitNexus/issues/1939).\n\n## Commands\n\n### analyze — Build or refresh the index\n\n```bash\nnode .gitnexus/run.cjs analyze\n```\n\nRun from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.\n\n| Flag | Effect |\n| -------------- | ---------------------------------------------------------------- |\n| `--watch` | Keep a Git repository index current with serialized refreshes |\n| `--debounce ` | Watch quiet period before refresh (default: 300 ms) |\n| `--force` | Force full re-index even if up to date |\n| `--embeddings` | Enable embedding generation for semantic search (off by default) |\n| `--drop-embeddings` | Drop existing embeddings on rebuild. By default, an `analyze` without `--embeddings` preserves them. |\n| `--pdg` | Build the program-dependence layers used by `explain` and `pdg_query` (taint, CDG, and REACHING_DEF). |\n| `--spring-actuator ` | Import opt-in Spring Boot Actuator mappings, beans, conditions, configprops, and env snapshots. Forces a full rebuild; unsupported with `--watch`. |\n| `--asyncapi-spec ` | Read opt-in AsyncAPI 3.x documents (directory or single file) and mint `Destination` nodes from their operations. 2.x is refused, not mapped. Unsupported with `--watch`. |\n\n**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook detects staleness after `git commit` and `git merge` and notifies the agent to run `analyze` — the hook does not run analyze itself, to avoid blocking the agent for up to 120s and risking KuzuDB corruption on timeout.\n\nFor Spring runtime enrichment, pass a JSON bundle, one endpoint JSON file, or a directory containing endpoint files. Route evidence is authoritative only when `runtimeConfirmed === true`; `runtimeSource` records provenance and may also accompany `handler-conflict`. Env/configprops values are never persisted.\n\n## Index storage and retention\n\nDefault location is `/.gitnexus/`. Override with environment variables (also documented in README):\n\n| Env | Effect |\n| --- | ------ |\n| `GITNEXUS_STORAGE_PATH` | One complete external index directory. Wins if both storage vars are set. |\n| `GITNEXUS_STORAGE_ROOT` | Absolute root; GitNexus creates an isolated `-<12-hex>/` slot per repository. |\n| `GITNEXUS_CONTENT_RETENTION` | `full` (default) keeps file text; `symbol` keeps snippets; `none` keeps the graph only. |\n\n`list_repos`, `gitnexus://repo/{name}/context`, and HTTP `GET /api/repos` / `GET /api/repo` expose `storagePath`, `contentRetention`, and `sourceAvailable`. HTTP `/api/file` and `/api/grep` return 410 unless retention is `full`. MCP `include_content` may still return symbol spans when retention is `symbol`.\n\nUse `node .gitnexus/run.cjs analyze --watch` for a long-lived local Git repository. It performs an initial analysis, queues scanner-admitted file changes, and retries intact failed batches with bounded backoff. Watch refreshes update only the graph: they skip AGENTS.md / CLAUDE.md injection and standard skill installation, so run a one-shot `analyze` when those generated files need updating. Watch rejects one-shot or context-output flags including `--force`, embedding flags, `--skills`, `--default-branch`, `--skip-agents-md`, `--skip-skills`, `--no-stats`, `--self-commit`, `--index-only`, and `--skip-git`. It never pulls remotes. Scheduled remote clone/pull is a different command: `gitnexus auto-sync`. Bare `gitnexus watch` is reserved and does not start either job. Running MCP and `serve` processes periodically check for a published replacement and reopen it without a restart. MCP checks are throttled to once every five seconds, so a tool call before the next check can briefly use the previous index.\n\n### status — Check index freshness\n\n```bash\nnode .gitnexus/run.cjs status\n```\n\nShows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.\n\n### clean — Delete the index\n\n```bash\nnode .gitnexus/run.cjs clean\n```\n\nDeletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.\n\n| Flag | Effect |\n| --------- | ------------------------------------------------- |\n| `--force` | Skip confirmation prompt |\n| `--all` | Clean all indexed repos, not just the current one |\n\n### wiki — Generate documentation from the graph\n\n```bash\nnode .gitnexus/run.cjs wiki\n```\n\nGenerates repository documentation from the knowledge graph using an LLM. HTTP providers require an API key (saved to `~/.gitnexus/config.json` on first use). Local CLI providers (`--provider cursor|claude|codex|opencode|grok`) use your existing CLI login.\n\n| Flag | Effect |\n| ------------------- | ----------------------------------------- |\n| `--force` | Force full regeneration, also required to re-generate an existing wiki in a different language |\n| `--provider ` | LLM provider: minimax, openai, openrouter, azure, custom, cursor, claude, codex, opencode, or grok (default: minimax). Local CLIs (`cursor`, `claude`, `codex`, `opencode`, `grok`) use your existing CLI login and skip `--api-key`. |\n| `--model ` | LLM model (default: MiniMax-M3) |\n| `--base-url ` | LLM API base URL |\n| `--api-key ` | LLM API key |\n| `--concurrency ` | Parallel LLM calls (default: 3) |\n| `--timeout ` | LLM request timeout in seconds (default: disabled) |\n| `--retries ` | Max LLM retry attempts per request (default: 3) |\n| `--lang ` | Output language for generated documentation (e.g. english, chinese, spanish, japanese) |\n| `--gist` | Publish wiki as a public GitHub Gist |\n\n### list — Show all indexed repos\n\n```bash\nnode .gitnexus/run.cjs list\n```\n\nLists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.\n\n## After Indexing\n\n1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded\n2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task\n\n## Troubleshooting\n\n- **\"Not inside a git repository\"**: Run from a directory inside a git repo\n- **Index is stale after re-analyzing**: Wait for the next MCP tool call to reopen the published index; this normally takes no more than five seconds\n- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding\n","frontmatter":{"name":"gitnexus-cli","description":"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \"Index this repo\", \"Reanalyze the codebase\", \"Generate a wiki\""},"isInternal":false,"tokens":2017,"sizeBytes":8280},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json","title":"Gitnexus-debugging Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-debugging Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/mcp.json)","tokens":300,"sizeBytes":246},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md","title":"gitnexus-debugging","category":"anthropic-skill","format":"markdown","content":"# gitnexus-debugging\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-debugging/SKILL.md)","tokens":300,"sizeBytes":240},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json","title":"Gitnexus-exploring Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-exploring Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-exploring/mcp.json)","tokens":300,"sizeBytes":246},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md","title":"gitnexus-exploring","category":"anthropic-skill","format":"markdown","content":"# gitnexus-exploring\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-exploring/SKILL.md)","tokens":300,"sizeBytes":240},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json","title":"Gitnexus-guide Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-guide Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-guide/mcp.json)","tokens":300,"sizeBytes":234},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md","title":"gitnexus-guide","category":"anthropic-skill","format":"markdown","content":"# gitnexus-guide\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-guide/SKILL.md)","tokens":300,"sizeBytes":228},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json","title":"Gitnexus-impact-analysis Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-impact-analysis Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-impact-analysis/mcp.json)","tokens":300,"sizeBytes":264},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md","title":"gitnexus-impact-analysis","category":"anthropic-skill","format":"markdown","content":"# gitnexus-impact-analysis\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-impact-analysis/SKILL.md)","tokens":300,"sizeBytes":258},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json","title":"Gitnexus-lfg Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-lfg Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/mcp.json)","tokens":300,"sizeBytes":228},{"name":"README.md","path":"gitnexus-claude-plugin/skills/gitnexus-lfg/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/README.md","title":"Gitnexus-lfg Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-lfg Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/README.md)","tokens":300,"sizeBytes":230},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md","title":"gitnexus-lfg","category":"anthropic-skill","format":"markdown","content":"# gitnexus-lfg\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-lfg/SKILL.md)","tokens":300,"sizeBytes":222},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md","title":"gitnexus-pdg-query","category":"anthropic-skill","format":"markdown","content":"# gitnexus-pdg-query\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-pdg-query/SKILL.md)","tokens":300,"sizeBytes":240},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json","title":"Gitnexus-plan Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-plan Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/mcp.json)","tokens":300,"sizeBytes":231},{"name":"README.md","path":"gitnexus-claude-plugin/skills/gitnexus-plan/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/README.md","title":"Gitnexus-plan Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-plan Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/README.md)","tokens":300,"sizeBytes":233},{"name":"context-ledger.md","path":"gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/context-ledger.md)","tokens":300,"sizeBytes":268},{"name":"context-pack.md","path":"gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/context-pack.md)","tokens":300,"sizeBytes":264},{"name":"evidence-provenance.md","path":"gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/evidence-provenance.md)","tokens":300,"sizeBytes":278},{"name":"pdg-slice.md","path":"gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/pdg-slice.md)","tokens":300,"sizeBytes":258},{"name":"plan-template.md","path":"gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/references/plan-template.md)","tokens":300,"sizeBytes":266},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md","title":"gitnexus-plan","category":"anthropic-skill","format":"markdown","content":"# gitnexus-plan\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-plan/SKILL.md)","tokens":300,"sizeBytes":225},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json","title":"Gitnexus-refactoring Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-refactoring Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-refactoring/mcp.json)","tokens":300,"sizeBytes":252},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md","title":"gitnexus-refactoring","category":"anthropic-skill","format":"markdown","content":"# gitnexus-refactoring\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-refactoring/SKILL.md)","tokens":300,"sizeBytes":246},{"name":"ci-adversarial-lens.md","path":"gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","tokens":300,"sizeBytes":285},{"name":"ci-blast-radius-lens.md","path":"gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","tokens":300,"sizeBytes":287},{"name":"ci-correctness-lens.md","path":"gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","tokens":300,"sizeBytes":285},{"name":"ci-coverage-lens.md","path":"gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","tokens":300,"sizeBytes":279},{"name":"ci-critic-lens.md","path":"gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","tokens":300,"sizeBytes":275},{"name":"ci-security-lens.md","path":"gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/ci-personas/ci-security-lens.md)","tokens":300,"sizeBytes":279},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-review/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/mcp.json","title":"Gitnexus-review Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-review Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/mcp.json)","tokens":300,"sizeBytes":237},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md","title":"gitnexus-review","category":"anthropic-skill","format":"markdown","content":"# gitnexus-review\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-review/SKILL.md)","tokens":300,"sizeBytes":231},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md","title":"gitnexus-taint-analysis","category":"anthropic-skill","format":"markdown","content":"# gitnexus-taint-analysis\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-taint-analysis/SKILL.md)","tokens":300,"sizeBytes":255},{"name":"mcp.json","path":"gitnexus-claude-plugin/skills/gitnexus-work/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/mcp.json","title":"Gitnexus-work Skill","category":"anthropic-skill","format":"json","content":"# Gitnexus-work Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/mcp.json)","tokens":300,"sizeBytes":231},{"name":"README.md","path":"gitnexus-claude-plugin/skills/gitnexus-work/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/README.md","title":"Gitnexus-work Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-work Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/README.md)","tokens":300,"sizeBytes":233},{"name":"evidence-provenance.md","path":"gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/references/evidence-provenance.md)","tokens":300,"sizeBytes":278},{"name":"SKILL.md","path":"gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md","title":"gitnexus-work","category":"anthropic-skill","format":"markdown","content":"# gitnexus-work\n\nPath: `gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/skills/gitnexus-work/SKILL.md)","tokens":300,"sizeBytes":225},{"name":"SKILL.md","path":"gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md","title":"gitnexus-debugging","category":"anthropic-skill","format":"markdown","content":"# gitnexus-debugging\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-debugging/SKILL.md)","tokens":300,"sizeBytes":250},{"name":"SKILL.md","path":"gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md","title":"gitnexus-exploring","category":"anthropic-skill","format":"markdown","content":"# gitnexus-exploring\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-exploring/SKILL.md)","tokens":300,"sizeBytes":250},{"name":"SKILL.md","path":"gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md","title":"gitnexus-impact-analysis","category":"anthropic-skill","format":"markdown","content":"# gitnexus-impact-analysis\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md)","tokens":300,"sizeBytes":268},{"name":"SKILL.md","path":"gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md","title":"gitnexus-refactoring","category":"anthropic-skill","format":"markdown","content":"# gitnexus-refactoring\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-refactoring/SKILL.md)","tokens":300,"sizeBytes":256},{"name":"ci-adversarial-lens.md","path":"gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","tokens":300,"sizeBytes":295},{"name":"ci-blast-radius-lens.md","path":"gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","tokens":300,"sizeBytes":297},{"name":"ci-correctness-lens.md","path":"gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","tokens":300,"sizeBytes":295},{"name":"ci-coverage-lens.md","path":"gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","tokens":300,"sizeBytes":289},{"name":"ci-critic-lens.md","path":"gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","tokens":300,"sizeBytes":285},{"name":"ci-security-lens.md","path":"gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/ci-personas/ci-security-lens.md)","tokens":300,"sizeBytes":289},{"name":"SKILL.md","path":"gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md","title":"gitnexus-review","category":"anthropic-skill","format":"markdown","content":"# gitnexus-review\n\nPath: `gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-cursor-integration/skills/gitnexus-review/SKILL.md)","tokens":300,"sizeBytes":241},{"name":"gitnexus-cli.md","path":"gitnexus/skills/gitnexus-cli.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-cli.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-cli.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-cli.md)","tokens":300,"sizeBytes":182},{"name":"gitnexus-debugging.md","path":"gitnexus/skills/gitnexus-debugging.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-debugging.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-debugging.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-debugging.md)","tokens":300,"sizeBytes":194},{"name":"gitnexus-exploring.md","path":"gitnexus/skills/gitnexus-exploring.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-exploring.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-exploring.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-exploring.md)","tokens":300,"sizeBytes":194},{"name":"gitnexus-guide.md","path":"gitnexus/skills/gitnexus-guide.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-guide.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-guide.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-guide.md)","tokens":300,"sizeBytes":186},{"name":"gitnexus-impact-analysis.md","path":"gitnexus/skills/gitnexus-impact-analysis.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-impact-analysis.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-impact-analysis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-impact-analysis.md)","tokens":300,"sizeBytes":206},{"name":"README.md","path":"gitnexus/skills/gitnexus-lfg/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-lfg/README.md","title":"Gitnexus-lfg Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-lfg Skill\n\nPath: `gitnexus/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-lfg/README.md)","tokens":300,"sizeBytes":202},{"name":"SKILL.md","path":"gitnexus/skills/gitnexus-lfg/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-lfg/SKILL.md","title":"gitnexus-lfg","category":"anthropic-skill","format":"markdown","content":"# gitnexus-lfg\n\nPath: `gitnexus/skills/gitnexus-lfg/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-lfg/SKILL.md)","tokens":300,"sizeBytes":194},{"name":"gitnexus-pdg-query.md","path":"gitnexus/skills/gitnexus-pdg-query.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-pdg-query.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-pdg-query.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-pdg-query.md)","tokens":300,"sizeBytes":194},{"name":"README.md","path":"gitnexus/skills/gitnexus-plan/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/README.md","title":"Gitnexus-plan Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-plan Skill\n\nPath: `gitnexus/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/README.md)","tokens":300,"sizeBytes":205},{"name":"context-ledger.md","path":"gitnexus/skills/gitnexus-plan/references/context-ledger.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/context-ledger.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/context-ledger.md)","tokens":300,"sizeBytes":240},{"name":"context-pack.md","path":"gitnexus/skills/gitnexus-plan/references/context-pack.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/context-pack.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/context-pack.md)","tokens":300,"sizeBytes":236},{"name":"evidence-provenance.md","path":"gitnexus/skills/gitnexus-plan/references/evidence-provenance.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/evidence-provenance.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/evidence-provenance.md)","tokens":300,"sizeBytes":250},{"name":"pdg-slice.md","path":"gitnexus/skills/gitnexus-plan/references/pdg-slice.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/pdg-slice.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/pdg-slice.md)","tokens":300,"sizeBytes":230},{"name":"plan-template.md","path":"gitnexus/skills/gitnexus-plan/references/plan-template.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/plan-template.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/references/plan-template.md)","tokens":300,"sizeBytes":238},{"name":"SKILL.md","path":"gitnexus/skills/gitnexus-plan/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/SKILL.md","title":"gitnexus-plan","category":"anthropic-skill","format":"markdown","content":"# gitnexus-plan\n\nPath: `gitnexus/skills/gitnexus-plan/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-plan/SKILL.md)","tokens":300,"sizeBytes":197},{"name":"gitnexus-refactoring.md","path":"gitnexus/skills/gitnexus-refactoring.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-refactoring.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-refactoring.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-refactoring.md)","tokens":300,"sizeBytes":198},{"name":"ci-adversarial-lens.md","path":"gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)","tokens":300,"sizeBytes":257},{"name":"ci-blast-radius-lens.md","path":"gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)","tokens":300,"sizeBytes":259},{"name":"ci-correctness-lens.md","path":"gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)","tokens":300,"sizeBytes":257},{"name":"ci-coverage-lens.md","path":"gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)","tokens":300,"sizeBytes":251},{"name":"ci-critic-lens.md","path":"gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-critic-lens.md)","tokens":300,"sizeBytes":247},{"name":"ci-security-lens.md","path":"gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md","title":"Ci-personas Skill","category":"anthropic-skill","format":"markdown","content":"# Ci-personas Skill\n\nPath: `gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/ci-personas/ci-security-lens.md)","tokens":300,"sizeBytes":251},{"name":"SKILL.md","path":"gitnexus/skills/gitnexus-review/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/SKILL.md","title":"gitnexus-review","category":"anthropic-skill","format":"markdown","content":"# gitnexus-review\n\nPath: `gitnexus/skills/gitnexus-review/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-review/SKILL.md)","tokens":300,"sizeBytes":203},{"name":"gitnexus-taint-analysis.md","path":"gitnexus/skills/gitnexus-taint-analysis.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-taint-analysis.md","title":"Skills Skill","category":"anthropic-skill","format":"markdown","content":"# Skills Skill\n\nPath: `gitnexus/skills/gitnexus-taint-analysis.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-taint-analysis.md)","tokens":300,"sizeBytes":204},{"name":"README.md","path":"gitnexus/skills/gitnexus-work/README.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/README.md","title":"Gitnexus-work Skill","category":"anthropic-skill","format":"markdown","content":"# Gitnexus-work Skill\n\nPath: `gitnexus/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/README.md)","tokens":300,"sizeBytes":205},{"name":"evidence-provenance.md","path":"gitnexus/skills/gitnexus-work/references/evidence-provenance.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/references/evidence-provenance.md","title":"References Skill","category":"anthropic-skill","format":"markdown","content":"# References Skill\n\nPath: `gitnexus/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/references/evidence-provenance.md)","tokens":300,"sizeBytes":250},{"name":"SKILL.md","path":"gitnexus/skills/gitnexus-work/SKILL.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/SKILL.md","title":"gitnexus-work","category":"anthropic-skill","format":"markdown","content":"# gitnexus-work\n\nPath: `gitnexus/skills/gitnexus-work/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/skills/gitnexus-work/SKILL.md)","tokens":300,"sizeBytes":197},{"name":"pubspec.yaml","path":"gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml","title":"Data Skill","category":"anthropic-skill","format":"yaml","content":"# Data Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/dart-package-imports/packages/data/pubspec.yaml)","tokens":300,"sizeBytes":290},{"name":"package.json","path":"gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json","title":"Barrel Skill","category":"anthropic-skill","format":"json","content":"# Barrel Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/barrel/package.json)","tokens":300,"sizeBytes":314},{"name":"package.json","path":"gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json","title":"Http Skill","category":"anthropic-skill","format":"json","content":"# Http Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/fetch-wrapper-target-identity/packages/http/package.json)","tokens":300,"sizeBytes":308},{"name":"package.json","path":"gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json","title":"Inner Skill","category":"anthropic-skill","format":"json","content":"# Inner Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/inner/package.json)","tokens":300,"sizeBytes":319},{"name":"package.json","path":"gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json","title":"Utils Skill","category":"anthropic-skill","format":"json","content":"# Utils Skill\n\nPath: `gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus/test/fixtures/lang-resolution/typescript-pnpm-workspace-imports/packages/utils/package.json)","tokens":300,"sizeBytes":319},{"name":"100-monorepo.mdc","path":".cursor/rules/100-monorepo.mdc","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/rules/100-monorepo.mdc","title":"Cursor Rule: 100-monorepo","category":"cursor-rule","format":"mdc","content":"# Cursor Rule: 100-monorepo\n\nPath: `.cursor/rules/100-monorepo.mdc`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/rules/100-monorepo.mdc)","tokens":300,"sizeBytes":193},{"name":"200-eval.mdc","path":".cursor/rules/200-eval.mdc","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/rules/200-eval.mdc","title":"Cursor Rule: 200-eval","category":"cursor-rule","format":"mdc","content":"# Cursor Rule: 200-eval\n\nPath: `.cursor/rules/200-eval.mdc`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/rules/200-eval.mdc)","tokens":300,"sizeBytes":181},{"name":".cursorrules","path":".cursorrules","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursorrules","title":"Cursor IDE Native Rules","category":"cursor-rule","format":"markdown","content":"# Cursor IDE Native Rules\n\nPath: `.cursorrules`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursorrules)","tokens":300,"sizeBytes":155},{"name":"evidence-provenance.mjs","path":".claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs","title":"Claude Directive: evidence-provenance.mjs","category":"claude-rule","format":"markdown","content":"# Claude Directive: evidence-provenance.mjs\n\nPath: `.claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/scripts/evidence-provenance.mjs)","tokens":300,"sizeBytes":269},{"name":"evidence-provenance.mjs","path":".claude/skills/gitnexus-work/scripts/evidence-provenance.mjs","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/scripts/evidence-provenance.mjs","title":"Claude Directive: evidence-provenance.mjs","category":"claude-rule","format":"markdown","content":"# Claude Directive: evidence-provenance.mjs\n\nPath: `.claude/skills/gitnexus-work/scripts/evidence-provenance.mjs`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/scripts/evidence-provenance.mjs)","tokens":300,"sizeBytes":269},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"# Claude Agent Guidelines & System Prompt\n\nPath: `CLAUDE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/CLAUDE.md)","tokens":300,"sizeBytes":165},{"name":".windsurfrules","path":".windsurfrules","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.windsurfrules","title":"Windsurf Cascade Agent Rules","category":"windsurf-rule","format":"markdown","content":"# Windsurf Cascade Agent Rules\n\nPath: `.windsurfrules`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.windsurfrules)","tokens":300,"sizeBytes":164},{"name":"marketplace.json","path":".agents/plugins/marketplace.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.agents/plugins/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.agents/plugins/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.agents/plugins/marketplace.json)","tokens":300,"sizeBytes":205},{"name":"marketplace.json","path":".claude-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.claude-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude-plugin/marketplace.json)","tokens":300,"sizeBytes":203},{"name":"marketplace.json","path":".factory-plugin/marketplace.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.factory-plugin/marketplace.json","title":"Claude Plugin Marketplace Catalog","category":"marketplace","format":"json","content":"# Claude Plugin Marketplace Catalog\n\nPath: `.factory-plugin/marketplace.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.factory-plugin/marketplace.json)","tokens":300,"sizeBytes":205},{"name":"plugin.json","path":"gitnexus-claude-plugin/.claude-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/.claude-plugin/plugin.json","title":"claude-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# claude-plugin Plugin Manifest\n\nPath: `gitnexus-claude-plugin/.claude-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/.claude-plugin/plugin.json)","tokens":300,"sizeBytes":235},{"name":"plugin.json","path":"gitnexus-claude-plugin/.codex-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/.codex-plugin/plugin.json","title":"codex-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# codex-plugin Plugin Manifest\n\nPath: `gitnexus-claude-plugin/.codex-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-claude-plugin/.codex-plugin/plugin.json)","tokens":300,"sizeBytes":232},{"name":"plugin.json","path":"gitnexus-factory-plugin/.factory-plugin/plugin.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-factory-plugin/.factory-plugin/plugin.json","title":"factory-plugin Plugin Manifest","category":"plugin-manifest","format":"json","content":"# factory-plugin Plugin Manifest\n\nPath: `gitnexus-factory-plugin/.factory-plugin/plugin.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-factory-plugin/.factory-plugin/plugin.json)","tokens":300,"sizeBytes":240},{"name":"mcp.json","path":"gitnexus-factory-plugin/mcp.json","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-factory-plugin/mcp.json","title":"Model Context Protocol (MCP) Configuration","category":"mcp-config","format":"json","content":"# Model Context Protocol (MCP) Configuration\n\nPath: `gitnexus-factory-plugin/mcp.json`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/gitnexus-factory-plugin/mcp.json)","tokens":300,"sizeBytes":214},{"name":"gitnexus-branch-hygiene-reviewer.md","path":".claude/agents/gitnexus-branch-hygiene-reviewer.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-branch-hygiene-reviewer.md","title":"Subagent: gitnexus-branch-hygiene-reviewer","category":"subagent-persona","format":"markdown","content":"# Subagent: gitnexus-branch-hygiene-reviewer\n\nPath: `.claude/agents/gitnexus-branch-hygiene-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-branch-hygiene-reviewer.md)","tokens":300,"sizeBytes":250},{"name":"gitnexus-docs-dod-reviewer.md","path":".claude/agents/gitnexus-docs-dod-reviewer.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-docs-dod-reviewer.md","title":"Subagent: gitnexus-docs-dod-reviewer","category":"subagent-persona","format":"markdown","content":"# Subagent: gitnexus-docs-dod-reviewer\n\nPath: `.claude/agents/gitnexus-docs-dod-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-docs-dod-reviewer.md)","tokens":300,"sizeBytes":232},{"name":"gitnexus-pr-facts-historian.md","path":".claude/agents/gitnexus-pr-facts-historian.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-pr-facts-historian.md","title":"Subagent: gitnexus-pr-facts-historian","category":"subagent-persona","format":"markdown","content":"# Subagent: gitnexus-pr-facts-historian\n\nPath: `.claude/agents/gitnexus-pr-facts-historian.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-pr-facts-historian.md)","tokens":300,"sizeBytes":235},{"name":"gitnexus-risk-architect.md","path":".claude/agents/gitnexus-risk-architect.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-risk-architect.md","title":"Subagent: gitnexus-risk-architect","category":"subagent-persona","format":"markdown","content":"# Subagent: gitnexus-risk-architect\n\nPath: `.claude/agents/gitnexus-risk-architect.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-risk-architect.md)","tokens":300,"sizeBytes":223},{"name":"gitnexus-security-boundary-reviewer.md","path":".claude/agents/gitnexus-security-boundary-reviewer.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-security-boundary-reviewer.md","title":"Subagent: gitnexus-security-boundary-reviewer","category":"subagent-persona","format":"markdown","content":"# Subagent: gitnexus-security-boundary-reviewer\n\nPath: `.claude/agents/gitnexus-security-boundary-reviewer.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-security-boundary-reviewer.md)","tokens":300,"sizeBytes":259},{"name":"gitnexus-synthesis-critic.md","path":".claude/agents/gitnexus-synthesis-critic.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-synthesis-critic.md","title":"Subagent: gitnexus-synthesis-critic","category":"subagent-persona","format":"markdown","content":"# Subagent: gitnexus-synthesis-critic\n\nPath: `.claude/agents/gitnexus-synthesis-critic.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-synthesis-critic.md)","tokens":300,"sizeBytes":229},{"name":"gitnexus-test-ci-verifier.md","path":".claude/agents/gitnexus-test-ci-verifier.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-test-ci-verifier.md","title":"Subagent: gitnexus-test-ci-verifier","category":"subagent-persona","format":"markdown","content":"# Subagent: gitnexus-test-ci-verifier\n\nPath: `.claude/agents/gitnexus-test-ci-verifier.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/agents/gitnexus-test-ci-verifier.md)","tokens":300,"sizeBytes":229},{"name":"gitnexus-pr-swarm-review.md","path":".cursor/commands/gitnexus-pr-swarm-review.md","rawUrl":"https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/commands/gitnexus-pr-swarm-review.md","title":"Command: /gitnexus-pr-swarm-review","category":"command-prompt","format":"markdown","content":"# Command: /gitnexus-pr-swarm-review\n\nPath: `.cursor/commands/gitnexus-pr-swarm-review.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.cursor/commands/gitnexus-pr-swarm-review.md)","tokens":300,"sizeBytes":230}],"systemPromptSnippet":"\n\n# AI Agent Protocol & Instructions\n\nPath: `AGENTS.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/AGENTS.md)\n\n\n# LLM Index & Context Digest\n\nPath: `llms.txt`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/llms.txt)\n\n\n# System Architecture & Module Boundaries\n\nPath: `ARCHITECTURE.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/ARCHITECTURE.md)\n\n\n---\nname: gitnexus-cli\ndescription: \"Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \\\"Index this repo\\\", \\\"Reanalyze the codebase\\\", \\\"Generate a wiki\\\"\"\n---\n\n# GitNexus CLI Commands\n\nCommands below use `node .gitnexus/run.cjs ` — the project-local runner `gitnexus analyze` drops next to the index. It auto-selects an available runner at call time (global `gitnexus`, else `pnpm dlx`, else `bunx`, else `npx`), so no package-manager assumption and no global install is required — including on a bun-only machine, which has no npm, npx or pnpm at all.\n\n> **Not analyzed yet, or `node .gitnexus/run.cjs` reports `Cannot find module`** (the gitignored runner is absent — e.g. a fresh clone or `git clean`)? (Re)generate it with `npx gitnexus analyze` from the project root, or `bunx gitnexus@latest analyze` on a bun-only machine. On **npm 11.x**, if `npx` crashes during install (`node.target is null`), install once with `npm i -g gitnexus` (then `gitnexus analyze`), or use `bunx gitnexus@latest analyze`, or `pnpm --allow-build=@ladybugdb/core --allow-build=gitnexus --allow-build=tree-sitter dlx gitnexus@latest analyze`. See [#1939](https://github.com/abhigyanpatwari/GitNexus/issues/1939).\n\n## Commands\n\n### analyze — Build or refresh the index\n\n```bash\nnode .gitnexus/run.cjs analyze\n```\n\nRun from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.\n\n| Flag | Effect |\n| -------------- | ---------------------------------------------------------------- |\n| `--watch` | Keep a Git repository index current with serialized refreshes |\n| `--debounce ` | Watch quiet period before refresh (default: 300 ms) |\n| `--force` | Force full re-index even if up to date |\n| `--embeddings` | Enable embedding generation for semantic search (off by default) |\n| `--drop-embeddings` | Drop existing embeddings on rebuild. By default, an `analyze` without `--embeddings` preserves them. |\n| `--pdg` | Build the program-dependence layers used by `explain` and `pdg_query` (taint, CDG, and REACHING_DEF). |\n| `--spring-actuator ` | Import opt-in Spring Boot Actuator mappings, beans, conditions, configprops, and env snapshots. Forces a full rebuild; unsupported with `--watch`. |\n| `--asyncapi-spec ` | Read opt-in AsyncAPI 3.x documents (directory or single file) and mint `Destination` nodes from their operations. 2.x is refused, not mapped. Unsupported with `--watch`. |\n\n**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook detects staleness after `git commit` and `git merge` and notifies the agent to run `analyze` — the hook does not run analyze itself, to avoid blocking the agent for up to 120s and risking KuzuDB corruption on timeout.\n\nFor Spring runtime enrichment, pass a JSON bundle, one endpoint JSON file, or a directory containing endpoint files. Route evidence is authoritative only when `runtimeConfirmed === true`; `runtimeSource` records provenance and may also accompany `handler-conflict`. Env/configprops values are never persisted.\n\n## Index storage and retention\n\nDefault location is `/.gitnexus/`. Override with environment variables (also documented in README):\n\n| Env | Effect |\n| --- | ------ |\n| `GITNEXUS_STORAGE_PATH` | One complete external index directory. Wins if both storage vars are set. |\n| `GITNEXUS_STORAGE_ROOT` | Absolute root; GitNexus creates an isolated `-<12-hex>/` slot per repository. |\n| `GITNEXUS_CONTENT_RETENTION` | `full` (default) keeps file text; `symbol` keeps snippets; `none` keeps the graph only. |\n\n`list_repos`, `gitnexus://repo/{name}/context`, and HTTP `GET /api/repos` / `GET /api/repo` expose `storagePath`, `contentRetention`, and `sourceAvailable`. HTTP `/api/file` and `/api/grep` return 410 unless retention is `full`. MCP `include_content` may still return symbol spans when retention is `symbol`.\n\nUse `node .gitnexus/run.cjs analyze --watch` for a long-lived local Git repository. It performs an initial analysis, queues scanner-admitted file changes, and retries intact failed batches with bounded backoff. Watch refreshes update only the graph: they skip AGENTS.md / CLAUDE.md injection and standard skill installation, so run a one-shot `analyze` when those generated files need updating. Watch rejects one-shot or context-output flags including `--force`, embedding flags, `--skills`, `--default-branch`, `--skip-agents-md`, `--skip-skills`, `--no-stats`, `--self-commit`, `--index-only`, and `--skip-git`. It never pulls remotes. Scheduled remote clone/pull is a different command: `gitnexus auto-sync`. Bare `gitnexus watch` is reserved and does not start either job. Running MCP and `serve` processes periodically check for a published replacement and reopen it without a restart. MCP checks are throttled to once every five seconds, so a tool call before the next check can briefly use the previous index.\n\n### status — Check index freshness\n\n```bash\nnode .gitnexus/run.cjs status\n```\n\nShows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.\n\n### clean — Delete the index\n\n```bash\nnode .gitnexus/run.cjs clean\n```\n\nDeletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.\n\n| Flag | Effect |\n| --------- | ------------------------------------------------- |\n| `--force` | Skip confirmation prompt |\n| `--all` | Clean all indexed repos, not just the current one |\n\n### wiki — Generate documentation from the graph\n\n```bash\nnode .gitnexus/run.cjs wiki\n```\n\nGenerates repository documentation from the knowledge graph using an LLM. HTTP providers require an API key (saved to `~/.gitnexus/config.json` on first use). Local CLI providers (`--provider cursor|claude|codex|opencode|grok`) use your existing CLI login.\n\n| Flag | Effect |\n| ------------------- | ----------------------------------------- |\n| `--force` | Force full regeneration, also required to re-generate an existing wiki in a different language |\n| `--provider ` | LLM provider: minimax, openai, openrouter, azure, custom, cursor, claude, codex, opencode, or grok (default: minimax). Local CLIs (`cursor`, `claude`, `codex`, `opencode`, `grok`) use your existing CLI login and skip `--api-key`. |\n| `--model ` | LLM model (default: MiniMax-M3) |\n| `--base-url ` | LLM API base URL |\n| `--api-key ` | LLM API key |\n| `--concurrency ` | Parallel LLM calls (default: 3) |\n| `--timeout ` | LLM request timeout in seconds (default: disabled) |\n| `--retries ` | Max LLM retry attempts per request (default: 3) |\n| `--lang ` | Output language for generated documentation (e.g. english, chinese, spanish, japanese) |\n| `--gist` | Publish wiki as a public GitHub Gist |\n\n### list — Show all indexed repos\n\n```bash\nnode .gitnexus/run.cjs list\n```\n\nLists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.\n\n## After Indexing\n\n1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded\n2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task\n\n## Troubleshooting\n\n- **\"Not inside a git repository\"**: Run from a directory inside a git repo\n- **Index is stale after re-analyzing**: Wait for the next MCP tool call to reopen the published index; this normally takes no more than five seconds\n- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding\n\n\n---\nname: gitnexus-debugging\ndescription: \"Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: \\\"Why is X failing?\\\", \\\"Where does this error come from?\\\", \\\"Trace this bug\\\"\"\n---\n\n# Debugging with GitNexus\n\n## When to Use\n\n- \"Why is this function failing?\"\n- \"Trace where this error comes from\"\n- \"Who calls this method?\"\n- \"This endpoint returns 500\"\n- Investigating bugs, errors, or unexpected behavior\n\n## Bind the repository first\n\nA root cause traced in the wrong repository is a wrong root cause.\n\nBind once using a confirmed registry name/path or configured MCP default. Call\n`list_repos {}` if the target is not yet known; reuse that binding across calls. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask. This matters most for `cypher`, whose\nstatement carries no in-band hint of which database it ran against.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\nA stale index describes the code from before your bug, so refresh before\ntrusting a trace, and state the repository and index freshness with the\ndiagnosis.\n\n## Workflow\n\n```\n0. Bind the repo once (list_repos only if not already known)\n1. If the suspect is unknown, query for the error/symptom with small result limits\n2. context({name: \"\"}) → See callers/callees/processes\n3. Read a process resource only if its trace resolves an open question\n4. cypher({statement: \"MATCH path...\"}) → Custom traces if needed\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Checklist\n\n```\n- [ ] Once per session: bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] Understand the symptom (error message, unexpected behavior)\n- [ ] query for error text or related code\n- [ ] Identify the suspect function from returned processes\n- [ ] context to see callers and callees\n- [ ] Trace execution flow via process resource if applicable\n- [ ] cypher for custom call chain traces if needed\n- [ ] Read source files to confirm root cause\n- [ ] State the repository and index freshness with the diagnosis\n```\n\n## Keep investigations focused\n\nStart with a known symbol's `context`, or a small `query` (`limit: 3`,\n`max_symbols: 3`, `include_content: false`, `chain_depth: 0`) to discover one.\nWhen the server advertises these single-repository filters, request only the\nneeded evidence:\n\n```text\ncontext({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"outgoing\"], relationTypes: [\"CALLS\"]})\ntrace({from_uid: \"\", to_uid: \"\", repo: \"my-app\"})\n```\n\n`symbol` and completeness/staleness diagnostics remain in a filtered context.\n`relationTypes` filters the returned incoming/outgoing categories only; it does\nnot expand their existing bounded window or filter an explicitly requested chain.\nFor callback registration, include `USES`; for imports or inheritance, request\nthose relation types or omit the filter. Omitted references are not absent\nreferences. Broaden when the hypothesis needs it, and preserve UNKNOWN/partial\nwarnings. Confirm source and tests before claiming a root cause. A useful 2–3\ncall investigation is a goal, not a reason to skip verification or pre-edit impact.\n\n## Debugging Patterns\n\n| Symptom | GitNexus Approach |\n| -------------------- | ---------------------------------------------------------- |\n| Error message | `query` for error text → `context` on throw sites |\n| Wrong return value | `context` on the function → trace callees for data flow |\n| Intermittent failure | `context` → look for external calls, async deps |\n| Performance issue | `context` → find symbols with many callers (hot paths) |\n| Recent regression | `detect_changes` to see what your changes affect — pass `worktree` for a linked worktree |\n| \"How does A reach B?\" | `trace` between the two symbols — shortest call chain in one call |\n\n## Tools\n\n**query** — find code related to error:\n\n```\nquery({search_query: \"payment validation error\", repo: \"my-app\"})\n→ Processes: CheckoutFlow, ErrorHandling\n→ Symbols: validatePayment, handlePaymentError, PaymentException\n```\n\n**context** — full context for a suspect:\n\n```\ncontext({name: \"validatePayment\", repo: \"my-app\"})\n→ Incoming calls: processCheckout, webhookHandler\n→ Outgoing calls: verifyCard, fetchRates (external API!)\n→ Processes: CheckoutFlow (step 3/7)\n```\n\n**cypher** — custom call chain traces. Pass `repo` alongside the statement; the\nCypher text itself names no repository, so the result is unattributable without\nit:\n\n```cypher\nMATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: \"validatePayment\"})\nRETURN [n IN nodes(path) | n.name] AS chain\n```\n\n**trace** — shortest call chain between two symbols (\"how does A reach B?\"), one call instead of chaining `context` hops:\n\n```\ntrace({ from: \"processCheckout\", to: \"fetchRates\", repo: \"my-app\" })\n→ status: ok, hopCount: 3\n→ hops: processCheckout → validatePayment → verifyCard → fetchRates\n→ edges: CALLS (1.0), CALLS (0.95), CALLS (1.0)\n```\n\nWhen no path exists, `trace` reports the furthest reachable node — exactly where the chain breaks (dynamic dispatch, reflection, or an external boundary).\n\n## Example: \"Payment endpoint returns 500 intermittently\"\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — bind my-app explicitly on every call\n\n1. query({search_query: \"payment error handling\", repo: \"my-app\"})\n → Processes: CheckoutFlow, ErrorHandling\n → Symbols: validatePayment, handlePaymentError\n\n2. context({name: \"validatePayment\", repo: \"my-app\"})\n → Outgoing calls: verifyCard, fetchRates (external API!)\n\n3. READ gitnexus://repo/my-app/process/CheckoutFlow\n → Step 3: validatePayment → calls fetchRates (external)\n\n4. Root cause: fetchRates calls external API without proper timeout\n Repository: my-app Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n\n\n---\nname: gitnexus-exploring\ndescription: \"Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: \\\"How does X work?\\\", \\\"What calls this function?\\\", \\\"Show me the auth flow\\\"\"\n---\n\n# Exploring Codebases with GitNexus\n\n## When to Use\n\n- \"How does authentication work?\"\n- \"What's the project structure?\"\n- \"Show me the main components\"\n- \"Where is the database logic?\"\n- Understanding code you haven't seen before\n\n## Bind the repository first\n\nBind once per session using a confirmed registry name/path or configured MCP\ndefault; reuse it. Call `list_repos {}` when the target is not yet known, not before\nevery question. Never guess the registry name from the checkout directory. With\none indexed repository, use the examples below as written. With more than one, pass `repo` on every call: an omitted `repo` normally errors,\nbut under an MCP policy with a configured default it resolves to that default\nsilently. If you cannot tell which repository is meant, stop and ask. Report\nthe bound repository and index freshness alongside your explanation.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\n## Workflow\n\n```\n1. Bind the repository once; use hot-tool staleness on subsequent calls\n2. If no symbol is known: query({search_query: \"\", limit: 3, max_symbols: 3})\n3. context({uid: \"\"}) → Inspect the selected symbol\n4. Read a process resource only when its full trace answers an unresolved question\n```\n\n> If the index is stale → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Ask for only the evidence needed\n\nUse options advertised by the connected server. `response_sections` and context\n`relationTypes` are opt-in views for a single repository, not `@group` routing.\nOn an older server, use the existing limits and content/chain options instead.\nUse filters when unwanted sections are bulky; their omission metadata can make\nan already-small response slightly larger.\nAim for 2–3 focused calls after repository binding; stop when the question is\nanswered, but expand if evidence or a required safety check is still missing.\n\n```text\nquery({search_query: \"payment retry\", repo: \"my-app\", limit: 3, max_symbols: 3,\n include_content: false, chain_depth: 0,\n response_sections: [\"process_symbols\", \"definitions\"]})\ncontext({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"incoming\", \"outgoing\"], relationTypes: [\"CALLS\"]})\n// Before editing, assess impact using the normal traversal and risk calculation:\nimpact({target: \"\", repo: \"my-app\", direction: \"upstream\", summaryOnly: true})\n```\n\nIf the symbol is already known, start with `context`; use `uid`, or `name` plus\n`file_path`/`kind`, to avoid ambiguous results. To answer only “who calls it?”,\nrequest `response_sections: [\"incoming\"]`, `relationTypes: [\"CALLS\"]` and leave\n`include_content` false. Keep `processes` in a query when the question is about\nflows, rather than requesting a symbols-only view.\n\nDo not request source and multi-hop chains for every search hit. Fetch source\nfor the selected symbol only; for a large class/file, prefer `read_file` with\na small 0-based `startLine`/`endLine` window (subtract 1 from graph line numbers),\nor `maxLines` for a whole-file read, if that tool is available. Use\n`trace` for a known A→B path instead of repeatedly expanding `context`.\n\nFilters retain requested sections/categories and hide the others; they do not prove other references\nare absent or make the existing bounded search exhaustive. Read `response_filter`,\n`warning`, `partial`, `truncated`, `epistemic` and `staleness`. Remove filters when\nbroader evidence is needed. `maxTokens` is a last-resort byte cutoff that can cut\nJSON: narrow the request rather than treating a cut response as complete. Never\nuse a filtered caller view to waive the required impact check or an UNKNOWN risk.\n\n## Checklist\n\n```\n- [ ] Once per session: bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] Check hot-tool staleness; read the overview only if needed\n- [ ] Query for the concept only if the relevant symbol is not already known\n- [ ] Review returned symbols; include processes when execution flow matters\n- [ ] context on selected symbols; request only relevant sections/relations\n- [ ] Read a process resource only if its full trace is needed\n- [ ] Read targeted source only when implementation details are needed\n- [ ] State the repository and index freshness with the explanation\n```\n\n## Resources\n\n| Resource | What you get |\n| --------------------------------------- | ------------------------------------------------------- |\n| `gitnexus://repo/{name}/context` | Stats, staleness warning (~150 tokens) |\n| `gitnexus://repo/{name}/clusters` | All functional areas with cohesion scores (~300 tokens) |\n| `gitnexus://repo/{name}/cluster/{name}` | Area members with file paths (~500 tokens) |\n| `gitnexus://repo/{name}/process/{name}` | Step-by-step execution trace (~200 tokens) |\n\n## Tools\n\n**query** — find execution flows related to a concept:\n\n```\nquery({search_query: \"payment processing\", repo: \"my-app\"})\n→ Processes: CheckoutFlow, RefundFlow, WebhookHandler\n→ Symbols grouped by flow with file locations\n```\n\n**context** — 360-degree view of a symbol:\n\n```\ncontext({name: \"validateUser\", repo: \"my-app\"})\n→ Incoming calls: loginHandler, apiMiddleware\n→ Outgoing calls: checkToken, getUserById\n→ Processes: LoginFlow (step 2/5), TokenRefresh (step 1/3)\n```\n\n`repo` is required once more than one repository is indexed, and may be omitted\nwith a single one.\n\n## Example: \"How does payment processing work?\"\n\nWith `my-app` already bound and the index current:\n\n```text\n1. query({search_query: \"payment processing\", repo: \"my-app\", limit: 3, max_symbols: 3})\n → CheckoutFlow and RefundFlow, with symbol IDs and locations\n2. context({uid: \"\", repo: \"my-app\", include_content: true,\n response_sections: [\"outgoing\", \"processes\"]})\n → Selected source, callees, process participation and completeness diagnostics\n3. Answer from that evidence; read one process resource only if its trace is still needed\n```\n\nReport the repository and index freshness with the explanation. If `my-app`\nhad not yet been bound, discover it once with `list_repos` first.\n\n\n---\nname: gitnexus-guide\ndescription: \"Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: \\\"What GitNexus tools are available?\\\", \\\"How do I use GitNexus?\\\"\"\n---\n\n# GitNexus Guide\n\nQuick reference for all GitNexus MCP tools, resources, and the knowledge graph schema.\n\n## Always Start Here\n\nFor any task involving code understanding, debugging, impact analysis, or refactoring:\n\n1. **Bind the repository once** — use a confirmed registry name/path or configured default; call `list_repos` if unknown. Read hot-tool `staleness`; use `gitnexus://repo/{name}/context` when an overview is needed.\n2. **Match your task to a skill below** and **read that skill file**\n3. **Follow the skill's workflow and checklist**\n\n> If step 1 warns the index is stale, run `node .gitnexus/run.cjs analyze` in the terminal first.\n> On `query` / `context` / `impact` / `cypher`, read `staleness.status` and `staleness.branch`/`lastCommit` before using the answer. Re-analyze only for `behind` or `diverged`.\n\n## Skills\n\n| Task | Skill to read |\n| -------------------------------------------- | ------------------- |\n| Understand architecture / \"How does X work?\" | `gitnexus-exploring` |\n| Blast radius / \"What breaks if I change X?\" | `gitnexus-impact-analysis` |\n| Trace bugs / \"Why is X failing?\" | `gitnexus-debugging` |\n| Rename / extract / split / refactor | `gitnexus-refactoring` |\n| Tools, resources, schema reference | `gitnexus-guide` (this file) |\n| Index, status, clean, wiki CLI commands | `gitnexus-cli` |\n\n## Tools Reference\n\n| Tool | What it gives you |\n| ---------------- | ------------------------------------------------------------------------ |\n| `query` | Process-grouped code intelligence — execution flows related to a concept |\n| `context` | 360-degree symbol view — categorized refs, processes it participates in |\n| `impact` | Symbol blast radius — what breaks at depth 1/2/3 with confidence |\n| `trace` | Shortest path between two symbols — \"how does A reach B?\" in one call |\n| `detect_changes` | Git-diff impact — what do your current changes affect |\n| `rename` | Semantic rename: previews by default (`dry_run` omitted/true), applies with `dry_run: false` and the preview's `plan_token`; inspect application status and failures |\n| `cypher` | Raw graph queries (read `gitnexus://repo/{name}/schema` first) |\n| `explain` | Persisted taint findings — source→sink data flows (needs `analyze --pdg`) |\n| `pdg_query` | Control/data dependence — what gates X (CDG) / where Y flows (REACHING_DEF); needs `analyze --pdg` |\n| `check` | Check graph invariants such as circular imports |\n| `route_map` | API route map — which components/hooks fetch which endpoints, and the handler files that serve them |\n| `shape_check` | Response-shape drift — keys each route returns vs keys its consumers access (flags MISMATCH) |\n| `api_impact` | Pre-change report for an API route — consumers, middleware, shape mismatches, risk level |\n| `tool_map` | MCP/RPC tool definitions and the files that handle them |\n| `group_list` | List configured multi-repo groups, or one group's config |\n| `group_sync` | Rebuild a group's Contract Registry (cross-repo HTTP contract links); run after `group.yaml` changes or member re-index |\n| `list_repos` | Discover indexed repos (paginated — `limit`/`offset`) |\n\n### Choose a focused response\n\nUse the connected server's schema; older servers may not advertise the new\nfilters. All options below are explicit: omitting them preserves existing output.\nUse filters for bulky unwanted sections; on an already-small response, omission\nmetadata can outweigh the bytes saved.\n\n| Question | Options |\n| --- | --- |\n| Which symbols implement this? | `query`: `limit: 3`, `max_symbols: 3`, `include_content: false`, `chain_depth: 0`, `response_sections: [\"process_symbols\", \"definitions\"]` |\n| Which execution flows match? | `query`: keep `processes` in `response_sections`; join its `id` to `process_symbols[].process_id` |\n| Who calls this exact symbol? | `context`: `uid`, `response_sections: [\"incoming\"]`, `relationTypes: [\"CALLS\"]` |\n| What does it call, with source? | `context`: `uid`, `include_content: true`, `response_sections: [\"outgoing\"]`, `relationTypes: [\"CALLS\"]` |\n| What is the impact summary? | `impact`: `direction: \"upstream\"`, `summaryOnly: true`; risk calculation and totals are retained |\n| Which affected symbols need inspection? | `impact`: `limit: 10`, `offset: 0`; page as indicated by the response |\n| How does A reach B? | `trace`: `from_uid`, `to_uid` |\n\n`response_sections` selects data sections for single-repository MCP `query` or\n`context` (not `@group` routes). Query choices: `processes`, `process_symbols`,\n`definitions`. Context choices: `incoming`, `outgoing`, `processes`, `chain`,\n`routes`, `typed_properties`; the selected symbol always remains. Context\n`relationTypes` accepts uppercase relationship names advertised by its schema\nand filters only the existing incoming/outgoing categories. It does not change\nranking, traversal, source retention or the bounded candidate/reference windows.\n\nFilters add `response_filter` with the selection and omitted fields/categories.\nWarnings, ambiguity, staleness and completeness metadata always remain. An empty\nfiltered view is not proof of absence. Omit filters to expand, and never waive\nimpact checks because a selected category is empty. `maxTokens` is a byte cutoff,\nnot pagination: it can cut JSON. Prefer these filters, small result counts, and\nsource/chain expansion for a selected symbol rather than a large search result.\nStop once enough evidence answers the question; do not run every tool by default.\n\n### Paginating `list_repos`\n\n`list_repos` is paginated so a large registry is not truncated by MCP/LLM token limits. It takes optional `limit` (default **50**, max **200**) and `offset`, and returns:\n\n```jsonc\n{\n \"repositories\": [\n { \"name\": \"...\", \"path\": \"...\", \"indexedAt\": \"...\", \"lastCommit\": \"...\", \"stats\": { } }\n ],\n \"pagination\": {\n \"total\": 437,\n \"limit\": 50,\n \"offset\": 0,\n \"returned\": 50,\n \"hasMore\": true,\n \"nextOffset\": 50\n }\n}\n```\n\nTo enumerate **every** repository, keep calling with `offset` set to `pagination.nextOffset` until `hasMore` is `false`:\n\n```text\nlist_repos {} → repos 1–50, nextOffset 50, hasMore true\nlist_repos { offset: 50 } → repos 51–100, nextOffset 100, hasMore true\n…\nlist_repos { offset: 400 } → repos 401–437, hasMore false (done)\n```\n\nNotes: `offset` ≥ `total` returns an empty page (with `total` still reported). Out-of-range or malformed `limit`/`offset` (non-integer, `limit` outside `[1, 200]`, `offset < 0`) are rejected with a clear error — `limit` above the max is rejected, not silently capped. The order is deterministic (lower-cased name, then path), so paging never skips or duplicates an entry while the registry is unchanged.\n\n### Inline staleness signal (`query` / `context` / `impact` / `cypher`)\n\nThese four hot read tools attach a non-blocking `staleness` field to every response, in the shape `{ status, branch?, lastCommit, indexedAt, measuredAgainst, commitsBehind?, hint? }`. It answers two different questions at once: **which index answered** and **how fresh it is**. The identity half is why the field is present even when nothing is wrong — an answer computed from a branch-pinned index is otherwise indistinguishable from one computed from the default branch (#3291):\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"current\",\n \"branch\": \"feature/checkout-v2\",\n \"lastCommit\": \"4f2a1c9e8b7d6a5c4e3f2a1b0c9d8e7f6a5b4c3d\",\n \"indexedAt\": \"2026-09-15T07:12:00.000Z\",\n \"measuredAgainst\": \"HEAD\"\n }\n}\n```\n\n`status: \"current\"` here means *this index is at the HEAD of the clone it was built from* — not that it is current with the default branch. `measuredAgainst` names what `commitsBehind` is counted against: the checked-out HEAD of that clone, never the remote. `branch` is the branch the index represents; it is absent for a detached HEAD, a non-git folder, or a legacy index that never recorded one, so read `lastCommit` when you need an identifier that is always present.\n\nWhen the index is behind that HEAD, the count and hint ride along:\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"behind\", \"commitsBehind\": 3, \"branch\": \"main\",\n \"lastCommit\": \"a0c945022d06b8815f93ffd8838df9ed5c08cbc0\",\n \"indexedAt\": \"2026-09-04T20:45:47.481Z\", \"measuredAgainst\": \"HEAD\",\n \"hint\": \"⚠️ Index is 3 commits behind HEAD. Run analyze tool to update.\"\n }\n}\n```\n\n`commitsBehind` is present only when git counted the gap. When git could not count it but HEAD still resolves to a commit other than the indexed one — usually because the indexed commit is no longer in the clone's history — the index is provably not at HEAD with no countable gap, so no number is reported:\n\n```jsonc\n{ /* …the tool's normal result… */\n \"staleness\": {\n \"status\": \"diverged\", \"branch\": \"main\",\n \"lastCommit\": \"a0c945022d06b8815f93ffd8838df9ed5c08cbc0\",\n \"indexedAt\": \"2026-09-04T20:45:47.481Z\", \"measuredAgainst\": \"HEAD\",\n \"hint\": \"⚠️ Index is not at HEAD and the commit gap could not be counted — the recorded commit may no longer be in this clone's history. Run analyze tool to update.\"\n }\n}\n```\n\nSo: **read `status` before using `commitsBehind`**, and read `branch`/`lastCommit` before assuming which ref the answer describes. `status: \"unknown\"` means the freshness check could not run at all (a `--skip-git` folder has no history to measure) — the ref is still reported, because which index answered is knowable even when its freshness is not. The field is only ever added to object results — raw-array `cypher` output and error envelopes are returned unchanged. `@group`-targeted calls do not carry it (multi-repo staleness is ill-defined). Re-run `analyze` only for `behind` or `diverged` — those mean the index is not at this clone's HEAD. `unknown` is unmeasurable, not stale; analyze cannot make it `current` unless git history exists.\n\n`list_repos` and the HTTP repo routes are unchanged: they omit `staleness` entirely for a current index and report the ref through their own top-level `branch` / `lastCommit` / `indexedAt` fields.\n\n### Taint findings (`explain`)\n\n`explain` returns taint findings recorded by `gitnexus analyze --pdg` — intra-procedural `TAINTED` edges plus cross-function `TAINT_PATH` hops where the interprocedural taint phase found a function-level source→sink chain. Each finding includes a sink category (command-injection, code-injection, path-traversal, sql-injection, xss), source/sink lines, and the ordered hop path with the variable carried on each hop.\n\n- `explain {}` — enumerate all findings for the repo (bounded by `limit`, deterministic order)\n- `explain { target: \"src/vuln.ts\" }` — findings in a file (suffix path match accepted)\n- `explain { target: \"runUserCommand\" }` — findings in a function (resolved like `context`; ambiguous names return ranked candidates)\n\nA repo indexed without `--pdg` returns a clear \"no taint layer\" note. Caveats: closure/callback, property/field, and implicit flows are not modeled, and interprocedural findings are function-level `TAINT_PATH` hops rather than statement-level path proof, so the absence of a finding is **not** proof of safety. `SANITIZES` (sanitizer-kill) edges are queryable via `cypher`.\n\n### Control & data dependence (`pdg_query`)\n\n`pdg_query` reads the control/data-dependence layers `gitnexus analyze --pdg` records (CDG + REACHING_DEF, basic-block granular) — the control/data analog of `explain`. It is **always anchored** (a `target` file path or symbol, resolved like `context`) and has two modes:\n\n- `pdg_query { mode: \"controls\", target: \"...\" }` — CDG: \"under what condition does X run?\". Each edge is a controlling predicate block → dependent block with the branch sense (`'T'`/`'F'`) in `reason`; an edge into an early `return`/`throw` is flagged `guard: true` (guard-clause discovery — the sense depends on the predicate, so don't filter guards by a fixed label).\n- `pdg_query { mode: \"flows\", target: \"...\", variable?: \"...\" }` — REACHING_DEF def→use edges within the function; pass `variable` to trace one binding.\n\nA repo indexed without `--pdg` returns a \"no PDG layer\" note (or \"status unknown\" when the layer can't be confirmed). Intra-procedural only — cross-function flow is taint's domain (`explain`). The raw CDG/REACHING_DEF edges are also queryable via `cypher`. See the `gitnexus-pdg-query` skill for the full query surface.\n\n### Shortest path between two symbols (`trace`)\n\n`trace` answers \"how does A reach B?\" in one call — the shortest directed path over `CALLS` (plus `HAS_METHOD`, so a class-rooted trace descends into its methods) instead of chaining 3–8 `context`/`impact` hops by hand.\n\n- `trace { from: \"validateUser\", to: \"executeQuery\" }` — shortest path between two symbols.\n- Disambiguate common names with `from_uid`/`to_uid` (zero-ambiguity) or `from_file`/`to_file`; an ambiguous name returns ranked candidates.\n- `maxDepth` (default 10, max 30) bounds the search; `includeTests` (default false) lets the traversal pass through test-file symbols.\n\nReturns ordered `hops` (each `{ name, filePath, startLine }`) and an aligned `edges[]` of `{ relType, confidence }`, so call hops and containment (`HAS_METHOD`) hops stay distinguishable. When no path exists it reports the **furthest** reachable node (where the chain breaks) and sets `truncated: true` if a traversal cap was hit first. Every result carries a `status`: `ok` / `no_path` / `ambiguous` / `not_found` / `error`.\n\nCross-repo (experimental): pass `repo: \"@groupName\"` to trace across a group's member repos — the path may cross **one** `ContractLink` boundary (reported as a `CONTRACT_LINK` hop with the bridged contract in `crossings[]`). Omit `to` entirely to follow `from`'s outgoing HTTP call to whatever provider endpoint it lands on. Groups are configured via `group_list` / `group_sync`.\n\n## Resources Reference\n\nLightweight reads (~100-500 tokens) for navigation:\n\n| Resource | Content |\n| ---------------------------------------------- | ----------------------------------------- |\n| `gitnexus://repo/{name}/context` | Stats, staleness check |\n| `gitnexus://repo/{name}/clusters` | All functional areas with cohesion scores |\n| `gitnexus://repo/{name}/cluster/{clusterName}` | Area members |\n| `gitnexus://repo/{name}/processes` | All execution flows |\n| `gitnexus://repo/{name}/process/{processName}` | Step-by-step trace |\n| `gitnexus://repo/{name}/schema` | Graph schema for Cypher |\n\n## Graph Schema\n\n**Nodes:** File, Folder, Function, Class, Interface, Method, CodeElement, Community, Process, Route, Tool, plus language-specific types (Struct, Enum, Trait, Impl, Namespace, Module, …) and BasicBlock (`--pdg` indexes only). The full node list lives in `gitnexus://repo/{name}/schema`.\n**Edges (via CodeRelation.type):** CALLS, IMPORTS, EXTENDS, IMPLEMENTS, DEFINES, CONTAINS, MEMBER_OF, HAS_METHOD, HAS_PROPERTY, ACCESSES, METHOD_OVERRIDES, METHOD_IMPLEMENTS, STEP_IN_PROCESS, HANDLES_ROUTE, FETCHES, HANDLES_TOOL, ENTRY_POINT_OF, WRAPS, QUERIES, INJECTS, plus `--pdg`-only types (CFG, REACHING_DEF, TAINTED, SANITIZES, TAINT_PATH, CDG — zero rows on a default index).\n\nRead `gitnexus://repo/{name}/schema` before writing Cypher — it is the authoritative schema for the indexed repo.\n\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"myFunc\"})\nRETURN caller.name, caller.filePath\n```\n\n\n---\nname: gitnexus-impact-analysis\ndescription: \"Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: \\\"Is it safe to change X?\\\", \\\"What depends on this?\\\", \\\"What will break?\\\"\"\n---\n\n# Impact Analysis with GitNexus\n\n## When to Use\n\n- \"Is it safe to change this function?\"\n- \"What will break if I modify X?\"\n- \"Show me the blast radius\"\n- \"Who uses this code?\"\n- Before making non-trivial code changes\n- Before committing — to understand what your changes affect\n\n## Bind the repository first\n\nImpact analysis is the gate that authorizes an edit, so it must answer for the\nrepository you are about to edit.\n\nCall `list_repos {}` before the first tool call. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask — every result below an ambiguous\nidentity inherits the ambiguity. `list_repos` is paginated, so page with\n`offset: pagination.nextOffset` until `hasMore` is false before concluding a\nrepository is absent.\n\n`detect_changes` takes `worktree` when your changes are in a linked worktree\nthe MCP server was not launched from. The server auto-detects a worktree only\nwhen it was launched from inside one; otherwise `git diff` runs in the wrong\ncheckout and reports zero changed symbols — a false clean check that carries\nnone of the degradation flags described below. In the CLI fallbacks, `--repo .`\nmeans the current checkout; pass the intended repository path instead when you\nare not standing in it.\n\nState the bound identity with your risk report:\n\n```\nRepository: () Worktree: Index: , behind HEAD\n```\n\n## Workflow\n\n```\n0. list_repos {} → Bind repo (and worktree)\n1. impact({target: \"X\", direction: \"upstream\"}) or `node .gitnexus/run.cjs impact \"X\" --direction upstream --repo .`\n2. READ gitnexus://repo/{name}/processes → Check affected execution flows\n3. detect_changes({scope: \"all\"}) or `node .gitnexus/run.cjs detect-changes --scope all --repo .`\n4. Assess risk and report to user, echoing repo/worktree/index identity\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n> If `.gitnexus/run.cjs` is missing, replace `node .gitnexus/run.cjs` with `npx gitnexus` in the fallback commands.\n\n## Checklist\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] impact({target, direction: \"upstream\"}) or CLI fallback to find dependents\n- [ ] Review d=1 items first (these WILL BREAK)\n- [ ] Check high-confidence (>0.8) dependencies\n- [ ] READ processes to check affected execution flows\n- [ ] detect_changes({scope: \"all\"}) or CLI fallback for pre-commit check\n- [ ] Confirm the checkout you edited is the checkout that was diffed\n- [ ] Assess risk level and report, stating repo/worktree/index identity\n```\n\n## Understanding Output\n\n| Depth | Risk Level | Meaning |\n| ----- | ---------------- | ------------------------ |\n| d=1 | **WILL BREAK** | Direct callers/importers |\n| d=2 | LIKELY AFFECTED | Indirect dependencies |\n| d=3 | MAY NEED TESTING | Transitive effects |\n\n## Risk Assessment\n\n| Affected | Risk |\n| ------------------------------ | -------- |\n| <5 symbols, few processes | LOW |\n| 5-15 symbols, 2-5 processes | MEDIUM |\n| >15 symbols or many processes | HIGH |\n| Critical path (auth, payments) | CRITICAL |\n| **Zero callers found** | **UNKNOWN** |\n\n`UNKNOWN` is not a low rung on this scale — it means the walk could not answer.\nAn empty caller set is equally consistent with \"genuinely unused\" and \"the\ncallers are not resolvable by the index\" (plain-object property access, dynamic\ndispatch, cross-language calls), so few-callers ⇒ LOW does **not** apply. The\nresult carries a `riskNote` saying so. Confirm with a text search before\ntreating the symbol as safe to change or delete.\n\n`risk` is the edit gate: warn on HIGH/CRITICAL and stop on UNKNOWN until the\nuncertainty is resolved. Within single-repo mode, compare File and symbol\ntargets with local `riskSharedAxes` (direct/total only). Within group mode,\ncompare only group results: their `riskSharedAxes` overlays resolved\ncross-repo crossings on that local value. Never use either field to waive the\nedit gate. Check `riskScale.unusedAxes` before comparing kinds: MCP File walks\nomit process/module axes, while web Graph-RAG expands File targets to in-file\nsymbols before enrichment.\n\n## Tools\n\n**impact** — the primary tool for symbol blast radius. If MCP is unavailable, use `node .gitnexus/run.cjs impact --direction upstream --repo .` instead:\n\n```\nimpact({\n target: \"validateUser\",\n repo: \"my-app\", // required once >1 repository is indexed\n direction: \"upstream\",\n minConfidence: 0.8,\n maxDepth: 3\n})\n\n→ d=1 (WILL BREAK):\n - loginHandler (src/auth/login.ts:42) [CALLS, 100%]\n - apiMiddleware (src/api/middleware.ts:15) [CALLS, 100%]\n\n→ d=2 (LIKELY AFFECTED):\n - authRouter (src/routes/auth.ts:22) [CALLS, 95%]\n```\n\n**detect_changes** — git-diff based impact analysis. If MCP is unavailable, use `node .gitnexus/run.cjs detect-changes --scope all --repo .` instead:\n\n```\ndetect_changes({scope: \"all\"})\n\n→ Changed: 5 symbols in 3 files\n→ Affected: LoginFlow, TokenRefresh, APIMiddlewarePipeline\n→ Risk: MEDIUM\n```\n\nAdd `repo` once more than one repository is indexed, and `worktree: \"\"` when your changes are in a linked worktree the server was not launched\nfrom.\n\n`partial: true` (a graph query failed) or `truncated: true` (the changed-symbol\nlisting was capped) means the result is short of the truth, and reads like\n`UNKNOWN` above: a zero there means unseen, not unaffected. Re-run it rather\nthan tick the pre-commit check.\n\nA wrong-worktree zero carries neither flag and is shape-identical to a genuine\nclean result, so confirm the checkout you edited is the one that was diffed\nbefore treating an empty change set as a passed check.\n\n## Example: \"What breaks if I change validateUser?\"\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly\n\n1. impact({target: \"validateUser\", repo: \"my-app\", direction: \"upstream\"}) or `node .gitnexus/run.cjs impact \"validateUser\" --direction upstream --repo .`\n → d=1: loginHandler, apiMiddleware (WILL BREAK)\n → d=2: authRouter, sessionManager (LIKELY AFFECTED)\n\n2. READ gitnexus://repo/my-app/processes\n → LoginFlow and TokenRefresh touch validateUser\n\n3. Risk: 2 direct callers, 2 processes = MEDIUM\n Repository: my-app (/abs/path/my-app) Worktree: same Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n\n\n# Gitnexus-lfg Skill\n\nPath: `.claude/skills/gitnexus-lfg/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-lfg/README.md)\n\n\n---\nname: gitnexus-lfg\ndescription: \"Use when the user wants the GitNexus engineering pipeline run end-to-end on a task: gitnexus-plan (plan depth chosen up front), a blocking gate to execute with gitnexus-work or stop, finishing with a gitnexus-review of the result. Examples: \\\"/gitnexus-lfg Add retry support to the ingestion pipeline\\\", \\\"run the gitnexus pipeline on this\\\", \\\"plan, build and review this feature\\\".\"\n---\n\n# gitnexus-lfg — plan → gate → work → review\n\nThin orchestrator over three existing skills. It adds no engineering logic of\nits own — it sequences `gitnexus-plan`, `gitnexus-work`, and\n`gitnexus-review`, with the user deciding at the plan gate. Run every lane\nby actually invoking the named skill (read its SKILL.md and follow it);\nnever inline a summary of what the skill would have done.\n\n```\n/gitnexus-lfg \n/gitnexus-lfg docs/plans/.md # skip lane 1, start at the gate\n```\n\n## Lane 1 — Plan\n\n**Boundary triage first.** If the task is plainly below the planning\nboundary — trivial or small-bounded work an agent finishes in well under ~35\nturns (the measured regime where a planning pass costs more than it returns;\nmeasured in the GitNexus repository's `eval/workflow_bench/`) — say so and\noffer `gitnexus-work` direct mode as an alternative to the full pipeline\nbefore spending the plan lane. Honor the user's choice.\n\nThe threshold is a promoted benchmark policy measured offline, not a\ntimeless heuristic — never self-edit it from a live task. Its re-evaluation\ngovernance lives in this skill's README.\n\nOtherwise invoke `gitnexus-plan` with the task (knob overrides pass through\nverbatim; `gitnexus-plan` owns the up-front depth question — never ask it\nagain here). If the input is already a plan file path, skip to Lane 2. The\nplan lands in `docs/plans/` — record its path; every later lane consumes it.\n\n## Lane 2 — The plan gate (user choice, blocking)\n\nPresent the plan's chat summary (objective, proposed changes, sequence, top\nrisks, open questions, plan path), then ask the user — as a blocking\nquestion (`AskUserQuestion` in Claude Code; a numbered list in chat on CLIs\nwithout a blocking tool):\n\n1. **Proceed to work** — continue to Lane 3.\n2. **Stop here** — the plan file is the deliverable; end the pipeline.\n\nDepth was the user's up-front choice in Lane 1, so deepening is not offered\nby default — but honor an explicit request for it at the gate: run\n`gitnexus-plan` Deepen mode on the plan file and return here with the\nstrengthened plan, as many times as the user asks. Do not proceed past the\ngate without an explicit choice — the gate is the pipeline's only checkpoint\nand exists precisely because execution is expensive to unwind.\n\n**Headless / non-interactive runs:** no one can answer the gate, so end the\npipeline after Lane 1 — the plan file is the deliverable (gate option 2) —\nand say so in the final report. Never auto-proceed to execution.\n\n## Lane 3 — Work\n\nInvoke `gitnexus-work` with the plan path. It re-anchors the plan at HEAD,\nexecutes the Implementation Sequence as verified atomic commits, refreshes\nthe knowledge graph when done (its Phase 4), and reports deviations. If it routes back for re-planning (structural drift), run the\nDeepen pass and return to the Lane 2 gate rather than pushing through.\n\n## Lane 4 — Review\n\nInvoke `gitnexus-review` on the completed work. Pass an open PR URL/number\nwhen one exists; otherwise pass the current branch. The review skill owns\ntarget resolution, exact-SHA checkout/index alignment, and merge-base\nselection. Do not duplicate that logic here. If work left local changes,\npass `local` as a second, separately labeled review surface.\n\nSurface the review verdict and findings to the user. Findings the user\nwants fixed: those within `gitnexus-work`'s direct-mode bounds (1–2 files,\nno architectural decisions) → hand to `gitnexus-work` direct mode; anything\nlarger → offer the plan gate instead (Deepen the plan with the findings, or\nstop). Then re-run this lane's review once. On that re-run, do not start\nanother fix cycle even if findings remain — report them and point the user\nat `/gitnexus-work` (or the plan gate) to continue deliberately.\n\n## Final report\n\nOne message: plan path, deepen cycles run, commits produced, verification\nstatus, review verdict with unresolved findings, and what (if anything) was\nexplicitly left undone. The pipeline does not push or open a PR on its own —\noffer both as next steps.\n\n\n# Gitnexus-plan Skill\n\nPath: `.claude/skills/gitnexus-plan/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/README.md)\n\n\n# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/context-ledger.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-ledger.md)\n\n\n# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/context-pack.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/context-pack.md)\n\n\n# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/evidence-provenance.md)\n\n\n# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/pdg-slice.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/pdg-slice.md)\n\n\n# References Skill\n\nPath: `.claude/skills/gitnexus-plan/references/plan-template.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-plan/references/plan-template.md)\n\n\n---\nname: gitnexus-plan\ndescription: 'Use when you need a deep, implementation-ready engineering plan for a code change — built from GitNexus graph intelligence, statement-level PDG analysis, and targeted source verification, compact enough that an implementation agent can start without re-investigating. Also strengthens existing plans via Deepen mode. Examples: \"/gitnexus-plan Add retry support to the ingestion pipeline\", \"/gitnexus-plan deepen docs/plans/.md\", \"plan this change using the knowledge graph\".'\n---\n\n# gitnexus-plan — implementation-ready engineering plans\n\nProduce an implementation-ready plan for an engineering task. GitNexus is the\nnavigation layer (where to look), statement-level PDG is the constraint layer\n(what gates and feeds the behavior), and your native targeted source reads are\nthe verification layer (what is actually true right now). The output is a plan\ndocument plus a compact, machine-readable **implementation context pack**\nthat a follow-up implementation agent (`gitnexus-work`, or any executor) can\nconsume without repeating the investigation.\n\n```\n/gitnexus-plan \n/gitnexus-plan impact_depth:3 depth:deep # knob overrides, see Configuration\n```\n\n**This skill plans. It never implements.** Do not modify production code,\ntests, or configuration while running it. The only repository file it writes\nis the plan document (a working ledger kept outside the repo is fine). The\nonly other permitted state change is an index refresh via\n`analyze --index-only`, which writes only the `.gitnexus` index store. It\nmust not build analyzer `dist/` output and must not mutate source, tests,\nconfiguration, or evaluation data. Stale analyzer provenance is disclosed as\na source-weighted limitation, never repaired by a planning run.\n\n## Hard rules\n\n- **Ledger first.** Before every GitNexus call and every repo file read, check\n the context ledger. Never repeat a query or reread an unchanged range that\n already answered the same question (allowed repeats are defined in\n `references/context-ledger.md`; this skill's own reference files are exempt\n from ledger bookkeeping).\n- **Every graph query answers a named planning question.** Record the question\n and the conclusion in the ledger. No exploratory dredging.\n- **Source beats graph.** The graph navigates; current source is authoritative.\n Verify before asserting (see Phase 4). Comments are the weakest evidence —\n never stronger than executable code.\n- **No fabrication.** Never invent symbols, filenames, test names, tool\n results, or PDG edges. Unknowns go to _Assumptions and Open Questions_.\n- **No scope creep.** Adjacent refactors the task didn't ask for go to plan\n §12 as explicitly-deferred follow-ups, not into Proposed Changes.\n- **Pin working-tree evidence, not only HEAD.** Every plan form carries the\n versioned global dirty digest and sorted cited-path manifest defined in\n `references/context-ledger.md`. Generate it only with the portable helper\n and byte contract in `scripts/evidence-provenance.mjs` and\n `references/evidence-provenance.md`; never reimplement the digest.\n- **Write the plan only through the helper.** The generated-plan path is a\n normalized repo-relative\n `docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md` path. Compose the\n complete UTF-8 document in memory or in a scratchpad outside the target\n repo, then pass it on stdin to the helper's `write-plan` command. Never\n write the destination directly or fall back to an external output path when\n the safe writer fails.\n- **Read an existing plan only through the helper.** Deepen must invoke\n `scripts/evidence-provenance.mjs read-plan`, parse the exact decoded\n `plan_bytes_base64` from its descriptor-anchored receipt, and retain that\n receipt's canonical `generated_plan_path` and `plan_digest` as one binding.\n Never parse a direct lexical-path read or apply one plan's digest to another\n path.\n- **Stop when you have enough.** Sufficient evidence ends exploration; plans\n do not improve monotonically with tokens spent.\n\n## Phase 0 — Parse and classify\n\nRead `references/context-ledger.md` and open the ledger with the task:\noriginal request, interpreted goal, acceptance criteria. Classify the task:\n\n| Category | Posture (depth · plan form · tool-call budget · freshness) |\n| ------------------------------ | -------------------------------------------------------------------------------- |\n| Bug fix (local) | Narrow, 1–2 primary symbols, `impact_depth` 1 · compact · ~15 · accept |\n| Feature | Default knobs · compact · ~30 · accept |\n| Refactor / shared API change | Impact mandatory, `impact_depth` 3 · full · ~45 · strict |\n| Performance | Default + performance PDG mode (`references/pdg-slice.md`) · full · ~45 · strict |\n| Security | Default + security PDG mode + `explain` taint findings · full · ~45 · strict |\n| Dependency upgrade / migration | Impact + compatibility focus; PDG rarely needed · compact · ~20 · accept |\n| Concurrency / transactional | Control-flow + state-mutation PDG focus · full · ~45 · strict |\n| Test improvement / docs | Narrowest: usually no impact or PDG pass · compact · ~10 · accept |\n| Architecture change / spike | Widest: clusters + processes first · full · no cap · strict |\n\nThe category posture overrides the Configuration baseline; explicit `key:value`\ninvocation knobs override both. A task matching several rows combines them:\ntake the widest depth, union the focus areas.\n\n**Seeded evidence.** When a completed investigation already supplies\nverified findings — a finished review, a triage document with `path:line`\nanchors and named failing scenarios — open the ledger FROM it: cite the\nsource document as the opening ledger entries and plan directly against\nthem instead of re-running the graph ladder over ground it already covers.\nRe-deriving what the evidence proves is budget spent against the\nturn-economy rule. Phase 4 still source-verifies whatever Proposed Changes\nwill cite, at the pinned commit — seeding replaces exploration, never\nverification.\n\n**Depth is the user's decision, asked once, up front.** In an interactive\nsession, when the invocation carries no explicit depth signal (no `depth:`,\n`form:`, or `freshness:` knob, and not Deepen mode), ask one blocking\nquestion before Phase 1 — how deep should this plan go?\n\n1. **Quick** — `depth:narrow form:compact freshness:accept`. Fastest useful\n plan: 1–2 primary symbols, minimal graph work, core sections only.\n2. **Standard** — the category posture above, unchanged. Recommend this\n unless the classification argues otherwise.\n3. **Deep** — `depth:deep form:full freshness:strict`. All 13 sections,\n `impact_depth` 3, clusters/processes read, PDG slices for the central\n functions.\n\nThe answer sets the knobs exactly as if they had been typed in the\ninvocation; explicit knobs win and skip the question. Headless runs never\nask — the category posture applies unchanged. Asking up front replaces\noffering to deepen a finished plan afterwards: Deepen mode (below) remains\nthe mechanism for strengthening an existing plan document — a later session,\nreview findings, an executor route-back — not a default follow-up question.\n\n**Turn economy is a deliverable.** The plan is judged on decision quality per\ntoken, not thoroughness theater (measured: a 63-turn plan for a two-line\nchange — the GitNexus repo's `eval/workflow_bench/`). Stay within the category's tool-call\nbudget; when the budget runs out with questions still open, record them in\n§12 instead of digging further — the executor re-verifies cheaply anyway.\n\n## Phase 1 — Anchor and freshness\n\n1. Resolve the target repo: `list_repos` if in doubt, else the indexed repo\n covering the working directory. Pass `repo` explicitly on every call when\n more than one repo is indexed.\n2. Record the repo's current HEAD commit in the ledger — every line-number\n citation in the plan is pinned to it.\n3. **Resolve and record the analyzer runner** (used by every `analyze`\n command in this skill): `node .gitnexus/run.cjs analyze …` when the\n project has a runner (a previous analyze dropped it next to the index),\n else `gitnexus analyze …` (installed CLI — `npm install -g gitnexus`),\n else `npx gitnexus analyze …`. Record its path/version and any available\n source/build identity; do not manufacture provenance from timestamps.\n4. Read `gitnexus://repo/{name}/context` — codebase overview + staleness check.\n **Freshness gate.** Plans built on a stale graph make stale blast-radius\n claims — but a re-index is the largest fixed cost a planning session\n carries, so the gate is category-priced:\n - Compact-plan categories default to `freshness: accept`: plan on the\n current graph with source verification weighted higher — their plans\n cite little graph evidence. Escalate to a refresh mid-plan only when a\n graph claim becomes load-bearing (e.g. Proposed Changes rest on a d=1\n dependent list), and only then.\n - Full-plan categories default to `freshness: strict`, and under it:\n - **Analyzer provenance check — before any refresh.** Compare the resolved\n runner identity with the index metadata and, in an analyzer-source\n checkout, with current analyzer source. If identity is stale or unknown,\n do not build output and do not make that graph load-bearing. Record a\n **stale analyzer provenance — source-weighted limitation** in\n `index_refresh`, the plan header, and §12; rely on targeted source reads\n or hand execution to `gitnexus-work`, which owns the build-current gate.\n - Stale index → run `analyze --index-only` via the resolved runner\n (append `--pdg` when the task category will reach Phase 3) and re-read\n the context resource **only when runner provenance is known-current**.\n Refresh budget, stated once here: at most one `--index-only` refresh in\n Phase 1 **plus** at most one later `--pdg` upgrade in Phase 3 (only when\n Phase 1's refresh lacked `--pdg`) per planning session — a Deepen run is\n its own session. Record each command, runner identity, and outcome in the\n ledger's `index_refresh`.\n - Refresh failed or impractical (no write access to the index, prohibitive\n repo size), or `freshness: accept` was passed → proceed on the stale\n graph, weight source verification higher, and state the staleness and\n the skipped refresh in the plan header and Assumptions.\n - Resources unreadable but tools working → proceed on tools alone, treat\n freshness as unknown (weight source higher), and note it in the plan.\n - GitNexus unavailable entirely → switch to **Fallback mode** (below).\n5. For architecture-scale tasks only, also read\n `gitnexus://repo/{name}/clusters` and `.../processes`.\n\n## Phase 2 — Graph navigation ladder\n\nUse the narrowest operation that answers the current ledger question, in this\norder. Budgets: at most `max_primary_symbols` (5) primary symbols and\n`max_related_symbols` (20) related symbols active in the ledger.\n\n1. `query {search_query, task_context}` — locate concepts, execution flows,\n modules, and related tests for the task.\n2. `context {name}` — 360° view of each candidate primary symbol: callers,\n callees, categorized refs, processes. Promote to primary or discard. An\n `ambiguous` result (ranked candidates) is answered by one retry narrowed\n with `kind` / `file_path` / uid — that retry is an allowed repeat.\n3. `impact {target, direction}` — upstream/downstream blast radius for shared\n or high-connectivity symbols (`maxDepth` = `impact_depth`; `summaryOnly:\ntrue` first for hub symbols, then drill in — an allowed repeat). Record the\n d=1 items — the **direct (depth-1) dependents** — the plan must account\n for every one of them.\n4. `trace {from, to}` — when the task hinges on _how A reaches B_, one call\n instead of chained context hops.\n5. Statement-level PDG — Phase 3, for the functions the change centers on.\n6. `cypher` — last resort, only for a precise graph question the tools above\n cannot express. Read `gitnexus://repo/{name}/schema` first; anchor and\n LIMIT every query.\n7. `detect_changes {scope}` — only when planning against existing uncommitted\n or branch work.\n\nDo not run every tool by default. A local test fix may finish the ladder at\nstep 2.\n\n## Phase 3 — Statement-level PDG slice\n\nFor the 1–3 functions most central to the change, build a bounded **PDG\ncontext slice**. Read `references/pdg-slice.md` and follow it — it owns the\ntool calls, inclusion criteria, depth bounds, slice schema, the security and\nperformance modes, and the no-PDG-layer fallback.\n\n## Phase 4 — Targeted source verification\n\nGitNexus said where to look; now confirm what is there. Using ordinary file\nreads (exact line ranges, not whole files unless genuinely required):\n\n- Read every source range the plan will cite: signatures, branch conditions,\n state mutations, error paths, nearby comments that change behavior. Compact\n plans cite less — verify what they cite, don't expand the citation set to\n have more to verify.\n- Read the tests GitNexus associated with the primary symbols; never claim a\n test exists without having located it.\n- Verify the build/test commands the plan will name actually exist\n (package.json scripts / CI workflows), and prefer the script form that\n carries its prerequisites (pre-hooks) over invoking underlying binaries\n directly.\n- Check repo conventions that constrain the change (AGENTS.md, GUARDRAILS.md,\n lint/build config) — only the parts the change touches.\n- Mark each ledger symbol `source_verified: true` as you go. **A symbol that\n is named in Proposed Changes must be source-verified.**\n- On graph/source disagreement: trust source, record the discrepancy in the\n ledger and the plan, recommend re-indexing. Never present stale graph data\n as fact.\n- Immediately before composition, recompute the versioned\n `evidence_provenance` snapshot by invoking\n `scripts/evidence-provenance.mjs` exactly as specified in\n `references/evidence-provenance.md`: the\n canonical global dirty digest over all dirty paths and the sorted manifest\n of every cited path, including object kind and\n HEAD/index/worktree/untracked layer digests. Re-read any citation that\n changed during planning. Exclude only the generated plan path.\n\nEvidence hierarchy, strongest first: current source and config → current tests\nand executable behavior → compiler/build/lint output → GitNexus graph and PDG\n→ documentation and comments.\n\n## Phase 5 — Compose the plan\n\n1. Read `references/plan-template.md` and fill the category's form — compact\n (core sections, ≤80 lines excluding the pack) or full (all 13 sections) —\n from the ledger, tagging claims with the template's four classes —\n `[verified]`, `[graph]`, `[inferred]`, `[assumed]` — and routing open\n questions to §12.\n2. Build the implementation context pack per `references/context-pack.md`\n (this is section 11 of the plan), including mandatory\n `evidence_provenance` in compact and full forms.\n3. Set `generated_plan_path` to\n `docs/plans/YYYY-MM-DD-gitnexus-plan-.md` under the root of the repo\n being planned (the Phase 1 target repo, not necessarily the cwd); use a\n 3–5-word kebab-case slug and repo-relative paths inside the document.\n Compose the complete document without creating that destination, then\n pipe its exact UTF-8 bytes to `scripts/evidence-provenance.mjs write-plan`\n as specified in `references/evidence-provenance.md`. The helper safely\n creates missing parent directories. Initial planning must not pass\n `--replace`. A safe-write failure blocks plan publication: report it and\n do not write directly, choose an external destination, or weaken the\n repo-relative provenance contract. The snapshot and writer commands apply\n the same strict generated-plan filename/date validator; do not substitute a\n source, `.git`, or arbitrary `docs/plans/` path in either invocation.\n4. Present in chat: objective, proposed-changes summary, implementation\n sequence, top risks, open questions, and the plan file path. Do not paste\n the whole document into chat.\n\n## Deepen mode\n\n`/gitnexus-plan deepen ` strengthens an existing plan in place\ninstead of creating a new one:\n\n1. Resolve the target repository and normalized repo-relative plan candidate,\n then load it with `scripts/evidence-provenance.mjs read-plan --repo \n--generated-plan ` exactly as specified in\n `references/evidence-provenance.md`. Reject a missing, external, escaping,\n symlinked, or differently scoped path. Decode and parse only the receipt's\n exact `plan_bytes_base64`; retain its canonical `generated_plan_path` and\n `plan_digest` unchanged for the entire Deepen session.\n2. Re-run Phase 1 in full — analyzer provenance check and freshness gate (a\n Deepen run is its own session, with its own refresh budget).\n3. **Re-anchor before re-pinning.** Recompute the plan's global dirty digest\n and cited-path manifest as well as comparing its old HEAD pin with current\n HEAD. Changed, renamed, deleted, mixed, or newly absent cited paths get\n their ranges re-read — or the claim downgraded — _before_ the pin and\n provenance snapshot move. Moving only the commit pin silently launders\n dirty or stale claims as verified.\n4. Escalate to `depth: deep` (impact_depth 3, clusters/processes read)\n unless the invocation overrides knobs explicitly.\n5. Seed the ledger from the plan's §11 pack, then re-verify: every\n `[graph]`/`[inferred]` claim gets a targeted pass toward `[verified]`;\n every `[assumed]` claim is resolved or kept with its reason; direct\n (d=1) dependent accounting is re-checked against the refreshed graph;\n PDG slices are built or expanded for the central functions when the\n layer is present.\n6. **Reconcile execution state.** If `gitnexus-work` already landed commits\n for this plan (a mid-execution route-back), mark the §7 steps present at\n HEAD as completed and re-sequence the remainder — the rewritten plan must\n be executable from the top without redoing landed steps.\n7. Strengthen whatever the deeper pass showed thin — test scenarios, risks,\n Definition of Done — and carry claim-tag upgrades through the prose.\n8. Rewrite the **same canonical file** through\n `scripts/evidence-provenance.mjs write-plan --replace\n--expected-plan-path \n--expected-plan-digest `: same 13 sections,\n context pack kept in sync, evidence header updated. `--replace` is reserved\n for Deepen mode, and both expected values must come from the same read-plan\n receipt; any digest/path mismatch blocks publication. Retain the successful receipt's\n `prior_plan_backup_git_path`; it names the verified Git-admin backup of the\n displaced plan. Summarize the delta in chat: claims upgraded, claims that\n failed re-verification, sections changed, and that backup path.\n\n## Configuration\n\nBaseline defaults — the Phase 0 category posture overrides them, and inline\n`key:value` tokens before the task text override both (the repo has no\nskill-config file mechanism; invocation args are the mechanism):\n\n| Knob | Default | Meaning |\n| --------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `depth` | by category | `narrow` = `impact_depth` 1, PDG only if one function is clearly central; `default` = this table; `deep` = `impact_depth` 3 + clusters/processes read |\n| `form` | by category | `compact` (core sections + mini-pack, ≤80 lines excl. pack — see `references/plan-template.md`) or `full` (all 13 sections) |\n| `impact_depth` | 2 | `maxDepth` for `impact` |\n| `pdg_data_depth` | 2 | Data-dependence hops in the PDG slice |\n| `pdg_control_depth` | 2 | Control-dependence hops in the PDG slice |\n| `max_primary_symbols` | 5 | Ledger budget (active symbols; discards don't count) |\n| `max_related_symbols` | 20 | Ledger budget (active symbols; discards don't count) |\n| `max_snippet_lines` | 30 | Longest source excerpt quoted in the plan |\n| `freshness` | by category | `strict` (full-plan categories) = refresh a stale index (and a missing PDG layer) with `analyze --index-only [--pdg]` before relying on the graph; `accept` (compact categories) = plan on the current graph, source-weighted and labelled, refreshing only if a graph claim becomes load-bearing |\n\n## Fallback mode (GitNexus or PDG unavailable)\n\n1. Say so, first thing, in chat and in the plan.\n2. Use targeted repo exploration (grep/glob/reads) to approximate callers,\n dependencies, execution flow, state changes, and related tests.\n3. Label every such finding **source-derived** in the plan — never present it\n as graph-derived, and never fabricate statement-level edges.\n4. Recommend `analyze --index-only` (add `--pdg` for the PDG layers) via\n the resolved runner — `node .gitnexus/run.cjs`, installed `gitnexus`, or\n `npx gitnexus` — when it would materially raise confidence.\n\n## Skill feedback\n\nIf this run exposed friction in the instructions, include concise feedback in\nthe final response. Feedback is chat-only: do not append evaluation learnings,\nedit benchmark data, or modify this skill during a live planning task.\n\n\n---\nname: gitnexus-pr-swarm-review\ndescription: \"Run a GitNexus production-readiness pull request review using a coordinated reviewer swarm.\"\n---\n\n# GitNexus PR Swarm Review (Claude Code adapter)\n\nUse this skill to review a GitNexus pull request and produce a production-readiness review.\n\n> This is the interactive, on-demand reviewer swarm. It is distinct from the CI\n> `gitnexus-review` skill's built-in \"Swarm lanes\" (`ci-personas/`), which the\n> review-agent workflow dispatches automatically inside a single review run.\n\n```\n/gitnexus-pr-swarm-review \n```\n\nYou are the **swarm coordinator**. The full review contract — lanes, dependencies,\nclassifications, output structure, finding format, hidden-Unicode checks, and behavior\nrules — is the canonical, CLI-neutral spec:\n\n**`pr-swarm-review/orchestration.md`** — read it now and follow it.\n\nThis adapter only pins the Claude Code specifics:\n\n- **Run in Swarm mode.** Dispatch each lane as its own subagent via the Agent tool. The\n seven subagents are the project agents named `gitnexus-*` (one per persona); each reads\n its canonical persona under `pr-swarm-review/personas/`. Run lanes 1–2 first, lanes 3–6\n in parallel after, and lane 7 last on the draft.\n- **Lane 7 is a hard gate.** Do not emit the final review while the synthesis critic's\n \"Required corrections before posting\" section is non-empty — revise and re-run it.\n- Stay **read-only**: investigate and report; never edit, commit, or post.\n\nDo not flatten the review into a generic checklist; delegate to the subagents and\nsynthesize per `orchestration.md`.\n\n\n---\nname: gitnexus-refactoring\ndescription: \"Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: \\\"Rename this function\\\", \\\"Extract this into a module\\\", \\\"Refactor this class\\\", \\\"Move this to a separate file\\\"\"\n---\n\n# Refactoring with GitNexus\n\n## When to Use\n\n- \"Rename this function safely\"\n- \"Extract this into a module\"\n- \"Split this service\"\n- \"Move this to a new file\"\n- Any task involving renaming, extracting, splitting, or restructuring code\n\n## Bind the repository first\n\nRefactoring writes to disk. `rename` with `dry_run: false` edits files in\nwhichever repository was resolved, so binding identity here is a safety gate,\nnot bookkeeping.\n\nCall `list_repos {}` before the first tool call. With one indexed repository,\nuse the examples below as written. With more than one, pass `repo` on every\ncall: an omitted `repo` normally errors, but under an MCP policy with a\nconfigured default it resolves to that default silently. If you cannot tell\nwhich repository is meant, stop and ask. Never run `rename` with\n`dry_run: false` until the preview in the same bound repository has been\nreviewed — its returned `file_path` values show which checkout is about to be\nwritten, so read them as a confirmation of identity.\n\n`list_repos` is paginated, so page with `offset: pagination.nextOffset` until\n`hasMore` is false before concluding a repository is absent.\n\n`detect_changes` takes `worktree` when you are editing a linked worktree the\nMCP server was not launched from; otherwise `git diff` runs in the wrong\ncheckout and reports nothing changed, which reads as a verified refactor.\n\n## Workflow\n\n```\n0. list_repos {} → Bind repo (and worktree)\n1. impact({target: \"X\", direction: \"upstream\"}) → Map all dependents\n2. query({search_query: \"X\"}) → Find execution flows involving X\n3. context({name: \"X\"}) → See all incoming/outgoing refs\n4. Plan update order: interfaces → implementations → callers → tests\n```\n\n> If \"Index is stale\" → run `node .gitnexus/run.cjs analyze` in terminal.\n> Hot-tool `staleness` names which index answered (`branch`/`lastCommit`) and how fresh it is (`status`). Re-analyze only for `behind` or `diverged` — `current` is identity, `unknown` is unmeasurable.\n\n## Checklists\n\n### Rename Symbol\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] rename({symbol_name: \"oldName\", new_name: \"newName\", dry_run: true}) — preview semantic edits (omitting dry_run also previews)\n- [ ] Confirm the previewed file paths are in the bound repository/worktree\n- [ ] Review exact graph-backed semantic spans, coverage, and limitations\n- [ ] If satisfied: rename({..., dry_run: false, plan_token: \"\"}) — apply exactly the reviewed edits\n- [ ] detect_changes() — verify only expected files changed\n- [ ] Run tests for affected processes\n```\n\n### Extract Module\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] context({name: target}) — see all incoming/outgoing refs\n- [ ] impact({target, direction: \"upstream\"}) — find all external callers\n- [ ] Define new module interface\n- [ ] Extract code, update imports\n- [ ] detect_changes() — verify affected scope\n- [ ] Run tests for affected processes\n```\n\n### Split Function/Service\n\n```\n- [ ] list_repos {} — bind repo; explicit repo when >1 indexed, ask if ambiguous\n- [ ] context({name: target}) — understand all callees\n- [ ] Group callees by responsibility\n- [ ] impact({target, direction: \"upstream\"}) — map callers to update\n- [ ] Create new functions/services\n- [ ] Update callers\n- [ ] detect_changes() — verify affected scope\n- [ ] Run tests for affected processes\n```\n\n## Tools\n\n**rename** — semantic rename; preview first, then apply:\n\n```\nrename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: true})\n→ 12 edits across 8 files\n→ semantic_edits: 12, coverage: {name: \"gitnexus-semantic\", scope: \"indexed-repository\", limitations: [...]}\n→ changes: [{file_path, edits: [{start, length, line, old_text, new_text, confidence: \"semantic\"}]}]\n```\n\n`dry_run` omitted or `true` previews and never writes; `dry_run: false` requires\nthe successful preview's `plan_token`. Keep the same repository, selected symbol,\nand destination name. Tokens are single-use, expire after 15 minutes or a server\nrestart, and may be evicted when retained previews reach 16 plans or 64 MiB.\nAny apply attempt consumes the token; request and review a fresh preview to retry.\nAn MCP server started with `GITNEXUS_MCP_READ_ONLY=1` still lists `rename`, but\nas preview-only: it rejects any `dry_run` other than omitted or `true`, so apply\nthrough a server that permits writes. Request and review a fresh preview there;\ntokens belong to the process that issued them.\n\nRename uses the indexed graph and GitNexus's own semantic layer. Language\nproviders resolve current source through scopes and bindings; no compiler or\nlanguage service is loaded. Unsupported syntax, ambiguous bindings, stale\ndeclarations, and incomplete occurrence coverage fail closed. Coverage describes\nindexed files accepted by the selected provider, including supported embedded sources,\nand excludes unindexed files and external consumers. All registered source-language\nproviders supply rename rules. Declaration and override families require complete\nsemantic evidence. Dynamic or computed references block a rename when the provider\ncannot resolve them or exclude them from the selected family. Provider-specific\nlimits, including class renames requiring a file move, remain explicit in results.\nThere is no regex fallback: legacy `graph_edits` and `text_search_edits` are zero.\nComments, strings, and unrelated same-spelled symbols are not replacements.\n\nPreview captures the exact semantic plan, source hashes and physical file targets.\nApply validates that plan and executes its edits without replanning. Changes to\nindexed targets, source bytes or paths (including newly added untracked source\nfiles) reject the plan before writing. Unindexed files remain outside semantic\ncoverage; analyze first when they need refactoring. Results use `result_version: 2`;\n`total_edits` counts occurrences, not matching lines. Exact replacements are shown in `new_text`.\nCheck `planning_status`, `application_status`, and `applied`. A completed apply\nhas `status: \"success\"`, `application_status: \"applied\"`, and `applied: true`.\nA successful preview has not written files. `rename` does not accept `branch`:\nit inspects the current checkout.\n\nRecover from a blocked or incomplete rename before applying again. A failed\nresult carries `code` and `error`; nothing was written unless the last row applies.\n\n| Result | Next step |\n| --- | --- |\n| `stale_graph` | Re-analyze the bound repository, then preview again with `rename` (`dry_run` omitted or `true`). |\n| `source_changed` | Preview again against the current source and review it. If it appears during an apply, see the `partial` row. |\n| `plan_required`, `invalid_plan`, `plan_mismatch` | Apply needs the successful preview's token and identical repository, symbol and new name. Expired, consumed or evicted plans require a fresh reviewed preview. |\n| `source_set_changed` | Source paths changed, including untracked files. Re-analyze and review a fresh preview. |\n| `plan_too_large` | The captured plan exceeds the 64 MiB retention budget. Narrow the indexed repository before previewing again. |\n| `unsupported_*` | Stop automated rename and inspect the reported limitation. Use a language-aware manual refactor if needed. |\n| Ambiguous target (`status: \"ambiguous\"` with candidates) | Inspect the returned candidates or `context`, then preview with the chosen `symbol_uid`. |\n| `ambiguous_reference`, `incomplete_semantics` | The planner could not prove a reference, import, or declaration is covered. Stop automated rename; resolve the named location by hand or pick a different symbol. |\n| `name_collision` | `new_name` would collide with, or change the identity of, another declaration or binding. Choose a different name and preview again. |\n| `invalid_name` | `new_name` is empty, equals the current name, or is not valid in the target language. Choose a valid, different identifier. |\n| `invalid_argument` | `dry_run` was sent but is not a boolean. Omit it or send `true` or `false`. |\n| `no_locations` | The planner produced no edits. Do not apply; re-check the target with `context` and pass `symbol_uid`. |\n| `overlapping_edits`, `invalid_edit` | The planned spans conflict or do not match the source text. The plan is rejected before any write; do not apply. Refactor manually or report the case. |\n| `duplicate_file`, `missing_snapshot`, `outside_repository` | A planner safety check failed (two paths resolve to one real file, a file has no source snapshot, or a path leaves the repository). Re-analyze and preview again; if it repeats, stop and report it. |\n| `source-unavailable` (`reason: \"content-retention\"` or `\"checkout-missing\"`) | The index was built without full source retention (`GITNEXUS_CONTENT_RETENTION`), or the checkout directory is missing. Re-analyze with full retention, or run against the checkout. |\n| `rename_failed` | An unexpected error while planning, before any write (`application_status: \"not_started\"`). Re-analyze and preview once more; if it repeats, stop and report the `error` text. |\n| `application_status: \"partial\"` or `\"failed\"` (`write_failed`, or `source_changed` mid-apply) | Writes are not transactional. Inspect landed `changes` (already written, with their counts), `failed_files` (the one file whose write or validation failed), and `unattempted_files` (later files never touched). Reconcile the current files, re-index, and review a fresh preview; never blindly retry the apply call. |\n\nRun the project validation suite after applying.\n\n**impact** — map all dependents first:\n\n```\nimpact({target: \"validateUser\", repo: \"my-app\", direction: \"upstream\"})\n→ d=1: loginHandler, apiMiddleware, testUtils\n→ Affected Processes: LoginFlow, TokenRefresh\n```\n\n**detect_changes** — verify your changes after refactoring:\n\n```\ndetect_changes({scope: \"all\"})\n→ Changed: 8 files, 12 symbols\n→ Affected processes: LoginFlow, TokenRefresh\n→ Risk: MEDIUM\n```\n\n`partial: true` (a graph query failed) or `truncated: true` (the changed-symbol\nlisting was capped) means the result is short of the truth: a short or empty\nlist is not proof that only the expected files changed. Re-run it rather than\ntreat the refactor as verified.\n\nA wrong-worktree zero carries neither flag and is indistinguishable from a\nclean verification, so confirm the diffed checkout is the one you edited.\n\n**cypher** — custom reference queries:\n\n```cypher\nMATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: \"validateUser\"})\nRETURN caller.name, caller.filePath ORDER BY caller.filePath\n```\n\n## Risk Rules\n\n| Risk Factor | Mitigation |\n| ------------------- | ----------------------------------------- |\n| Many callers (>5) | Use rename for automated updates |\n| Cross-area refs | Use detect_changes after to verify scope |\n| String/dynamic refs | query to find them |\n| External/public API | Version and deprecate properly |\n| Same name in another indexed repo | Bind `repo`; verify previewed paths before applying |\n\n## Example: Rename `validateUser` to `authenticateUser`\n\n```\n0. list_repos {}\n → total: 2 (my-app, billing-api) — both define validateUser, so bind explicitly\n\n1. rename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: true})\n → 12 semantic occurrences in the indexed repository's supported provider scope\n → Files: validator.ts, login.ts, middleware.ts...\n\n2. Review semantic spans and provider coverage; inspect dynamic references separately\n\n3. rename({symbol_name: \"validateUser\", new_name: \"authenticateUser\", repo: \"my-app\", dry_run: false, plan_token: \"\"})\n → Applied 12 edits across 8 files\n\n4. detect_changes({scope: \"all\", repo: \"my-app\"})\n → Affected: LoginFlow, TokenRefresh\n → Risk: MEDIUM — run tests for these flows\n Repository: my-app (/abs/path/my-app) Worktree: same Index: current\n```\n\nWith a single indexed repository, step 0 returns `total: 1` and the `repo`\nargument drops out of every call above.\n\n\n# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-adversarial-lens.md)\n\n\n# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-blast-radius-lens.md)\n\n\n# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-correctness-lens.md)\n\n\n# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-coverage-lens.md)\n\n\n# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-critic-lens.md)\n\n\n# Ci-personas Skill\n\nPath: `.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-review/ci-personas/ci-security-lens.md)\n\n\n---\nname: gitnexus-review\ndescription: 'Review code changes with GitNexus from a GitHub PR URL or number, a branch/ref or commit range, or local staged, unstaged, and untracked changes. Use when the user asks for a code review, merge-risk assessment, regression hunt, missing-test analysis, or a verdict on whether a PR, branch, commit range, or local diff is safe.'\n---\n\n# GitNexus review\n\nReview the requested change surface without editing source, committing, pushing,\nposting, or resolving threads. A later explicit request may authorize those\nactions. Use GitNexus for structural evidence and source inspection for proof;\nneither substitutes for the other.\n\n## Resolve the target\n\nAccept these forms:\n\n| Input | Review surface |\n| ------------------------------------------------------ | --------------------------------------------------------------------------- |\n| PR URL, `owner/repo#42`, `#42`, or bare number | GitHub PR |\n| `base...head` | Merge-base range |\n| `base..head` | Exact two-dot range |\n| Branch, tag, or commit | Ref against the repository default branch |\n| `local`, `staged`, `unstaged`, or working-tree wording | Local changes |\n| No target | Current branch's open PR; otherwise local changes; otherwise current branch |\n\nAn explicit target always wins. Interpret a bare number as a PR only in a\nGitHub repository with working `gh` authentication; otherwise ask for a ref or\nURL. If implicit mode finds both branch commits and local changes, review them\nas two labeled surfaces rather than silently dropping or blending either one.\n\nRecord the resolved target kind, repository root, default branch, base SHA,\nhead SHA, merge-base when applicable, and included local states. Resolve the\ndefault branch from remote metadata (`refs/remotes//HEAD` or GitHub\nrepository metadata); use `main` or `master` only as an explicit fallback and\nsay when doing so.\n\n### PR\n\nUse `gh pr view`/`gh api` to pin the PR number, repository, title, URL, base\nref, base SHA, head ref, and head SHA. Fetch those exact commits without\nswitching the user's branch. Compute `git merge-base ` and use\nthat SHA as the review base: GitHub PR diffs are merge-base diffs, while\n`detect_changes(scope: \"compare\")` is a two-dot comparison.\n\nUse the local `git diff ` as the complete diff source of\ntruth; use GitHub metadata for PR facts and review state. For fork PRs, fetch\nthe pull ref or the contributor remote instead of assuming the head branch\nexists on `origin`.\n\n### Branch, ref, or range\n\nResolve every ref to a commit before reviewing. For a branch or `A...B`, use\nthe merge-base as the comparison base. For an explicit `A..B`, honor `A` as\nthe exact base. Do not compare a feature branch directly with a moving default\nbranch tip when merge-base semantics were intended.\n\n### Local changes\n\nInspect `git status --short`, the staged diff, the unstaged diff, and every\nuntracked file. Use `detect_changes` with `staged`, `unstaged`, or `all` as\nrequested. Untracked files are not guaranteed to appear in Git diff or graph\nmapping, so read them directly and list them in the review provenance.\n\n## Align the checkout and index\n\nThe graph and diff must describe the same head. Reuse an existing worktree only\nwhen it is at the exact target SHA. Otherwise create a temporary detached\nworktree for the PR/ref head, review there, and remove only that temporary\nworktree afterward. Never switch or reset the user's current worktree.\n\nCheck GitNexus status in the target worktree. If stale, run\n`node .gitnexus/run.cjs analyze --index-only` before trusting graph results\n(temporary worktrees never carry the gitignored `run.cjs` — fall back to the\ninstalled `gitnexus` CLI, then `npx gitnexus`), and include `--pdg` in that\nsame refresh when the diff plausibly touches trust or data-flow boundaries,\nso the taint pass below doesn't pay a second full analyze. Taint and\ndependence evidence needs that PDG layer: when the workflow's taint pass\nfinds it missing, rebuild with `analyze --pdg --index-only` and record the\nrebuild in provenance. For local changes, refresh the index so new or\nmodified source is represented.\nIf an exact target checkout/index cannot be established, state the limitation\nand do not claim a complete graph-backed review.\n\n## Review workflow\n\n1. Read the full diff and changed-file list. Separate generated files,\n dependency churn, tests, and behavior changes.\n2. Run `detect_changes` against the exact surface:\n - PR/branch/`...`: `scope: \"compare\"`, `base_ref: `.\n - Explicit `A..B`: `scope: \"compare\"`, `base_ref: ` from a worktree\n at `B`.\n - Local: `scope: \"staged\"`, `\"unstaged\"`, or `\"all\"`.\n Pass `worktree` when the MCP server is attached elsewhere.\n3. Run upstream `impact` with `includeTests: true` for each behaviorally changed\n symbol. Prioritize public contracts, shared types, control flow, persistence,\n security boundaries, and error handling; skip mechanical/generated changes.\n4. Inspect every direct (`d=1`) dependent that is outside the diff. A dependent\n outside the diff is a lead, not automatically a bug—verify the changed\n contract and caller behavior in source.\n5. Use `context` on key or ambiguous symbols and inspect affected execution\n flows. Read the surrounding implementation and tests at cited locations.\n6. **Taint and dependence pass.** For changed code on trust or data-flow\n boundaries — external input, persistence, process execution, network,\n auth — run `explain` on the changed files or symbols and judge its\n source→sink taint findings against the diff: a flow the change\n introduces, or a sanitizer/guard the change removes, is a finding; a\n pre-existing flow is context, not a defect of this change. When the\n change claims to guard or sanitize something, verify with `pdg_query`:\n what controls the changed statement, and where its values flow. This\n needs a `--pdg` index; if one cannot be built, state that the taint pass\n was skipped rather than implying coverage.\n7. Check whether tests exercise the changed behavior, boundary conditions, and\n affected flows. Run focused read-only validation when practical. When the\n diff refreshes a committed baseline, fingerprint, or golden, re-run the\n exact CI check command against the head instead of trusting the committed\n value — a stale artifact is invisible in the diff and fails only in CI.\n8. Reconcile graph evidence with the raw diff. New files, dynamic dispatch,\n configuration, reflection, and untracked content may require direct review\n even when graph results are empty. Version and invalidation constants are\n review surface: when the diff changes what gets emitted or persisted,\n verify every schema/version constant gating caches, incremental\n writebacks, and fingerprint baselines was bumped or regenerated — in\n GitNexus itself, for example: graph DDL needs no manual bump, because\n `SCHEMA_FINGERPRINT` (`gitnexus/src/core/lbug/schema.ts`) is derived\n from `NODE_SCHEMA_QUERIES` + `REL_SCHEMA_QUERIES` and moves on its own;\n the check there is whether the diff changed any string in those arrays,\n and, if it added a new DDL array, whether that array was folded into the\n fingerprint. Parser compatibility is also automatic: review the base/PDG\n ownership boundaries in `gitnexus/src/core/parse-cache-identity.ts`, the\n import/asset coverage audit, and real cold → warm replay tests. New parser\n dependencies outside those boundaries need explicit coverage; contributors\n do not allocate a semantic counter. Both benchmark fingerprint sets still\n need deliberate review before re-baselining: automatic invalidation does\n not establish semantic correctness. Other semantic changes that leave DDL\n untouched rely on the analyzer runner-identity receipt in index metadata.\n\n## Expert lenses\n\nDepth comes from matching reviewers to what actually changed, not from one\ngeneralist pass. After workflow step 2, group the changed files and symbols\nby the functional areas the graph already knows — the index's cluster\nlisting; `context` names each symbol's cluster — and give each touched area\nan expert lens: a reviewer charged with that domain's contracts, invariants,\nand failure modes, grounded in the repo's own material (architecture docs,\nagent rules, the domain's tests) before judging the diff. A lens verifies,\nnot just reads: when the changed code is a pure function reachable from the\nrepo's own toolchain — parsers, extractors, capture emitters, formatters —\nexecute it on the candidate failing shape (a scratch probe, deleted\nafterward) and cite the observed output. An empirical probe outranks source\nreading in the evidence hierarchy; role swaps, dead branches, and\nerror-recovery-dependent behavior repeatedly pass a reading and fail a\nten-line probe. The numbered\nworkflow runs exactly once; dispatch the lens passes after step 6, handing\neach lens the evidence already collected rather than letting lenses repeat\nthe `impact`, `context`, or taint calls. In GitNexus\nitself, for example: shared ingestion-pipeline changes get an ingestion\nexpert plus one language expert per changed language extractor; embeddings\nchanges an embeddings expert; LadybugDB/storage changes a Ladybug expert.\n\nFour cross-cutting lenses run regardless of domain:\n\n- **Architectural fit** — the change lands where the architecture says the\n concern lives, reuses existing seams, and adds no parallel structure.\n- **Language conformance** — the repo's own type/lint/test contract as\n configured (tsconfig strictness, lint rules, test conventions); in a\n strict TypeScript repo, for example: strictness intact, no `any`/`as any`\n escapes, module boundaries typed. Judge by the repo's contract, never a\n universal style bar.\n- **Definition of Done** — changed behavior has tests, docs the change makes\n stale are updated, and sync/drift guards (shipped copies, manifests,\n changelogs) still hold.\n- **Simplicity** — YAGNI and clear-code check: flag speculative abstraction,\n unused knobs, and overengineering; the smallest diff that meets the\n Definition of Done is the standard.\n\nScale effort to the surface: a single-domain change of a few files gets one\ncombined pass covering its domain lens plus the four cross-cutting checks;\na multi-domain change gets one lens per touched area — run as parallel\nsubagents where the harness supports them, each scoped to its own files\nplus the shared graph evidence, and as sequential passes otherwise. Never\nspawn a lens for a domain the diff does not touch. Merge lenses that ground\nin the same material — two lenses reading the same files pay twice for one\nread's coverage, so give one reviewer both charges. Where the harness\noffers model or effort tiers, run mechanical lenses (rename sweeps,\ndoc-consistency checks) on a cheaper tier and reserve the strongest engine\nfor adversarial judgment. Every lens reports\nthrough the Finding standard below; merge and dedup before the verdict,\ndropping anything without a concrete failing scenario.\n\n### Swarm lanes\n\nSix dispatchable lane definitions ship with this skill in `ci-personas/` —\nread-only reviewers restricted to file reads plus the safe graph tools. Five are finder lanes: `ci-correctness-lens`, `ci-security-lens`,\n`ci-blast-radius-lens`, `ci-coverage-lens`, and `ci-adversarial-lens`\n(which assumes the change is broken and constructs reachable failure\nscenarios the pattern checks miss). They carry the verification\ndimensions of the numbered workflow across every touched domain; domain\ngrouping and the four cross-cutting checks above remain the\norchestrator's charge. The sixth, `ci-critic-lens`, is a gate, not a\nfinder — it audits the finished draft.\n\nWhen the harness supports subagents and these lanes are registered as\nagents (the CI review workflow installs them from its trusted control\ncheckout; a local harness may register them by copying `ci-personas/*.md`\ninto `~/.claude/agents/` or the project's `.claude/agents/`), run the\nexpert-lens pass as follows. First establish your own graph evidence —\nmake at least one substantive context call on a changed symbol yourself,\nbefore dispatching any lane, since lane calls never satisfy the evidence\nthis skill or its runner requires. Then dispatch all five finder lanes in\nparallel in a single message. Give each lane the diff, the changed-file\nmanifest, the exact base and head identifiers, the checkout paths, and the\nslice of changed files matching its charge.\n\nTreat every lane report as an unverified claim: re-anchor each finding to\nthe diff, the source, or your own graph queries before it enters the\nreview; dedup across lanes; drop anything without a concrete failing\nscenario. Lane tool calls never substitute for evidence this skill or its\nrunner requires from the orchestrating conversation itself.\n\nAfter composing the complete draft review, dispatch `ci-critic-lens` with\nthe full draft body plus the same context. On `DEFECTS`, repair the draft\nand re-dispatch the critic once; if defects remain after the second pass,\nfix what you accept, note the unresolved critic objections in the\ncoverage section, and proceed — the critic hardens the review; it never\nblocks it. This fail-open is deliberate: the critic is bounded to two\npasses so it cannot deadlock or wedge the run, and the review is still\ngated by the runner's own evidence and schema checks. (This is distinct\nfrom the separate `gitnexus-pr-swarm-review` skill, whose interactive\nroster treats its critic as a hard gate that must clear before emission;\nthis CI lane must always emit a review or a clean failure.) If subagent\ndispatch is unavailable or any lane fails, run that lane's charge inline —\nthe lanes structure the work; they never gate it.\n\n## Finding standard\n\nReport a finding only when the reviewed change introduces a concrete defect,\nregression, security issue, compatibility break, material coverage gap, or a\nmaintainability cost with a concrete carrying scenario (a dead knob, a\nduplicated contract, a drift-prone copy).\nEach finding must include:\n\n- severity and a precise `path:line` anchor;\n- the failing scenario or contract;\n- GitNexus evidence (dependent symbol/process) when applicable;\n- why existing code or tests do not mitigate it;\n- a concise remediation or missing test.\n\nDo not report style preferences, pre-existing issues, raw risk counts, or\nspeculation as defects. Do not infer safety from zero graph hits. Calibrate\noverall risk from consequence, reachability, reversibility, and test evidence,\nnot from the number of changed symbols alone.\n\n## Output\n\nLead with findings in severity order. If there are none, say so explicitly.\nThen provide:\n\n```markdown\n## Review: \n\n### Findings\n\n- [HIGH|MEDIUM|LOW] `path:line` — \n\n### Change and blast-radius summary\n\n- Target/base/head/merge-base and local states reviewed\n- Changed symbols and affected execution flows\n\n### Coverage and residual risk\n\n- Tests present, tests missing, graph/diff limitations\n\n### Verdict\n\nAPPROVE | REQUEST CHANGES | NEEDS DISCUSSION\n```\n\nFor a branch or local review, use `READY`, `NOT READY`, or `NEEDS DISCUSSION`\ninstead of a PR approval action. Include the exact target SHAs so a later run\ncan tell whether the evidence is stale.\n\n\n# Gitnexus-work Skill\n\nPath: `.claude/skills/gitnexus-work/README.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/README.md)\n\n\n# References Skill\n\nPath: `.claude/skills/gitnexus-work/references/evidence-provenance.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus-work/references/evidence-provenance.md)\n\n\n---\nname: gitnexus-work\ndescription: 'Use when executing an engineering plan produced by gitnexus-plan (or a small bounded task directly) — implements step by step with GitNexus impact checks before every symbol edit, tests from the plan''s scenarios, and detect_changes gating every commit. Examples: \"/gitnexus-work docs/plans/2026-07-11-gitnexus-plan-ingestion-retry.md\", \"/gitnexus-work\" (latest plan), \"execute the plan\".'\n---\n\n# gitnexus-work — execute a gitnexus-plan\n\nExecute an implementation plan produced by `gitnexus-plan`, shipping it as a\nsequence of verified, atomic commits. The plan's section 11\n(`implementation_context` pack) is the primary machine-readable input; the\nprose sections are its rationale. This skill **does** edit code — it is the\nexecutor counterpart to the planning-only `gitnexus-plan`.\n\n```\n/gitnexus-work # execute this plan\n/gitnexus-work # newest docs/plans/*gitnexus-plan*.md here\n/gitnexus-work # direct mode, see Input triage\n```\n\n## Input triage\n\n- **Plan path** (or blank → the newest `docs/plans/*gitnexus-plan*.md` under\n the current repo root): the normal mode; continue to Phase 1. Schema-2\n plans have a normalized repo-relative\n `docs/plans/YYYY-MM-DD-gitnexus-plan-<3-5-word-slug>.md`\n `generated_plan_path`. Resolve only a lexical candidate, then invoke\n `scripts/evidence-provenance.mjs read-plan --repo --generated-plan\n` and load only the exact bytes in its descriptor-anchored\n receipt. Require the receipt's canonical repo-relative path to equal the\n document's `generated_plan_path` byte-for-byte;\n reject an external, escaping, differently scoped, or mismatched value. A\n plan in another target repo may still be passed by explicit path. If Phase 1's\n pre-completed check finds every §7 step of the newest plan already landed,\n stop and ask instead of re-executing it.\n- **Bare task text**: trivial and bounded (1–2 files, no architectural\n decisions) → implement directly with the same discipline: `impact` before\n every symbol edit, minimal change, tests when behavior changes,\n verification commands taken from the repo's own scripts (package.json /\n CI), `detect_changes` before every commit, and the shared\n Build-current/index-current procedure before graph-dependent impact and\n final verification. Anything larger → recommend running\n `/gitnexus-plan` first; honor the user's choice if they decline.\n\n## Phase 1 — Load and re-anchor the plan\n\n1. Resolve the target repo and normalized plan candidate, then invoke this\n skill's descriptor-anchored `scripts/evidence-provenance.mjs read-plan`\n command exactly as\n specified in `references/evidence-provenance.md`. Reject a missing,\n external, escaping, symlinked, or differently scoped path. Decode and read\n the receipt's exact `plan_bytes_base64` completely; never read or reopen the\n lexical path directly. It is a decision artifact, not a script: scope\n boundaries and `avoid` entries bind you; exact code is yours to write.\n Retain the receipt's canonical `generated_plan_path` and `plan_digest` in\n session state. Never edit the plan body.\n2. Parse the §11 `implementation_context` pack: `acceptance_criteria`,\n `evidence_provenance`, `primary_symbols`, `related_symbols`,\n `files_to_modify`, `execution_path`, `pdg_constraints`,\n `architectural_patterns`, `tests`, `verification_commands`, `risks`,\n `assumptions`, `open_questions`, `avoid`. Compact plans carry the\n mini-pack subset — absent optional fields are empty, not errors.\n `evidence_provenance` is mandatory: absence or schema 1 means a legacy\n plan, not a clean tree. Before relying on it, require exact byte-for-byte\n equality between the read-plan receipt's canonical `generated_plan_path`\n and `evidence_provenance.generated_plan_path`.\n3. **Two-layer drift check — always recompute.** Even when current HEAD is the\n same HEAD as the plan pin, recompute both the canonical global dirty digest\n and the sorted cited-path manifest. Read\n `references/evidence-provenance.md`, then invoke this skill's\n `scripts/evidence-provenance.mjs` with the plan's exact\n `generated_plan_path`, every cited manifest path, and schema version 2.\n Never recreate its bytes in shell or prose. Schema 1 cannot be recomputed\n unambiguously and requires conservative re-anchoring. Include\n object kind plus HEAD/index/worktree/untracked layer digests, and classify\n `staged`, `unstaged`, `untracked`, `deleted`, `renamed`, `mixed`,\n and `absent` evidence. Honor the generated-plan exclusion exactly; do not\n exclude all plans.\n4. **Re-anchor on either mismatch.** Missing or legacy provenance, a HEAD\n mismatch, or a global dirty digest mismatch requires a conservative\n re-anchor before work:\n - Diff every cited-path manifest entry. Changed cited paths — including\n staged-only, unstaged-only, deleted, both rename endpoints, mixed\n staged+unstaged, and disappeared untracked paths — get their cited ranges\n re-read before reliance.\n - Compare the current whole-tree dirty set with the pinned global digest.\n New uncited dirty paths get a scope assessment: determine whether they\n overlap the plan, requirements, tests, or a key technical decision; do not\n silently ignore them merely because they are uncited.\n - Unreadable or unclassifiable cited evidence blocks every dependent step\n until it can be restored, read, or resolved with the user. Never substitute\n an invented digest or treat absence as an empty file.\n - Keep the re-anchor result in session state; never mutate the plan body.\n Use Deepen only if reconciliation invalidates scope, requirements, a key\n technical decision (KTD), or the planned implementation seam. Ordinary\n byte drift that leaves those decisions valid is re-verified locally.\n5. **Re-verify `assumptions` cheaply** (each one names what to check).\n A failed assumption is a stop-and-replan signal for the steps that\n depend on it, not something to code around silently.\n6. Note `open_questions` — if one blocks a step and the answer materially\n changes the work, ask the user before that step, not after.\n7. **Pre-completed check.** If commits for this plan already exist on the\n branch (a prior partial run, or a post-route-back Deepen cycle), verify\n which §7 steps have landed at HEAD: those are skipped and reported as\n pre-completed, and execution resumes at the first unlanded step. All\n steps landed → report that and stop.\n\n## Phase 2 — Environment\n\n- On the default branch → create a feature branch named from the plan slug.\n On a feature branch already → stay only if it is meaningful _for this\n plan_ (name matches the plan slug, or the user confirms); otherwise\n branch from here with the slug name.\n- If the plan document is not yet committed, commit it now\n (`docs(plans): add plan`) — the plan travels with the work it\n drives, and the final review diff then includes it.\n- Confirm the `verification_commands` from the pack actually run in this\n checkout (dependencies installed, builds present) before starting, not\n after the last step.\n\n### Build-current/index-current procedure\n\nThis is the single graph-freshness procedure owned by `gitnexus-work`; it\napplies in plan mode and direct mode. Before every graph-dependent `impact`\nquery, run the Build-current/index-current procedure. Before final graph\nverification, run the same Build-current/index-current procedure again.\n\n1. Capture current HEAD and working-tree provenance. Read\n `gitnexus://repo//context` and use its typed `index.commit` and\n `index.runner_identity` receipt — never infer analyzer identity from prose,\n timestamps, or a path alone. Compare `index.commit` with current HEAD. A\n current receipt has `schemaVersion: 4`, resolved runtime path/version, CLI\n version, invoked-artifact path/digest, build\n kind/root/canonicalization/digest, and dependency-runtime\n manifest/lockfile/canonicalization/package-count/artifact-count/digest. Its\n dependency canonicalization is\n `gitnexus-analyzer-dependency-runtime-v4`. The dependency-runtime digest\n covers resolved package metadata and complete loadable package payloads,\n including JavaScript, JSON, native, Wasm, and parser artifacts; schema-1,\n schema-2, and schema-3 receipts are legacy/stale (the MCP context labels\n them `runner_identity_schema_status: legacy-or-unknown`). Require MCP\n `index.incomplete_reasons: []`. Run the exact candidate CLI's\n `status --json` command and require `index.runnerIdentityStatus: current`,\n `index.incompleteReasons: []`, and top-level `status: up-to-date`. The\n status comparator checks every semantic field while deliberately excluding\n only diagnostic `invokedArtifact`; a worker-authored persisted receipt and\n the CLI's live receipt may therefore differ in that field without becoming\n stale. Missing, malformed, differently versioned, semantically unequal, or\n incomplete receipts are unknown/stale, not a match.\n2. Relationship-affecting committed and uncommitted edits invalidate\n freshness after the last successful procedure run. This includes staged,\n unstaged, untracked, deleted, or renamed analyzer/source/config changes\n that can alter symbols or edges. Any such edit between steps requires an\n inter-step refresh before the next graph query, even when HEAD did not move.\n3. If the typed runner receipt is stale or unknown in an analyzer-source\n checkout, build current local source using the verified package script. In\n this repo: `cd gitnexus && npm run build`. Resolve the package's `bin`\n target and run that exact artifact's `status --json` command to capture its\n current receipt. Source/build timestamps are a conservative rebuild\n trigger, not proof that an artifact is current.\n4. Invoke that exact freshly built local CLI from the target repo root with\n PDG layers enabled. In this repo:\n `node gitnexus/dist/cli/index.js analyze --index-only --pdg`.\n Add `--force` when the persisted receipt was absent, malformed,\n differently versioned, or unequal so an already-up-to-date fast path cannot\n leave legacy/stale provenance in place. The usual project-runner form,\n `node .gitnexus/run.cjs analyze`, is acceptable only when its proven runner\n identity resolves to that same freshly built artifact. Do not fall back to\n an older project runner, global install, or package download after\n resolving/building the local artifact.\n5. Re-read index context, rerun the exact invoked CLI's `status --json`, and\n prove the post-refresh `index.commit` equals current HEAD, MCP\n `index.incomplete_reasons` is empty, and its complete\n `index.runner_identity` equals status `index.runnerIdentity` (the persisted\n receipt). Require status `index.runnerIdentityStatus: current`, empty\n `index.incompleteReasons`, and top-level `status: up-to-date`; do not require\n raw equality with `current.runnerIdentity` because `invokedArtifact` is a\n diagnostic entrypoint deliberately excluded from semantic freshness.\n Record the dirty-state digest indexed in this procedure so same-HEAD\n uncommitted edits can invalidate it later.\n6. Any build, refresh, metadata-read, or identity-verification failure blocks\n graph-dependent impact work and final completion. Report the failing\n command and evidence; do not continue on an older graph.\n\n## Phase 3 — Execute the Implementation Sequence\n\nWork through plan §7 step by step, in order. For each step:\n\n1. **Fresh impact before editing.** Run the Build-current/index-current\n procedure immediately before every graph-dependent\n `impact {target, direction: \"upstream\"}` query. Then account for every\n direct (d=1) dependent. HIGH or CRITICAL risk → surface it to the user\n with the blast radius before proceeding (repo mandate — see AGENTS.md\n GitNexus rules).\n2. **Honor the constraints.** `pdg_constraints` entries state ordering and\n dependence facts the change must preserve; `avoid` entries are hard\n prohibitions; `architectural_patterns` name the shape to mirror (read the\n example location before inventing one).\n3. **Implement minimally.** The smallest change that completes the step,\n following the surrounding code's conventions.\n4. **Test from the plan's scenarios.** Each `tests[]` scenario (input →\n action → expected outcome) becomes a real test in the named file. Add\n coverage the plan missed if the step's behavior demands it; never delete\n or weaken an assertion to make a step pass. Prove a new regression test\n discriminates: when the failure mode is subtle, run it once against the\n pre-fix tree (write the test before the fix, or stash the fix) and watch\n it fail — a test that passes both ways pins nothing.\n5. **Verify.** Run the step-relevant `verification_commands` (they carry\n their build prerequisites; use them as written). If any part of the\n change executes from build output — worker entrypoints, dist-shipped\n CLIs, bundled assets — rebuild that output before every verification\n run: a pass or fail against outdated build output is noise, and \"the\n fix doesn't work\" is more often \"the fix never loaded\".\n6. **Commit atomically.** `detect_changes {scope: \"staged\"}` before every\n commit to confirm only the expected symbols and flows are affected\n (repo mandate); then one conventional commit per step. Run stage →\n `detect_changes` → commit as one unbroken sequence from the repository\n root — interleaving other work between the gate and the commit is how\n the gate gets skipped. Unexpected\n affected flows → investigate before committing, not after. A result\n flagged `partial` (a graph query failed) or `truncated` (the symbol\n listing was capped) blocks the commit the same way: the gate did not\n see every changed symbol, so re-run it rather than read it as clean.\n\nA relationship-affecting implementation edit or commit invalidates the\nprocedure's prior proof. The next step must perform the required inter-step\nrefresh before its impact query; final verification refreshes again after the\nlast edit.\n\nSteps are independently actionable: after any commit the tree is coherent.\nIf a step reveals the plan is wrong, stop that step, re-verify the affected\nclaims at HEAD, and either adapt (small, in-scope deviation — record it in\nthe commit message and final summary) or route back to `gitnexus-plan`\nDeepen mode (structural miss) — with a one-line ask to the user when the\nchoice isn't obvious.\n\n## Phase 4 — Finish\n\n1. Run the full `verification_commands` suite once, at the end, even if\n every step already passed individually.\n2. Walk plan §13 (Definition of Done) and the pack's `acceptance_criteria`\n item by item; anything unmet is either finished now or reported as\n explicitly unmet — never silently dropped.\n3. **Verify the final knowledge graph.** Before final graph verification, run\n the same Build-current/index-current procedure after the last edit, even\n when no commit landed or HEAD still equals the original pin. Then run\n `detect_changes {scope: \"all\"}` (or the repo's equivalent final graph\n check) against that proven-current index and account for every unexpected\n symbol or flow. A procedure failure blocks completion.\n4. Report: steps completed, commits made, deviations from the plan (with\n why), assumptions that failed re-verification, DoD status, final indexed\n commit and runner identity, and anything deferred. Test failures are\n reported with their output, not smoothed over.\n\n## Never\n\n- Skip the Phase 3 gates: no symbol edit without `impact`, no commit without\n `detect_changes`.\n- Expand scope beyond the plan — §12's deferred follow-ups stay deferred.\n- Mutate the plan body (committing the file verbatim in Phase 2 is not\n mutation), weaken failing tests, or present unverified work as verified.\n\n## Skill feedback (GitNexus repo only)\n\nIf this run exposed friction in this skill's own instructions — wrong or\nmissing guidance, a wasted tool budget, a phase that misrouted — and the repo\ncarries `eval/workflow_bench/`, append one JSON line to\n`eval/workflow_bench/learnings.jsonl` (create the file if absent):\n`{\"skill\": \"gitnexus-work\", \"date\": \"YYYY-MM-DD\", \"task\": \"\", \"friction\": \"\", \"suggestion\": \"\"}`.\nNever edit this skill file itself from a live task: improvements go through\nthe offline candidate loop (`eval/workflow_bench/README.md` § Prompt and\nskill evolution loop), where a candidate must beat the incumbent on the\npaired benchmark before a human merges it.\n\n\n# gitnexus-pdg-query\n\nPath: `.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md`\n\n[View Raw Content on GitHub](https://raw.githubusercontent.com/abhigyanpatwari/GitNexus/HEAD/.claude/skills/gitnexus/gitnexus-pdg-query/SKILL.md)\n\n\n"}