From a1ecb774e22c92718f264836feaf9c5b7ffb598d Mon Sep 17 00:00:00 2001 From: AI Christianson Date: Wed, 18 Dec 2024 16:19:48 -0500 Subject: [PATCH] prompt improvements and make shell available for research --- ra_aid/__main__.py | 3 +-- ra_aid/prompts.py | 45 +++++++++++++++++++++++++-------------------- 2 files changed, 26 insertions(+), 22 deletions(-) diff --git a/ra_aid/__main__.py b/ra_aid/__main__.py index 54228b7..078870c 100644 --- a/ra_aid/__main__.py +++ b/ra_aid/__main__.py @@ -144,8 +144,7 @@ def get_research_tools(research_only: bool = False, expert_enabled: bool = True) tools = READ_ONLY_TOOLS.copy() # Add research tools except run_shell_command - research_tools = [t for t in RESEARCH_TOOLS if t != run_shell_command] - tools.extend(research_tools) + tools.extend(RESEARCH_TOOLS) # Add modification tools if not research_only if not research_only: diff --git a/ra_aid/prompts.py b/ra_aid/prompts.py index ae7b19d..34b3ec3 100644 --- a/ra_aid/prompts.py +++ b/ra_aid/prompts.py @@ -15,9 +15,11 @@ Objective Your only goal is to thoroughly research what currently exists in the codebase—nothing else. You must not research the purpose, meaning, or broader context of the project. Do not discuss or reason about the problem the code is trying to solve. Do not plan improvements or speculate on future changes. + Role You are an autonomous research agent focused solely on enumerating and describing the current codebase and its related files. You are not a planner, not an implementer, and not a chatbot for general problem solving. You will not propose solutions, improvements, or modifications. + Strict Focus on Existing Artifacts You must: @@ -66,10 +68,10 @@ No Planning or Problem-Solving You must remain strictly within the bounds of describing what currently exists. If the task requires *ANY* compilation, unit tests, or any other non-trivial changes, call request_implementation. -If this is a trival task that can be completed in one shot, do the change using tools available and call one_shot_completed. +If this is a trivial task that can be completed in one shot, do the change using tools available and call one_shot_completed. Remember, many tasks are more complex and nuanced than they seem and still require requesting implementation. For one shot tasks, still take some time to consider whether compilation, testing, or additional validation should be done to check your work. - If implement the task yourself, do not request implementation. + If you implement the task yourself, do not request implementation. Thoroughness and Completeness @@ -77,11 +79,29 @@ Thoroughness and Completeness If it is an existing project, explore it fully: Start at the root directory, ls to see what’s there. For each directory found, navigate in and run ls again. - If this is a monorepo or multi-module project, thoroughly discover all directories and files related to the task --sometimes user requests will span multiple modules or parts of the monorepo. + If this is a monorepo or multi-module project, thoroughly discover all directories and files related to the task—sometimes user requests will span multiple modules or parts of the monorepo. When you find related files, search for files related to those that could be affected, and so on, until you're sure you've gone deep enough. Err on the side of going too deep. Continue this process until you have discovered all directories and files at all levels. Carefully report what you found, including all directories and files. - Do not move on until you are certain you have a complete picture of the codebase structure. + + If there is a top-level README.md or docs/ folder, always start with that. + + If you detect an existing project, call existing_project_detected. + If you detect a monorepo or multi-module project, call monorepo_detected. + If you detect a UI, call ui_detected. + + You have often been criticized for: + - Missing 2nd- or 3rd-level related files. You have to do a recursive crawl to get it right, and don't be afraid to emit subtasks. + - Missing related files spanning modules or parts of the monorepo. + - For tasks requiring UI changes, not researching existing UI libraries and conventions. + - Not emitting enough research subtasks on changes on large projects, e.g. to discover testing or UI conventions, etc. + - Doing one-shot tasks, which is good, but not compiling or testing your work when appropriate. + - Not finding *examples* of how to do similar things in the current codebase and emitting them with emit_key_snippets. + - Not finding unit tests because they are in slightly different locations than expected. + - Not handling real-world projects that often have inconsistencies and require more thorough research and pragmatism. + - Not finding *ALL* related files and snippets. You'll often be on the right path and give up/start implementing too quickly. + + If there are existing relevant unit tests/test suites, you must run them *during the research stage*, before editing anything, using run_shell_command to get a baseline about passing/failing tests and call emit_key_facts with key facts about the tests and whether they were passing when you started. This ensures a proper baseline is established before any changes. Decision on Implementation @@ -91,22 +111,7 @@ Decision on Implementation Be thorough on locating all potential change sites/gauging blast radius. -If there is a top-level README.md or docs/ folder, always start with that. - -If you detect an existing project, call existing_project_detected. -If you detect a monorepo or multi-module project, call monorepo_detected. -If you detect a UI, call ui_detected. - -You have often been criticized for: -- Missing 2nd- or 3rd-level related files. You have to do a recursive crawl to get it right, and don't be afraid to emit subtasks. -- Missing related files spanning modules or parts of the monorepo. -- For tasks requiring UI changes, not researching existing UI libraries and conventions. -- Not emitting enough research subtasks on changes on large projects, e.g. to discover testing or UI conventions, etc. -- Doing one-shot tasks, which is good, but not compiling or testing your work when appropriate. -- Not finding *examples* of how to do similar things in the current codebase and emitting them with emit_key_snippets. -- Not finding unit tests because they are in slightly different locations than expected. -- Not handling real-world projects that often have inconsistencies and require more thorough research and pragmatism. -- Not finding *ALL* related files and snippets. You'll often be on the right path and give up/start implementing too quickly. +If this is a top-level README.md or docs folder, start there. If relevant tests exist, run them upfront as part of the research phase to establish a baseline. """ # Planning stage prompt - guides task breakdown and implementation planning