plan-work

Break down an issue or task into concrete implementation steps with file locations, code changes, and acceptance criteria. Use when the user asks to "plan the implementation", "break down this task", "create an implementation plan", or needs a structured plan before coding.

Enter plan mode using the EnterPlanMode tool, then produce a detailed implementation plan for the given issue. Plan mode enforces read-only access during investigation and gives the developer a structured approval flow before any changes are made.

Prioritize long-term correctness, maintainability, and idiomatic solutions over quick fixes.

Investigation Phase

Use Explore agents and read tools to understand the problem. You are read-only in plan mode — use this constraint to investigate thoroughly before committing to an approach.

  • Verify understanding: Confirm the problem statement and root cause
  • Map the implementation surface: Identify files, functions, and data flows involved
  • Study patterns: How does the codebase handle similar cases? Find existing functions and utilities that can be reused.
  • Check runtime behavior: Gather logs, queries, or API responses as needed
  • Note constraints: Performance, compatibility, security requirements

Use AskUserQuestion to clarify requirements or choose between approaches during investigation.

Plan Structure

Write the plan to the plan file provided by plan mode. Structure it as follows:

Context

Why this change is being made: the problem or need, what prompted it, and the intended outcome.

Root Cause Analysis

  • What's happening and why (with evidence)
  • Sequence of events or data flow leading to the issue
  • Key code references: [filename.ext:line](path#Lline)

Solution Design

Address the root cause directly — no workarounds:

  • Follow idiomatic patterns for the language/framework
  • Respect separation of concerns — logic belongs in the appropriate layer
  • Consider idempotency and graceful degradation for distributed systems
  • Flag breaking changes clearly for developer confirmation
  • Reference existing functions and utilities found during investigation, with file paths

Alternatives Considered: Document rejected approaches and why.

Files to Modify

List each file with:

  • Path and line reference
  • Brief description of the change (1-2 sentences)
  • Concise code snippet only if essential

Implementation Steps

Numbered, actionable steps. Keep code examples minimal — show the essential change, not surrounding context.

Each step should be specific enough to execute without re-investigation.

Verification

Automated Testing:

  • Specific test commands to run
  • New test cases needed (describe intent, not full implementations)

Manual/Staging Verification:

  • Steps to validate in a running environment
  • Log queries or monitoring checks
  • Expected behavior vs. previous behavior

Post-Deployment:

  • Deployment sequence if order matters
  • Rollback criteria and procedure
  • Monitoring queries for regressions

Quality Checklist

Before finalizing:

  • Follows idiomatic patterns for the language/framework?
  • Addresses root cause, not just symptoms?
  • Handles concurrent/distributed edge cases?
  • Handles error cases appropriately?
  • Is this the simplest solution that solves the problem?
  • Breaking changes called out for developer confirmation?
  • No injection, auth bypass, or data exposure risks?

Finalize

Once the plan is complete and the quality checklist passes, call ExitPlanMode to present the plan for developer approval. Do not ask about plan approval via text or AskUserQuestionExitPlanMode handles this.

Principles

Prioritize: Long-term correctness > backward compatibility > implementation speed

Avoid:

  • Leaking internal details across layer boundaries
  • Over-engineering (extra config, abstractions, or features not requested)
  • Ignoring existing codebase patterns
  • Large code blocks — summarize or show only the essential diff