zach
/
RA.Aid
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

prompts + remove oneshot in research

This commit is contained in:
AI Christianson 2025-02-26 22:09:04 -05:00
parent c83815c836
commit c89a92e4f0
2 changed files with 4 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
ra_aid/prompts.py
View File

@ -219,20 +219,17 @@ If uncertain at any stage, consult the expert (if ask_expert is available) for f
If you find this is an empty directory, you can stop research immediately and assume this is a new project. If you find this is an empty directory, you can stop research immediately and assume this is a new project.
You have often been criticized for:
- Needlessly requesting more research tasks, especially for general background knowledge which you already know.
- Not requesting more research tasks when it is truly called for, e.g. to dig deeper into a specific aspect of a monorepo project.
{expert_section} {expert_section}
{human_section} {human_section}
{web_research_section} {web_research_section}
You have often been criticized for: You have often been criticized for:
- Needlessly requesting more research tasks, especially for general background knowledge which you already know.
- Not requesting more research tasks when it is truly called for, e.g. to dig deeper into a specific aspect of a monorepo project.
- Missing 2nd- or 3rd-level related files. You have to do a recursive crawl to get it right, and don't be afraid to request subtasks. - Missing 2nd- or 3rd-level related files. You have to do a recursive crawl to get it right, and don't be afraid to request subtasks.
- Missing related files spanning modules or parts of the monorepo. - Missing related files spanning modules or parts of the monorepo.
- For tasks requiring UI changes, not researching existing UI libraries and conventions. - For tasks requiring UI changes, not researching existing UI libraries and conventions.
- Not requesting enough research subtasks on changes on large projects, e.g. to discover testing or UI conventions, etc. - Not requesting 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 calling emit_key_snippet to report them. - Not finding *examples* of how to do similar things in the current codebase and calling emit_key_snippet to report them.
- Not finding unit tests because they are in slightly different locations than expected. - 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 handling real-world projects that often have inconsistencies and require more thorough research and pragmatism.
@ -260,8 +257,6 @@ When necessary, emit research subtasks.
{research_only_note} {research_only_note}
If there is a top-level README.md or docs/ folder, always start with that.
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. 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.
Objective Objective
@ -277,14 +272,7 @@ Decision on Implementation
If you see reasons that implementation changes will be required in the future, after documenting all findings, call request_implementation and specify why. 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. If no changes are needed, simply state that no changes are required.
If the task requires *ANY* compilation, unit tests, or any other non-trivial changes, call request_implementation. If this is a top-level README.md or docs folder, start there.
If this is a trivial task that can be completed in one shot, do the change using tools available, call one_shot_completed, and immediately exit without saying anything.
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.
Even if it is something as simple as a hello world, snake game, or a simple web app, make sure it runs and compiles/lints etc. Do not hesitate to request implementation if needed.
If you implement the task yourself, do not request implementation.
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.
NEVER ANNOUNCE WHAT YOU ARE DOING, JUST DO IT! NEVER ANNOUNCE WHAT YOU ARE DOING, JUST DO IT!
""" """

2
ra_aid/tool_configs.py
View File

@ -112,8 +112,8 @@ COMMON_TOOLS = get_read_only_tools(use_aider=_config.get("use_aider", False))
EXPERT_TOOLS = [emit_expert_context, ask_expert] EXPERT_TOOLS = [emit_expert_context, ask_expert]
RESEARCH_TOOLS = [ RESEARCH_TOOLS = [
emit_research_notes, emit_research_notes,
one_shot_completed,
# *TEMPORARILY* disabled to improve tool calling perf. # *TEMPORARILY* disabled to improve tool calling perf.
# one_shot_completed,
# monorepo_detected, # monorepo_detected,
# ui_detected, # ui_detected,
] ]