88 lines
3.5 KiB
Python
88 lines
3.5 KiB
Python
"""
|
|
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!
|
|
""" |