odin-planning

Use when a task is ambiguous, maximum clarification is needed before planning, or the user requests exhaustive, collaborative, or adversarial askme mode. Runs Verbalized Sampling, fires batched clarifying questions, and confirms intent before planning proceeds. Not for source or remote-system changes; not for a single fork — use decide.

Use when the user runs /autoplan on a plan or idea. Runs CEO, design, DX, and engineering review phases over the idea, amends the plan, derives deterministic task IDs into a task JSONL ledger, and waits at a final human approval gate. Not for remote, credential, publish, deploy, or irreversible changes.

Use when asked to park an undecided idea without representing it as decided or active work. Creates or updates one reversible local backlog entry with evidence and a readiness threshold. Not for decided or active work — use the project task system.

Use when the user faces multi-fork decisions or unresolved prerequisites. Maps a decision tree and asks its frontier as batched single-select questions until shared understanding is confirmed. Also handles "batch questions". Not for one-at-a-time interviews — use interview-me.

Use when the user begins knowledge work with notes, a transcript, a brain dump, or a problem. Captures original wording, reads prior knowledge, resolves up to three load-bearing questions, and writes a brainstorm file before planning. For divergent option generation, use ideate.

Use when the user says "clarify", "what is ambiguous here", or when a prompt or spec reads as under-specified before planning. Surfaces ambiguities as a certainty-tiered findings report with recommended defaults. Not for exploring intent with questions — use askme.

Use when the user has a fork and wants it resolved and applied, not explored: "decide this", "choose the path", or "decide and fix it". Grounds the fork, frames one single-select with a recommended default, takes the pick, and applies it in the same turn.

Use when asked to derive the general rule a request carries when it arrives as examples instead of a stated rule, then bound that rule. Not for ambiguity resolution inside a stated request — use clarify. Read-only.

Use when a user commits to a direction and asks to plan, brief, research, or operationalize it. Classifies type and tier, researches read-only, and writes to plans/ after acknowledgment. Not for scoring — use planning; not for codebase audit — use plan-review.

Use when a plan path or text is supplied. Audits every item in the plan against the current codebase, including targetless decisions and assumptions, and produces an HTML accuracy verdict page. Not for tuning review questions, use plan-review-tune; not for scoring, use planning.

Use when asked to judge whether this project should adopt, switch to, reject, or revisit a technology, library, pattern, or architecture, or give a mid-session second opinion. Graded verdict clears two evidence floors. Not for scoping, use brainstorm; not for forks, use decide.

Use when the user says "shape this", "pitch this", "gut check the shape", "fix this pitch", or asks whether a result matches the bet. Shapes work into a fat-marker pitch with five ingredients: problem, appetite, solution, rabbit holes, no-gos. Not for tasks requiring source or remote-system changes; not for detailed implementation plans — use plan.

Use when a settled plan needs implementation tickets published as blocker-linked slices, tracer bullets, or expand-contract sequencing, and a human invokes the publication. Publishes GitHub issues or local ticket files and writes their URLs back into the plan. Not for implementation — use work; not for unsupervised publication.

Use when a message contains `TODO ADD: <requirement>`, adding it to the durable source and the native todo in the same turn. Not for deepening coarse task lists — use todos-enhance; not for re-syncing stale lists — use todos-update; not for retitling, reordering, or completing existing todos.

Use when the user says the tasks are too vague or asks to sophisticate the todos, or the list reads as headings rather than executable work. Not for stale-list reconciliation — use todos-update; not for adding requirements — use todo-add.

Use when the user asks to update the todos, resync the task list, or say what to do next, or the plan and the tree have drifted apart. Not for deepening coarse lists — use todos-enhance; not for adding requirements — use todo-add.

Use when a greenfield project or large feature build will not fit in a single agent session. Charts a route by naming the destination, mapping the fog, and graduating decision tickets on the frontier. Don't use for implementation, remote credential changes, or work that fits in one session.