
Gitnexus Pdg Query
- 185 installs
- 45.1k repo stars
- Updated August 4, 2026
- abhigyanpatwari/gitnexus
gitnexus-pdg-query is a Claude Code skill providing expert knowledge of GitNexus's pdg_query MCP tool for querying control- and data-dependence (CDG / REACHING_DEF) edges in a codebase.
About
This skill is expert reference knowledge for GitNexus's pdg_query MCP tool and the control- and data-dependence edges it reads. It explains the two query modes: 'controls' (control-dependence, CDG) to find which predicate guards a statement, and 'flows' (reaching-definition data dependence) to trace where a variable flows inside a function. A developer uses it when querying or extending GitNexus's program-dependence graph, discovering guard clauses, or debugging an empty or surprising pdg_query result. It documents the opt-in --pdg layers, the anchored-and-bounded query contract, and the corrected guard-clause Cypher.
- Queries GitNexus program-dependence edges (CDG control + REACHING_DEF data flow)
- Answers 'what controls X' and 'where does Y flow' inside a function
- Reference knowledge for the pdg_query MCP tool and guard-clause discovery
Gitnexus Pdg Query by the numbers
- 185 all-time installs (skills.sh)
- Ranked #185 of 596 Debugging skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
gitnexus-pdg-query capabilities & compatibility
- Capabilities
- control dependence query · data flow query · guard clause discovery
- Works with
- github
- Use cases
- code review · debugging
What gitnexus-pdg-query says it does
Expert knowledge for the `pdg_query` MCP tool and the control/data-dependence
"Where does this variable flow inside the function?" (def→use).
Intra-procedural only.** Cross-function flow is taint's domain (`explain`).
npx skills add https://github.com/abhigyanpatwari/gitnexus --skill gitnexus-pdg-queryAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 185 |
|---|---|
| repo stars | ★ 45.1k |
| Last updated | August 4, 2026 |
| Repository | abhigyanpatwari/gitnexus ↗ |
What it does
Query control- and data-dependence edges in GitNexus to find what guards a statement or where a variable flows within a function.
Who is it for?
Reasoning about which predicate guards a statement or where a variable flows within a function, and extending GitNexus's pdg_query read path.
Skip if: Cross-function (interprocedural) data flow, which is handled by GitNexus taint's explain tool, not pdg_query.
When should I use this skill?
Querying or extending GitNexus's PDG surface, discovering guard clauses, or debugging an empty pdg_query result.
What you get
Precise control-dependence and reaching-definition query results anchored to a target function.
By the numbers
- 3 opt-in dependence layers documented (CFG, REACHING_DEF, CDG)
- 2 query modes (controls, flows)
Files
PDG query surface with GitNexus
Expert knowledge for the pdg_query MCP tool and the control/data-dependence edges it reads — the opt-in --pdg program-dependence layers. Read this before touching gitnexus/src/mcp/local/local-backend.ts (_pdgQueryImpl) or the pdg_query tool def, or when explaining a pdg_query result.
When to Use
- "Under what condition does this statement run?" (guarding predicates).
- "Where does this variable flow inside the function?" (def→use).
- Guard-clause discovery (early-return guards — subsumes the #559 heuristic).
- Extending or reviewing
pdg_query/ the CDG / REACHING_DEF read path. - Debugging an empty or surprising
pdg_queryresult.
The layered substrate (build order)
pdg_query runs on the same graph taint runs on. Each layer is opt-in behind --pdg; a default analyze run records none of them (byte-identical).
L1 CFG per-function basic blocks + control-flow edges (M1 #2081)
L2 REACHING_DEF GEN/KILL def→use data dependence (pure solver) (M2 #2082)
L5 CDG Ferrante control dependence (post-dominators) (M5 #2085)All three are BasicBlock → BasicBlock edges in the single CodeRelation table (keyed by the type property). There is no Function → BasicBlock edge.
The two modes
pdg_query({ mode: 'controls', target })— CDG. For the anchored function,
each edge: controlling predicate block → dependent block + branch sense in label ('T' = predicate's true/taken arm, 'F' = false/fall-through). An edge into an early-return/throw block is flagged guard: true.
pdg_query({ mode: 'flows', target, variable? })— REACHING_DEF def→use
edges; variable filters to one binding.
target is required — a file path or a symbol/function name (resolved like context()). There is no anchorless mode (see below).
The corrected guard-clause Cypher
The RFC #567 §2 form ([:CDG {label:'F'}]) does not run as written. Edges are values of the single CodeRelation table's type property, and the branch sense is in reason, NOT a label column:
MATCH (pred:BasicBlock)-[r:CodeRelation {type: 'CDG'}]->(dep:BasicBlock)
WHERE dep.text STARTS WITH 'return' OR dep.text STARTS WITH 'throw'
RETURN pred.startLine, r.reason AS branch, dep.startLine, dep.textr.reason is the sense the predicate took to reach the early exit. For if (!ok) return; the return rides the predicate's true arm ('T') and the protected body rides the false arm ('F') — polarity depends on the guard, so don't hard-code one sense.
Gotchas (the load-bearing ones)
- Always anchored + LIMIT-bounded. LadybugDB has no rel-property index, so
an unanchored [:CDG*]/[:REACHING_DEF*] path scan is unbounded. pdg_query requires target and bounds the page; raw cypher callers must anchor on a file id-prefix or symbol span themselves.
- BasicBlock↔symbol join is reconstructed. No
Function→BasicBlockedge:
the block is matched by its id-prefix (BasicBlock:<file>:<fnStartLine>:…) plus startLine within the symbol's span. BasicBlock startLine is 1-based while the symbol node's startLine/endLine are 0-based, so both bounds are shifted +1 ([symStart+1, symEnd+1]): the upper +1 keeps a guard/def/use on the function's final line, the lower +1 excludes an adjacent function's block on the line directly above. Same-line / nested functions anchor coarsely.
- No PDG layer ⇒ a note, not an error. If the repo wasn't indexed with
--pdg the tool returns { results: [], note: "no PDG layer …" } (cheap meta probe on RepoMeta.pdg.maxCdgEdgesPerFunction / maxReachingDefEdgesPerFunction).
- CDG labels are binary in M5/M6. Every
switch-case arm is'T'; per-case
conditions are not yet distinguished.
- Intra-procedural only. Cross-function flow is taint's domain (
explain).
Mirror, don't fork
_pdgQueryImpl is the front half of _explainImpl (WAL wrapper, meta no-layer probe, limit validation, resolveSymbolCandidates anchoring) with CDG/ REACHING_DEF instead of TAINTED — and none of taint's path-codec / interproc TAINT_PATH machinery. Reuse those shared helpers; do not re-implement them.
Related skills
FAQ
What are the two pdg_query modes?
'controls' returns control-dependence (CDG) edges showing which predicate guards a statement, and 'flows' returns reaching-definition data-dependence edges tracing where a variable flows inside a function.
Does pdg_query work across functions?
No. It is intra-procedural only; cross-function flow is taint's domain via the explain tool.