본문으로 건너뛰기
cccskills
무료GitHub에 공개

gitnexus-pdg-query

Use GitNexus to inspect which conditions control a statement and how variable values flow within a function. Understand early exits, investigate empty query results, and guide changes to the tool’s control and data dependency queries.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

원문원문 설명 보기

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

설치 방법 보기

이럴 때 유용합니다

  • Check which conditions control a statement
  • Trace a variable within a function
  • Investigate empty pdg_query results
  • Extend control and data dependency queries

포함된 파일(1)

  • SKILL.md4.6 KB

SKILL.md(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

Build and maintain a GitNexus code index, a searchable map of code relationships. Use CLI commands to refresh or remove indexes, check their status, list indexed projects, and generate repository documentation with an LLM.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Create a code index for a new project
  • Refresh the index after code changes
  • Check, remove, or list existing indexes
abhigyanpatwari/GitNexus4.8만2026년 10월 19일 업데이트

Investigate errors and unexpected behavior by finding related code, following function calls, and checking source files. GitNexus helps trace execution paths, while the diagnosis identifies the repository and reports how current its code index is.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Finding where an error originates
  • Investigating an endpoint that returns 500
  • Tracing calls between two functions
abhigyanpatwari/GitNexus4.8만2026년 10월 19일 업데이트

Explore unfamiliar code with GitNexus to understand project structure and execution flows. Find related functions, inspect their callers and callees, and read implementation files to explain how a feature works, with repository and index freshness information.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Understand the structure of an unfamiliar project
  • Trace authentication or payment flows
  • Find a function's callers and callees
abhigyanpatwari/GitNexus4.8만2026년 10월 19일 업데이트

Find the right GitNexus tools and workflows for exploring code relationships. This reference explains available commands, graph queries, and resources, including how to check which branch an answer describes and whether its index is current.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Find a GitNexus tool for a specific task
  • Learn how to query code relationships
  • Check index freshness and branch information
abhigyanpatwari/GitNexus4.8만2026년 10월 19일 업데이트

Assess the impact of code changes with GitNexus by tracing callers, dependencies, and affected execution flows. Check existing changes and report their scope, risk, and uncertainty before editing or committing.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Checking the impact of changing a function
  • Finding code that depends on a target
  • Reviewing affected flows before committing
abhigyanpatwari/GitNexus4.8만2026년 10월 19일 업데이트

Coordinate a development task from planning through implementation and review. Choose whether to proceed after seeing the plan, then receive a report covering commits, verification results, review findings, and any work left unfinished.

한국어 요약은 준비 중입니다. 영어 요약을 표시하고 있습니다.

  • Plan, implement, and review a feature
  • Review a plan before authorizing implementation
  • Start implementation from an existing plan
abhigyanpatwari/GitNexus4.8만2026년 10월 19일 업데이트

abhigyanpatwari의 스킬 모두 보기

이 스킬의 문제 신고