plan

name

plan

description

Create a grounded, decision-complete plan, then stop for approval. Use ONLY when the user explicitly asks to plan — when they request a plan, design, approach, rollout/migration strategy, or PR breakdown, or invoke the plan skill (/plan or /skill plan). Do NOT use for ordinary implement, build, fix, debug, or refactor requests — when asked to make a code change, implement it directly without planning first. One rule applies whether or not you read the body: when an explicit plan divides work into separate diffs, commits, or PRs and you are asked to publish, publish that split — never silently collapse the planned units into fewer; tell the user before deviating.

Plan

Create a grounded, decision-complete plan before complex work.

Scope

• Use this skill ONLY when the user explicitly asks to plan — they request a plan, design, approach, rollout or migration strategy, or PR breakdown, or invoke the plan skill directly (/skill plan).
• Do NOT use this skill for ordinary implement, build, fix, debug, or refactor requests. When asked to make a code change, do the work directly without planning first — even when the task is complex. Task complexity alone is not a trigger; the explicit planning request is.
• Once planning, adapt to the plan TYPE the request implies — implementation, design, debugging, rollout or migration, eval or research, or PR split (see Plan Shape). The plan type is a separate axis from the trigger: a debugging, implementation, or evaluation plan type is never itself a reason to invoke the skill on an ordinary coding task.
• Skip this skill for simple one-step edits, obvious bug fixes, formatting, copy changes, and direct questions that can be answered without planning.
• Treat this as planning guidance, not a host-enforced mode. Do not claim that the host is blocking write tools, commands, edits, or approvals for you.
• You may write at most one plan markdown file when durable handoff is useful. Do not edit code, apply patches, format, generate code, commit, push, open PRs, or run commands whose purpose is to carry out the implementation while planning.
• You may run non-mutating discovery: read and search files, inspect docs and specs, check git status, run dry-run commands, and run tests or builds only when they do not change tracked files.