{"owner":"SWE-agent","repo":"mini-swe-agent","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":1752,"categories":["subagent-persona","copilot-instructions","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["docs/reference/agents/default.md",".github/copilot-instructions.md","src/minisweagent/agents/README.md","docs/reference/agents/interactive.md","AGENTS.md"],"skills":{"docs/reference/agents/default.md":"# DefaultAgent\n\n!!! note \"DefaultAgent class\"\n\n    - [Read on GitHub](https://github.com/swe-agent/mini-swe-agent/blob/main/src/minisweagent/agents/default.py)\n\n    ??? note \"Full source code\"\n\n        ```python\n        --8<-- \"src/minisweagent/agents/default.py\"\n        ```\n\n!!! tip \"Understanding the control flow\"\n\n    Check out the [control flow guide](../../advanced/control_flow.md) for a visual explanation of the agent's control flow.\n\n::: minisweagent.agents.default.AgentConfig\n\n::: minisweagent.agents.default.DefaultAgent\n\n::: minisweagent.exceptions.InterruptAgentFlow\n\n::: minisweagent.exceptions.Submitted\n\n::: minisweagent.exceptions.LimitsExceeded\n\n::: minisweagent.exceptions.FormatError\n\n::: minisweagent.exceptions.UserInterruption\n\n{% include-markdown \"../../_footer.md\" %}",".github/copilot-instructions.md":"# 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. Not every exception has to be caught. Exceptions are a good way to show problems to a user.\n12. This repository rewards minimal code. Try to be as concise as possible.\n13. Do NOT warn about print messages in tests, print statements in tests are OK!\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!).\n6. Do NOT warn about print messages in tests, print statements in tests are OK!\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","src/minisweagent/agents/README.md":"# Agent implementations\n\n* `default.py` - Minimal default agent implementation.\n* `interactive.py` - Extends `default.py` with some minimal human-in-the-loop functionality (confirm actions, etc.).","docs/reference/agents/interactive.md":"# Interactive\n\n!!! note \"InteractiveAgent class\"\n\n    - [Read on GitHub](https://github.com/swe-agent/mini-swe-agent/blob/main/src/minisweagent/agents/interactive.py)\n\n    ??? note \"Full source code\"\n\n        ```python\n        --8<-- \"src/minisweagent/agents/interactive.py\"\n        ```\n\n!!! tip \"See also\"\n\n    * This agent subclass builds on top of the [default agent](default.md), make sure to read that first.\n    * This class powers the `mini` command line tool, see [usage](../../usage/mini.md) for more details.\n\n::: minisweagent.agents.interactive\n\n{% include-markdown \"../../_footer.md\" %}","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":{"docs/reference/agents/default.md":"# DefaultAgent\n\n!!! note \"DefaultAgent class\"\n\n    - [Read on GitHub](https://github.com/swe-agent/mini-swe-agent/blob/main/src/minisweagent/agents/default.py)\n\n    ??? note \"Full source code\"\n\n        ```python\n        --8<-- \"src/minisweagent/agents/default.py\"\n        ```\n\n!!! tip \"Understanding the control flow\"\n\n    Check out the [control flow guide](../../advanced/control_flow.md) for a visual explanation of the agent's control flow.\n\n::: minisweagent.agents.default.AgentConfig\n\n::: minisweagent.agents.default.DefaultAgent\n\n::: minisweagent.exceptions.InterruptAgentFlow\n\n::: minisweagent.exceptions.Submitted\n\n::: minisweagent.exceptions.LimitsExceeded\n\n::: minisweagent.exceptions.FormatError\n\n::: minisweagent.exceptions.UserInterruption\n\n{% include-markdown \"../../_footer.md\" %}",".github/copilot-instructions.md":"# 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. Not every exception has to be caught. Exceptions are a good way to show problems to a user.\n12. This repository rewards minimal code. Try to be as concise as possible.\n13. Do NOT warn about print messages in tests, print statements in tests are OK!\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!).\n6. Do NOT warn about print messages in tests, print statements in tests are OK!\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","src/minisweagent/agents/README.md":"# Agent implementations\n\n* `default.py` - Minimal default agent implementation.\n* `interactive.py` - Extends `default.py` with some minimal human-in-the-loop functionality (confirm actions, etc.).","docs/reference/agents/interactive.md":"# Interactive\n\n!!! note \"InteractiveAgent class\"\n\n    - [Read on GitHub](https://github.com/swe-agent/mini-swe-agent/blob/main/src/minisweagent/agents/interactive.py)\n\n    ??? note \"Full source code\"\n\n        ```python\n        --8<-- \"src/minisweagent/agents/interactive.py\"\n        ```\n\n!!! tip \"See also\"\n\n    * This agent subclass builds on top of the [default agent](default.md), make sure to read that first.\n    * This class powers the `mini` command line tool, see [usage](../../usage/mini.md) for more details.\n\n::: minisweagent.agents.interactive\n\n{% include-markdown \"../../_footer.md\" %}","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","rawUrl":"https://raw.githubusercontent.com/SWE-agent/mini-swe-agent/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","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","isInternal":false,"tokens":980,"sizeBytes":4260},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/SWE-agent/mini-swe-agent/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# 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. Not every exception has to be caught. Exceptions are a good way to show problems to a user.\n12. This repository rewards minimal code. Try to be as concise as possible.\n13. Do NOT warn about print messages in tests, print statements in tests are OK!\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!).\n6. Do NOT warn about print messages in tests, print statements in tests are OK!\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","isInternal":false,"tokens":379,"sizeBytes":1546},{"name":"default.md","path":"docs/reference/agents/default.md","rawUrl":"https://raw.githubusercontent.com/SWE-agent/mini-swe-agent/HEAD/docs/reference/agents/default.md","title":"Subagent: default","category":"subagent-persona","format":"markdown","content":"# DefaultAgent\n\n!!! note \"DefaultAgent class\"\n\n    - [Read on GitHub](https://github.com/swe-agent/mini-swe-agent/blob/main/src/minisweagent/agents/default.py)\n\n    ??? note \"Full source code\"\n\n        ```python\n        --8<-- \"src/minisweagent/agents/default.py\"\n        ```\n\n!!! tip \"Understanding the control flow\"\n\n    Check out the [control flow guide](../../advanced/control_flow.md) for a visual explanation of the agent's control flow.\n\n::: minisweagent.agents.default.AgentConfig\n\n::: minisweagent.agents.default.DefaultAgent\n\n::: minisweagent.exceptions.InterruptAgentFlow\n\n::: minisweagent.exceptions.Submitted\n\n::: minisweagent.exceptions.LimitsExceeded\n\n::: minisweagent.exceptions.FormatError\n\n::: minisweagent.exceptions.UserInterruption\n\n{% include-markdown \"../../_footer.md\" %}","isInternal":false,"tokens":199,"sizeBytes":795},{"name":"interactive.md","path":"docs/reference/agents/interactive.md","rawUrl":"https://raw.githubusercontent.com/SWE-agent/mini-swe-agent/HEAD/docs/reference/agents/interactive.md","title":"Subagent: interactive","category":"subagent-persona","format":"markdown","content":"# Interactive\n\n!!! note \"InteractiveAgent class\"\n\n    - [Read on GitHub](https://github.com/swe-agent/mini-swe-agent/blob/main/src/minisweagent/agents/interactive.py)\n\n    ??? note \"Full source code\"\n\n        ```python\n        --8<-- \"src/minisweagent/agents/interactive.py\"\n        ```\n\n!!! tip \"See also\"\n\n    * This agent subclass builds on top of the [default agent](default.md), make sure to read that first.\n    * This class powers the `mini` command line tool, see [usage](../../usage/mini.md) for more details.\n\n::: minisweagent.agents.interactive\n\n{% include-markdown \"../../_footer.md\" %}","isInternal":false,"tokens":153,"sizeBytes":598},{"name":"README.md","path":"src/minisweagent/agents/README.md","rawUrl":"https://raw.githubusercontent.com/SWE-agent/mini-swe-agent/HEAD/src/minisweagent/agents/README.md","title":"Subagent: readme","category":"subagent-persona","format":"markdown","content":"# Agent implementations\n\n* `default.py` - Minimal default agent implementation.\n* `interactive.py` - Extends `default.py` with some minimal human-in-the-loop functionality (confirm actions, etc.).","isInternal":false,"tokens":41,"sizeBytes":196}],"systemPromptSnippet":"<yakaai_skills repo=\"SWE-agent/mini-swe-agent\">\n<!-- File: AGENTS.md (Tokens: ~980 | Category: root-instruction) -->\n# 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\n<!-- File: .github/copilot-instructions.md (Tokens: ~379 | Category: copilot-instructions) -->\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. Not every exception has to be caught. Exceptions are a good way to show problems to a user.\n12. This repository rewards minimal code. Try to be as concise as possible.\n13. Do NOT warn about print messages in tests, print statements in tests are OK!\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!).\n6. Do NOT warn about print messages in tests, print statements in tests are OK!\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<!-- File: docs/reference/agents/default.md (Tokens: ~199 | Category: subagent-persona) -->\n# DefaultAgent\n\n!!! note \"DefaultAgent class\"\n\n    - [Read on GitHub](https://github.com/swe-agent/mini-swe-agent/blob/main/src/minisweagent/agents/default.py)\n\n    ??? note \"Full source code\"\n\n        ```python\n        --8<-- \"src/minisweagent/agents/default.py\"\n        ```\n\n!!! tip \"Understanding the control flow\"\n\n    Check out the [control flow guide](../../advanced/control_flow.md) for a visual explanation of the agent's control flow.\n\n::: minisweagent.agents.default.AgentConfig\n\n::: minisweagent.agents.default.DefaultAgent\n\n::: minisweagent.exceptions.InterruptAgentFlow\n\n::: minisweagent.exceptions.Submitted\n\n::: minisweagent.exceptions.LimitsExceeded\n\n::: minisweagent.exceptions.FormatError\n\n::: minisweagent.exceptions.UserInterruption\n\n{% include-markdown \"../../_footer.md\" %}\n\n<!-- File: docs/reference/agents/interactive.md (Tokens: ~153 | Category: subagent-persona) -->\n# Interactive\n\n!!! note \"InteractiveAgent class\"\n\n    - [Read on GitHub](https://github.com/swe-agent/mini-swe-agent/blob/main/src/minisweagent/agents/interactive.py)\n\n    ??? note \"Full source code\"\n\n        ```python\n        --8<-- \"src/minisweagent/agents/interactive.py\"\n        ```\n\n!!! tip \"See also\"\n\n    * This agent subclass builds on top of the [default agent](default.md), make sure to read that first.\n    * This class powers the `mini` command line tool, see [usage](../../usage/mini.md) for more details.\n\n::: minisweagent.agents.interactive\n\n{% include-markdown \"../../_footer.md\" %}\n\n<!-- File: src/minisweagent/agents/README.md (Tokens: ~41 | Category: subagent-persona) -->\n# Agent implementations\n\n* `default.py` - Minimal default agent implementation.\n* `interactive.py` - Extends `default.py` with some minimal human-in-the-loop functionality (confirm actions, etc.).\n</yakaai_skills>"}