Debug Issue
Trace bugs through a code knowledge graph with minimal-context calls instead of random file grepping when something breaks in production or after a merge.
Overview
debug issue is an agent skill most often used in Operate (errors), also Ship (review) and Build (backend), that systematically traces bugs via graph search, call chains, flows, recent changes, and impact radius.
Install
npx skills add https://github.com/tirth8205/code-review-graph --skill debug-issueWhat is this skill?
- Hard rule: start with get_minimal_context(task=...) before any other graph tool
- Workflow: semantic_search_nodes → query_graph (callers_of/callees_of) → get_flow → detect_changes → get_impact_radius
- Token budget: aim for ≤5 tool calls and ≤800 total output tokens using detail_level=minimal unless escalation is require
- Tips emphasize bidirectional call chains, flow entry points, and recent changes as the top regression signal
- Pairs with code-review-graph MCP-style tools for navigation, not ad-hoc stack reading alone
- Token efficiency target: complete review/debug/refactor tasks in ≤5 tool calls and ≤800 total output tokens
- Mandatory first step: get_minimal_context before other graph tools
Adoption & trust: 680 installs on skills.sh; 18.2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a symptom but no clear entry point—grep and stack traces miss how callers, callees, and recent diffs connect to the failure.
Who is it for?
Solo developers debugging regressions in larger codebases that already expose semantic_search_nodes, query_graph, get_flow, detect_changes, and get_impact_radius.
Skip if: Tiny repos with no graph index, or problems that only need a single failing unit test without structural navigation.
When should I use this skill?
Systematically debug issues using graph-powered code navigation when symptoms need call-chain and change-aware tracing.
What do I get? / Deliverables
You narrow suspects with a bounded graph investigation: related nodes, execution flow, likely regression from detect_changes, and affected dependents from impact radius.
- Traced call chain and flow hypothesis for the bug
- List of recent changes and impacted files from graph tools
- Bounded debug narrative within the ≤5-call token budget
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Systematic issue debugging is shelved under Operate/errors because it targets live failures, regressions, and blast-radius containment—not greenfield feature work. Graph-backed caller/callee tracing, flow reconstruction, and impact radius fit incident response and defect isolation in running systems.
Where it fits
Production alert fires; agent pulls minimal context, traces callees from the suspected API handler, and checks recent diffs on that subgraph.
Post-merge flake appears; detect_changes highlights touched files and get_impact_radius lists downstream packages to retest.
New integration misbehaves; semantic_search_nodes locates related modules before you patch the wrong layer.
After a hotfix, get_flow confirms the execution path from entrypoint to the failing branch without re-reading the whole service.
How it compares
Prefer this graph workflow over unstructured multi-file reads when you need caller/callee and change-aware tracing with a strict token budget.
Common Questions / FAQ
Who is debug issue for?
Indie and solo builders using code-review-graph style tooling who want agents to debug methodically instead of opening random files.
When should I use debug issue?
In Operate/errors for production defects; in Ship/review after merges; in Build/backend when integrating features and tracing unexpected behavior through call graphs.
Is debug issue safe to install?
It drives read-oriented graph tools in your workspace—confirm scope in the Security Audits panel on this Prism page before granting repository or CI access.
SKILL.md
READMESKILL.md - Debug Issue
## Debug Issue Use the knowledge graph to systematically trace and debug issues. ### Steps 1. Use `semantic_search_nodes` to find code related to the issue. 2. Use `query_graph` with `callers_of` and `callees_of` to trace call chains. 3. Use `get_flow` to see full execution paths through suspected areas. 4. Run `detect_changes` to check if recent changes caused the issue. 5. Use `get_impact_radius` on suspected files to see what else is affected. ### Tips - Check both callers and callees to understand the full context. - Look at affected flows to find the entry point that triggers the bug. - Recent changes are the most common source of new issues. ## Token Efficiency Rules - ALWAYS start with `get_minimal_context(task="<your task>")` before any other graph tool. - Use `detail_level="minimal"` on all calls. Only escalate to "standard" when minimal is insufficient. - Target: complete any review/debug/refactor task in ≤5 tool calls and ≤800 total output tokens.