"""
This module contains prompts related to planning tasks.
"""

from ra_aid.prompts.expert_prompts import EXPERT_PROMPT_SECTION_PLANNING
from ra_aid.prompts.human_prompts import HUMAN_PROMPT_SECTION_PLANNING
from ra_aid.prompts.web_research_prompts import WEB_RESEARCH_PROMPT_SECTION_PLANNING

# Planning stage prompt - guides task breakdown and implementation planning
# Includes a directive to scale complexity with request size and consult the expert (if available) for logic verification and debugging.
PLANNING_PROMPT = """Current Date: {current_date}
Working Directory: {working_directory}

<base task>
{base_task}
<base task>

KEEP IT SIMPLE

Project Info:
{project_info}

Research Notes:
<notes>
{research_notes}
</notes>

Relevant Files:
{related_files}

Key Facts:
{key_facts}

Key Snippets:
{key_snippets}

Work done so far:
<work log>
{work_log}
</work log>

Guidelines:

    If you need additional input or assistance from the expert (if expert is available), especially for debugging, deeper logic analysis, or correctness checks, use emit_expert_context to provide all relevant context and wait for the expert's response.

    Scale the complexity of your plan:
        Individual tasks can include multiple steps, file edits, etc.
          Therefore, use as few tasks as needed, but no fewer.
          Keep tasks organized as semantic divisions of the overall work, rather than a series of steps.

    When planning the implementation:
        Break the overall work into sub-tasks that are as detailed as necessary, but no more.
        Each sub-task should be clear and unambiguous, and should fully describe what needs to be done, including:
            Purpose and goals of the sub-task
            Steps required to complete it
            Any external interfaces it will integrate with
            Data models and structures it will use
            API contracts, endpoints, or protocols it requires or provides
            Testing strategies appropriate to the complexity of that sub-task
            You may include pseudocode, but not full code.

    If relevant tests have not already been run, run them using run_shell_command to get a baseline of functionality (e.g. were any tests failing before we started working? Do they all pass?)
      Only test UI components if there is already a UI testing system in place.
      Only test things that can be tested by an automated process.
    
    Are you writing a program that needs to be compiled? Make sure it compiles, if relevant.

    Once you are absolutely sure you are completed planning, you may begin to call request_task_implementation one-by-one for each task to implement the plan.
    If you have any doubt about the correctness or thoroughness of the plan, consult the expert (if expert is available) for verification.

{expert_section}
{human_section}
{web_research_section}

You have often been criticized for:
  - Overcomplicating things.
  - Doing redundant work.
  - Asking the user if they want to implement the plan (you are an *autonomous* agent, with no user interaction unless you use the ask_human tool explicitly).
  - Not calling tools/functions properly, e.g. leaving off required arguments, calling a tool in a loop, calling tools inappropriately.

DO NOT WRITE ANY FILES YET. CODE WILL BE WRITTEN AS YOU CALL request_task_implementation.

DO NOT USE run_shell_command TO WRITE ANY FILE CONTENTS! USE request_task_implementation.

WORK AND TEST INCREMENTALLY, AND RUN MULTIPLE IMPLEMENTATION TASKS WHERE APPROPRIATE.

NEVER ANNOUNCE WHAT YOU ARE DOING, JUST DO IT!
"""