ix-debug

ix-claude-plugin shared model

Check command -v ix first. If unavailable, use Grep + Read as fallback.

Argument parsing

Strip --save and any following path token from $ARGUMENTS before resolving the entry point.

• If --save <path> is present, set SAVE_PATH to that path.
• If --save is present without a path, auto-generate ix-debug-<target-slug>.md in cwd (target slug = the first symbol or first three words of the symptom with spaces and slashes replaced by -).
• If --save is absent, SAVE_PATH is empty — do not write a file.

Pro check (optional)

Run once at the start:

ix briefing --format json 2>&1

If it returns JSON with a revision field, Pro is available. Extract openBugs and recentDecisions for use in Pro steps below. If it errors, skip all [Pro] labeled steps.

[Pro] If openBugs is non-empty, scan for a known bug matching this symptom before proceeding. If found, surface it immediately — an existing bug record may already have candidates or a fix. [Pro] If recentDecisions is non-empty, scan for recent decisions or context that might explain the symptom or constrain the likely fix. Surface any relevant match before continuing.

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 --format llm

If $ARGUMENTS is a symptom description rather than a symbol name, also run:

ix text "$ARGUMENTS" --limit 10 --format llm

Identify the most likely entry point (where the failure originates or first manifests).

Phase 2 — Explain (always)

ix explain <entry-point> --format llm

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