Odin Planning

Use when asked to judge whether to adopt, switch, reject, or revisit technology, library, pattern, or architecture, or a second opinion. Not for scoping: use brainstorm. Not for forks: use decide.

Use when a user commits to a direction and asks to plan, brief, or research it; modes score, breakdown, shape, visual. Not for codebase audit: use plan-review. Not for four-phase review: use autoplan.

Use when a task is ambiguous or intent needs eliciting: exhaustive/collaborative/adversarial askme, batch questions, interview, ambiguity scan, or intent proposal. Not for one fork: use decide.

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".

Use when asked to park an undecided idea without representing it as decided or active work. Not for decided or active work: use the project task system.

Use when the user says "loop me" or asks to design a recurring workflow. Don't use for remote, credential, publish, deploy, or irreversible changes.

Use when the user runs /autoplan on a plan or idea. Reviews, amends, and derives task IDs with a final human approval gate. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user wants to collapse an open decision field to one decision and record its rationale locally. Not for multi-lens pressure testing. No remote or irreversible changes.

Use when the user asks for a flattened view of roadmaps and next actions. Not for multi-session route planning: use wayfinder.

Use when a message contains `TODO ADD: <requirement>`. Not for deepening coarse lists: use todos-enhance. Not for resyncing lists: use todos-update. Not for retitling/reordering/completing todos.

Use when a durable effort needs an approved, checkable success predicate before work starts. Not for requirement-to-evidence ledgers. Never remote, credential, publish, deploy, or irreversible.

Use when a greenfield project or large feature build will not fit in a single agent session. Don't use for implementation, remote credential changes, or work that fits in one session.

Use when the user begins knowledge work with notes, a transcript, or a brain dump, asks for divergent ideas (mode: ideate), or wants options shown in a local browser (mode: visual).

Use when asked to derive the general rule a request carries as examples instead of a stated rule, then bound it. Not for ambiguity in a stated request: use askme. Read-only.

Use when a settled plan needs implementation tickets published as blocker-linked slices, tracer bullets, or expand-contract sequencing. Not for implementation: use work.

Use when a user wants to define failure states, recovery actions, bypasses, and degraded modes for a component during design. Not for runtime recovery.

Use when a plan path or text is supplied for audit against the current codebase, or when tuning which plan-review questions fire. Not for scoring: use plan.

Use when starting a project or feature, requirements are unclear, or a change crosses modules. Not for implementing from an existing spec: use spec-driven-implementation.

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

Use when the user wants to classify abstractions as useful, bad, or busy and keep one shallow level. Not for tasks requiring source or remote-system changes.

Use when the user asks to park ideas or inspiration for later. Not for code, backlog, or divergence-class cards, or remote, credential, publish, deploy, or irreversible changes.

Use when tasks are too vague, read as headings, or the user asks to sophisticate the todos. Not for stale reconciliation: use todos-update. Not for adding requirements: use todo-add.

Use when defining, revising, or gate-replanning the project structural backbone in project-root graph.yaml. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a design dispute has at least two live interpretations and the caller wants worlds made explicit or a plain-language recommendation. Not for selecting a design or source/remote changes.

Use when a user wants to lock greenfield architecture and interfaces early for coherent parallel execution.

Use when the user wants the finished-system contract for a piece of work: behavior, protocols, allowed, forbidden, and impossible states with a state-space proof. Not for runtime verification.

Use when a project is between phases, the author asks what to do next, too many threads are open, or work needs re-entry. Not for gating whether one named task may proceed.

Use when user wants an async questionnaire, a discovery questionnaire, or a knowledge gap needs answers outside the repo. Not for direct conversation: use askme. Not for agent research: use research.

Use when a user wants to design an abstraction boundary that collapses a complex implementation into a simpler interface without leaking internal state. Not for implementation.

Use when a user wants to enumerate plausible designs, configurations, scenarios, and paths and diagram the field before choosing. Not for remote, credential, publish, deploy, or irreversible changes.

Use when a user wants to rebuild a design, organization, or API from primitives. Not for a perspective take: use from-*-perspective seats.

Use when a user asks for a gut-check on a decision or action, or asks whether enough is known to proceed. Not for numeric confidence scoring.

Use when work has distinct modes and the user wants states, events, guards, outcomes, illegal transitions, not a prose todo list. Not for remote, credential, publish, deploy, or irreversible changes.

Use when the user explicitly requests a Tarot draw or casually delegates an ambiguous choice among multiple valid approaches.

Use when asked to prune a design or codebase until only primitives remain, producing a first-principles map. Not for remote, credential, publish, deploy, or irreversible changes.