ix-infrastructure/ix-codex-plugin/ix-plan

Check command -v ix first. If unavailable, use Grep + Read to manually assess blast radius per target.

Goal

Answer: in what order should these changes be made, what will break, and what needs testing?

Phase 1 — Scope (always)

If $ARGUMENTS contains symbol names, proceed. If $ARGUMENTS is a description (no identifiable symbols), first run:

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

Identify the 1-4 most relevant symbols and treat those as targets.

Phase 2 — Impact per target (parallel)

For each identified target, run simultaneously:

ix impact  <target> --format llm
ix callers <target> --limit 10 --format llm

Rank targets by risk level: critical > high > medium > low.

Text-fallback confidence rule: If ix callers or ix depends for any target returns a text fallback (i.e. results are not graph-backed — no symbol IDs, only prose or filename strings), that target's impact assessment must be marked lower confidence in the Output with the reason explicitly stated (e.g. "ix callers fell back to text — graph coverage partial for this target").

Fast path — all low risk: If every target is low risk AND has < 3 dependents, skip Phases 3 and 4. Go directly to Output with verdict "SAFE — all targets low risk; no data-flow or shared-dependent analysis needed."

Phase 3 — Data flow (only if 2+ targets AND at least one is medium/high/critical)

Find how the targets connect:

ix trace <highest-risk-target> --to <second-target> --format llm

Run for the most architecturally significant pair. Skip if targets are in independent subsystems.

Phase 4 — Shared dependents (only if high/critical targets exist; skip if all low risk)

ix depends <highest-risk-target> --depth 2 --format llm

Identify if any third symbol depends on multiple targets (shared blast radius — highest testing priority).

Shared-blast-radius qualification rule: Any claim that "no shared downstream symbol was found across these targets" (or equivalent) must explicitly state which target pairs were actually checked with ix depends and which were not. If ix depends was run for only one target, the claim is only valid for that target's dependents. Never generalize across all targets unless every pair was verified.

Phase 5 — Ix Pro plan (if ix pro available)

Do not probe for Pro separately — run the command this phase needs and read the result. Pro commands are always registered: when @ix/pro is absent the CLI installs a stub that exits 1 with The 'plans' command requires Ix Pro., so that message is the definitive "OSS-only, skip this phase" signal, and it costs nothing beyond the call you were making anyway. Do not probe with --help (commander handles it before the stub's action runs, so it succeeds either way and tells you nothing), and do not gate on a field in the JSON — revision is present on every Pro briefing and is often null.

You must run:

ix plans --format json

Use the output to qualify change ordering — existing plans may already cover some targets or establish priority constraints. If active plans are present and this step is skipped, the plan output is incomplete.

Skip this phase only if ix pro is confirmed unavailable.

Output

# Change Plan
 
## Targets & Risk
 
| Target | Risk | Dependents | Key Callers |
|--------|------|------------|-------------|
| <A>    | high | 12         | X, Y, Z     |
| <B>    | low  | 2          | P           |
 
## Change Order
 
Edit in this sequence to minimize breakage:
1. [target] — [reason: lowest risk / most-depended-upon first]
2. ...
 
## Data Flow
[A -> trace path -> B — or "targets are independent"]
 
## Shared Risk
[Symbols affected by changes to multiple targets — these need testing after every change]
 
## Test Checkpoints
After [target A]: verify [specific callers]
After [target B]: verify [specific callers]
 
## Red Flags
- [any critical/high target needing extra care]
- [any cross-subsystem boundary being crossed]

Do not read source code in this skill unless a target cannot be resolved by ix locate.