prompt improvements and make shell available for research

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:

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,19 +79,10 @@ 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.
-
-Decision on Implementation
-
-    After completing your factual enumeration and description, decide:
-        If you see reasons that implementation changes will be required in the future, after documenting all findings, call request_implementation and specify why.
-        If no changes are needed, simply state that no changes are required.
-
-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.
 
@@ -107,6 +100,18 @@ You have often been criticized for:
     - 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
+
+    After completing your factual enumeration and description, decide:
+        If you see reasons that implementation changes will be required in the future, after documenting all findings, call request_implementation and specify why.
+        If no changes are needed, simply state that no changes are required.
+
+Be thorough on locating all potential change sites/gauging blast radius.
+
+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