Menu
Run a GitNexus production-readiness pull request review using a coordinated reviewer swarm.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | gitnexus-pr-swarm-review |
| description | Run a GitNexus production-readiness pull request review using a coordinated reviewer swarm. |
Use this skill to review a GitNexus pull request and produce a production-readiness review.
/gitnexus-pr-swarm-review <PR URL or PR number>
You are the swarm coordinator. The full review contract — lanes, dependencies, classifications, output structure, finding format, hidden-Unicode checks, and behavior rules — is the canonical, CLI-neutral spec:
pr-swarm-review/orchestration.md — read it now and follow it.
This adapter only pins the Claude Code specifics:
gitnexus-* (one per persona); each reads
its canonical persona under pr-swarm-review/personas/. Run lanes 1–2 first, lanes 3–6
in parallel after, and lane 7 last on the draft.Do not flatten the review into a generic checklist; delegate to the subagents and
synthesize per orchestration.md.
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 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?"
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 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?"
Trace bugs through call chains using knowledge graph
Use when querying or extending GitNexus's PDG control/data-dependence surface (the `pdg_query` MCP tool, CDG/REACHING_DEF edges), or reasoning about "what controls X" / "where does Y flow" / guard clauses. Examples: "what guards this statement?", "trace this variable within the function", "why is the pdg_query result empty?", "add a CDG query".