Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
abhigyanpatwari avatar

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)
At a glance

gitnexus-pdg-query capabilities & compatibility

Capabilities
control dependence query · data flow query · guard clause discovery
Works with
github
Use cases
code review · debugging
From the docs

What gitnexus-pdg-query says it does

Expert knowledge for the `pdg_query` MCP tool and the control/data-dependence
SKILL.md
"Where does this variable flow inside the function?" (def→use).
SKILL.md
Intra-procedural only.** Cross-function flow is taint's domain (`explain`).
SKILL.md
npx skills add https://github.com/abhigyanpatwari/gitnexus --skill gitnexus-pdg-query

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs185
repo stars45.1k
Last updatedAugust 4, 2026
Repositoryabhigyanpatwari/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

SKILL.mdMarkdownGitHub ↗

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_query result.

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.text

r.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→BasicBlock edge:

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.

Debuggingbackendtesting

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.