{"owner":"SWE-agent","repo":"mini-swe-agent","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# mini-SWE-agent overview\n\n- mini-SWE-agent implements an AI software engineering agent that solves github issues and similar programming challenges\n- The idea of this project is to write the simplest, smallest, most readable agent.\n\nThe project is structured as\n\n```bash\nminisweagent/__init__  # Protocols/interfaces for all base classes\nminisweagent/agents  # Agent control flow & loop\nminisweagent/environments  # Executing agent actions\nminisweagent/models  # LM interfaces\nminisweagent/run  # Run scripts that serve as an entry point\n```\n\n- The project embraces polymorphism: Every individual class should be simple, but we offer alternatives\n- Every use case should start with a run script, that picks one agent, environment, and model class to run\n\n# Style guide\n\n1. Target python 3.10 or higher\n2. Use python with type annotations. Use `list` instead of `List`.\n3. Use `pathlib` instead of `os.path`. Use `Path.read_text()` over `with ...open()` constructs.\n4. Use `typer` to add interfaces\n5. Keep code comments to a minimum and only highlight particularly logically challenging things\n6. Do not append to the README unless specifically requested\n7. Use `jinja` for formatting templates\n8. Use `dataclass` for keeping track config\n9. Do not catch exceptions unless explicitly told to.\n10. Write concise, short, minimal code.\n11. In most cases, avoid initializing variables just to pass them to a function. Instead just pass the expression to the function directly.\n12. Not every exception has to be caught. Exceptions are a good way to show problems to a user.\n13. This repository rewards minimal code. Try to be as concise as possible.\n\nHere's an example for rule 11:\n\n```python\n# bad\na = func()\nClass(a)\n\n# good\nClass(func())\n```\n\n## Test style\n\n1. Use `pytest`, not `unittest`.\n2. <IMPORTANT>Do not mock/patch anything that you're not explicitly asked to do</IMPORTANT>\n3. Avoid writing trivial tests. Every test should test for at least one, preferably multiple points of failure\n4. Avoid splitting up code in multiple lines like this: `a=func()\\n assert a=b`. Instead, just do `assert func() == b`\n5. The first argument to `pytest.mark.parametrize` should be a tuple (not a string! not a list!), the second argument must be a list (not a tuple!).\n\nHere's an example for rule 4:\n\n```python\n# bad\nresult = func()\nassert result == b\n\n# good\nassert func() == b\n```\n\n# Commit messages\n\nUse the following format for commit messages:\n\n- `ci: description` for all testing related changes, and changes to github workflows etc.\n- `dev: description` for development related changes, including updates to the cursor or claude rules\n- `fix(component): description` for bug fixes\n- `feat(component): description` for new features\n- `enh(component): description` for enhancements\n- `docs: description` for documentation\n- `ref(component): description` for refactoring\n- `chore: description` for maintenance tasks (pre-commit hooks, imports, etc.)\n\nGenerally, the description should focus on the intent of the changes, not the implementation details.\n\n## Style notes\n\n<IMPORTANT>Do **NOT** add \"Co-authored-by: Cursor\" lines to the commit message or to the trailer.</IMPORTANT>\n\n## Reviewing\n\nWhile preparing the commit message, flag critical issues that should be addressed before committing. Do not flag style issues or minor changes.\n\nFlag the following:\n\n- Anything that might raise an unhandled exception in an unintentional manner\n- Anything that looks logically wrong or inconsistent\n- Breaking changes to protocols/interfaces without corresponding updates to implementations\n\nFlag the following style issue as minor:\n\n- Imports not at top of file\n\n## Components\n\nUse these component names in parentheses for `fix`, `feat`, `enh`, and `ref` commits:\n\n- `models` - Changes to model interfaces (litellm, anthropic, openai, portkey, openrouter)\n- `agents` - Changes to agent classes (default, interactive, multimodal)\n- `env` - Changes to environments (docker, local, singularity, bubblewrap, swerex)\n- `config` - Changes to configuration files or config handling\n- `run` - Changes to run scripts (mini, hello_world)\n- `benchmarks` - Changes to benchmark runners (swebench, inspector)\n- `cli` - Changes to CLI argument handling\n- `deps` - Dependency updates\n"},"files":{"AGENTS.md":"# mini-SWE-agent overview\n\n- mini-SWE-agent implements an AI software engineering agent that solves github issues and similar programming challenges\n- The idea of this project is to write the simplest, smallest, most readable agent.\n\nThe project is structured as\n\n```bash\nminisweagent/__init__  # Protocols/interfaces for all base classes\nminisweagent/agents  # Agent control flow & loop\nminisweagent/environments  # Executing agent actions\nminisweagent/models  # LM interfaces\nminisweagent/run  # Run scripts that serve as an entry point\n```\n\n- The project embraces polymorphism: Every individual class should be simple, but we offer alternatives\n- Every use case should start with a run script, that picks one agent, environment, and model class to run\n\n# Style guide\n\n1. Target python 3.10 or higher\n2. Use python with type annotations. Use `list` instead of `List`.\n3. Use `pathlib` instead of `os.path`. Use `Path.read_text()` over `with ...open()` constructs.\n4. Use `typer` to add interfaces\n5. Keep code comments to a minimum and only highlight particularly logically challenging things\n6. Do not append to the README unless specifically requested\n7. Use `jinja` for formatting templates\n8. Use `dataclass` for keeping track config\n9. Do not catch exceptions unless explicitly told to.\n10. Write concise, short, minimal code.\n11. In most cases, avoid initializing variables just to pass them to a function. Instead just pass the expression to the function directly.\n12. Not every exception has to be caught. Exceptions are a good way to show problems to a user.\n13. This repository rewards minimal code. Try to be as concise as possible.\n\nHere's an example for rule 11:\n\n```python\n# bad\na = func()\nClass(a)\n\n# good\nClass(func())\n```\n\n## Test style\n\n1. Use `pytest`, not `unittest`.\n2. <IMPORTANT>Do not mock/patch anything that you're not explicitly asked to do</IMPORTANT>\n3. Avoid writing trivial tests. Every test should test for at least one, preferably multiple points of failure\n4. Avoid splitting up code in multiple lines like this: `a=func()\\n assert a=b`. Instead, just do `assert func() == b`\n5. The first argument to `pytest.mark.parametrize` should be a tuple (not a string! not a list!), the second argument must be a list (not a tuple!).\n\nHere's an example for rule 4:\n\n```python\n# bad\nresult = func()\nassert result == b\n\n# good\nassert func() == b\n```\n\n# Commit messages\n\nUse the following format for commit messages:\n\n- `ci: description` for all testing related changes, and changes to github workflows etc.\n- `dev: description` for development related changes, including updates to the cursor or claude rules\n- `fix(component): description` for bug fixes\n- `feat(component): description` for new features\n- `enh(component): description` for enhancements\n- `docs: description` for documentation\n- `ref(component): description` for refactoring\n- `chore: description` for maintenance tasks (pre-commit hooks, imports, etc.)\n\nGenerally, the description should focus on the intent of the changes, not the implementation details.\n\n## Style notes\n\n<IMPORTANT>Do **NOT** add \"Co-authored-by: Cursor\" lines to the commit message or to the trailer.</IMPORTANT>\n\n## Reviewing\n\nWhile preparing the commit message, flag critical issues that should be addressed before committing. Do not flag style issues or minor changes.\n\nFlag the following:\n\n- Anything that might raise an unhandled exception in an unintentional manner\n- Anything that looks logically wrong or inconsistent\n- Breaking changes to protocols/interfaces without corresponding updates to implementations\n\nFlag the following style issue as minor:\n\n- Imports not at top of file\n\n## Components\n\nUse these component names in parentheses for `fix`, `feat`, `enh`, and `ref` commits:\n\n- `models` - Changes to model interfaces (litellm, anthropic, openai, portkey, openrouter)\n- `agents` - Changes to agent classes (default, interactive, multimodal)\n- `env` - Changes to environments (docker, local, singularity, bubblewrap, swerex)\n- `config` - Changes to configuration files or config handling\n- `run` - Changes to run scripts (mini, hello_world)\n- `benchmarks` - Changes to benchmark runners (swebench, inspector)\n- `cli` - Changes to CLI argument handling\n- `deps` - Dependency updates\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# mini-SWE-agent overview\n\n- mini-SWE-agent implements an AI software engineering agent that solves github issues and similar programming challenges\n- The idea of this project is to write the simplest, smallest, most readable agent.\n\nThe project is structured as\n\n```bash\nminisweagent/__init__  # Protocols/interfaces for all base classes\nminisweagent/agents  # Agent control flow & loop\nminisweagent/environments  # Executing agent actions\nminisweagent/models  # LM interfaces\nminisweagent/run  # Run scripts that serve as an entry point\n```\n\n- The project embraces polymorphism: Every individual class should be simple, but we offer alternatives\n- Every use case should start with a run script, that picks one agent, environment, and model class to run\n\n# Style guide\n\n1. Target python 3.10 or higher\n2. Use python with type annotations. Use `list` instead of `List`.\n3. Use `pathlib` instead of `os.path`. Use `Path.read_text()` over `with ...open()` constructs.\n4. Use `typer` to add interfaces\n5. Keep code comments to a minimum and only highlight particularly logically challenging things\n6. Do not append to the README unless specifically requested\n7. Use `jinja` for formatting templates\n8. Use `dataclass` for keeping track config\n9. Do not catch exceptions unless explicitly told to.\n10. Write concise, short, minimal code.\n11. In most cases, avoid initializing variables just to pass them to a function. Instead just pass the expression to the function directly.\n12. Not every exception has to be caught. Exceptions are a good way to show problems to a user.\n13. This repository rewards minimal code. Try to be as concise as possible.\n\nHere's an example for rule 11:\n\n```python\n# bad\na = func()\nClass(a)\n\n# good\nClass(func())\n```\n\n## Test style\n\n1. Use `pytest`, not `unittest`.\n2. <IMPORTANT>Do not mock/patch anything that you're not explicitly asked to do</IMPORTANT>\n3. Avoid writing trivial tests. Every test should test for at least one, preferably multiple points of failure\n4. Avoid splitting up code in multiple lines like this: `a=func()\\n assert a=b`. Instead, just do `assert func() == b`\n5. The first argument to `pytest.mark.parametrize` should be a tuple (not a string! not a list!), the second argument must be a list (not a tuple!).\n\nHere's an example for rule 4:\n\n```python\n# bad\nresult = func()\nassert result == b\n\n# good\nassert func() == b\n```\n\n# Commit messages\n\nUse the following format for commit messages:\n\n- `ci: description` for all testing related changes, and changes to github workflows etc.\n- `dev: description` for development related changes, including updates to the cursor or claude rules\n- `fix(component): description` for bug fixes\n- `feat(component): description` for new features\n- `enh(component): description` for enhancements\n- `docs: description` for documentation\n- `ref(component): description` for refactoring\n- `chore: description` for maintenance tasks (pre-commit hooks, imports, etc.)\n\nGenerally, the description should focus on the intent of the changes, not the implementation details.\n\n## Style notes\n\n<IMPORTANT>Do **NOT** add \"Co-authored-by: Cursor\" lines to the commit message or to the trailer.</IMPORTANT>\n\n## Reviewing\n\nWhile preparing the commit message, flag critical issues that should be addressed before committing. Do not flag style issues or minor changes.\n\nFlag the following:\n\n- Anything that might raise an unhandled exception in an unintentional manner\n- Anything that looks logically wrong or inconsistent\n- Breaking changes to protocols/interfaces without corresponding updates to implementations\n\nFlag the following style issue as minor:\n\n- Imports not at top of file\n\n## Components\n\nUse these component names in parentheses for `fix`, `feat`, `enh`, and `ref` commits:\n\n- `models` - Changes to model interfaces (litellm, anthropic, openai, portkey, openrouter)\n- `agents` - Changes to agent classes (default, interactive, multimodal)\n- `env` - Changes to environments (docker, local, singularity, bubblewrap, swerex)\n- `config` - Changes to configuration files or config handling\n- `run` - Changes to run scripts (mini, hello_world)\n- `benchmarks` - Changes to benchmark runners (swebench, inspector)\n- `cli` - Changes to CLI argument handling\n- `deps` - Dependency updates\n","category":"root","tokens":1065}]}