Claude Skills by ReidenXerx

HTTP API route changes. Use api_impact/route_map/shape_check on framework routers (Express/Fastify/Hono/Next); use graph tools on dispatcher symbols when the project has a custom hand-rolled router (no indexed Route nodes). Examples: add endpoint, change route, trace handler + consumers.

Use to JUDGE structure — coupling, cohesion, layering violations, import cycles, god objects. Exploring/imaging help you understand; this produces an assessment with evidence. Examples: \"review the architecture\", \"where's the coupling\", \"are there layering violations\", \"find import cycles / god objects\".

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\"

Decide WHEN to ask the human and when to just decide — so a senior engineer is interrupted for things that actually change the product, and never for boring technical essentials. Use when you notice you are about to INVENT a requirement rather than implement one, when two readings of the request lead to materially different work, or before a ONE-WAY DOOR (deleting data, pushing, publishing, migrating). NOT for questions the repo can answer, not for permission you already have, not to offload ...

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\"

Use when verifying app behaviour in a real browser, or when the user asks for a screenshot of a page/view. Covers writing a verifier in .e2e/, testing a destructive write without performing it, and capturing shots. Examples: \"check the payer editor works\", \"screenshot the dashboard\", \"does this button send the right payload\", \"verify the fix end to end\".

North-star tool router when GitNexus hooks block Grep/Read/SemanticSearch. Graph + embeddings + cypher reasoning, autonomous refresh when stale, classical fallback when GN fails.

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\"

Use when ADDING new code — implement a feature, add an endpoint/handler, wire in a new module. The graph finds existing patterns to reuse and the right place to integrate. Examples: \"add a feature that does X\", \"where do I wire this in\", \"implement X like the existing Y\", \"add a new endpoint\".

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?\"

Graph-first mental models for pipelines, call chains, and cross-module flows. Use when explaining architecture, tracing business flows, mapping functional areas, or answering "how does X connect to Y?" — never reconstruct structure from grep.

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?\"

Use when WORKING IN a complex, multi-layered architecture — trace a request through layers (controller→service→repo→model), change at the right layer, and respect boundaries/contracts between layers. For monoliths, hexagonal/onion, and monorepos with packages. Examples: \"trace this request through the layers\", \"which layer should I change\", \"what crosses this boundary\", \"change the DTO between service and API safely\".

Compressed GitNexus playbook for local/Ollama models in Zed — graph-first with minimal context overhead. Use when running qwen/deepseek/llama via Ollama.

Deep multi-lens audit ('microscope waves') for MILESTONE moments — feature done / big-task checkpoint / shared-code refactor / pre-ship, or when asked to 'audit / find real bugs / is this solid'. NOT for small localized changes. Goes beyond cascade code-review: it opinionates (relevance, soundness, over-engineering) as a senior domain expert, verifies findings adversarially, and iterates in waves. Examples: \"microscope this\", \"audit before we ship\", \"find the real oversights\", \"deep re...

Fan work out to a swarm of cheap, anchored subagents that GATHER — for wide mechanical work you would otherwise grind through serially: finding every call site, auditing N files against one rule, discovering migration sites, cross-referencing a list against the codebase, 'where is this used and how does it flow'. Use when the work is bounded, verifiable, independent and wide (3+ units). NOT when the judgment IS the work, when the answer only survives verbatim, or when the unit needs conversat...

Read, cite, and maintain the project's north-stars — the authoritative numbered fixed points (invariants, exact term meanings, evidence standards, settled decisions, graveyard) that outrank every other doc and stop semantic drift. Use when starting work on a project that has .bearing/northstars.md, when a re-anchor fires, when a doc/code conflicts with a north-star, when proposing or rejecting an idea, or when drafting/updating the north-stars themselves.

Use when optimizing a slow path or reasoning about cost/hot paths. GitNexus reveals call STRUCTURE (depth, fan-in, repeated work) — pair with a real profiler for runtime numbers. Examples: \"this endpoint is slow\", \"find the hot path\", \"why is this expensive\", \"reduce redundant work\".

Use when reviewing a pull request, understanding what a PR changes, assessing merge risk, or checking test coverage gaps. Examples: \"Review this PR\", \"What does PR #42 change?\", \"Is this PR safe to merge?\"

Use when opening a pull request, writing or improving a PR description, or preparing a branch for review. Examples: \"Open a PR for this\", \"Write the PR description\", \"Is this branch ready to review?\". For reviewing SOMEONE ELSE'S PR, use bearing-pr-review instead.

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\"

Scenario playbooks for GitNexus — pre-edit, pre-commit, PR review, bugs, refactors, cross-module changes, presets. Read when starting a structured task.

Use for security-sensitive changes, taint/source-to-sink questions, injection risk, path traversal, XSS, command/code/sql injection, auth/input/file/db/exec reviews.

Maintain a dense, AI-facing TASK-CORE save-state so a long task survives context COMPACTION without drift. Load it when: a PostToolUse nudge says edits have accumulated since the core was last written, at a milestone / before a risky pivot / when the task shifts, OR on recovery after a compaction (read it back first). The core is for the model, not humans — terse, anchors over prose. Examples: \"context is filling — save state\", \"update the task core\", \"clean it from log-like things but k...

Use when deciding WHAT to test or checking coverage. The graph turns blast radius into a precise test target list and surfaces untested symbols. Examples: \"what should I test for this change\", \"is this covered\", \"write tests for X\", \"which flows need tests\".

Master index for __GITNEXUS_REPO__ GitNexus usage in Cursor. Use at the start of any code task — exploration, edits, refactors, PR review, or API changes. Teaches workflow chain, anti-patterns, and which skill to load.