execplan-planner

name	execplan-planner
description	Create or update a self-contained ExecPlan Markdown file under `.agent/plans/` by synthesizing the current conversation (and any extra hint) and following `.agent/PLANS.md` exactly. Use when the user asks for plan mode, an execution plan, an ExecPlan, or wants a complex feature/refactor planned with explicit steps, validation, and file-level guidance.

ExecPlan Planner

Overview

Create a high-quality ExecPlan in .agent/plans/ that a novice can execute end-to-end without relying on chat history. Enforce the repository's ExecPlan format, required sections, and naming conventions defined in .agent/PLANS.md.

Workflow

1) Read the source of truth

Open .agent/PLANS.md from the repository root and follow it to the letter. Treat it as the only authoritative definition of ExecPlan structure, sections, formatting, and content requirements.

2) Interpret the inputs

Use the entire conversation as raw requirements and decisions. If the user supplies an extra hint (requirements summary or constraints), treat it as higher priority and layer it on top of the conversation.

If requirements are ambiguous, ask 1-3 short, focused questions before writing the ExecPlan. If the user explicitly requests plan mode without sufficient context, do not draft the plan until key requirements are clarified.

3) Define scope and plan target

State what the ExecPlan will cover and what is out of scope. Assume the plan is for a complex feature or significant refactor whenever the user invokes plan mode.

Choose a short, action-oriented kebab-case filename under .agent/plans/. If a plan already exists for the same goal, update that file instead of creating a new one.

4) Draft the ExecPlan

Write the plan directly into the .md file (no outer triple backticks). Start with a top-level # heading and include every required section from .agent/PLANS.md. Provide real content in each section; never leave placeholders like "TBD" or "TODO".

Make the plan self-contained:

• Define non-obvious terms in plain language.
• Specify exact files and sections to change using repository-relative paths.
• Provide concrete commands with working directory and expected output or behavior.
• Describe observable validation and acceptance criteria.

Write in English by default and keep code, commands, file paths, and API names as-is. Use plain English and beginner-friendly explanations. Prefer short paragraphs and full sentences over dense bullet lists except where checklists are explicitly helpful (for example, Progress or Validation sections).

5) Enforce behavioral constraints

Do not implement code changes as part of this plan workflow. Do not create multiple overlapping plans for the same goal. Do not rely on chat history inside the plan; rewrite all needed context into the plan itself.

6) Respond to the user

After writing or updating the plan file, reply with:

• The plan file path.
• A 2-5 sentence summary of what the plan covers.
• Optional short excerpts of key sections if helpful.

Make it clear the ExecPlan is the source of truth for implementation and should be followed and updated during execution.

Output Checklist

• Read .agent/PLANS.md before drafting.
• Use .agent/plans/<kebab-case>.md and update an existing plan when appropriate.
• Include every required section from .agent/PLANS.md with real content.
• Provide commands, expected outputs, and acceptance criteria.
• Avoid implementing code; plan only.
• Summarize and link to the plan file in the response.