Agent skill
ix-debug
Root cause analysis — trace execution path to a failure, narrow candidates, read minimal source only at suspected failure points.
Install this agent skill to your Project
npx add-skill https://github.com/ix-infrastructure/ix-codex-plugin/tree/main/plugins/ix-memory/skills/ix-debug
SKILL.md
Check command -v ix first. If unavailable, use Grep + Read as fallback.
Goal
Answer: where in the execution path is this likely failing, and why? Stop once you have 1-3 root cause candidates with supporting evidence.
Phase 1 — Locate the entry point (always)
ix locate $ARGUMENTS --limit 5 --format json
If $ARGUMENTS is a symptom description rather than a symbol name, also run:
ix text "$ARGUMENTS" --limit 10 --format json
Identify the most likely entry point (where the failure originates or first manifests).
Phase 2 — Explain (always)
ix explain <entry-point> --format json
Extract: role, callers, callees, confidence. Identify whether this is:
- A boundary (external input, API, event) — failure likely from unexpected input
- An orchestrator — failure likely from wrong sequencing or state
- A utility/helper — failure likely from wrong assumptions by caller
Stop if: the explanation makes the failure source obvious -> skip to Output.
Phase 3 — Trace the execution path
ix trace <entry-point> --downstream --format json
Walk the downstream path. At each step, look for:
- Functions that validate or transform state (potential incorrect assumptions)
- Cross-subsystem calls (where contracts might differ)
- Functions with high callee count (potential god functions, many failure points)
Narrow: Identify the 1-3 nodes most likely to contain the bug.
Stop if: trace reveals an obvious candidate -> proceed to Phase 5.
Phase 4 — Callers (if failure might come from upstream)
ix callers <entry-point> --limit 10 --format json
Check whether the fault is in how this is called rather than in its own logic.
Phase 5 — Targeted code read (only at suspected failure points)
For each root cause candidate (max 2):
ix read <candidate-function> --format json
Read the specific function only. Look for:
- Edge cases in input handling
- Assumptions about state that might be violated
- Missing null/error checks
- Incorrect sequencing
Hard limit: 2 ix read calls maximum. If still ambiguous, surface the candidates and uncertainty to the user.
Output
## Debug: [entry point]
**Execution path:**
[entry-point] -> [step] -> [step] -> [suspected failure point]
**Root cause candidates:**
1. [function/file] — [reason: what assumption might be wrong]
2. [function/file] — [reason]
**Evidence:**
- [what graph data supports each candidate]
- [what code read revealed, if any]
**Confidence:** [high / medium / low] — [why]
**Next steps:**
- Add logging at [specific point] to confirm
- Check [specific edge case] in [function]
- Run `ix-investigate <X>` to understand [unclear component] more deeply
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
ix-architecture
Analyze system design — structure, coupling, code smells, and high-risk hotspots. Purely graph-based, no code reads.
ix-understand
Build a mental model of a system, subsystem, or the whole repo. Graph-first, no code reads unless necessary.
ix-plan
Generate a risk-ordered implementation plan for a set of targets. Assesses blast radius per target, finds data flows between them, and produces a safe change sequence.
ix-investigate
Deep dive into a symbol, feature, or bug. Graph-first, minimal code reads, early stopping when sufficient evidence found.
ix-impact
Change risk analysis — blast radius, affected systems, and what to test. Depth scales with risk level; low-risk targets stop early.
ix-docs
Generate narrative-first, importance-weighted documentation for a repo, system, or subsystem with a selective reference layer. Use --full for deeper module/class/method coverage.
Didn't find tool you were looking for?