Planner

Planner

Use this skill only when the user explicitly requests this skill or explicitly asks for a plan-first workflow. The goal is to prevent premature implementation, make assumptions visible, and give the user a concrete plan they can review, revise, or approve.

When To Use

Use this skill only when the user explicitly names this skill or clearly asks for a plan-first workflow for:

• a feature addition or behavior change
• a bug fix or regression fix
• implementation work that may touch code, tests, docs, build scripts, or runtime configuration
• a plan-first workflow, working document, or approval step before changes

Do not infer this skill from ordinary software change requests. Do not use it for read-only explanations, simple command output, pure code review, implementation requests without an explicit planning step, or explicitly scoped verification-only work unless the user asks for a plan.

Core Rule

Do not edit production code before the user approves the plan.

During the planning phase, inspect files, read specifications, trace the current implementation, and run non-mutating commands as needed. If a browser, desktop app, external service, or other side-effectful tool is needed to confirm behavior, explain why it is needed and ask the user before using it.

If the user explicitly overrides part of this workflow, follow the user's latest instruction. For example, if the user says not to commit, do not commit even if this skill normally includes commit steps.

Planning Workflow

1. Inspect the current system.

   • Read the relevant code paths, tests, specs, README files, and project instructions.
   • Identify the current contract before proposing changes.
   • For bugs, find the likely cause before proposing a fix.

2. Write an implementation plan.

   • Save the plan as a Markdown file under docs/plans/.
   • If the project already uses another working-docs directory, use that directory's plans/ subdirectory.
   • Name the file yyyy-mm-dd-{plan-name}.md.
   • Write the plan in the user's preferred language.

3. Validate the plan with a subagent.

   • Spawn a subagent after writing the plan and ask it to independently review the plan's validity.
   • Revise the plan when the review identifies an issue.
   • If the plan changes, spawn a new subagent and repeat the review until no further revision is needed.