ix-debug

Trace execution paths from failure symptoms to root-cause candidates.

7|2|Updated Mar 28, 2026
One-click install
npx skills add https://github.com/ix-infrastructure/ix-claude-plugin --skill ix-debug
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ix-debug
Source: https://github.com/ix-infrastructure/ix-claude-plugin/tree/main/skills/ix-debug
Command: npx skills add https://github.com/ix-infrastructure/ix-claude-plugin --skill ix-debug

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

ix-debug helps you pinpoint where a failure most likely originates in an execution path and identify a small set of actionable root-cause candidates with minimal source reading.

Core Features & Use Cases

  • Execution-path root-cause analysis: Locates likely entry points from a symptom and explains roles, callers/callees, and failure positioning with graph queries.
  • Targeted tracing with adaptive depth: Traces downstream from the entry point to narrow the 1–3 most suspicious nodes, and optionally checks callers when upstream invocation is likely.
  • Minimal-code reading with guardrails: Reads at most two candidate functions for confirmation, preserving performance and token efficiency.

Use Case: You have an error log for a failing function or behavior in a codebase; ix-debug narrows the likely faulty boundary/orchestrator/utility contract and outputs 1–3 candidates with evidence.

Quick Start

Ask for root-cause analysis by running: ix-debug "<error message or symptom description>".

Frequently Asked Questions about ix-debug

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I trace a failure symptom to its root cause in a complex codebase?

Root cause analysis traces an execution path from a failure symptom to the most likely failing entry point and downstream nodes. It uses graph queries to locate and explain roles, callers, and failure positioning with minimal source reading.

What is the best way to debug orchestrator sequencing or state issues without reading the entire source?

Debugging orchestrator sequencing issues is handled by tracing downstream from an entry point to narrow down one to three suspicious nodes. It limits source reads to at most two candidate functions for confirmation, preserving token efficiency.

How do I pinpoint boundary or input problems from an error log?

Pinpointing boundary or input problems starts by providing the error message or symptom description. The system locates likely entry points and identifies actionable root-cause candidates using graph reasoning and targeted tracing.

Can I trace upstream callers when diagnosing a utility or helper assumption violation?

Diagnosing utility or helper assumption violations can optionally check upstream callers when invocation is likely. It traces downstream from the entry point first, then adaptively checks callers to narrow the suspicious nodes.

Does root cause analysis work for medium-complex codebases with multiple failure candidates?

Root cause analysis fits debugging workflows for medium-complex codebases by narrowing the likely faulty boundary, orchestrator, or utility contract. It outputs one to three candidates with evidence, limiting source reads to suspected failure points.

What are the limitations of using graph queries for failure triage and code inspection?

Failure triage using graph queries limits source reading to at most two candidate functions for confirmation. It is designed for medium-complex codebases and focuses on boundary, orchestrator, and utility failures rather than widespread architectural issues.