odin-planning

Plugin odin-planning from marketplace odin-marketplace in OutlineDriven/odin-claude-plugin. Commands read from the repo's manifest — 1 month ago.

Skills (36)

• abstract-well

  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.

• askme

  Use when eliciting intent/scope/referents or gating long/bundled/high-stakes/hard-to-undo work: exhaustive/collaborative/adversarial/gate/batch/interview/scan/proposal. Not for one fork: use decide.

• autoplan

  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.

• backlog

  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.

• brainstorm

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

• converge

  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.

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

• define-goalstate

  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.

• diverge

  Use when the user wants to expand a decision field with additional options and dimensions. Not for selecting or applying an option: use decide. No source or remote-system changes.

• entropy-assisted-planning

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

• fail-design

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

• from-first-principle

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

• generalize

  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.

• goal-init

  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.

• graph-backbone

  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.

• idea-sparkbox

  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.

• leave-only-first-principle

  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.

• loop-me

  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.

• minimap

  Use when the user needs a compact read-only current-work view from Git state, recorded test evidence, and optional graph.yaml. Not for tasks that need source or remote-system changes.

• next-best-action

  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.

• plan

  Use when a user commits to a direction and asks to plan, brief, research, or operationalize it; or wants to enumerate designs, configurations, scenarios, and paths, audit a supplied plan, tune the review flow, or a plan-mode enforcement hook intercepts a plan review, or lock a greenfield architectur

• possible-worlds

  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.

• pov

  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.

• readiness-assessment

  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.

• show-way

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

• solidate

  Use when the user wants to harden a chosen but tentative artifact into one durable result. Not for remote, credential, publish, deploy, or irreversible changes.

• spec-driven

  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.

• state-machine-workflow

  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.

• tasty-abstraction

  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.

• to-questionnaire

  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.

• to-spec

  Use when settled conversation decisions need synthesis into an agent-ready implementation spec, stopping before publication. Not for turning plans into tickets: use to-tickets.

• to-tickets

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

• todo-add

  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.

• todos-enhance

  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.

• todos-update

  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.

• wayfinder

  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.

Similar plugins