ReidenXerx
UserAn intel layer for AI coding agents that assumes its own rules might be wrong — and keeps the evidence. Authoritative north-stars the agent must cite, a task-core written before compaction eats it, review by an expert in YOUR domain, and an installer that verifies its own claims instead of printing success. Claude Code, Cursor, Zed, Codex.
Categories
Indexed Skills (26)
bearing-enforcement
North-star tool router when GitNexus hooks block Grep/Read/SemanticSearch. Graph + embeddings + cypher reasoning, autonomous refresh when stale, classical fallback when GN fails.
bearing-api-routes
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.
bearing-architecture-review
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".
bearing-cli
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"
bearing-consult
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 risk. Examples: "should I ask about this?", "is this my call or theirs?", "about to change observable behaviour", "this migration is irreversible".
bearing-debugging
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"
bearing-e2e
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".
bearing-exploring
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"
bearing-feature-dev
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".
bearing-guide
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?"
bearing-imaging
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.
bearing-impact-analysis
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?"
bearing-layered-systems
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".
bearing-local
Compressed GitNexus playbook for local/Ollama models in Zed — graph-first with minimal context overhead. Use when running qwen/deepseek/llama via Ollama.
bearing-microscope
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 review this refactor".
bearing-minions
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 conversation context the minion was never in. Examples: "find every place we do X", "which files still use the old API", "trace all callers of these 12 symbols", "audit every route for auth".
bearing-northstars
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.
bearing-performance
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".
bearing-pr-review
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?"
bearing-pr
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.
bearing-refactoring
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"
bearing-scenarios
Scenario playbooks for GitNexus — pre-edit, pre-commit, PR review, bugs, refactors, cross-module changes, presets. Read when starting a structured task.
bearing-security-review
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.
bearing-taskcore
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 keep the lessons", "checkpoint the task before compaction", "recover the task after compaction".
bearing-testing
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".
bearing-workspace
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.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.