Variet/guitar_score
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

wip: [01-stabilize] paused at task 1/1 - OCR Hallucination Immune logic via Semantic delta window and fret-isolation

Browse Source
This commit is contained in:
authentik Default Admin
2026-03-29 22:08:40 +09:00
parent aca7bf592a
commit 2507de45d3
4289 changed files with 732689 additions and 28672 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
.agent/vendor/mini-swe/config/README.md vendored Normal file
View File

@@ -0,0 +1,15 @@
* Default config: `anthropic_filemap.yaml`
* `swebench_submissions`: Configs that were used for swebench submissions
* `sweagent_0_7`: Configs from SWE-agent 0.7, similar to the one used in the paper
* `exotic`: Various specific configurations that might be more of niche interest
* `human`: Demo/debug configs that have the human type commands and run without a LM
* `demo`: Configs for demonstrations/talks
* Configs for running with SWE-smith are at https://github.com/SWE-bench/SWE-smith/blob/main/agent/swesmith_infer.yaml
🔗 Tutorial on [adding custom tools](https://swe-agent.com/latest/usage/adding_custom_tools/)
🔗 For more information on config files, visit [our documentation website][docs].
You can also find the corresponding markdown files in the [`docs/` folder][source].
[docs]: https://swe-agent.com/latest/config/config
[source]: https://github.com/SWE-agent/SWE-agent/tree/main/docs

222
.agent/vendor/mini-swe/config/bash_only.yaml vendored Normal file
View File

@@ -0,0 +1,222 @@
# This config is a super basic, stripped down config that should be compatible with any instruction following LM
agent:
type: default
templates:
system_template: |-
You are a helpful assistant that can interact multiple times with a computer shell to solve programming tasks.
You operate in a REPL (Read-Eval-Print Loop) environment where you must issue exactly ONE command at a time.
Your response must contain exactly ONE bash code block with ONE command (or commands connected with && or ||).
Include a THOUGHT section before your command where you explain your reasoning process.
Format your response as:
THOUGHT: Your reasoning and analysis here
```bash
your_command_here
```
Failure to follow these rules will cause your response to be rejected.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
<pr_description>
I've uploaded a python code repository in the directory {{working_dir}}.
Consider the following PR description:
{{problem_statement}}
</pr_description>
<instructions>
# Task Instructions
## Overview
You're a software engineer interacting continuously with a computer shell in a REPL (Read-Eval-Print Loop) environment.
You'll be helping implement necessary changes to meet requirements in the PR description.
Your task is specifically to make changes to non-test files in the {{working_dir}} directory in order to fix the issue described in the PR description in a way that is general and consistent with the codebase.
IMPORTANT: This is an interactive process where you will think and issue ONE command, see its result, then think and issue your next command.
For each response:
1. Include a THOUGHT section explaining your reasoning and what you're trying to accomplish
2. Provide exactly ONE bash command to execute
## Important Boundaries
- MODIFY: Regular source code files in {{working_dir}}
- DO NOT MODIFY: Tests, configuration files (pyproject.toml, setup.cfg, etc.)
## Recommended Workflow
1. Analyze the codebase by finding and reading relevant files
2. Create a script to reproduce the issue
3. Edit the source code to resolve the issue
4. Verify your fix works by running your script again
5. Test edge cases to ensure your fix is robust
## Command Execution Rules
You are operating in a REPL (Read-Eval-Print Loop) environment where:
1. You write a single command
2. The system executes that command
3. You see the result
4. You write your next command
Each response should include:
1. A **THOUGHT** section where you explain your reasoning and plan
2. A single bash code block with your command
Format your responses like this:
```
THOUGHT: Here I explain my reasoning process, analysis of the current situation,
and what I'm trying to accomplish with the command below.
```bash
your_command_here
```
```
Commands must be specified in a single bash code block:
```bash
your_command_here
```
**CRITICAL REQUIREMENTS:**
- Your response SHOULD include a THOUGHT section explaining your reasoning
- Your response MUST include EXACTLY ONE bash code block
- This bash block MUST contain EXACTLY ONE command (or a set of commands connected with && or ||)
- If you include zero or multiple bash blocks, or no command at all, YOUR RESPONSE WILL FAIL
- Do NOT try to run multiple independent commands in separate blocks in one response
Example of a CORRECT response:
<example_response>
THOUGHT: I need to understand the structure of the repository first. Let me check what files are in the current directory to get a better understanding of the codebase.
```bash
ls -la
```
</example_response>
Example of an INCORRECT response:
<example_response>
THOUGHT: I need to examine the codebase and then look at a specific file. I'll run multiple commands to do this.
```bash
ls -la
```
Now I'll read the file:
```bash
cat file.txt
```
</example_response>
If you need to run multiple commands, either:
1. Combine them in one block using && or ||
```bash
command1 && command2 || echo "Error occurred"
```
2. Wait for the first command to complete, see its output, then issue the next command in your following response.
## Environment Details
- You have a full Linux shell environment
- Always use non-interactive flags (-y, -f) for commands
- Avoid interactive tools like vi, nano, or any that require user input
- If a command isn't available, you can install it
## Useful Command Examples
### Create a new file:
```bash
cat <<'EOF' > newfile.py
import numpy as np
hello = "world"
print(hello)
EOF
```
### Edit files with sed:
```bash
# Replace all occurrences
sed -i 's/old_string/new_string/g' filename.py
# Replace only first occurrence
sed -i 's/old_string/new_string/' filename.py
# Replace first occurrence on line 1
sed -i '1s/old_string/new_string/' filename.py
# Replace all occurrences in lines 1-10
sed -i '1,10s/old_string/new_string/g' filename.py
```
### View file content:
```bash
# View specific lines with numbers
nl -ba filename.py | sed -n '10,20p'
```
### Any other command you want to run
```bash
anything
```
## Submission
When you've completed your changes or can't make further progress:
```bash
submit
```
We'll automatically save your work and have maintainers evaluate it.
</instructions>
next_step_template: |-
<observation>
{{observation}}
</observation>
next_step_no_output_template: |-
<warning>
Your last command ran successfully and did not produce any output.
</warning>
max_observation_length: 10_000
next_step_truncated_observation_template: |-
<warning>
The output of your last command was too long.
Please try a different command that produces less output.
If you're looking at a file you can try use head, tail or sed to view a smaller number of lines selectively.
If you're using grep or find and it produced too much output, you can use a more selective search pattern.
If you really need to see something from the full command's output, you can redirect output to a file and then search in that file.
</warning>
<observation_head>
{{observation[ : max_observation_length // 2]}}
</observation_head>
<elided_chars>
{{elided_chars}} characters elided
</elided_chars>
<observation_tail>
{{observation[- max_observation_length // 2:]}}
</observation_tail>
command_cancelled_timeout_template: |-
<warning>
The command '{{command}}' was cancelled because it took more than {{timeout}} seconds to complete.
It may have been waiting for user input or otherwise blocked.
Please try a different command.
</warning>
tools:
execution_timeout: 60
bundles:
- path: tools/submit
parse_function:
type: single_bash_code_block
model:
per_instance_cost_limit: 3
per_instance_call_limit: 250
total_cost_limit: 1500.0
temperature: 0.0
delay: 0.0
retry:
retries: 6
max_wait: 30

188
.agent/vendor/mini-swe/config/benchmarks/250212_sweagent_heavy_sbl.yaml vendored Normal file
View File

@@ -0,0 +1,188 @@
# Used for our SWE-Bench lite benchmark submission from 12 Feb 2025
# Used together with swe-agent as
# sweagent run-batch --num_workers=12 --instances.type=swe_bench --instances.subset=lite --instances.split=test
# --instances.shuffle=True --instances.evaluate=True --instances.deployment.docker_args=--memory=10g --config config/retry_heavy_v3.yaml
# This template is heavily inspired by anthropic's computer use demo
agent:
type: retry
agent_configs:
# +filemap
- type: default
model: &model
name: claude-3-7-sonnet-latest
api_key: $CLAUDE_API_KEY_ROTATION
per_instance_cost_limit: 1.5
per_instance_call_limit: 75
total_cost_limit: 1000.0
temperature: 0.0
delay: 1.0
templates:
system_template: &system_template |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: &instance_template |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: &next_step_no_diff |-
OBSERVATION:
{{observation}}
next_step_no_output_template: &next_step_no_output_no_diff |-
Your last command ran successfully and did not produce any output.
tools:
execution_timeout: &execution_timeout 300
bundles: &vanilla_bundles
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
- path: tools/diff_state
enable_bash_tool: true
parse_function: &parse_function
type: function_calling
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES: &submit_review_messages
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
history_processors: &vanilla_history_processors
- type: cache_control
last_n_messages: 2
# vanilla anthropic
- type: default
model: *model
templates:
system_template: *system_template
instance_template: *instance_template
next_step_template: *next_step_no_diff
next_step_no_output_template: *next_step_no_output_no_diff
tools:
execution_timeout: *execution_timeout
bundles: *vanilla_bundles
enable_bash_tool: true
parse_function: *parse_function
registry_variables:
SUBMIT_REVIEW_MESSAGES: *submit_review_messages
history_processors: *vanilla_history_processors
# + state
- type: default
model: *model
templates:
system_template: *system_template
instance_template: *instance_template
next_step_template: &next_step_with_diff |-
{% if diff %}
<diff>
Your cumulative changes so far:
{{diff}}
</diff>
{% endif %}
The observation from the last command:
{{observation}}
next_step_no_output_template: &next_step_no_output_with_diff |-
{% if diff %}
<diff>
Your cumulative changes so far:
{{diff}}
</diff>
{% endif %}
Your last command ran successfully and did not produce any output.
tools:
execution_timeout: *execution_timeout
bundles: *vanilla_bundles
enable_bash_tool: true
parse_function: *parse_function
registry_variables:
SUBMIT_REVIEW_MESSAGES: *submit_review_messages
history_processors: &diff_history_processors
- type: remove_regex
keep_last: 2
remove:
- "<diff>.*</diff>"
- type: cache_control
last_n_messages: 2
last_n_messages_offset: 2
retry_loop:
type: chooser
cost_limit: 6.0
max_attempts: 10
min_budget_for_new_attempt: 1.0
chooser:
system_template: |
You are an expert software engineer reviewing code. Your thinking is very thorough, so it is ok if its very long.
instance_template: |
You will be given a problem statement and a list of patch submissions.
Pick the most reasonable patch.
The patch should solve the problem described in the problem statement in a way that is consistent with the rest of the codebase and the conventions of the codebase.
Note: Disregard all testing code in the patch, as testing was already done in a separate step.
Having a test in the patch does not make it any better.
<IMPORTANT>The last line of your response should be the index of the patch you chose.
You must choose a single index no matter what. If you cannot decide between two or more
submissions, choose the first one of these.
</IMPORTANT>
Problem statement:
{{problem_statement}}
Submissions:
{% for submission in submissions %}
Submission {{loop.index0}}:
{{submission}}
{% endfor %}
<IMPORTANT>The last line of your response should be the index of the patch you chose without any other text.</IMPORTANT>
submission_template: |
Patch:
```python
{{submission}}
```
The final edited file with 30 lines of context:
```python
{{edited_files30}}
```
max_len_submission: &chooser_max_len_submission 5000
model: &chooser_model
name: o1
top_p: null
temperature: 1.
per_instance_cost_limit: 30
completion_kwargs:
reasoning_effort: "high"

75
.agent/vendor/mini-swe/config/benchmarks/250225_anthropic_filemap_simple_review.yaml vendored Normal file
View File

@@ -0,0 +1,75 @@
# This template is heavily inspired by anthropic and openhands
# For running on lite:
# sweagent run-batch --num_workers=20 --instances.type=swe_bench --instances.subset=lite --instances.split=test --instances.shuffle=True --instances.evaluate=True --instances.deployment.docker_args='--memory=10g' --config config/250225_anthropic_filemap_simple_review.yaml
# For running on test:
agent:
type: default
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your last command ran successfully and did not produce any output.
tools:
execution_timeout: 300
bundles:
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
- path: tools/diff_state
enable_bash_tool: true
parse_function:
type: function_calling
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
history_processors:
- type: cache_control
last_n_messages: 2
model:
name: claude-3-7-sonnet-20250219
api_key: $CLAUDE_API_KEY_ROTATION
per_instance_cost_limit: 2
per_instance_call_limit: 150
total_cost_limit: 1000.0
temperature: 0.0
delay: 0.0

92
.agent/vendor/mini-swe/config/benchmarks/250522_anthropic_filemap_simple_review.yaml vendored Normal file
View File

@@ -0,0 +1,92 @@
# This template only features minor adaptions from the 250225 config.
# For running on lite:
# sweagent run-batch --config config/benchmarks/250522_anthropic_filemap_simple_review.yaml --num_workers=20
# To fully reproduce, please run from the submissions/250522-sonnet-4-sbv branch
# For running on test:
random_delay_multiplier: 1.0
instances:
type: swe_bench
subset: verified
split: test
shuffle: true
evaluate: true
deployment:
type: docker
docker_args:
- '--memory=10g'
agent:
type: default
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your last command ran successfully and did not produce any output.
tools:
execution_timeout: 300
bundles:
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
- path: tools/diff_state
enable_bash_tool: true
parse_function:
type: function_calling
env_variables:
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
history_processors:
- type: cache_control
last_n_messages: 2
model:
name: claude-sonnet-4-20250514
api_key: $CLAUDE_API_KEY_ROTATION
per_instance_cost_limit: 3
per_instance_call_limit: 150
total_cost_limit: 1000.0
temperature: 0.0
delay: 0.0

93
.agent/vendor/mini-swe/config/benchmarks/250526_anthropic_filemap_simple_review_sbl.yaml vendored Normal file
View File

@@ -0,0 +1,93 @@
# Identical to the 250522 config except for a $5 limit/instance
# For running on lite:
# sweagent run-batch --config config/benchmarks/250526_anthropic_filemap_simple_review_sbl.yaml --num_workers=20
# To fully reproduce, please run from the submissions/250526-sonnet-4-sbl branch
# For running on test:
random_delay_multiplier: 1.0
instances:
type: swe_bench
subset: lite
split: test
shuffle: true
evaluate: true
deployment:
type: docker
docker_args:
- '--memory=10g'
agent:
type: default
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your last command ran successfully and did not produce any output.
tools:
execution_timeout: 300
bundles:
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
- path: tools/diff_state
enable_bash_tool: true
parse_function:
type: function_calling
env_variables:
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
history_processors:
- type: cache_control
last_n_messages: 2
model:
name: claude-sonnet-4-20250514
api_key: $CLAUDE_API_KEY_ROTATION
per_instance_cost_limit: 5
per_instance_call_limit: 0
total_cost_limit: 1000.0
temperature: 0.0
delay: 0.0
completion_kwargs: {'extra_headers': {'anthropic-beta': 'output-128k-2025-02-19'}}

66
.agent/vendor/mini-swe/config/benchmarks/anthropic_filemap_multilingual.yaml vendored Normal file
View File

@@ -0,0 +1,66 @@
# This template is heavily inspired by anthropic, but you can use it with any LM. It is almost
# identical to anthropic_filemap.yaml, but it removes python-specific language
# and adds the multilingual_setup tool to support evaluation on the Multilingual dataset.
agent:
type: default
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
tools:
execution_timeout: 300
bundles:
- path: tools/multilingual_setup
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
- path: tools/diff_state
enable_bash_tool: true
parse_function:
type: function_calling
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
history_processors:
- type: cache_control
last_n_messages: 2

104
.agent/vendor/mini-swe/config/coding_challenge.yaml vendored Normal file
View File

@@ -0,0 +1,104 @@
# This is the template you should use when using SWE-agent to solve a coding challenge (i.e. LeetCode).
# It also shows how to repurpose the agent to do tasks different from software engineering.
agent:
templates:
system_template: |-
SETTING: You are an autonomous programmer, and you're working directly in the command line with a special interface.
The special interface consists of a file editor that shows you {{WINDOW}} lines of a file at a time.
In addition to typical bash commands, you can also use the following commands to help you navigate and edit files.
COMMANDS:
{{command_docs}}
Please note that THE EDIT COMMAND REQUIRES PROPER INDENTATION.
If you'd like to add the line ' print(x)' you must fully write that out, with all those spaces before the code! Indentation is important and code that is not indented correctly will fail and require fixing before it can be run.
RESPONSE FORMAT:
Your shell prompt is formatted as follows:
(Open file: <path>) <cwd> $
You need to format your output using two fields; discussion and command.
Your output should always include _one_ discussion and _one_ command field EXACTLY as in the following example:
DISCUSSION
First I'll start by using ls to see what files are in the current directory. Then maybe we can look at some relevant files to see what they look like.
```
ls -a
```
You should only include a *SINGLE* command in the command section and then wait for a response from the shell before continuing with more discussion and commands. Everything you include in the DISCUSSION section will be saved for future reference.
If you'd like to issue two commands at once, PLEASE DO NOT DO THAT! Please instead first submit just the first command, and then after receiving a response you'll be able to issue the second command.
You're free to use any other bash commands you want (e.g. find, grep, cat, ls, cd) in addition to the special commands listed above.
However, the environment does NOT support interactive session commands (e.g. python, vim), so please do not invoke them.
instance_template: |-
We're currently attempting to solve the following problem:
ISSUE:
{{issue}}
INSTRUCTIONS:
Now, you're going to solve this issue on your own. Your terminal session has started and you're in the repository's root directory. You can use any bash commands or the special interface to help you. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU CAN ONLY ENTER ONE COMMAND AT A TIME. You should always wait for feedback after every command.
When you're satisfied with all of the changes you've made, you can submit your changes to the code base by simply running the submit command.
Note however that you cannot use any interactive session commands (e.g. python, vim) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with `python <script_name>.py`.
NOTE ABOUT THE EDIT COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
IMPORTANT TIPS:
1. Write your solution in main.py. Always test your code thoroughly before submitting, and if any of the tests fail, try to fix the code before continuing.
2. If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it!
3. If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, don't just use the scroll_down command multiple times. Instead, use the goto 583 command. It's much quicker.
4. Always make sure to look at the currently open file and the current working directory (which appears right after the currently open file). The currently open file might be in a different directory than the working directory! Note that some commands, such as 'create', open files, so they might change the current open file.
5. When editing files, it is easy to accidentally specify a wrong line number or to write code with incorrect indentation. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
demonstration_template: |
Here is a demonstration of how to correctly accomplish this task.
It is included to show you how to correctly use the interface.
You do not need to follow exactly what is done in the demonstration.
--- DEMONSTRATION ---
{{demonstration}}
--- END OF DEMONSTRATION ---
demonstrations:
- trajectories/demonstrations/human_thought__swe-bench-HumanEvalFix-python__lcb__t-0.00__p-0.95__c-4.00__install-0/humanevalfix-python-0.traj
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
CURRENT_LINE: 0
CURRENT_FILE: ""
SEARCH_RESULTS: ()
SEARCH_FILES: ()
SEARCH_INDEX: 0
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_replace
- path: tools/submit
parse_function:
type: thought_action
history_processors:
- type: last_n_observations
n: 5

69
.agent/vendor/mini-swe/config/default.yaml vendored Normal file
View File

@@ -0,0 +1,69 @@
# Formerly called: anthropic_filemap.yaml
# This template is heavily inspired by anthropic's computer use demo, but you can use
# it with any LM.
agent:
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
tools:
env_variables:
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: cache_control
last_n_messages: 2

69
.agent/vendor/mini-swe/config/default_backticks.yaml vendored Normal file
View File

@@ -0,0 +1,69 @@
# Formerly called: anthropic_filemap.yaml
# This template is heavily inspired by anthropic's computer use demo, but you can use
# it with any LM.
agent:
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
tools:
env_variables:
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
enable_bash_tool: true
parse_function:
type: thought_action
history_processors:
- type: cache_control
last_n_messages: 2

82
.agent/vendor/mini-swe/config/default_mm_no_images.yaml vendored Normal file
View File

@@ -0,0 +1,82 @@
# Configuration for SWE-agent with image viewing capabilities
# This extends the default config with image parsing history processor
# and the image_tools bundle for viewing images as base64-encoded markdown.
agent:
templates:
# disable_image_processing: false
disable_image_processing: true
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
Note: You can use the view_image command to display images as embedded base64 data when relevant.
If you need to start a command that has long-running output (e.g. a web server), you should _always_ use the following pattern:
server_command &> my_server_log.txt &
This way you can see the server's output in the my_server_log.txt file and it will not block the rest of your work.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
max_observation_length: 10_000_000 # need longer for images
tools:
execution_timeout: 300 # need longer for builds
bundles:
- path: tools/registry
- path: tools/edit_anthropic
# - path: tools/image_tools # lets models view image files
# - path: tools/web_browser # browser tool for interacting with web servers
- path: tools/review_on_submit_m
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
enable_bash_tool: true
parse_function:
type: function_calling
# history_processors:
# - type: image_parsing # parses base64 encoded images in the observation
# - type: cache_control # enable for claude
# last_n_messages: 2 # enable for claude
instances:
type: swe_bench
subset: multimodal
split: dev
shuffle: true
# filter: processing__p5.js-6069

83
.agent/vendor/mini-swe/config/default_mm_with_images.yaml vendored Normal file
View File

@@ -0,0 +1,83 @@
# Configuration for SWE-agent with image viewing capabilities
# This extends the default config with image parsing history processor
# and the image_tools bundle for viewing images as base64-encoded markdown.
agent:
templates:
disable_image_processing: false
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
Note: You can use the view_image command to display images as embedded base64 data when relevant.
You'll also be given access browser tools to interact with the web or a local server.
In the browser, your mouse is shown as a red crosshair.
If you need to start a command that has long-running output (e.g. a web server), you should _always_ use the following pattern:
server_command &> my_server_log.txt &
This way you can see the server's output in the my_server_log.txt file and it will not block the rest of your work.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
max_observation_length: 10_000_000 # need longer for images
tools:
execution_timeout: 300 # need longer for builds
bundles:
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/image_tools # lets models view image files
- path: tools/web_browser # browser tool for interacting with web servers
- path: tools/review_on_submit_m
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: image_parsing # parses base64 encoded images in the observation
# - type: cache_control # enable for claude
# last_n_messages: 2 # enable for claude
instances:
type: swe_bench
subset: multimodal
split: dev
shuffle: true
# filter: processing__p5.js-6069

80
.agent/vendor/mini-swe/config/demo/default.yaml vendored Normal file
View File

@@ -0,0 +1,80 @@
# Formerly called: anthropic_filemap.yaml
# This template is heavily inspired by anthropic's computer use demo, but you can use
# it with any LM.
agent:
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
tools:
env_variables:
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: cache_control
last_n_messages: 2
model:
name: claude-sonnet-4-20250514
env:
repo:
github_url: https://github.com/SWE-agent/test-repo
deployment:
image: tiny
python_standalone_dir: ""
problem_statement:
github_url:
https://github.com/SWE-agent/test-repo/issues/1

69
.agent/vendor/mini-swe/config/demo/no_instructions.yaml vendored Normal file
View File

@@ -0,0 +1,69 @@
# Formerly called: anthropic_filemap.yaml
# This template is heavily inspired by anthropic's computer use demo, but you can use
# it with any LM.
agent:
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
tools:
env_variables:
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/edit_anthropic
- path: tools/review_on_submit_m
registry_variables:
USE_FILEMAP: 'true'
SUBMIT_REVIEW_MESSAGES:
- |
Thank you for your work on this issue. Please carefully follow the steps below to help review your changes.
1. If you made any changes to your code after running the reproduction script, please run the reproduction script again.
If the reproduction script is failing, please revisit your changes and make sure they are correct.
If you have already removed your reproduction script, please ignore this step.
2. Remove your reproduction script (if you haven't done so already).
3. If you have modified any TEST files, please revert them to the state they had before you started fixing the issue.
You can do this with `git checkout -- /path/to/test/file.py`. Use below <diff> to find the files you need to revert.
4. Run the submit command again to confirm.
Here is a list of all of your changes:
<diff>
{{diff}}
</diff>
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: cache_control
last_n_messages: 2
model:
name: claude-sonnet-4-20250514
env:
repo:
github_url: https://github.com/SWE-agent/test-repo
deployment:
image: tiny
python_standalone_dir: ""
problem_statement:
github_url:
https://github.com/SWE-agent/test-repo/issues/1

60
.agent/vendor/mini-swe/config/demo/only_bash.yaml vendored Normal file
View File

@@ -0,0 +1,60 @@
# Formerly called: anthropic_filemap.yaml
# This template is heavily inspired by anthropic's computer use demo, but you can use
# it with any LM.
agent:
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
tools:
env_variables:
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/submit
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: cache_control
last_n_messages: 2
model:
name: claude-sonnet-4-20250514
env:
repo:
github_url: https://github.com/SWE-agent/test-repo
deployment:
image: tiny
python_standalone_dir: ""
problem_statement:
github_url:
https://github.com/SWE-agent/test-repo/issues/1

52
.agent/vendor/mini-swe/config/exotic/default_shell.yaml vendored Normal file
View File

@@ -0,0 +1,52 @@
# For use with sweagent sh
agent:
type: shell
templates:
system_template: |-
You are a helpful assistant that can interact with a computer to solve tasks.
instance_template: |-
<uploaded_files>
{{working_dir}}
</uploaded_files>
I've uploaded a python code repository in the directory {{working_dir}}. Consider the following PR description:
<pr_description>
{{problem_statement}}
</pr_description>
Can you help me implement the necessary changes to the repository so that the requirements specified in the <pr_description> are met?
I've already taken care of all changes to any of the test files described in the <pr_description>. This means you DON'T have to modify the testing logic or any of the tests in any way!
Your task is to make the minimal changes to non-tests files in the {{working_dir}} directory to ensure the <pr_description> is satisfied.
Follow these steps to resolve the issue:
1. As a first step, it might be a good idea to find and read code relevant to the <pr_description>
2. Create a script to reproduce the error and execute it with `python <filename.py>` using the bash tool, to confirm the error
3. Edit the sourcecode of the repo to resolve the issue
4. Rerun your reproduce script and confirm that the error is fixed!
5. Think about edgecases and make sure your fix handles them as well
Your thinking should be thorough and so it's fine if it's very long.
next_step_template: |-
OBSERVATION:
{{observation}}
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
tools:
env_variables:
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/edit_anthropic
registry_variables:
USE_FILEMAP: 'true'
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: cache_control
last_n_messages: 2
model:
name: claude-sonnet-4-20250514

125
.agent/vendor/mini-swe/config/exotic/windowed_replace.yaml vendored Normal file
View File

@@ -0,0 +1,125 @@
# This config uses the windowed-replace tools together with a prompt similar to
agent:
templates:
system_template: |-
SETTING: You are an autonomous programmer, and you're working directly in the command line with a special interface.
The special interface consists of a file editor that shows you {{WINDOW}} lines of a file at a time.
In addition to typical bash commands, you can also use specific commands to help you navigate and edit files.
To call a command, you need to invoke it with a function call/tool call.
Please note that THE EDIT COMMAND REQUIRES PROPER INDENTATION.
For example, if you are looking at this file:
def fct():
print("Hello world")
and you want to edit the file to read:
def fct():
print("Hello")
print("world")
you search string should be `Hello world` and your replace string should be `"Hello"\n print("world")`
(note the extra spaces before the print statement!).
You could also get the same result by search for ` print("Hello world")` and replace with ` print("Hello")\n print("world")`.
RESPONSE FORMAT:
Your shell prompt is formatted as follows:
(Open file: <path>)
(Current directory: <cwd>)
bash-$
First, you should _always_ include a general thought about what you're going to do next.
Then, for every response, you must include exactly _ONE_ tool call/function call.
Remember, you should always include a _SINGLE_ tool call/function call and then wait for a response from the shell before continuing with more discussion and commands. Everything you include in the DISCUSSION section will be saved for future reference.
If you'd like to issue two commands at once, PLEASE DO NOT DO THAT! Please instead first submit just the first tool call, and then after receiving a response you'll be able to issue the second .
Note that the environment does NOT support interactive session commands (e.g. python, vim), so please do not invoke them.
instance_template: |-
We're currently solving the following issue within our repository. Here's the issue text:
ISSUE:
{{problem_statement}}
INSTRUCTIONS:
Now, you're going to solve this issue on your own. Your terminal session has started and you're in the repository's root directory. You can use any bash commands or the special interface to help you. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU SHOULD ALWAYS INCLUDE EXACTLY ONE TOOL CALL/FUNCTION CALL PER RESPONSE.
When you're satisfied with all of the changes you've made, you can submit your changes to the code base by simply running the submit command.
Note however that you cannot use any interactive session commands (e.g. python, vim) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with the python command.
NOTE ABOUT THE EDIT COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
GENERAL IMPORTANT TIPS:
1. If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it!
2. If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, don't just use the scroll_down command multiple times. Instead, use the goto 583 command. It's much quicker.
3. If the bug reproduction script requires inputting/reading a specific file, such as buggy-input.png, and you'd like to understand how to input that file, conduct a search in the existing repo code, to see whether someone else has already done that. Do this by running the command: find_file "buggy-input.png" If that doesn't work, use the linux 'find' command.
4. Always make sure to look at the currently open file and the current working directory (which appears right after the currently open file). The currently open file might be in a different directory than the working directory! Note that some commands, such as 'create', open files, so they might change the current open file.
5. When editing files, it is easy to accidentally to write code with incorrect indentation or make other mistakes. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
6. When editing files, first explain the code you want to edit and why it is causing the problem. Then explain the edit you want to make and how it fixes the problem. Explain how the edit does not break existing functionality.
7. Do not try to install any packages with `pip`, `conda`, or any other way. This will usually not work. If the environment is not set up correctly, try to fix the issue without executing python code or running any tests that require the package installed.
STRATEGY:
1. Always start by trying to replicate the bug that the issues discusses.
If the issue includes code for reproducing the bug, we recommend that you re-implement that in your environment, and run it to make sure you can reproduce the bug.
Then start trying to fix it.
If the bug reproduction script does not print anything when it successfully runs, we recommend adding a print("Script completed successfully, no errors.") command at the end of the file,
so that you can be sure that the script indeed ran fine all the way through.
2. Locate relevant code using the find and search commands. `open` the file you want to edit.
3. Use the `edit` command to perform edits.
4. When you think you've fixed the bug, re-run the bug reproduction script to make sure that the bug has indeed been fixed.
5. Create additional tests to verify the fix in a style similar to the existing reproduction script. In particular, make sure to test edge cases.
If you find any issues, go back to the file you edited and perform further edits.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
demonstrations:
- trajectories/demonstrations/replay__marshmallow-code__marshmallow-1867__function_calling_replace__install-1/marshmallow-code__marshmallow-1867.traj
put_demos_in_history: true
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_replace
- path: tools/submit
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: last_n_observations
n: 5

127
.agent/vendor/mini-swe/config/exotic/windowed_replace_late_repro.yaml vendored Normal file
View File

@@ -0,0 +1,127 @@
# This config is similar to windowed_replace.yaml, but with a slightly tweaked prompt that encourages the model
# to write the reproduction script _after_ it has investigated the codebase.
agent:
templates:
system_template: |-
SETTING: You are an autonomous programmer, and you're working directly in the command line with a special interface.
The special interface consists of a file editor that shows you {{WINDOW}} lines of a file at a time.
In addition to typical bash commands, you can also use specific commands to help you navigate and edit files.
To call a command, you need to invoke it with a function call/tool call.
Please note that THE EDIT COMMAND REQUIRES PROPER INDENTATION.
For example, if you are looking at this file:
def fct():
print("Hello world")
and you want to edit the file to read:
def fct():
print("Hello")
print("world")
you search string should be `Hello world` and your replace string should be `"Hello"\n print("world")`
(note the extra spaces before the print statement!).
You could also get the same result by search for ` print("Hello world")` and replace with ` print("Hello")\n print("world")`.
RESPONSE FORMAT:
Your shell prompt is formatted as follows:
(Open file: <path>)
(Current directory: <cwd>)
bash-$
First, you should _always_ include a general thought about what you're going to do next.
Then, for every response, you must include exactly _ONE_ tool call/function call.
Remember, you should always include a _SINGLE_ tool call/function call and then wait for a response from the shell before continuing with more discussion and commands. Everything you include in the DISCUSSION section will be saved for future reference.
If you'd like to issue two commands at once, PLEASE DO NOT DO THAT! Please instead first submit just the first tool call, and then after receiving a response you'll be able to issue the second .
Note that the environment does NOT support interactive session commands (e.g. python, vim), so please do not invoke them.
instance_template: |-
We're currently solving the following issue within our repository. Here's the issue text:
ISSUE:
{{problem_statement}}
INSTRUCTIONS:
Now, you're going to solve this issue on your own. Your terminal session has started and you're in the repository's root directory. You can use any bash commands or the special interface to help you. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU SHOULD ALWAYS INCLUDE EXACTLY ONE TOOL CALL/FUNCTION CALL PER RESPONSE.
When you're satisfied with all of the changes you've made, you can submit your changes to the code base by simply running the submit command.
Note however that you cannot use any interactive session commands (e.g. python, vim) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with the python command.
NOTE ABOUT THE EDIT COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
GENERAL IMPORTANT TIPS:
1. If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it!
2. If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, don't just use the scroll_down command multiple times. Instead, use the goto 583 command. It's much quicker.
3. If the bug reproduction script requires inputting/reading a specific file, such as buggy-input.png, and you'd like to understand how to input that file, conduct a search in the existing repo code, to see whether someone else has already done that. Do this by running the command: find_file "buggy-input.png" If that doesn't work, use the linux 'find' command.
4. Always make sure to look at the currently open file and the current working directory (which appears right after the currently open file). The currently open file might be in a different directory than the working directory! Note that some commands, such as 'create', open files, so they might change the current open file.
5. When editing files, it is easy to accidentally to write code with incorrect indentation or make other mistakes. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
6. When editing files, first explain the code you want to edit and why it is causing the problem. Then explain the edit you want to make and how it fixes the problem. Explain how the edit does not break existing functionality.
7. Do not try to install any packages with `pip`, `conda`, or any other way. This will usually not work. If the environment is not set up correctly, try to fix the issue without executing python code or running any tests that require the package installed.
STRATEGY:
1. Locate relevant files using the find and search commands, then read the code related to the issue.
2. Try to replicate the bug that the issues discusses.
If the issue includes code for reproducing the bug, we recommend that you re-implement that in your environment, and run it to make sure you can reproduce the bug.
Then start trying to fix it.
If the bug reproduction script does not print anything when it successfully runs, we recommend adding a print("Script completed successfully, no errors.") command at the end of the file,
so that you can be sure that the script indeed ran fine all the way through.
3. Use the `edit` command to perform edits on the files that cause the issue.
4. When you think you've fixed the bug, re-run the bug reproduction script to make sure that the bug has indeed been fixed.
5. Create additional tests to verify the fix in a style similar to the existing reproduction script. In particular, make sure to test edge cases.
If you find any issues, go back to the file you edited and perform further edits.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
demonstrations:
- trajectories/demonstrations/function_calling_simple.traj
put_demos_in_history: true
tools:
submit_command: "submit -f"
env_variables:
WINDOW: 100
OVERLAP: 2
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_replace
- path: tools/submit
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: last_n_observations
n: 5

24
.agent/vendor/mini-swe/config/human/human.yaml vendored Normal file
View File

@@ -0,0 +1,24 @@
env:
deployment:
image: python:3.11
agent:
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_linting
- path: tools/submit
parse_function:
type: thought_action
model:
name: human

52
.agent/vendor/mini-swe/config/human/human_demo.yaml vendored Normal file
View File

@@ -0,0 +1,52 @@
env:
deployment:
image: python:3.11
agent:
templates:
system_template: |-
Enter any commands you want to run.
There are a few special commands you can use to raise exceptions for testing:
`raise_runtime`, `raise_cost`, `raise_context`, `raise_function_calling:<error_code>`,
etc.
instance_template: |-
We're currently solving the following issue within our repository. Here's the issue text:
ISSUE:
{{problem_statement}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
PAGER: cat
MANPAGER: cat
LESS: -R
PIP_PROGRESS_BAR: 'off'
TQDM_DISABLE: '1'
GIT_PAGER: cat
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_linting
- path: tools/submit
parse_function:
type: thought_action
history_processors:
- type: last_n_observations
n: 5
model:
name: human_thought

101
.agent/vendor/mini-swe/config/sweagent_0_7/07.yaml vendored Normal file
View File

@@ -0,0 +1,101 @@
# This is the configuration from SWE-agent 0.7
agent:
templates:
system_template: |-
SETTING: You are an autonomous programmer, and you're working directly in the command line with a special interface.
The special interface consists of a file editor that shows you {{WINDOW}} lines of a file at a time.
In addition to typical bash commands, you can also use the following commands to help you navigate and edit files.
COMMANDS:
{{command_docs}}
Please note that THE EDIT COMMAND REQUIRES PROPER INDENTATION.
If you'd like to add the line ' print(x)' you must fully write that out, with all those spaces before the code! Indentation is important and code that is not indented correctly will fail and require fixing before it can be run.
RESPONSE FORMAT:
Your shell prompt is formatted as follows:
(Open file: <path>) <cwd> $
You need to format your output using two fields; discussion and command.
Your output should always include _one_ discussion and _one_ command field EXACTLY as in the following example:
DISCUSSION
First I'll start by using ls to see what files are in the current directory. Then maybe we can look at some relevant files to see what they look like.
```
ls -a
```
You should only include a *SINGLE* command in the command section and then wait for a response from the shell before continuing with more discussion and commands. Everything you include in the DISCUSSION section will be saved for future reference.
If you'd like to issue two commands at once, PLEASE DO NOT DO THAT! Please instead first submit just the first command, and then after receiving a response you'll be able to issue the second command.
You're free to use any other bash commands you want (e.g. find, grep, cat, ls, cd) in addition to the special commands listed above.
However, the environment does NOT support interactive session commands (e.g. python, vim), so please do not invoke them.
instance_template: |-
We're currently solving the following issue within our repository. Here's the issue text:
ISSUE:
{{problem_statement}}
INSTRUCTIONS:
Now, you're going to solve this issue on your own. Your terminal session has started and you're in the repository's root directory. You can use any bash commands or the special interface to help you. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU CAN ONLY ENTER ONE COMMAND AT A TIME. You should always wait for feedback after every command.
When you're satisfied with all of the changes you've made, you can submit your changes to the code base by simply running the submit command.
Note however that you cannot use any interactive session commands (e.g. python, vim) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with `python <script_name>.py`.
NOTE ABOUT THE EDIT COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
IMPORTANT TIPS:
1. Always start by trying to replicate the bug that the issues discusses.
If the issue includes code for reproducing the bug, we recommend that you re-implement that in your environment, and run it to make sure you can reproduce the bug.
Then start trying to fix it.
When you think you've fixed the bug, re-run the bug reproduction script to make sure that the bug has indeed been fixed.
If the bug reproduction script does not print anything when it successfully runs, we recommend adding a print("Script completed successfully, no errors.") command at the end of the file,
so that you can be sure that the script indeed ran fine all the way through.
2. If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it!
3. If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, don't just use the scroll_down command multiple times. Instead, use the goto 583 command. It's much quicker.
4. If the bug reproduction script requires inputting/reading a specific file, such as buggy-input.png, and you'd like to understand how to input that file, conduct a search in the existing repo code, to see whether someone else has already done that. Do this by running the command: find_file "buggy-input.png" If that doesn't work, use the linux 'find' command.
5. Always make sure to look at the currently open file and the current working directory (which appears right after the currently open file). The currently open file might be in a different directory than the working directory! Note that some commands, such as 'create', open files, so they might change the current open file.
6. When editing files, it is easy to accidentally specify a wrong line number or to write code with incorrect indentation. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
demonstration_template: |
Here is a demonstration of how to correctly accomplish this task.
It is included to show you how to correctly use the interface.
You do not need to follow exactly what is done in the demonstration.
--- DEMONSTRATION ---
{{demonstration}}
--- END OF DEMONSTRATION ---
demonstrations:
- trajectories/demonstrations/replay__marshmallow-code__marshmallow-1867__default_sys-env_window100__t-0.20__p-0.95__c-2.00__install-1/marshmallow-code__marshmallow-1867.traj
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_linting
- path: tools/submit
parse_function:
type: thought_action
history_processors:
- type: last_n_observations
n: 5

100
.agent/vendor/mini-swe/config/sweagent_0_7/07_fcalling.yaml vendored Normal file
View File

@@ -0,0 +1,100 @@
# This config shows the use of the function calling action parser together with the line-range based replace tools
# This config is close to SWE-agent 0.7
agent:
templates:
system_template: |-
SETTING: You are an autonomous programmer, and you're working directly in the command line with a special interface.
The special interface consists of a file editor that shows you {{WINDOW}} lines of a file at a time.
In addition to typical bash commands, you can also use specific commands to help you navigate and edit files.
To call a command, you need to invoke it with a function call/tool call.
Please note that THE EDIT COMMAND REQUIRES PROPER INDENTATION.
If you'd like to add the line ' print(x)' you must fully write that out, with all those spaces before the code! Indentation is important and code that is not indented correctly will fail and require fixing before it can be run.
RESPONSE FORMAT:
Your shell prompt is formatted as follows:
(Open file: <path>)
(Current directory: <cwd>)
bash-$
First, you should _always_ include a general thought about what you're going to do next.
Then, for every response, you must include exactly _ONE_ tool call/function call.
Remember, you should always include a _SINGLE_ tool call/function call and then wait for a response from the shell before continuing with more discussion and commands. Everything you include in the DISCUSSION section will be saved for future reference.
If you'd like to issue two commands at once, PLEASE DO NOT DO THAT! Please instead first submit just the first tool call, and then after receiving a response you'll be able to issue the second tool call.
Note that the environment does NOT support interactive session commands (e.g. python, vim), so please do not invoke them.
instance_template: |-
We're currently solving the following issue within our repository. Here's the issue text:
ISSUE:
{{problem_statement}}
INSTRUCTIONS:
Now, you're going to solve this issue on your own. Your terminal session has started and you're in the repository's root directory. You can use any bash commands or the special interface to help you. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU SHOULD ALWAYS INCLUDE EXACTLY ONE TOOL CALL/FUNCTION CALL PER RESPONSE.
When you're satisfied with all of the changes you've made, you can submit your changes to the code base by simply running the submit command.
Note however that you cannot use any interactive session commands (e.g. python, vim) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with the python <script_name>.py`.
NOTE ABOUT THE EDIT COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
IMPORTANT TIPS:
1. Always start by trying to replicate the bug that the issues discusses.
If the issue includes code for reproducing the bug, we recommend that you re-implement that in your environment, and run it to make sure you can reproduce the bug.
Then start trying to fix it.
When you think you've fixed the bug, re-run the bug reproduction script to make sure that the bug has indeed been fixed.
If the bug reproduction script does not print anything when it successfully runs, we recommend adding a print("Script completed successfully, no errors.") command at the end of the file,
so that you can be sure that the script indeed ran fine all the way through.
2. If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it!
3. If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, don't just use the scroll_down command multiple times. Instead, use the goto 583 command. It's much quicker.
4. If the bug reproduction script requires inputting/reading a specific file, such as buggy-input.png, and you'd like to understand how to input that file, conduct a search in the existing repo code, to see whether someone else has already done that. Do this by running the command: find_file "buggy-input.png" If that doesn't work, use the linux 'find' command.
5. Always make sure to look at the currently open file and the current working directory (which appears right after the currently open file). The currently open file might be in a different directory than the working directory! Note that some commands, such as 'create', open files, so they might change the current open file.
6. When editing files, it is easy to accidentally specify a wrong line number or to write code with incorrect indentation. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
7. Do not try to install any packages with `pip`, `conda`, or any other way. This will usually not work. If the environment is not set up correctly, try to fix the issue without executing python code or running any tests that require the package installed.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
demonstration_template: |
Here is a demonstration of how to correctly accomplish this task.
It is included to show you how to correctly use the interface.
You do not need to follow exactly what is done in the demonstration.
--- DEMONSTRATION ---
{{demonstration}}
--- END OF DEMONSTRATION ---
demonstrations:
- trajectories/demonstrations/replay__marshmallow-code__marshmallow-1867__function_calling__install-1/marshmallow-code__marshmallow-1867.traj
put_demos_in_history: true
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_linting
- path: tools/submit
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: last_n_observations
n: 5

114
.agent/vendor/mini-swe/config/sweagent_0_7/07_from_url.yaml vendored Normal file
View File

@@ -0,0 +1,114 @@
# This config is close to SWE-agent 0.7, i.e., using the line-range based replace edit tools.
# This config was specifically used to be pointed to an arbitrary github issue rather than for benchmarking.
agent:
templates:
system_template: |-
SETTING: You are an autonomous programmer, and you're working directly in the command line with a special interface.
The special interface consists of a file editor that shows you {{WINDOW}} lines of a file at a time.
In addition to typical bash commands, you can also use specific commands to help you navigate and edit files.
To call a command, you need to invoke it with a function call/tool call.
Please note that THE EDIT COMMAND REQUIRES PROPER INDENTATION.
For example, if you are looking at this file:
def fct():
print("Hello world")
and you want to edit the file to read:
def fct():
print("Hello")
print("world")
you search string should be `Hello world` and your replace string should be `"Hello"\n print("world")`
(note the extra spaces before the print statement!).
You could also get the same result by search for ` print("Hello world")` and replace with ` print("Hello")\n print("world")`.
RESPONSE FORMAT:
Your shell prompt is formatted as follows:
(Open file: <path>)
(Current directory: <cwd>)
bash-$
First, you should _always_ include a general thought about what you're going to do next.
Then, for every response, you must include exactly _ONE_ tool call/function call.
Remember, you should always include a _SINGLE_ tool call/function call and then wait for a response from the shell before continuing with more discussion and commands. Everything you include in the DISCUSSION section will be saved for future reference.
If you'd like to issue two commands at once, PLEASE DO NOT DO THAT! Please instead first submit just the first tool call, and then after receiving a response you'll be able to issue the second .
Note that the environment does NOT support interactive session commands (e.g. python, vim), so please do not invoke them.
instance_template: |-
We're currently solving the following issue within our repository. Here's the issue text:
ISSUE:
{{problem_statement}}
INSTRUCTIONS:
Now, you're going to solve this issue on your own. Your terminal session has started and you're in the repository's root directory. You can use any bash commands or the special interface to help you. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU SHOULD ALWAYS INCLUDE EXACTLY ONE TOOL CALL/FUNCTION CALL PER RESPONSE.
When you're satisfied with all of the changes you've made, you can submit your changes to the code base by simply running the submit command.
Note however that you cannot use any interactive session commands (e.g. python, vim) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with the python command.
NOTE ABOUT THE EDIT COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
IMPORTANT TIPS:
1. Always start by trying to replicate the bug that the issues discusses.
If the issue includes code for reproducing the bug, we recommend that you re-implement that in your environment, and run it to make sure you can reproduce the bug.
Then start trying to fix it.
When you think you've fixed the bug, re-run the bug reproduction script to make sure that the bug has indeed been fixed.
If the bug reproduction script does not print anything when it successfully runs, we recommend adding a print("Script completed successfully, no errors.") command at the end of the file,
so that you can be sure that the script indeed ran fine all the way through.
2. If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it!
3. If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, don't just use the scroll_down command multiple times. Instead, use the goto 583 command. It's much quicker.
4. If the bug reproduction script requires inputting/reading a specific file, such as buggy-input.png, and you'd like to understand how to input that file, conduct a search in the existing repo code, to see whether someone else has already done that. Do this by running the command: find_file "buggy-input.png" If that doesn't work, use the linux 'find' command.
5. Always make sure to look at the currently open file and the current working directory (which appears right after the currently open file). The currently open file might be in a different directory than the working directory! Note that some commands, such as 'create', open files, so they might change the current open file.
6. When editing files, it is easy to accidentally to write code with incorrect indentation or make other mistakes. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
7. It may be necessary to install the repository from source before you can run code. Please think about how to install the environment from the repository directory if you need to do so.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
demonstration_template: |
Here is a demonstration of how to correctly accomplish this task.
It is included to show you how to correctly use the interface.
You do not need to follow exactly what is done in the demonstration.
--- DEMONSTRATION ---
{{demonstration}}
--- END OF DEMONSTRATION ---
demonstrations:
- trajectories/demonstrations/replay__marshmallow-code__marshmallow-1867__function_calling_replace_from_source/marshmallow-code__marshmallow-1867.traj
put_demos_in_history: true
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_replace
- path: tools/submit
enable_bash_tool: true
parse_function:
type: function_calling
history_processors:
- type: last_n_observations
n: 5

102
.agent/vendor/mini-swe/config/sweagent_0_7/07_thought_action.yaml vendored Normal file
View File

@@ -0,0 +1,102 @@
# This config shows the use of the thought_action action parser together with the line-range based replace tools
# This config is close to SWE-agent 0.7
agent:
templates:
system_template: |-
SETTING: You are an autonomous programmer, and you're working directly in the command line with a special interface.
The special interface consists of a file editor that shows you {{WINDOW}} lines of a file at a time.
In addition to typical bash commands, you can also use the following commands to help you navigate and edit files.
COMMANDS:
{{command_docs}}
Please note that THE EDIT COMMAND REQUIRES PROPER INDENTATION.
If you'd like to add the line ' print(x)' you must fully write that out, with all those spaces before the code! Indentation is important and code that is not indented correctly will fail and require fixing before it can be run.
RESPONSE FORMAT:
Your shell prompt is formatted as follows:
(Open file: <path>) <cwd> $
You need to format your output using two fields; discussion and command.
Your output should always include _one_ discussion and _one_ command field EXACTLY as in the following example:
DISCUSSION
First I'll start by using ls to see what files are in the current directory. Then maybe we can look at some relevant files to see what they look like.
```
ls -a
```
You should only include a *SINGLE* command in the command section and then wait for a response from the shell before continuing with more discussion and commands. Everything you include in the DISCUSSION section will be saved for future reference.
If you'd like to issue two commands at once, PLEASE DO NOT DO THAT! Please instead first submit just the first command, and then after receiving a response you'll be able to issue the second command.
You're free to use any other bash commands you want (e.g. find, grep, cat, ls, cd) in addition to the special commands listed above.
However, the environment does NOT support interactive session commands (e.g. python, vim), so please do not invoke them.
instance_template: |-
We're currently solving the following issue within our repository. Here's the issue text:
ISSUE:
{{problem_statement}}
INSTRUCTIONS:
Now, you're going to solve this issue on your own. Your terminal session has started and you're in the repository's root directory. You can use any bash commands or the special interface to help you. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU CAN ONLY ENTER ONE COMMAND AT A TIME. You should always wait for feedback after every command.
When you're satisfied with all of the changes you've made, you can submit your changes to the code base by simply running the submit command.
Note however that you cannot use any interactive session commands (e.g. python, vim) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with `python <script_name>.py`.
NOTE ABOUT THE EDIT COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
IMPORTANT TIPS:
1. Always start by trying to replicate the bug that the issues discusses.
If the issue includes code for reproducing the bug, we recommend that you re-implement that in your environment, and run it to make sure you can reproduce the bug.
Then start trying to fix it.
When you think you've fixed the bug, re-run the bug reproduction script to make sure that the bug has indeed been fixed.
If the bug reproduction script does not print anything when it successfully runs, we recommend adding a print("Script completed successfully, no errors.") command at the end of the file,
so that you can be sure that the script indeed ran fine all the way through.
2. If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it!
3. If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, don't just use the scroll_down command multiple times. Instead, use the goto 583 command. It's much quicker.
4. If the bug reproduction script requires inputting/reading a specific file, such as buggy-input.png, and you'd like to understand how to input that file, conduct a search in the existing repo code, to see whether someone else has already done that. Do this by running the command: find_file "buggy-input.png" If that doesn't work, use the linux 'find' command.
5. Always make sure to look at the currently open file and the current working directory (which appears right after the currently open file). The currently open file might be in a different directory than the working directory! Note that some commands, such as 'create', open files, so they might change the current open file.
6. When editing files, it is easy to accidentally specify a wrong line number or to write code with incorrect indentation. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
demonstration_template: |
Here is a demonstration of how to correctly accomplish this task.
It is included to show you how to correctly use the interface.
You do not need to follow exactly what is done in the demonstration.
--- DEMONSTRATION ---
{{demonstration}}
--- END OF DEMONSTRATION ---
demonstrations:
- trajectories/demonstrations/replay__marshmallow-code__marshmallow-1867__default_sys-env_window100__t-0.20__p-0.95__c-2.00__install-1/marshmallow-code__marshmallow-1867.traj
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_linting
- path: tools/submit
parse_function:
type: thought_action
history_processors:
- type: last_n_observations
n: 5

96
.agent/vendor/mini-swe/config/sweagent_0_7/07_thought_action_xml.yaml vendored Normal file
View File

@@ -0,0 +1,96 @@
# This config shows the use of the thought action xml parser together with the line-range based replace tools
# This config is close to SWE-agent 0.7
agent:
templates:
system_template: |-
SETTING: You are an autonomous programmer, and you're working directly in the command line with a special interface.
The special interface consists of a file editor that shows you {{WINDOW}} lines of a file at a time.
In addition to typical bash commands, you can also use the following commands to help you navigate and edit files.
COMMANDS:
{{command_docs}}
Please note that THE EDIT COMMAND REQUIRES PROPER INDENTATION.
If you'd like to add the line ' print(x)' you must fully write that out, with all those spaces before the code! Indentation is important and code that is not indented correctly will fail and require fixing before it can be run.
RESPONSE FORMAT:
Your shell prompt is formatted as follows:
(Open file: <path>) <cwd> $
You need to format your output using two fields; discussion and command.
Your output should always include _one_ discussion and _one_ command field EXACTLY as in the following example:
DISCUSSION
First I'll start by using ls to see what files are in the current directory. Then maybe we can look at some relevant files to see what they look like.
<command>
ls -a
</command>
You should only include a *SINGLE* command in the command section and then wait for a response from the shell before continuing with more discussion and commands. Everything you include in the DISCUSSION section will be saved for future reference.
If you'd like to issue two commands at once, PLEASE DO NOT DO THAT! Please instead first submit just the first command, and then after receiving a response you'll be able to issue the second command.
You're free to use any other bash commands you want (e.g. find, grep, cat, ls, cd) in addition to the special commands listed above.
However, the environment does NOT support interactive session commands (e.g. python, vim), so please do not invoke them.
instance_template: |-
We're currently solving the following issue within our repository. Here's the issue text:
ISSUE:
{{problem_statement}}
INSTRUCTIONS:
Now, you're going to solve this issue on your own. Your terminal session has started and you're in the repository's root directory. You can use any bash commands or the special interface to help you. Edit all the files you need to and run any checks or tests that you want.
Remember, YOU CAN ONLY ENTER ONE COMMAND AT A TIME. You should always wait for feedback after every command.
When you're satisfied with all of the changes you've made, you can submit your changes to the code base by simply running the submit command.
Note however that you cannot use any interactive session commands (e.g. python, vim) in this environment, but you can write scripts and run them. E.g. you can write a python script and then run it with `python <script_name>.py`.
NOTE ABOUT THE EDIT COMMAND: Indentation really matters! When editing a file, make sure to insert appropriate indentation before each line!
IMPORTANT TIPS:
1. Always start by trying to replicate the bug that the issues discusses.
If the issue includes code for reproducing the bug, we recommend that you re-implement that in your environment, and run it to make sure you can reproduce the bug.
Then start trying to fix it.
When you think you've fixed the bug, re-run the bug reproduction script to make sure that the bug has indeed been fixed.
If the bug reproduction script does not print anything when it successfully runs, we recommend adding a print("Script completed successfully, no errors.") command at the end of the file,
so that you can be sure that the script indeed ran fine all the way through.
2. If you run a command and it doesn't work, try running a different command. A command that did not work once will not work the second time unless you modify it!
3. If you open a file and need to get to an area around a specific line that is not in the first 100 lines, say line 583, don't just use the scroll_down command multiple times. Instead, use the goto 583 command. It's much quicker.
4. If the bug reproduction script requires inputting/reading a specific file, such as buggy-input.png, and you'd like to understand how to input that file, conduct a search in the existing repo code, to see whether someone else has already done that. Do this by running the command: find_file "buggy-input.png" If that doesn't work, use the linux 'find' command.
5. Always make sure to look at the currently open file and the current working directory (which appears right after the currently open file). The currently open file might be in a different directory than the working directory! Note that some commands, such as 'create', open files, so they might change the current open file.
6. When editing files, it is easy to accidentally specify a wrong line number or to write code with incorrect indentation. Always check the code after you issue an edit to make sure that it reflects what you wanted to accomplish. If it didn't, issue another command to fix it.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_template: |-
{{observation}}
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
next_step_no_output_template: |-
Your command ran successfully and did not produce any output.
(Open file: {{open_file}})
(Current directory: {{working_dir}})
bash-$
demonstrations:
- trajectories/demonstrations/replay__marshmallow-code__marshmallow-1867__xml_sys-env_window100__t-0.20__p-0.95__c-2.00__install-1/marshmallow-code__marshmallow-1867.traj
put_demos_in_history: true
tools:
env_variables:
WINDOW: 100
OVERLAP: 2
bundles:
- path: tools/registry
- path: tools/windowed
- path: tools/search
- path: tools/windowed_edit_linting
- path: tools/submit
parse_function:
type: xml_thought_action
history_processors:
- type: last_n_observations
n: 5