Complex plan

Create a new plan file in the .complex_plans directory.

CRITICAL PROTOCOL FOR COMPLEX TASKS:

• YOU MUST automatically generate a plan for ANY complex task (multi-file edits, significant changes)
• MUST reason internally (use sequential_thinking tool if available) first to analyze the task
• MUST create markdown plan in .complex_plans/{plan-name}.md
• MUST open plan in editor for user review using open_in_editor tool
• MUST terminate the conversation and await explicit user approval before implementing (the user must prompt something like "ok, proceed", "let's implement it" or similar)
• MUST re-read plan from disk before implementation (the user might have changed it, with more details)
• MUST follow the plan exactly as written

PLAN STRUCTURE:

# Plan: [Task Name]
## Goal
[2-3 line summary of what will be accomplished]
## Current status
[Short summary of the current status of the project, regarding the user request]
## General plan
[Use this section to describe the plan and strategy in details, format the plan nicely using titles, list and tables]
## Steps
1. [Specific Action] -> [Specific File or Project section]
2. [Specific Action] -> [Specific File or Project section]
## Risks/Doubts
- [Questions for user]
## Verification
- [Test commands]
- [Verification steps]
# Additional user provided details

CRITICAL RULES:

• ALWAYS create plans for complex tasks
• ALWAYS read plans from disk at every iteration
• ALWAYS get explicit user approval before implementing
• ALWAYS re-read the plan from disk before implementation
• NEVER proceed without a plan for complex tasks
• NEVER assume the plan hasn't changed
• Leave the Additional user provided details section empty when generating a plan, it's reserved for the user review
• If no question or doubts are present write "No other details needed" in the Risks/Doubts section
• Write as manny steps you think are necessary
• ALWAYS consider details in the Additional user provided details section provided by the user, when implementing the plan

WHEN TO USE:

• Multi-file refactoring operations
• Large-scale feature implementations
• Complex bug fixes requiring multiple changes
• Architectural changes
• Any task requiring user approval or careful planning
• When the user explicity requires a plan to be written

TOOL INTEGRATION:

• sequential_thinking (if available): Use before plan creation for analysis
• ask_user_question: To ask user specif question before finalizing the plan
• open_in_editor: Use to show plans to users for review
• read_plan: Use to re-read plans before implementation, update or review
• delete_plan: Called automatically if auto_delete_plans enabled
• todo: Use for implementation task tracking

EXECUTION PROCESS:

• User ask for a complex task or to generate a plan
• You MUST research and think about the request use tools like readPlan (for plans), grep, web_search, ls and, if available, sequential_thinking.
• You MUST call create_plan to create a markdown plan
• You can call additional readonly tools like readPlan (for plans), grep, web_search or ls before finalizng the plan.
• You CAN call update_plan if you need to make changes to the plan, add details or modify it.
• You MUST terminate the conversation and ask the user to review the plan when finalized.
• The user could supply additional information and/or ask question, call the update_plan to update the plan with new information provided by the user.
• Only when the user prompt something like "ok, proceed", "let's implement it" or similar, you can proceed with the implementation of the plan or installing any dependency
• Then use the todo task and genate a clear step-by-step list of task
• Then implement the changes
• Then run the verifications steps

IMPORTANT: After creating a plan, you MUST call the open_in_editor tool to show the plan to the user. The process MUST be interrupted at this point, and you MUST return control to the user. You MUST NOT proceed with any other actions until the user has explicitly confirmed the plan. Ask the user to review the plan and provide explicit confirmation before proceeding with any other actions. Always use readPlan tool to re-read the plan from disk to ensure you have the latest content before implementing it.

Delete a plan file from the .complex_plans directory. Use this tool when a plan has been completed and is no longer needed, when you want to clean up old or obsolete plans, or when you need to remove sensitive information from plans. This operation cannot be undone. This tool is safeguarded to only delete PLAN files. DO NOT USE THIS TOOL FOR NORMAL PROJECT FILES.

Lists all available plans in the current project. Returns an array of plan names that can be used with other plan tools. Useful for when a user ask to update or search for a plan. Always use this tool when the user ask to update plan.

Open a file in the configured editor for the user to review, terminate the conversation after calling this tool by simply reporting Please review the plan. Open the plan after editing it, not before.

Read the content of an existing plan file from the .complex_plans directory. Use this tool INSTEAD OF read_file to retrieve plan details before updates, reviews, or implementation. Use this tool not the standard read_file to read a plan. ONLY USE THIS TOOL FOR READING PLANS, NOT FOR NORMAL PROJECT FILES AWLAYS use this tool before implementing the plan when the user give you permission to procced.

When to use:

• Retrieving plan content for review or updates
• Preparing for plan implementation
• Verifying plan details before making changes
• When the user explicitly asks to read a plan
• ANY TIME you need to read a plan file (use this instead of read_file)

IMPORTANT:

• Always verify the plan exists first using listPlans
• Read the plan content carefully before implementation
• The ready_to_implement flag should only be used when actually starting implementation
• Never set ready_to_implement to true during plan review or editing phases

Update an existing plan file in the .complex_plans directory using SEARCH/REPLACE blocks. This tool allows partial edits without rewriting the entire plan. Use this tool when the user want to add details, review the plan, or one explcity ask to update a plan. Do not create a new plan when user ask to update plan. Never create a plan for planning the update of a plan. Always prefer to specify multiple changes in a single tool call over calling the tool multiple times. Do not ask confirmation before editing the plan, unless the user request is unclear. Do not open the plan for the user to review before editing the plan, unless the user request is unclear. After editing a plan (when all edits are done) open the plan for review with the openInEditor tool. Awlays think with the sequentialThinking tool befor updating the plan. ONLY USE THIS TOOL FOR EDITING PLANS, NOT FOR NORMAL PROJECT FILES.

The content format is:

<<<<<<< SEARCH
[exact text to find in the file]
=======
[exact text to replace it with]
>>>>>>> REPLACE

You can include multiple SEARCH/REPLACE blocks to make multiple changes to the same file:

<<<<<<< SEARCH
[exact text to find in the file]
=======
[exact text to replace it with]
>>>>>>> REPLACE

<<<<<<< SEARCH
[exact text to find in the file]
=======
[exact text to replace it with]
>>>>>>> REPLACE

IMPORTANT:

• The SEARCH text must match EXACTLY (including whitespace, indentation, and line endings)
• The SEARCH text must appear exactly once in the file - if it appears multiple times, the tool will error
• Use at exaclty 7 equals signs (=======) between SEARCH and REPLACE sections
• The tool will provide detailed error messages showing context if search text is not found
• Each search/replace block is applied in order, so later blocks see the results of earlier ones
• Be careful with escape sequences in string literals - use \n NOT \\n for newlines in code