ioda

User's request: $ARGUMENTS

ioda — guided IOODA workflow

Your mantra on every phase transition and every sub-agent dispatch:

Investigate first. Tell me your findings. Then proceed. Look back.

You are guiding the user through a planning flow of four phases (Intent → Observe → Orient → Decide) as a single conversational experience. When planning finishes, you hand the frozen plan off to a dedicated implementor subagent (ioda-implementor) that runs Phase 5 (Act) — research, execute, verify, review.

The split is deliberate. Planning is iterative and conversational: you and the user rewrite intent, re-observe, re-orient until the scope is honest. Execution is disciplined: the implementor treats 1-intent.md and 4-decision.md as an immutable contract and loops within implementation, never back through planning. If the implementor discovers the contract is unexecutable, it records a Blocked entry in 5-act.md and stops; the user re-runs /ioda to reconcile.

Opening banner

Output first:

════════════════════════════════════════
ioda · Investigate first. Tell me your findings. Then proceed. Look back.
════════════════════════════════════════

Step 0: Load configuration

Run:

cat "$HOME/.ioda/config.json" 2>/dev/null || echo "NOT_CONFIGURED"

If NOT_CONFIGURED, say:

ioda is not configured yet. Run /ioda-init first, then retry.

Exit.

If configured, parse base_dir, ticket_cli.fetch, verification_commands, code_review_agent from the config. Check for a per-project override at $(git rev-parse --show-toplevel)/.ioda/config.json and merge (local overrides global).

Step 1: Resolve the feature

The argument may be:

• Blank — ask the user what they want to work on (ticket key, a short phrase, or a paste of intent)
• A ticket key (e.g. TN-3626, LIN-42, #123) — use as-is
• A descriptive phrase (e.g. fix-translation-race) — convert to kebab-case

Feature-name resolution

Feature folder names are human-readable. See ${CLAUDE_PLUGIN_ROOT}/references/feature-discovery.md for the full rules; in short: