plan

name	plan
description	Create implementation plans in two phases: clarify requirements first, then produce a concrete step-by-step plan without writing code. Trigger: explicit.

Produce implementation plans, not implementations. Explore, ask questions, and document a clear path forward, then stop.

How this works

This task has two phases with a hard boundary between them:

1. Clarify: Understand the request fully before planning. Explore the codebase to resolve ambiguity on your own when possible. Only ask questions for things you cannot determine from the code. Do not proceed until the user confirms you have it right.
2. Plan: Explore the codebase further if needed, identify the relevant pieces, and write a step-by-step implementation plan. Then stop.

You must complete Phase 1 before starting Phase 2. You must stop after Phase 2. Do not write code. Do not begin implementing.

Phase 1: Clarify the request

Read the request below. Explore the codebase to answer your own questions when the code can provide clarity. Only ask the user about things you cannot determine from the code itself.

If the request is unambiguous (or becomes clear after exploring the code), summarize your understanding in two to three sentences and ask the user to confirm.

If you must ask questions, keep them minimal, and focus only on decisions that genuinely require user input. Number questions from 1 to n.

Do not guess at requirements. Do not fill gaps with assumptions. But do use the codebase to reduce what you need to ask.

Phase 2: Write the implementation plan

Once the user confirms your understanding, explore the codebase and produce a plan with exactly these sections:

Summary

One paragraph: what is being built and why.

Background

The context a developer would need: relevant existing behavior, constraints, edge cases, and dependencies.

Plan

Numbered steps describing what to change and where. Each step should be concrete enough that a developer could execute it without re-reading the original request. Reference specific files, functions, or patterns when you know them.

Relevant files

A list of files and code sections involved, with a one-line note on each file's role. If you found none, say so.

Writing style

Write the plan as a standalone document, not as a conversation. Use imperative voice ("Add a validation check to...") or neutral third person ("The handler should validate..."). Avoid first person ("I will add..."). The output should be suitable for a GitHub issue or design document without editing.

When you are done

End your response after the plan. Do not offer to implement it. Do not write code unless the user explicitly asks in a follow-up message.