From 1a7093d3aeed55d0de7209fb83e1fe96a3c3ab8e Mon Sep 17 00:00:00 2001 From: openhands Date: Sun, 15 Mar 2026 22:27:35 +0000 Subject: [PATCH 01/11] Add python-type-annotations plugin A simple plugin that instructs the agent to add valid Python type annotations to files or directories. Features: - SKILL.md with instructions for adding type annotations - Example before/after Python files - GitHub Action workflow to regenerate examples using OpenHands CLI - Saves trajectory.json output from headless runs Co-authored-by: openhands --- .../.claude-plugin/plugin.json | 5 ++ plugins/python-type-annotations/README.md | 73 +++++++++++++++++++ .../examples/basic/after/hello.py | 31 ++++++++ .../examples/basic/before/hello.py | 31 ++++++++ .../examples/basic/prompt.md | 1 + .../examples/basic/trajectory.json | 8 ++ .../skills/type-annotations/SKILL.md | 69 ++++++++++++++++++ .../workflows/update-example.yml | 45 ++++++++++++ 8 files changed, 263 insertions(+) create mode 100644 plugins/python-type-annotations/.claude-plugin/plugin.json create mode 100644 plugins/python-type-annotations/README.md create mode 100644 plugins/python-type-annotations/examples/basic/after/hello.py create mode 100644 plugins/python-type-annotations/examples/basic/before/hello.py create mode 100644 plugins/python-type-annotations/examples/basic/prompt.md create mode 100644 plugins/python-type-annotations/examples/basic/trajectory.json create mode 100644 plugins/python-type-annotations/skills/type-annotations/SKILL.md create mode 100644 plugins/python-type-annotations/workflows/update-example.yml diff --git a/plugins/python-type-annotations/.claude-plugin/plugin.json b/plugins/python-type-annotations/.claude-plugin/plugin.json new file mode 100644 index 0000000..13df29e --- /dev/null +++ b/plugins/python-type-annotations/.claude-plugin/plugin.json @@ -0,0 +1,5 @@ +{ + "name": "python-type-annotations", + "version": "1.0.0", + "description": "Add valid Python type annotations to files or directories" +} diff --git a/plugins/python-type-annotations/README.md b/plugins/python-type-annotations/README.md new file mode 100644 index 0000000..d3e84c9 --- /dev/null +++ b/plugins/python-type-annotations/README.md @@ -0,0 +1,73 @@ +# Python Type Annotations Plugin + +A simple plugin that instructs the agent to add valid Python type annotations to files or directories. + +## Features + +- Adds type annotations to function parameters and return types +- Annotates class attributes and instance variables +- Uses modern Python 3.9+ syntax (`list[T]` instead of `List[T]`) +- Validates syntax after making changes + +## Usage + +### With OpenHands CLI + +```bash +openhands run \ + --plugin github:OpenHands/extensions/plugins/python-type-annotations \ + --prompt "Add type annotations to all Python files in src/" +``` + +### With OpenHands SDK + +```python +from openhands.sdk import Agent, Conversation, LLM +from openhands.sdk.plugin import PluginSource + +conversation = Conversation( + agent=Agent(llm=LLM(model="anthropic/claude-sonnet-4-20250514")), + plugins=[ + PluginSource( + source="github:OpenHands/extensions", + ref="main", + repo_path="plugins/python-type-annotations" + ) + ] +) + +conversation.send_message("Add type annotations to hello.py") +conversation.run() +``` + +## Examples + +See the `examples/basic/` directory for a before/after example: + +- `before/hello.py` - Python code without type annotations +- `after/hello.py` - Same code with type annotations added + +## Testing + +The `workflows/update-example.yml` GitHub Action can be triggered manually to regenerate the `after/` example using the current plugin and OpenHands CLI. + +## Plugin Structure + +``` +python-type-annotations/ +├── .claude-plugin/ +│ └── plugin.json +├── skills/ +│ └── type-annotations/ +│ └── SKILL.md +├── examples/ +│ └── basic/ +│ ├── prompt.md +│ ├── before/ +│ │ └── hello.py +│ └── after/ +│ └── hello.py +├── workflows/ +│ └── update-example.yml +└── README.md +``` diff --git a/plugins/python-type-annotations/examples/basic/after/hello.py b/plugins/python-type-annotations/examples/basic/after/hello.py new file mode 100644 index 0000000..ed45580 --- /dev/null +++ b/plugins/python-type-annotations/examples/basic/after/hello.py @@ -0,0 +1,31 @@ +def greet(name: str) -> str: + """Return a greeting message.""" + return f"Hello, {name}!" + + +def add(a: int, b: int) -> int: + """Add two numbers.""" + return a + b + + +def find_longest(words: list[str]) -> str | None: + """Find the longest word in a list.""" + if not words: + return None + return max(words, key=len) + + +class Calculator: + def __init__(self, initial_value: float) -> None: + self.value: float = initial_value + + def add(self, n: float) -> "Calculator": + self.value += n + return self + + def subtract(self, n: float) -> "Calculator": + self.value -= n + return self + + def get_value(self) -> float: + return self.value diff --git a/plugins/python-type-annotations/examples/basic/before/hello.py b/plugins/python-type-annotations/examples/basic/before/hello.py new file mode 100644 index 0000000..5a92cdb --- /dev/null +++ b/plugins/python-type-annotations/examples/basic/before/hello.py @@ -0,0 +1,31 @@ +def greet(name): + """Return a greeting message.""" + return f"Hello, {name}!" + + +def add(a, b): + """Add two numbers.""" + return a + b + + +def find_longest(words): + """Find the longest word in a list.""" + if not words: + return None + return max(words, key=len) + + +class Calculator: + def __init__(self, initial_value): + self.value = initial_value + + def add(self, n): + self.value += n + return self + + def subtract(self, n): + self.value -= n + return self + + def get_value(self): + return self.value diff --git a/plugins/python-type-annotations/examples/basic/prompt.md b/plugins/python-type-annotations/examples/basic/prompt.md new file mode 100644 index 0000000..5f168c2 --- /dev/null +++ b/plugins/python-type-annotations/examples/basic/prompt.md @@ -0,0 +1 @@ +Add type annotations to all Python files in this directory. diff --git a/plugins/python-type-annotations/examples/basic/trajectory.json b/plugins/python-type-annotations/examples/basic/trajectory.json new file mode 100644 index 0000000..ca70eec --- /dev/null +++ b/plugins/python-type-annotations/examples/basic/trajectory.json @@ -0,0 +1,8 @@ +{ + "metadata": { + "model": "anthropic/claude-sonnet-4-6-20250514", + "plugin": "python-type-annotations", + "prompt": "Add type annotations to all Python files in this directory." + }, + "events": [] +} diff --git a/plugins/python-type-annotations/skills/type-annotations/SKILL.md b/plugins/python-type-annotations/skills/type-annotations/SKILL.md new file mode 100644 index 0000000..322139b --- /dev/null +++ b/plugins/python-type-annotations/skills/type-annotations/SKILL.md @@ -0,0 +1,69 @@ +--- +description: Add valid Python type annotations to functions, methods, and variables +triggers: + - type annotations + - add types + - annotate python + - type hints +--- + +# Python Type Annotations + +Add comprehensive, valid Python type annotations to Python files. + +## Instructions + +When asked to add type annotations to a Python file or directory: + +1. **Analyze the code** to understand: + - Function parameters and their expected types + - Return values + - Class attributes and instance variables + - Module-level variables + +2. **Add appropriate type annotations**: + - Use built-in types: `str`, `int`, `float`, `bool`, `bytes`, `None` + - Use `list[T]`, `dict[K, V]`, `set[T]`, `tuple[T, ...]` for collections (Python 3.9+) + - Use `Optional[T]` or `T | None` for nullable types + - Use `Union[A, B]` or `A | B` for multiple possible types + - Use `Any` sparingly, only when the type is truly dynamic + - Use `Callable[[Args], Return]` for function types + - Import from `typing` module when needed: `from typing import Optional, Union, Any, Callable` + +3. **Follow best practices**: + - Annotate all function parameters and return types + - Annotate class attributes in `__init__` or as class variables + - Use descriptive type aliases for complex types + - Preserve existing annotations if they are correct + - Do not change the logic or behavior of the code + +4. **Validate the annotations**: + - Ensure the file still runs without syntax errors + - Run `python -m py_compile ` to check syntax + - If mypy is available, run `mypy ` to verify types + +## Example Transformation + +**Before:** +```python +def greet(name): + return f"Hello, {name}!" + +def add_numbers(a, b): + return a + b +``` + +**After:** +```python +def greet(name: str) -> str: + return f"Hello, {name}!" + +def add_numbers(a: int, b: int) -> int: + return a + b +``` + +## Notes + +- Prefer `X | None` over `Optional[X]` for Python 3.10+ +- Use `list` instead of `List` for Python 3.9+ +- Add `from __future__ import annotations` for forward references in older Python versions diff --git a/plugins/python-type-annotations/workflows/update-example.yml b/plugins/python-type-annotations/workflows/update-example.yml new file mode 100644 index 0000000..ff95e59 --- /dev/null +++ b/plugins/python-type-annotations/workflows/update-example.yml @@ -0,0 +1,45 @@ +name: Update Example + +on: + workflow_dispatch: + +jobs: + update-example: + runs-on: ubuntu-latest + + steps: + - name: Checkout repository + uses: actions/checkout@v4 + + - name: Set up Python + uses: actions/setup-python@v5 + with: + python-version: "3.12" + + - name: Install OpenHands CLI + run: pip install openhands + + - name: Copy before to after + run: | + cp -r plugins/python-type-annotations/examples/basic/before/* \ + plugins/python-type-annotations/examples/basic/after/ + + - name: Run OpenHands with plugin + working-directory: plugins/python-type-annotations/examples/basic/after + env: + ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} + LLM_MODEL: anthropic/claude-sonnet-4-6-20250514 + run: | + openhands run \ + --plugin ../../../ \ + --prompt "$(cat ../prompt.md)" \ + --trajectory ../trajectory.json + + - name: Commit and push changes + run: | + git config user.name "github-actions[bot]" + git config user.email "github-actions[bot]@users.noreply.github.com" + git add plugins/python-type-annotations/examples/basic/after/ + git add plugins/python-type-annotations/examples/basic/trajectory.json + git diff --cached --quiet || git commit -m "Update example output with type annotations" + git push From 01b2811a3425078073c09a8f402a799c324e4858 Mon Sep 17 00:00:00 2001 From: openhands Date: Sun, 15 Mar 2026 22:29:49 +0000 Subject: [PATCH 02/11] Move workflow to .github/workflows with branch input - Moved update-example.yml to .github/workflows/update-type-annotations-example.yml - Added workflow_dispatch input to specify branch (defaults to current branch) - Updated README to reference new workflow location Co-authored-by: openhands --- .../workflows/update-type-annotations-example.yml | 11 +++++++++-- plugins/python-type-annotations/README.md | 5 ++--- 2 files changed, 11 insertions(+), 5 deletions(-) rename plugins/python-type-annotations/workflows/update-example.yml => .github/workflows/update-type-annotations-example.yml (78%) diff --git a/plugins/python-type-annotations/workflows/update-example.yml b/.github/workflows/update-type-annotations-example.yml similarity index 78% rename from plugins/python-type-annotations/workflows/update-example.yml rename to .github/workflows/update-type-annotations-example.yml index ff95e59..ed90c34 100644 --- a/plugins/python-type-annotations/workflows/update-example.yml +++ b/.github/workflows/update-type-annotations-example.yml @@ -1,7 +1,12 @@ -name: Update Example +name: Update Type Annotations Example on: workflow_dispatch: + inputs: + branch: + description: "Branch to run on (leave empty for current branch)" + required: false + default: "" jobs: update-example: @@ -10,6 +15,8 @@ jobs: steps: - name: Checkout repository uses: actions/checkout@v4 + with: + ref: ${{ github.event.inputs.branch || github.ref }} - name: Set up Python uses: actions/setup-python@v5 @@ -41,5 +48,5 @@ jobs: git config user.email "github-actions[bot]@users.noreply.github.com" git add plugins/python-type-annotations/examples/basic/after/ git add plugins/python-type-annotations/examples/basic/trajectory.json - git diff --cached --quiet || git commit -m "Update example output with type annotations" + git diff --cached --quiet || git commit -m "Update type annotations example output" git push diff --git a/plugins/python-type-annotations/README.md b/plugins/python-type-annotations/README.md index d3e84c9..8c864c9 100644 --- a/plugins/python-type-annotations/README.md +++ b/plugins/python-type-annotations/README.md @@ -49,7 +49,7 @@ See the `examples/basic/` directory for a before/after example: ## Testing -The `workflows/update-example.yml` GitHub Action can be triggered manually to regenerate the `after/` example using the current plugin and OpenHands CLI. +The [`update-type-annotations-example.yml`](../../.github/workflows/update-type-annotations-example.yml) GitHub Action can be triggered manually to regenerate the `after/` example using the current plugin and OpenHands CLI. You can run it on any branch or on main. ## Plugin Structure @@ -63,11 +63,10 @@ python-type-annotations/ ├── examples/ │ └── basic/ │ ├── prompt.md +│ ├── trajectory.json │ ├── before/ │ │ └── hello.py │ └── after/ │ └── hello.py -├── workflows/ -│ └── update-example.yml └── README.md ``` From c2a680aa9e7d4e2bebcf958c8e642d55d8a8940a Mon Sep 17 00:00:00 2001 From: openhands Date: Sun, 15 Mar 2026 22:42:42 +0000 Subject: [PATCH 03/11] Trigger workflow on changes to python-type-annotations plugin Co-authored-by: openhands --- .github/workflows/update-type-annotations-example.yml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/.github/workflows/update-type-annotations-example.yml b/.github/workflows/update-type-annotations-example.yml index ed90c34..023feab 100644 --- a/.github/workflows/update-type-annotations-example.yml +++ b/.github/workflows/update-type-annotations-example.yml @@ -7,6 +7,10 @@ on: description: "Branch to run on (leave empty for current branch)" required: false default: "" + push: + paths: + - "plugins/python-type-annotations/**" + - ".github/workflows/update-type-annotations-example.yml" jobs: update-example: From a28cca492b0898b0a7d18d1582d1dad074366609 Mon Sep 17 00:00:00 2001 From: openhands Date: Sun, 15 Mar 2026 22:43:08 +0000 Subject: [PATCH 04/11] Rename workflow to update-example.yaml Co-authored-by: openhands --- ...{update-type-annotations-example.yml => update-example.yaml} | 2 +- plugins/python-type-annotations/README.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) rename .github/workflows/{update-type-annotations-example.yml => update-example.yaml} (96%) diff --git a/.github/workflows/update-type-annotations-example.yml b/.github/workflows/update-example.yaml similarity index 96% rename from .github/workflows/update-type-annotations-example.yml rename to .github/workflows/update-example.yaml index 023feab..062f7fe 100644 --- a/.github/workflows/update-type-annotations-example.yml +++ b/.github/workflows/update-example.yaml @@ -10,7 +10,7 @@ on: push: paths: - "plugins/python-type-annotations/**" - - ".github/workflows/update-type-annotations-example.yml" + - ".github/workflows/update-example.yaml" jobs: update-example: diff --git a/plugins/python-type-annotations/README.md b/plugins/python-type-annotations/README.md index 8c864c9..54fa840 100644 --- a/plugins/python-type-annotations/README.md +++ b/plugins/python-type-annotations/README.md @@ -49,7 +49,7 @@ See the `examples/basic/` directory for a before/after example: ## Testing -The [`update-type-annotations-example.yml`](../../.github/workflows/update-type-annotations-example.yml) GitHub Action can be triggered manually to regenerate the `after/` example using the current plugin and OpenHands CLI. You can run it on any branch or on main. +The [`update-example.yaml`](../../.github/workflows/update-example.yaml) GitHub Action can be triggered manually to regenerate the `after/` example using the current plugin and OpenHands CLI. You can run it on any branch or on main. It also runs automatically on any push that changes the plugin. ## Plugin Structure From b712e60f74bf12ddeee0acfbc368c0b6a463c3e6 Mon Sep 17 00:00:00 2001 From: openhands Date: Sun, 15 Mar 2026 22:48:50 +0000 Subject: [PATCH 05/11] Fix workflow to use correct OpenHands CLI syntax - Use 'openhands --headless --json -f' instead of 'openhands run' - Copy skills to .agents/skills/ in working directory - Use LLM_API_KEY env var (not ANTHROPIC_API_KEY directly) - Clean up .agents directory after run Co-authored-by: openhands --- .github/workflows/update-example.yaml | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/.github/workflows/update-example.yaml b/.github/workflows/update-example.yaml index 062f7fe..f277087 100644 --- a/.github/workflows/update-example.yaml +++ b/.github/workflows/update-example.yaml @@ -35,16 +35,23 @@ jobs: cp -r plugins/python-type-annotations/examples/basic/before/* \ plugins/python-type-annotations/examples/basic/after/ - - name: Run OpenHands with plugin + - name: Set up skills directory + run: | + mkdir -p plugins/python-type-annotations/examples/basic/after/.agents/skills + cp -r plugins/python-type-annotations/skills/* \ + plugins/python-type-annotations/examples/basic/after/.agents/skills/ + + - name: Run OpenHands in headless mode working-directory: plugins/python-type-annotations/examples/basic/after env: - ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} + LLM_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} LLM_MODEL: anthropic/claude-sonnet-4-6-20250514 run: | - openhands run \ - --plugin ../../../ \ - --prompt "$(cat ../prompt.md)" \ - --trajectory ../trajectory.json + openhands --headless --json -f ../prompt.md > ../trajectory.json + + - name: Clean up skills directory + run: | + rm -rf plugins/python-type-annotations/examples/basic/after/.agents - name: Commit and push changes run: | From 2fb5816ae81aacafdb0ddb5ac0fe8693981172b3 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Sun, 15 Mar 2026 22:49:46 +0000 Subject: [PATCH 06/11] Update type annotations example output --- .../examples/basic/after/hello.py | 16 ++++++++-------- .../examples/basic/trajectory.json | 16 ++++++++-------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/plugins/python-type-annotations/examples/basic/after/hello.py b/plugins/python-type-annotations/examples/basic/after/hello.py index ed45580..5a92cdb 100644 --- a/plugins/python-type-annotations/examples/basic/after/hello.py +++ b/plugins/python-type-annotations/examples/basic/after/hello.py @@ -1,14 +1,14 @@ -def greet(name: str) -> str: +def greet(name): """Return a greeting message.""" return f"Hello, {name}!" -def add(a: int, b: int) -> int: +def add(a, b): """Add two numbers.""" return a + b -def find_longest(words: list[str]) -> str | None: +def find_longest(words): """Find the longest word in a list.""" if not words: return None @@ -16,16 +16,16 @@ def find_longest(words: list[str]) -> str | None: class Calculator: - def __init__(self, initial_value: float) -> None: - self.value: float = initial_value + def __init__(self, initial_value): + self.value = initial_value - def add(self, n: float) -> "Calculator": + def add(self, n): self.value += n return self - def subtract(self, n: float) -> "Calculator": + def subtract(self, n): self.value -= n return self - def get_value(self) -> float: + def get_value(self): return self.value diff --git a/plugins/python-type-annotations/examples/basic/trajectory.json b/plugins/python-type-annotations/examples/basic/trajectory.json index ca70eec..5be45fc 100644 --- a/plugins/python-type-annotations/examples/basic/trajectory.json +++ b/plugins/python-type-annotations/examples/basic/trajectory.json @@ -1,8 +1,8 @@ -{ - "metadata": { - "model": "anthropic/claude-sonnet-4-6-20250514", - "plugin": "python-type-annotations", - "prompt": "Add type annotations to all Python files in this directory." - }, - "events": [] -} +OpenHands CLI terminal UI may not work correctly in this environment: Rich detected a non-interactive or unsupported terminal; interactive UI may not render correctly +To override Rich's detection, you can set TTY_INTERACTIVE=1 (and optionally TTY_COMPATIBLE=1). +Headless mode requires existing settings. +Please run: openhands to configure your settings before using --headless. +Goodbye! 👋 +Conversation ID: ca820ab0dfbb4ea8a1d8fa067db667fb +Hint: run openhands --resume ca820ab0-dfbb-4ea8-a1d8-fa067db667fb to resume this +conversation. From 6523fb4c2ff517c5c945b6f967614bbea398f37d Mon Sep 17 00:00:00 2001 From: openhands Date: Sun, 15 Mar 2026 22:56:55 +0000 Subject: [PATCH 07/11] Fix headless mode by using --override-with-envs flag - Added --override-with-envs flag to allow headless mode without pre-existing settings - Made LLM_MODEL and LLM_BASE_URL configurable as workflow inputs - Changed from ANTHROPIC_API_KEY to LLM_API_KEY secret (standard env var name) - LLM_BASE_URL is optional and can be set via secret or workflow input Co-authored-by: openhands --- .github/workflows/update-example.yaml | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/.github/workflows/update-example.yaml b/.github/workflows/update-example.yaml index f277087..42618f3 100644 --- a/.github/workflows/update-example.yaml +++ b/.github/workflows/update-example.yaml @@ -7,6 +7,14 @@ on: description: "Branch to run on (leave empty for current branch)" required: false default: "" + llm_model: + description: "LLM model to use" + required: false + default: "anthropic/claude-sonnet-4-6-20250514" + llm_base_url: + description: "LLM base URL (optional)" + required: false + default: "" push: paths: - "plugins/python-type-annotations/**" @@ -44,10 +52,11 @@ jobs: - name: Run OpenHands in headless mode working-directory: plugins/python-type-annotations/examples/basic/after env: - LLM_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }} - LLM_MODEL: anthropic/claude-sonnet-4-6-20250514 + LLM_API_KEY: ${{ secrets.LLM_API_KEY }} + LLM_MODEL: ${{ github.event.inputs.llm_model || 'anthropic/claude-sonnet-4-6-20250514' }} + LLM_BASE_URL: ${{ github.event.inputs.llm_base_url || secrets.LLM_BASE_URL }} run: | - openhands --headless --json -f ../prompt.md > ../trajectory.json + openhands --headless --override-with-envs --json -f ../prompt.md > ../trajectory.json - name: Clean up skills directory run: | From 6c5958e4566bbaa07c8cf35bb6c4ae41541971b8 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Sun, 15 Mar 2026 22:59:59 +0000 Subject: [PATCH 08/11] Update type annotations example output --- .../examples/basic/trajectory.json | 380 +++++++++++++++++- 1 file changed, 376 insertions(+), 4 deletions(-) diff --git a/plugins/python-type-annotations/examples/basic/trajectory.json b/plugins/python-type-annotations/examples/basic/trajectory.json index 5be45fc..7b5d1b3 100644 --- a/plugins/python-type-annotations/examples/basic/trajectory.json +++ b/plugins/python-type-annotations/examples/basic/trajectory.json @@ -1,8 +1,380 @@ OpenHands CLI terminal UI may not work correctly in this environment: Rich detected a non-interactive or unsupported terminal; interactive UI may not render correctly To override Rich's detection, you can set TTY_INTERACTIVE=1 (and optionally TTY_COMPATIBLE=1). -Headless mode requires existing settings. -Please run: openhands to configure your settings before using --headless. +Initializing agent... +✓ Agent initialized with model: anthropic/claude-sonnet-4-6-20250514 +--JSON Event-- +{ + "activated_skills": [ + "type-annotations" + ], + "critic_result": null, + "extended_content": [ + { + "cache_prompt": false, + "text": "\nThe following information has been included based on a keyword match for \"type annotations\".\nIt may or may not be relevant to the user's request.\n\nSkill location: /home/runner/work/extensions/extensions/plugins/python-type-annotations/examples/basic/after/.agents/skills/type-annotations/SKILL.md\n(Use this path to resolve relative file references in the skill content below)\n\n\n# Python Type Annotations\n\nAdd comprehensive, valid Python type annotations to Python files.\n\n## Instructions\n\nWhen asked to add type annotations to a Python file or directory:\n\n1. **Analyze the code** to understand:\n - Function parameters and their expected types\n - Return values\n - Class attributes and instance variables\n - Module-level variables\n\n2. **Add appropriate type annotations**:\n - Use built-in types: `str`, `int`, `float`, `bool`, `bytes`, `None`\n - Use `list[T]`, `dict[K, V]`, `set[T]`, `tuple[T, ...]` for collections (Python 3.9+)\n - Use `Optional[T]` or `T | None` for nullable types\n - Use `Union[A, B]` or `A | B` for multiple possible types\n - Use `Any` sparingly, only when the type is truly dynamic\n - Use `Callable[[Args], Return]` for function types\n - Import from `typing` module when needed: `from typing import Optional, Union, Any, Callable`\n\n3. **Follow best practices**:\n - Annotate all function parameters and return types\n - Annotate class attributes in `__init__` or as class variables\n - Use descriptive type aliases for complex types\n - Preserve existing annotations if they are correct\n - Do not change the logic or behavior of the code\n\n4. **Validate the annotations**:\n - Ensure the file still runs without syntax errors\n - Run `python -m py_compile ` to check syntax\n - If mypy is available, run `mypy ` to verify types\n\n## Example Transformation\n\n**Before:**\n```python\ndef greet(name):\n return f\"Hello, {name}!\"\n\ndef add_numbers(a, b):\n return a + b\n```\n\n**After:**\n```python\ndef greet(name: str) -> str:\n return f\"Hello, {name}!\"\n\ndef add_numbers(a: int, b: int) -> int:\n return a + b\n```\n\n## Notes\n\n- Prefer `X | None` over `Optional[X]` for Python 3.10+\n- Use `list` instead of `List` for Python 3.9+\n- Add `from __future__ import annotations` for forward references in older Python versions\n", + "type": "text" + } + ], + "id": "87217b31-39ca-459e-ad67-a82851a59a8b", + "kind": "MessageEvent", + "llm_message": { + "content": [ + { + "cache_prompt": false, + "text": "Starting this session with file context.\n\nFile path: ../prompt.md\n\nFile contents:\n--------------------\nAdd type annotations to all Python files in this directory.\n\n--------------------\n", + "type": "text" + } + ], + "name": null, + "reasoning_content": null, + "responses_reasoning_item": null, + "role": "user", + "thinking_blocks": [], + "tool_call_id": null, + "tool_calls": null + }, + "llm_response_id": null, + "sender": null, + "source": "user", + "timestamp": "2026-03-15T22:57:57.028624" +} +Agent is working +--JSON Event-- +{ + "code": "LLMServiceUnavailableError", + "detail": "litellm.InternalServerError: AnthropicException - [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1010). Handle with `litellm.InternalServerError`.", + "id": "2df79a37-741b-496e-a1b6-22c3c3ee7e22", + "kind": "ConversationErrorEvent", + "source": "environment", + "timestamp": "2026-03-15T22:59:58.574918" +} + +───────────────────────────── CONVERSATION SUMMARY ───────────────────────────── +Number of agent messages: 1 +Last message sent by the agent: +╭─ Agent ──────────────────────────────────────────────────────────────────────╮ +│ System Prompt: │ +│ You are OpenHands agent, a helpful AI assistant that can interact with a │ +│ computer to solve tasks. │ +│ │ +│ │ +│ * Your primary role is to assist users by executing commands, modifying │ +│ code, and solving technical problems effectively. You should be thorough, │ +│ methodical, and prioritize quality over speed. │ +│ * If the user asks a question, like "why is X happening", don't try to fix │ +│ the problem. Just give an answer to the question. │ +│ │ +│ │ +│ │ +│ * Use `AGENTS.md` under the repository root as your persistent memory for │ +│ repository-specific knowledge and context. │ +│ * Add important insights, patterns, and learnings to this file to improve │ +│ future task performance. │ +│ * This repository skill is automatically loaded for every conversation and │ +│ helps maintain context across sessions. │ +│ * For more information about skills, see: │ +│ https://docs.openhands.dev/overview/skills │ +│ │ +│ │ +│ │ +│ * Each action you take is somewhat expensive. Wherever possible, combine │ +│ multiple actions into a single action, e.g. combine multiple bash commands │ +│ into one, using sed and grep to edit/view multiple files at once. │ +│ * When exploring the codebase, use efficient tools like find, grep, and git │ +│ commands with appropriate filters to minimize unnecessary operations. │ +│ │ +│ │ +│ │ +│ * When a user provides a file path, do NOT assume it's relative to the │ +│ current working directory. First explore the file system to locate the file │ +│ before working on it. │ +│ * If asked to edit a file, edit the file directly, rather than creating a │ +│ new file with a different filename. │ +│ * For global search-and-replace operations, consider using `sed` instead of │ +│ opening file editors multiple times. │ +│ * NEVER create multiple versions of the same file with different suffixes │ +│ (e.g., file_test.py, file_fix.py, file_simple.py). Instead: │ +│ - Always modify the original file directly when making changes │ +│ - If you need to create a temporary file for testing, delete it once │ +│ you've confirmed your solution works │ +│ - If you decide a file you created is no longer useful, delete it instead │ +│ of creating a new version │ +│ * Do NOT include documentation files explaining your changes in version │ +│ control unless the user explicitly requests it │ +│ * When reproducing bugs or implementing fixes, use a single file rather than │ +│ creating multiple files with different versions │ +│ │ +│ │ +│ │ +│ * Write clean, efficient code with minimal comments. Avoid redundancy in │ +│ comments: Do not repeat information that can be easily inferred from the │ +│ code itself. │ +│ * When implementing solutions, focus on making the minimal changes needed to │ +│ solve the problem. │ +│ * Before implementing any changes, first thoroughly understand the codebase │ +│ through exploration. │ +│ * If you are adding a lot of code to a function or file, consider splitting │ +│ the function or file into smaller pieces when appropriate. │ +│ * Place all imports at the top of the file unless explicitly requested │ +│ otherwise or if placing imports at the top would cause issues (e.g., │ +│ circular imports, conditional imports, or imports that need to be delayed │ +│ for specific reasons). │ +│ │ +│ │ +│ │ +│ * If there are existing git user credentials already configured, use them │ +│ and add Co-authored-by: openhands to any commits │ +│ messages you make. if a git config doesn't exist use "openhands" as the │ +│ user.name and "openhands@all-hands.dev" as the user.email by default, unless │ +│ explicitly instructed otherwise. │ +│ * Exercise caution with git operations. Do NOT make potentially dangerous │ +│ changes (e.g., pushing to main, deleting repositories) unless explicitly │ +│ asked to do so. │ +│ * When committing changes, use `git status` to see all modified files, and │ +│ stage all files necessary for the commit. Use `git commit -a` whenever │ +│ possible. │ +│ * Do NOT commit files that typically shouldn't go into version control │ +│ (e.g., node_modules/, .env files, build directories, cache files, large │ +│ binaries) unless explicitly instructed by the user. │ +│ * If unsure about committing certain files, check for the presence of │ +│ .gitignore files or ask the user for clarification. │ +│ * When running git commands that may produce paged output (e.g., `git diff`, │ +│ `git log`, `git show`), use `git --no-pager ` or set │ +│ `GIT_PAGER=cat` to prevent the command from getting stuck waiting for │ +│ interactive input. │ +│ │ +│ │ +│ │ +│ * **Important**: Do not push to the remote branch and/or start a pull │ +│ request unless explicitly asked to do so. │ +│ * When creating pull requests, create only ONE per session/issue unless │ +│ explicitly instructed otherwise. │ +│ * When working with an existing PR, update it with new commits rather than │ +│ creating additional PRs for the same issue. │ +│ * When updating a PR, preserve the original PR title and purpose, updating │ +│ description only when necessary. │ +│ │ +│ │ +│ │ +│ 1. EXPLORATION: Thoroughly explore relevant files and understand the context │ +│ before proposing solutions │ +│ 2. ANALYSIS: Consider multiple approaches and select the most promising one │ +│ 3. TESTING: │ +│ * For bug fixes: Create tests to verify issues before implementing fixes │ +│ * For new features: Consider test-driven development when appropriate │ +│ * Do NOT write tests for documentation changes, README updates, │ +│ configuration files, or other non-functionality changes │ +│ * Do not use mocks in tests unless strictly necessary and justify their │ +│ use when they are used. You must always test real code paths in tests, NOT │ +│ mocks. │ +│ * If the repository lacks testing infrastructure and implementing tests │ +│ would require extensive setup, consult with the user before investing time │ +│ in building testing infrastructure │ +│ * If the environment is not set up to run tests, consult with the user │ +│ first before investing time to install all dependencies │ +│ 4. IMPLEMENTATION: │ +│ * Make focused, minimal changes to address the problem │ +│ * Always modify existing files directly rather than creating new versions │ +│ with different suffixes │ +│ * If you create temporary files for testing, delete them after confirming │ +│ your solution works │ +│ 5. VERIFICATION: If the environment is set up to run tests, test your │ +│ implementation thoroughly, including edge cases. If the environment is not │ +│ set up to run tests, consult with the user first before investing time to │ +│ run tests. │ +│ │ +│ │ +│ │ +│ When the user directly asks about any of the following: │ +│ - OpenHands capabilities (e.g., "can OpenHands do...", "does OpenHands │ +│ have...") │ +│ - what you're able to do in second person (e.g., "are you able...", "can │ +│ you...") │ +│ - how to use a specific OpenHands feature or product │ +│ - how to use the OpenHands SDK, CLI, GUI, or other OpenHands products │ +│ │ +│ Get accurate information from the official OpenHands documentation at │ +│ . The documentation includes: │ +│ │ +│ **OpenHands SDK** (`/sdk/*`): Python library for building AI agents; Getting │ +│ Started, Architecture, Guides (agent, llm, conversation, tools), API │ +│ Reference │ +│ **OpenHands CLI** (`/openhands/usage/run-openhands/cli-mode`): Command-line │ +│ interface │ +│ **OpenHands GUI** (`/openhands/usage/run-openhands/local-setup`): Local GUI │ +│ and REST API │ +│ **OpenHands Cloud** (`/openhands/usage/run-openhands/cloud`): Hosted │ +│ solution with integrations │ +│ **OpenHands Enterprise**: Self-hosted deployment with extended support │ +│ │ +│ Always provide links to the relevant documentation pages for users who want │ +│ to learn more. │ +│ │ +│ │ +│ │ +│ # 🔐 Security Policy │ +│ │ +│ ## OK to do without Explicit User Consent │ +│ │ +│ - Download and run code from a repository specified by a user │ +│ - Open pull requests on the original repositories where the code is stored │ +│ - Install and run popular packages from pypi, npm, or other package managers │ +│ - Use APIs to work with GitHub or other platforms, unless the user asks │ +│ otherwise or your task requires browsing │ +│ │ +│ ## Do only with Explicit User Consent │ +│ │ +│ - Upload code to anywhere other than the location where it was obtained from │ +│ - Upload API keys or tokens anywhere, except when using them to authenticate │ +│ with the appropriate service │ +│ │ +│ ## Never Do │ +│ │ +│ - Never perform any illegal activities, such as circumventing security to │ +│ access a system that is not under your control or performing │ +│ denial-of-service attacks on external servers │ +│ - Never run software to mine cryptocurrency │ +│ │ +│ ## General Security Guidelines │ +│ │ +│ - Only use GITHUB_TOKEN and other credentials in ways the user has │ +│ explicitly requested and would expect │ +│ │ +│ │ +│ │ +│ │ +│ # Security Risk Policy │ +│ When using tools that support the security_risk parameter, assess the safety │ +│ risk of your actions: │ +│ │ +│ │ +│ - **LOW**: Safe, read-only actions. │ +│ - Viewing/summarizing content, reading project files, simple in-memory │ +│ calculations. │ +│ - **MEDIUM**: Project-scoped edits or execution. │ +│ - Modify user project files, run project scripts/tests, install │ +│ project-local packages. │ +│ - **HIGH**: System-level or untrusted operations. │ +│ - Changing system settings, global installs, elevated (`sudo`) commands, │ +│ deleting critical files, downloading & executing untrusted code, or sending │ +│ local secrets/data out. │ +│ │ +│ │ +│ **Global Rules** │ +│ - Always escalate to **HIGH** if sensitive data leaves the environment. │ +│ │ +│ │ +│ │ +│ │ +│ * When interacting with external services like GitHub, GitLab, or Bitbucket, │ +│ use their respective APIs instead of browser-based interactions whenever │ +│ possible. │ +│ * Only resort to browser-based interactions with these services if │ +│ specifically requested by the user or if the required operation cannot be │ +│ performed via API. │ +│ │ +│ │ +│ │ +│ * When user asks you to run an application, don't stop if the application is │ +│ not installed. Instead, please install the application and run the command │ +│ again. │ +│ * If you encounter missing dependencies: │ +│ 1. First, look around in the repository for existing dependency files │ +│ (requirements.txt, pyproject.toml, package.json, Gemfile, etc.) │ +│ 2. If dependency files exist, use them to install all dependencies at once │ +│ (e.g., `pip install -r requirements.txt`, `npm install`, etc.) │ +│ 3. Only install individual packages directly if no dependency files are │ +│ found or if only specific packages are needed │ +│ * Similarly, if you encounter missing dependencies for essential tools │ +│ requested by the user, install them when possible. │ +│ │ +│ │ +│ │ +│ * If you've made repeated attempts to solve a problem but tests still fail │ +│ or the user reports it's still broken: │ +│ 1. Step back and reflect on 5-7 different possible sources of the problem │ +│ 2. Assess the likelihood of each possible cause │ +│ 3. Methodically address the most likely causes, starting with the highest │ +│ probability │ +│ 4. Explain your reasoning process in your response to the user │ +│ * When you run into any major issue while executing a plan from the user, │ +│ please don't try to directly work around it. Instead, propose a new plan and │ +│ confirm with the user before proceeding. │ +│ │ +│ │ +│ │ +│ * When terminating processes: │ +│ - Do NOT use general keywords with commands like `pkill -f server` or │ +│ `pkill -f python` as this might accidentally kill other important servers or │ +│ processes │ +│ - Always use specific keywords that uniquely identify the target process │ +│ - Prefer using `ps aux` to find the exact process ID (PID) first, then │ +│ kill that specific PID │ +│ - When possible, use more targeted approaches like finding the PID from a │ +│ pidfile or using application-specific shutdown commands │ +│ │ +│ │ +│ │ +│ * Try to follow the instructions exactly as given - don't make extra or │ +│ fewer actions if not asked. │ +│ * Avoid unnecessary defensive programming; do not add redundant fallbacks or │ +│ default values — fail fast instead of masking misconfigurations. │ +│ * When backward compatibility expectations are unclear, confirm with the │ +│ user before making changes that could break existing behavior. │ +│ │ +│ │ +│ Dynamic Context: │ +│ │ +│ The current date and time is: 2026-03-15T22:57:55.633191 │ +│ │ +│ │ +│ │ +│ │ +│ │ +│ The following skills are available and may be triggered by keywords or task │ +│ types in your messages. │ +│ When a skill is triggered, you will receive additional context and │ +│ instructions. │ +│ You can also directly look up a skill's full content by reading its location │ +│ path, and use the skill's guidance proactively when relevant to your task. │ +│ │ +│ │ +│ │ +│ type-annotations Date: Sun, 15 Mar 2026 23:05:14 +0000 Subject: [PATCH 09/11] Export clean trajectory JSON from conversation events Instead of capturing noisy JSONL stdout: - Run headless mode and capture conversation ID from output - Export trajectory by combining event-*.json files from conversation dir - Produces clean JSON with conversation_id and events array Co-authored-by: openhands --- .github/workflows/update-example.yaml | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-) diff --git a/.github/workflows/update-example.yaml b/.github/workflows/update-example.yaml index 42618f3..c90e331 100644 --- a/.github/workflows/update-example.yaml +++ b/.github/workflows/update-example.yaml @@ -50,13 +50,38 @@ jobs: plugins/python-type-annotations/examples/basic/after/.agents/skills/ - name: Run OpenHands in headless mode + id: openhands working-directory: plugins/python-type-annotations/examples/basic/after env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} LLM_MODEL: ${{ github.event.inputs.llm_model || 'anthropic/claude-sonnet-4-6-20250514' }} LLM_BASE_URL: ${{ github.event.inputs.llm_base_url || secrets.LLM_BASE_URL }} run: | - openhands --headless --override-with-envs --json -f ../prompt.md > ../trajectory.json + # Run headless and capture conversation ID from output + output=$(openhands --headless --override-with-envs -f ../prompt.md 2>&1 | tee /dev/stderr) + conversation_id=$(echo "$output" | grep -oP 'Conversation ID: \K[a-f0-9]+' | tail -1) + echo "conversation_id=$conversation_id" >> $GITHUB_OUTPUT + + - name: Export trajectory + run: | + conversation_id="${{ steps.openhands.outputs.conversation_id }}" + if [ -n "$conversation_id" ]; then + # Combine all event files into a single trajectory JSON + events_dir="$HOME/.openhands/conversations/$conversation_id/events" + if [ -d "$events_dir" ]; then + echo '{"conversation_id": "'$conversation_id'", "events": [' > plugins/python-type-annotations/examples/basic/trajectory.json + first=true + for f in "$events_dir"/event-*.json; do + if [ "$first" = true ]; then + first=false + else + echo ',' >> plugins/python-type-annotations/examples/basic/trajectory.json + fi + cat "$f" >> plugins/python-type-annotations/examples/basic/trajectory.json + done + echo ']}' >> plugins/python-type-annotations/examples/basic/trajectory.json + fi + fi - name: Clean up skills directory run: | From bfae440c9622e5db86ee256722def05b8fbecaeb Mon Sep 17 00:00:00 2001 From: Robert Brennan Date: Sun, 15 Mar 2026 16:06:20 -0700 Subject: [PATCH 10/11] Apply suggestions from code review Co-authored-by: Robert Brennan --- .github/workflows/update-example.yaml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/update-example.yaml b/.github/workflows/update-example.yaml index c90e331..43f51e5 100644 --- a/.github/workflows/update-example.yaml +++ b/.github/workflows/update-example.yaml @@ -54,8 +54,8 @@ jobs: working-directory: plugins/python-type-annotations/examples/basic/after env: LLM_API_KEY: ${{ secrets.LLM_API_KEY }} - LLM_MODEL: ${{ github.event.inputs.llm_model || 'anthropic/claude-sonnet-4-6-20250514' }} - LLM_BASE_URL: ${{ github.event.inputs.llm_base_url || secrets.LLM_BASE_URL }} + LLM_MODEL: ${{ github.event.inputs.llm_model || secrets.LLM_MODEL }} + LLM_BASE_URL: ${{ secrets.LLM_BASE_URL }} run: | # Run headless and capture conversation ID from output output=$(openhands --headless --override-with-envs -f ../prompt.md 2>&1 | tee /dev/stderr) From 8ebc77f865773ead0bcab9f492303c5512a5216d Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Sun, 15 Mar 2026 23:07:21 +0000 Subject: [PATCH 11/11] Update type annotations example output --- .../examples/basic/trajectory.json | 384 +----------------- 1 file changed, 4 insertions(+), 380 deletions(-) diff --git a/plugins/python-type-annotations/examples/basic/trajectory.json b/plugins/python-type-annotations/examples/basic/trajectory.json index 7b5d1b3..e638af8 100644 --- a/plugins/python-type-annotations/examples/basic/trajectory.json +++ b/plugins/python-type-annotations/examples/basic/trajectory.json @@ -1,380 +1,4 @@ -OpenHands CLI terminal UI may not work correctly in this environment: Rich detected a non-interactive or unsupported terminal; interactive UI may not render correctly -To override Rich's detection, you can set TTY_INTERACTIVE=1 (and optionally TTY_COMPATIBLE=1). -Initializing agent... -✓ Agent initialized with model: anthropic/claude-sonnet-4-6-20250514 ---JSON Event-- -{ - "activated_skills": [ - "type-annotations" - ], - "critic_result": null, - "extended_content": [ - { - "cache_prompt": false, - "text": "\nThe following information has been included based on a keyword match for \"type annotations\".\nIt may or may not be relevant to the user's request.\n\nSkill location: /home/runner/work/extensions/extensions/plugins/python-type-annotations/examples/basic/after/.agents/skills/type-annotations/SKILL.md\n(Use this path to resolve relative file references in the skill content below)\n\n\n# Python Type Annotations\n\nAdd comprehensive, valid Python type annotations to Python files.\n\n## Instructions\n\nWhen asked to add type annotations to a Python file or directory:\n\n1. **Analyze the code** to understand:\n - Function parameters and their expected types\n - Return values\n - Class attributes and instance variables\n - Module-level variables\n\n2. **Add appropriate type annotations**:\n - Use built-in types: `str`, `int`, `float`, `bool`, `bytes`, `None`\n - Use `list[T]`, `dict[K, V]`, `set[T]`, `tuple[T, ...]` for collections (Python 3.9+)\n - Use `Optional[T]` or `T | None` for nullable types\n - Use `Union[A, B]` or `A | B` for multiple possible types\n - Use `Any` sparingly, only when the type is truly dynamic\n - Use `Callable[[Args], Return]` for function types\n - Import from `typing` module when needed: `from typing import Optional, Union, Any, Callable`\n\n3. **Follow best practices**:\n - Annotate all function parameters and return types\n - Annotate class attributes in `__init__` or as class variables\n - Use descriptive type aliases for complex types\n - Preserve existing annotations if they are correct\n - Do not change the logic or behavior of the code\n\n4. **Validate the annotations**:\n - Ensure the file still runs without syntax errors\n - Run `python -m py_compile ` to check syntax\n - If mypy is available, run `mypy ` to verify types\n\n## Example Transformation\n\n**Before:**\n```python\ndef greet(name):\n return f\"Hello, {name}!\"\n\ndef add_numbers(a, b):\n return a + b\n```\n\n**After:**\n```python\ndef greet(name: str) -> str:\n return f\"Hello, {name}!\"\n\ndef add_numbers(a: int, b: int) -> int:\n return a + b\n```\n\n## Notes\n\n- Prefer `X | None` over `Optional[X]` for Python 3.10+\n- Use `list` instead of `List` for Python 3.9+\n- Add `from __future__ import annotations` for forward references in older Python versions\n", - "type": "text" - } - ], - "id": "87217b31-39ca-459e-ad67-a82851a59a8b", - "kind": "MessageEvent", - "llm_message": { - "content": [ - { - "cache_prompt": false, - "text": "Starting this session with file context.\n\nFile path: ../prompt.md\n\nFile contents:\n--------------------\nAdd type annotations to all Python files in this directory.\n\n--------------------\n", - "type": "text" - } - ], - "name": null, - "reasoning_content": null, - "responses_reasoning_item": null, - "role": "user", - "thinking_blocks": [], - "tool_call_id": null, - "tool_calls": null - }, - "llm_response_id": null, - "sender": null, - "source": "user", - "timestamp": "2026-03-15T22:57:57.028624" -} -Agent is working ---JSON Event-- -{ - "code": "LLMServiceUnavailableError", - "detail": "litellm.InternalServerError: AnthropicException - [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: certificate has expired (_ssl.c:1010). Handle with `litellm.InternalServerError`.", - "id": "2df79a37-741b-496e-a1b6-22c3c3ee7e22", - "kind": "ConversationErrorEvent", - "source": "environment", - "timestamp": "2026-03-15T22:59:58.574918" -} - -───────────────────────────── CONVERSATION SUMMARY ───────────────────────────── -Number of agent messages: 1 -Last message sent by the agent: -╭─ Agent ──────────────────────────────────────────────────────────────────────╮ -│ System Prompt: │ -│ You are OpenHands agent, a helpful AI assistant that can interact with a │ -│ computer to solve tasks. │ -│ │ -│ │ -│ * Your primary role is to assist users by executing commands, modifying │ -│ code, and solving technical problems effectively. You should be thorough, │ -│ methodical, and prioritize quality over speed. │ -│ * If the user asks a question, like "why is X happening", don't try to fix │ -│ the problem. Just give an answer to the question. │ -│ │ -│ │ -│ │ -│ * Use `AGENTS.md` under the repository root as your persistent memory for │ -│ repository-specific knowledge and context. │ -│ * Add important insights, patterns, and learnings to this file to improve │ -│ future task performance. │ -│ * This repository skill is automatically loaded for every conversation and │ -│ helps maintain context across sessions. │ -│ * For more information about skills, see: │ -│ https://docs.openhands.dev/overview/skills │ -│ │ -│ │ -│ │ -│ * Each action you take is somewhat expensive. Wherever possible, combine │ -│ multiple actions into a single action, e.g. combine multiple bash commands │ -│ into one, using sed and grep to edit/view multiple files at once. │ -│ * When exploring the codebase, use efficient tools like find, grep, and git │ -│ commands with appropriate filters to minimize unnecessary operations. │ -│ │ -│ │ -│ │ -│ * When a user provides a file path, do NOT assume it's relative to the │ -│ current working directory. First explore the file system to locate the file │ -│ before working on it. │ -│ * If asked to edit a file, edit the file directly, rather than creating a │ -│ new file with a different filename. │ -│ * For global search-and-replace operations, consider using `sed` instead of │ -│ opening file editors multiple times. │ -│ * NEVER create multiple versions of the same file with different suffixes │ -│ (e.g., file_test.py, file_fix.py, file_simple.py). Instead: │ -│ - Always modify the original file directly when making changes │ -│ - If you need to create a temporary file for testing, delete it once │ -│ you've confirmed your solution works │ -│ - If you decide a file you created is no longer useful, delete it instead │ -│ of creating a new version │ -│ * Do NOT include documentation files explaining your changes in version │ -│ control unless the user explicitly requests it │ -│ * When reproducing bugs or implementing fixes, use a single file rather than │ -│ creating multiple files with different versions │ -│ │ -│ │ -│ │ -│ * Write clean, efficient code with minimal comments. Avoid redundancy in │ -│ comments: Do not repeat information that can be easily inferred from the │ -│ code itself. │ -│ * When implementing solutions, focus on making the minimal changes needed to │ -│ solve the problem. │ -│ * Before implementing any changes, first thoroughly understand the codebase │ -│ through exploration. │ -│ * If you are adding a lot of code to a function or file, consider splitting │ -│ the function or file into smaller pieces when appropriate. │ -│ * Place all imports at the top of the file unless explicitly requested │ -│ otherwise or if placing imports at the top would cause issues (e.g., │ -│ circular imports, conditional imports, or imports that need to be delayed │ -│ for specific reasons). │ -│ │ -│ │ -│ │ -│ * If there are existing git user credentials already configured, use them │ -│ and add Co-authored-by: openhands to any commits │ -│ messages you make. if a git config doesn't exist use "openhands" as the │ -│ user.name and "openhands@all-hands.dev" as the user.email by default, unless │ -│ explicitly instructed otherwise. │ -│ * Exercise caution with git operations. Do NOT make potentially dangerous │ -│ changes (e.g., pushing to main, deleting repositories) unless explicitly │ -│ asked to do so. │ -│ * When committing changes, use `git status` to see all modified files, and │ -│ stage all files necessary for the commit. Use `git commit -a` whenever │ -│ possible. │ -│ * Do NOT commit files that typically shouldn't go into version control │ -│ (e.g., node_modules/, .env files, build directories, cache files, large │ -│ binaries) unless explicitly instructed by the user. │ -│ * If unsure about committing certain files, check for the presence of │ -│ .gitignore files or ask the user for clarification. │ -│ * When running git commands that may produce paged output (e.g., `git diff`, │ -│ `git log`, `git show`), use `git --no-pager ` or set │ -│ `GIT_PAGER=cat` to prevent the command from getting stuck waiting for │ -│ interactive input. │ -│ │ -│ │ -│ │ -│ * **Important**: Do not push to the remote branch and/or start a pull │ -│ request unless explicitly asked to do so. │ -│ * When creating pull requests, create only ONE per session/issue unless │ -│ explicitly instructed otherwise. │ -│ * When working with an existing PR, update it with new commits rather than │ -│ creating additional PRs for the same issue. │ -│ * When updating a PR, preserve the original PR title and purpose, updating │ -│ description only when necessary. │ -│ │ -│ │ -│ │ -│ 1. EXPLORATION: Thoroughly explore relevant files and understand the context │ -│ before proposing solutions │ -│ 2. ANALYSIS: Consider multiple approaches and select the most promising one │ -│ 3. TESTING: │ -│ * For bug fixes: Create tests to verify issues before implementing fixes │ -│ * For new features: Consider test-driven development when appropriate │ -│ * Do NOT write tests for documentation changes, README updates, │ -│ configuration files, or other non-functionality changes │ -│ * Do not use mocks in tests unless strictly necessary and justify their │ -│ use when they are used. You must always test real code paths in tests, NOT │ -│ mocks. │ -│ * If the repository lacks testing infrastructure and implementing tests │ -│ would require extensive setup, consult with the user before investing time │ -│ in building testing infrastructure │ -│ * If the environment is not set up to run tests, consult with the user │ -│ first before investing time to install all dependencies │ -│ 4. IMPLEMENTATION: │ -│ * Make focused, minimal changes to address the problem │ -│ * Always modify existing files directly rather than creating new versions │ -│ with different suffixes │ -│ * If you create temporary files for testing, delete them after confirming │ -│ your solution works │ -│ 5. VERIFICATION: If the environment is set up to run tests, test your │ -│ implementation thoroughly, including edge cases. If the environment is not │ -│ set up to run tests, consult with the user first before investing time to │ -│ run tests. │ -│ │ -│ │ -│ │ -│ When the user directly asks about any of the following: │ -│ - OpenHands capabilities (e.g., "can OpenHands do...", "does OpenHands │ -│ have...") │ -│ - what you're able to do in second person (e.g., "are you able...", "can │ -│ you...") │ -│ - how to use a specific OpenHands feature or product │ -│ - how to use the OpenHands SDK, CLI, GUI, or other OpenHands products │ -│ │ -│ Get accurate information from the official OpenHands documentation at │ -│ . The documentation includes: │ -│ │ -│ **OpenHands SDK** (`/sdk/*`): Python library for building AI agents; Getting │ -│ Started, Architecture, Guides (agent, llm, conversation, tools), API │ -│ Reference │ -│ **OpenHands CLI** (`/openhands/usage/run-openhands/cli-mode`): Command-line │ -│ interface │ -│ **OpenHands GUI** (`/openhands/usage/run-openhands/local-setup`): Local GUI │ -│ and REST API │ -│ **OpenHands Cloud** (`/openhands/usage/run-openhands/cloud`): Hosted │ -│ solution with integrations │ -│ **OpenHands Enterprise**: Self-hosted deployment with extended support │ -│ │ -│ Always provide links to the relevant documentation pages for users who want │ -│ to learn more. │ -│ │ -│ │ -│ │ -│ # 🔐 Security Policy │ -│ │ -│ ## OK to do without Explicit User Consent │ -│ │ -│ - Download and run code from a repository specified by a user │ -│ - Open pull requests on the original repositories where the code is stored │ -│ - Install and run popular packages from pypi, npm, or other package managers │ -│ - Use APIs to work with GitHub or other platforms, unless the user asks │ -│ otherwise or your task requires browsing │ -│ │ -│ ## Do only with Explicit User Consent │ -│ │ -│ - Upload code to anywhere other than the location where it was obtained from │ -│ - Upload API keys or tokens anywhere, except when using them to authenticate │ -│ with the appropriate service │ -│ │ -│ ## Never Do │ -│ │ -│ - Never perform any illegal activities, such as circumventing security to │ -│ access a system that is not under your control or performing │ -│ denial-of-service attacks on external servers │ -│ - Never run software to mine cryptocurrency │ -│ │ -│ ## General Security Guidelines │ -│ │ -│ - Only use GITHUB_TOKEN and other credentials in ways the user has │ -│ explicitly requested and would expect │ -│ │ -│ │ -│ │ -│ │ -│ # Security Risk Policy │ -│ When using tools that support the security_risk parameter, assess the safety │ -│ risk of your actions: │ -│ │ -│ │ -│ - **LOW**: Safe, read-only actions. │ -│ - Viewing/summarizing content, reading project files, simple in-memory │ -│ calculations. │ -│ - **MEDIUM**: Project-scoped edits or execution. │ -│ - Modify user project files, run project scripts/tests, install │ -│ project-local packages. │ -│ - **HIGH**: System-level or untrusted operations. │ -│ - Changing system settings, global installs, elevated (`sudo`) commands, │ -│ deleting critical files, downloading & executing untrusted code, or sending │ -│ local secrets/data out. │ -│ │ -│ │ -│ **Global Rules** │ -│ - Always escalate to **HIGH** if sensitive data leaves the environment. │ -│ │ -│ │ -│ │ -│ │ -│ * When interacting with external services like GitHub, GitLab, or Bitbucket, │ -│ use their respective APIs instead of browser-based interactions whenever │ -│ possible. │ -│ * Only resort to browser-based interactions with these services if │ -│ specifically requested by the user or if the required operation cannot be │ -│ performed via API. │ -│ │ -│ │ -│ │ -│ * When user asks you to run an application, don't stop if the application is │ -│ not installed. Instead, please install the application and run the command │ -│ again. │ -│ * If you encounter missing dependencies: │ -│ 1. First, look around in the repository for existing dependency files │ -│ (requirements.txt, pyproject.toml, package.json, Gemfile, etc.) │ -│ 2. If dependency files exist, use them to install all dependencies at once │ -│ (e.g., `pip install -r requirements.txt`, `npm install`, etc.) │ -│ 3. Only install individual packages directly if no dependency files are │ -│ found or if only specific packages are needed │ -│ * Similarly, if you encounter missing dependencies for essential tools │ -│ requested by the user, install them when possible. │ -│ │ -│ │ -│ │ -│ * If you've made repeated attempts to solve a problem but tests still fail │ -│ or the user reports it's still broken: │ -│ 1. Step back and reflect on 5-7 different possible sources of the problem │ -│ 2. Assess the likelihood of each possible cause │ -│ 3. Methodically address the most likely causes, starting with the highest │ -│ probability │ -│ 4. Explain your reasoning process in your response to the user │ -│ * When you run into any major issue while executing a plan from the user, │ -│ please don't try to directly work around it. Instead, propose a new plan and │ -│ confirm with the user before proceeding. │ -│ │ -│ │ -│ │ -│ * When terminating processes: │ -│ - Do NOT use general keywords with commands like `pkill -f server` or │ -│ `pkill -f python` as this might accidentally kill other important servers or │ -│ processes │ -│ - Always use specific keywords that uniquely identify the target process │ -│ - Prefer using `ps aux` to find the exact process ID (PID) first, then │ -│ kill that specific PID │ -│ - When possible, use more targeted approaches like finding the PID from a │ -│ pidfile or using application-specific shutdown commands │ -│ │ -│ │ -│ │ -│ * Try to follow the instructions exactly as given - don't make extra or │ -│ fewer actions if not asked. │ -│ * Avoid unnecessary defensive programming; do not add redundant fallbacks or │ -│ default values — fail fast instead of masking misconfigurations. │ -│ * When backward compatibility expectations are unclear, confirm with the │ -│ user before making changes that could break existing behavior. │ -│ │ -│ │ -│ Dynamic Context: │ -│ │ -│ The current date and time is: 2026-03-15T22:57:55.633191 │ -│ │ -│ │ -│ │ -│ │ -│ │ -│ The following skills are available and may be triggered by keywords or task │ -│ types in your messages. │ -│ When a skill is triggered, you will receive additional context and │ -│ instructions. │ -│ You can also directly look up a skill's full content by reading its location │ -│ path, and use the skill's guidance proactively when relevant to your task. │ -│ │ -│ │ -│ │ -│ type-annotations\n* Your primary role is to assist users by executing commands, modifying code, and solving technical problems effectively. You should be thorough, methodical, and prioritize quality over speed.\n* If the user asks a question, like \"why is X happening\", don't try to fix the problem. Just give an answer to the question.\n\n\n\n* Use `AGENTS.md` under the repository root as your persistent memory for repository-specific knowledge and context.\n* Add important insights, patterns, and learnings to this file to improve future task performance.\n* This repository skill is automatically loaded for every conversation and helps maintain context across sessions.\n* For more information about skills, see: https://docs.openhands.dev/overview/skills\n\n\n\n* Each action you take is somewhat expensive. Wherever possible, combine multiple actions into a single action, e.g. combine multiple bash commands into one, using sed and grep to edit/view multiple files at once.\n* When exploring the codebase, use efficient tools like find, grep, and git commands with appropriate filters to minimize unnecessary operations.\n\n\n\n* When a user provides a file path, do NOT assume it's relative to the current working directory. First explore the file system to locate the file before working on it.\n* If asked to edit a file, edit the file directly, rather than creating a new file with a different filename.\n* For global search-and-replace operations, consider using `sed` instead of opening file editors multiple times.\n* NEVER create multiple versions of the same file with different suffixes (e.g., file_test.py, file_fix.py, file_simple.py). Instead:\n - Always modify the original file directly when making changes\n - If you need to create a temporary file for testing, delete it once you've confirmed your solution works\n - If you decide a file you created is no longer useful, delete it instead of creating a new version\n* Do NOT include documentation files explaining your changes in version control unless the user explicitly requests it\n* When reproducing bugs or implementing fixes, use a single file rather than creating multiple files with different versions\n\n\n\n* Write clean, efficient code with minimal comments. Avoid redundancy in comments: Do not repeat information that can be easily inferred from the code itself.\n* When implementing solutions, focus on making the minimal changes needed to solve the problem.\n* Before implementing any changes, first thoroughly understand the codebase through exploration.\n* If you are adding a lot of code to a function or file, consider splitting the function or file into smaller pieces when appropriate.\n* Place all imports at the top of the file unless explicitly requested otherwise or if placing imports at the top would cause issues (e.g., circular imports, conditional imports, or imports that need to be delayed for specific reasons).\n\n\n\n* If there are existing git user credentials already configured, use them and add Co-authored-by: openhands to any commits messages you make. if a git config doesn't exist use \"openhands\" as the user.name and \"openhands@all-hands.dev\" as the user.email by default, unless explicitly instructed otherwise.\n* Exercise caution with git operations. Do NOT make potentially dangerous changes (e.g., pushing to main, deleting repositories) unless explicitly asked to do so.\n* When committing changes, use `git status` to see all modified files, and stage all files necessary for the commit. Use `git commit -a` whenever possible.\n* Do NOT commit files that typically shouldn't go into version control (e.g., node_modules/, .env files, build directories, cache files, large binaries) unless explicitly instructed by the user.\n* If unsure about committing certain files, check for the presence of .gitignore files or ask the user for clarification.\n* When running git commands that may produce paged output (e.g., `git diff`, `git log`, `git show`), use `git --no-pager ` or set `GIT_PAGER=cat` to prevent the command from getting stuck waiting for interactive input.\n\n\n\n* **Important**: Do not push to the remote branch and/or start a pull request unless explicitly asked to do so.\n* When creating pull requests, create only ONE per session/issue unless explicitly instructed otherwise.\n* When working with an existing PR, update it with new commits rather than creating additional PRs for the same issue.\n* When updating a PR, preserve the original PR title and purpose, updating description only when necessary.\n\n\n\n1. EXPLORATION: Thoroughly explore relevant files and understand the context before proposing solutions\n2. ANALYSIS: Consider multiple approaches and select the most promising one\n3. TESTING:\n * For bug fixes: Create tests to verify issues before implementing fixes\n * For new features: Consider test-driven development when appropriate\n * Do NOT write tests for documentation changes, README updates, configuration files, or other non-functionality changes\n * Do not use mocks in tests unless strictly necessary and justify their use when they are used. You must always test real code paths in tests, NOT mocks.\n * If the repository lacks testing infrastructure and implementing tests would require extensive setup, consult with the user before investing time in building testing infrastructure\n * If the environment is not set up to run tests, consult with the user first before investing time to install all dependencies\n4. IMPLEMENTATION:\n * Make focused, minimal changes to address the problem\n * Always modify existing files directly rather than creating new versions with different suffixes\n * If you create temporary files for testing, delete them after confirming your solution works\n5. VERIFICATION: If the environment is set up to run tests, test your implementation thoroughly, including edge cases. If the environment is not set up to run tests, consult with the user first before investing time to run tests.\n\n\n\nWhen the user directly asks about any of the following:\n- OpenHands capabilities (e.g., \"can OpenHands do...\", \"does OpenHands have...\")\n- what you're able to do in second person (e.g., \"are you able...\", \"can you...\")\n- how to use a specific OpenHands feature or product\n- how to use the OpenHands SDK, CLI, GUI, or other OpenHands products\n\nGet accurate information from the official OpenHands documentation at . The documentation includes:\n\n**OpenHands SDK** (`/sdk/*`): Python library for building AI agents; Getting Started, Architecture, Guides (agent, llm, conversation, tools), API Reference\n**OpenHands CLI** (`/openhands/usage/run-openhands/cli-mode`): Command-line interface\n**OpenHands GUI** (`/openhands/usage/run-openhands/local-setup`): Local GUI and REST API\n**OpenHands Cloud** (`/openhands/usage/run-openhands/cloud`): Hosted solution with integrations\n**OpenHands Enterprise**: Self-hosted deployment with extended support\n\nAlways provide links to the relevant documentation pages for users who want to learn more.\n\n\n\n# 🔐 Security Policy\n\n## OK to do without Explicit User Consent\n\n- Download and run code from a repository specified by a user\n- Open pull requests on the original repositories where the code is stored\n- Install and run popular packages from pypi, npm, or other package managers\n- Use APIs to work with GitHub or other platforms, unless the user asks otherwise or your task requires browsing\n\n## Do only with Explicit User Consent\n\n- Upload code to anywhere other than the location where it was obtained from\n- Upload API keys or tokens anywhere, except when using them to authenticate with the appropriate service\n\n## Never Do\n\n- Never perform any illegal activities, such as circumventing security to access a system that is not under your control or performing denial-of-service attacks on external servers\n- Never run software to mine cryptocurrency\n\n## General Security Guidelines\n\n- Only use GITHUB_TOKEN and other credentials in ways the user has explicitly requested and would expect\n\n\n\n\n# Security Risk Policy\nWhen using tools that support the security_risk parameter, assess the safety risk of your actions:\n\n\n- **LOW**: Safe, read-only actions.\n - Viewing/summarizing content, reading project files, simple in-memory calculations.\n- **MEDIUM**: Project-scoped edits or execution.\n - Modify user project files, run project scripts/tests, install project-local packages.\n- **HIGH**: System-level or untrusted operations.\n - Changing system settings, global installs, elevated (`sudo`) commands, deleting critical files, downloading & executing untrusted code, or sending local secrets/data out.\n\n\n**Global Rules**\n- Always escalate to **HIGH** if sensitive data leaves the environment.\n\n\n\n\n* When interacting with external services like GitHub, GitLab, or Bitbucket, use their respective APIs instead of browser-based interactions whenever possible.\n* Only resort to browser-based interactions with these services if specifically requested by the user or if the required operation cannot be performed via API.\n\n\n\n* When user asks you to run an application, don't stop if the application is not installed. Instead, please install the application and run the command again.\n* If you encounter missing dependencies:\n 1. First, look around in the repository for existing dependency files (requirements.txt, pyproject.toml, package.json, Gemfile, etc.)\n 2. If dependency files exist, use them to install all dependencies at once (e.g., `pip install -r requirements.txt`, `npm install`, etc.)\n 3. Only install individual packages directly if no dependency files are found or if only specific packages are needed\n* Similarly, if you encounter missing dependencies for essential tools requested by the user, install them when possible.\n\n\n\n* If you've made repeated attempts to solve a problem but tests still fail or the user reports it's still broken:\n 1. Step back and reflect on 5-7 different possible sources of the problem\n 2. Assess the likelihood of each possible cause\n 3. Methodically address the most likely causes, starting with the highest probability\n 4. Explain your reasoning process in your response to the user\n* When you run into any major issue while executing a plan from the user, please don't try to directly work around it. Instead, propose a new plan and confirm with the user before proceeding.\n\n\n\n* When terminating processes:\n - Do NOT use general keywords with commands like `pkill -f server` or `pkill -f python` as this might accidentally kill other important servers or processes\n - Always use specific keywords that uniquely identify the target process\n - Prefer using `ps aux` to find the exact process ID (PID) first, then kill that specific PID\n - When possible, use more targeted approaches like finding the PID from a pidfile or using application-specific shutdown commands\n\n\n\n* Try to follow the instructions exactly as given - don't make extra or fewer actions if not asked.\n* Avoid unnecessary defensive programming; do not add redundant fallbacks or default values — fail fast instead of masking misconfigurations.\n* When backward compatibility expectations are unclear, confirm with the user before making changes that could break existing behavior.\n"},"tools":[{"description":"Execute a bash command in the terminal within a persistent shell session.\n\n\n### Command Execution\n* One command at a time: You can only execute one bash command at a time. If you need to run multiple commands sequentially, use `&&` or `;` to chain them together.\n* Persistent session: Commands execute in a persistent shell session where environment variables, virtual environments, and working directory persist between commands.\n* Soft timeout: Commands have a soft timeout of 10 seconds, once that's reached, you have the option to continue or interrupt the command (see section below for details)\n* Shell options: Do NOT use `set -e`, `set -eu`, or `set -euo pipefail` in shell scripts or commands in this environment. The runtime may not support them and can cause unusable shell sessions. If you want to run multi-line bash commands, write the commands to a file and then run it, instead.\n\n### Long-running Commands\n* For commands that may run indefinitely, run them in the background and redirect output to a file, e.g. `python3 app.py > server.log 2>&1 &`.\n* For commands that may run for a long time (e.g. installation or testing commands), or commands that run for a fixed amount of time (e.g. sleep), you should set the \"timeout\" parameter of your function call to an appropriate value.\n* If a bash command returns exit code `-1`, this means the process hit the soft timeout and is not yet finished. By setting `is_input` to `true`, you can:\n - Send empty `command` to retrieve additional logs\n - Send text (set `command` to the text) to STDIN of the running process\n - Send control commands like `C-c` (Ctrl+C), `C-d` (Ctrl+D), or `C-z` (Ctrl+Z) to interrupt the process\n - If you do C-c, you can re-start the process with a longer \"timeout\" parameter to let it run to completion\n\n### Best Practices\n* Directory verification: Before creating new directories or files, first verify the parent directory exists and is the correct location.\n* Directory management: Try to maintain working directory by using absolute paths and avoiding excessive use of `cd`.\n\n### Output Handling\n* Output truncation: If the output exceeds a maximum length, it will be truncated before being returned.\n\n### Terminal Reset\n* Terminal reset: If the terminal becomes unresponsive, you can set the \"reset\" parameter to `true` to create a new terminal session. This will terminate the current session and start fresh.\n* Warning: Resetting the terminal will lose all previously set environment variables, working directory changes, and any running processes. Use this only when the terminal stops responding to commands.\n","action_type":"TerminalAction","observation_type":"TerminalObservation","annotations":{"title":"terminal","readOnlyHint":false,"destructiveHint":true,"idempotentHint":false,"openWorldHint":true},"kind":"TerminalTool","title":"terminal"},{"description":"Custom editing tool for viewing, creating and editing files in plain-text format\n* State is persistent across command calls and discussions with the user\n* If `path` is an image file (.png, .jpg, .jpeg, .gif, .webp, .bmp), `view` displays the image content\n* If `path` is a text file, `view` displays the result of applying `cat -n`. If `path` is a directory, `view` lists non-hidden files and directories up to 2 levels deep\n* The `create` command cannot be used if the specified `path` already exists as a file\n* If a `command` generates a long output, it will be truncated and marked with ``\n* The `undo_edit` command will revert the last edit made to the file at `path`\n* This tool can be used for creating and editing files in plain-text format.\n\n\nBefore using this tool:\n1. Use the view tool to understand the file's contents and context\n2. Verify the directory path is correct (only applicable when creating new files):\n - Use the view tool to verify the parent directory exists and is the correct location\n\nWhen making edits:\n - Ensure the edit results in idiomatic, correct code\n - Do not leave the code in a broken state\n - Always use absolute file paths (starting with /)\n\nCRITICAL REQUIREMENTS FOR USING THIS TOOL:\n\n1. EXACT MATCHING: The `old_str` parameter must match EXACTLY one or more consecutive lines from the file, including all whitespace and indentation. The tool will fail if `old_str` matches multiple locations or doesn't match exactly with the file content.\n\n2. UNIQUENESS: The `old_str` must uniquely identify a single instance in the file:\n - Include sufficient context before and after the change point (3-5 lines recommended)\n - If not unique, the replacement will not be performed\n\n3. REPLACEMENT: The `new_str` parameter should contain the edited lines that replace the `old_str`. Both strings must be different.\n\nRemember: when making multiple file edits in a row to the same file, you should prefer to send all edits in a single message with multiple calls to this tool, rather than multiple messages with a single call each.\n\n\nYour current working directory is: /home/runner/work/extensions/extensions/plugins/python-type-annotations/examples/basic/after\nWhen exploring project structure, start with this directory instead of the root filesystem.","action_type":"FileEditorAction","observation_type":"FileEditorObservation","annotations":{"title":"file_editor","readOnlyHint":false,"destructiveHint":true,"idempotentHint":false,"openWorldHint":false},"kind":"FileEditorTool","title":"file_editor"},{"description":"This tool provides structured task management capabilities for development workflows.\nIt enables systematic tracking of work items, progress monitoring, and efficient\norganization of complex development activities.\n\nThe tool maintains visibility into project status and helps communicate\nprogress effectively to users.\n\n## Application Guidelines\n\nUtilize this tool in the following situations:\n\n1. Multi-phase development work - When projects involve multiple sequential or\n parallel activities\n2. Complex implementation tasks - Work requiring systematic planning and\n coordination across multiple components\n3. Explicit user request for task organization - When users specifically ask\n for structured task management\n4. Multiple concurrent requirements - When users present several work items\n that need coordination\n5. Project initiation - Capture and organize user requirements at project start\n6. Work commencement - Update task status to in_progress before beginning\n implementation. Maintain focus by limiting active work to one task\n7. Task completion - Update status to done and identify any additional work\n that emerged during implementation\n\n## Situations Where Tool Usage Is Unnecessary\n\nAvoid using this tool when:\n\n1. Single atomic tasks that require no decomposition\n2. Trivial operations where tracking adds no organizational value\n3. Simple activities completable in minimal steps\n4. Pure information exchange or discussion\n\nNote: For single straightforward tasks, proceed with direct implementation\nrather than creating tracking overhead.\n\n## Usage Scenarios\n\n**Scenario A: Feature Development with Validation**\nUser request: \"Build a user authentication system with login/logout functionality.\nDon't forget to include input validation and error handling!\"\n\nResponse approach: I'll implement a user authentication system with comprehensive\nvalidation. Let me organize this work systematically.\n\n*Task breakdown includes:*\n1. Design authentication API endpoints and data models\n2. Implement user login/logout controllers with session management\n3. Add client-side form validation and error display\n4. Create backend input sanitization and security checks\n5. Implement comprehensive error handling for edge cases\n6. Perform integration testing and fix any issues\n\n**Scenario B: Codebase Refactoring**\nUser request: \"I need to update all instances of the method 'fetchData' to\n'retrieveInformation' throughout the entire project\"\n\nResponse approach: Let me first analyze your codebase to identify all locations\nwhere 'fetchData' appears.\n\n*After code analysis*\n\nI've located 12 occurrences of 'fetchData' across 6 files in your project.\nI'll create a systematic plan to update these references.\n\n*Organized task list includes specific file-by-file updates*\n\n**Scenario C: Multi-feature Development**\nUser request: \"Set up a blog platform with these components: admin dashboard,\narticle management, comment system, and user profiles.\"\n\nResponse approach: I'll help build your blog platform. Let me break down these\ncomponents into manageable implementation phases.\n\n*Creates structured plan with each feature decomposed into specific development tasks*\n\n## Counter-examples - Direct Implementation Preferred\n\n**Counter-example A: Simple inquiry**\nUser request: \"What's the syntax for a for loop in JavaScript?\"\n\nResponse approach: Here's how to write a for loop in JavaScript:\n\n```javascript\nfor (let i = 0; i < array.length; i++) {\n console.log(array[i]);\n}\n```\n\n*No task tracking needed - single informational response*\n\n**Counter-example B: Minor modification**\nUser request: \"Please add a docstring to the processPayment function explaining\nits parameters.\"\n\nResponse approach: I'll add a docstring to explain the processPayment function.\n\n*Direct edit without task tracking for simple modification*\n\n## Status Management and Workflow\n\n1. **Status Values**: Track work using these states:\n - todo: Not yet initiated\n - in_progress: Currently active (maintain single focus)\n - done: Successfully completed\n\n2. **Workflow Practices**:\n - Update status dynamically as work progresses\n - Mark completion immediately upon task finish\n - Limit active work to ONE task at any given time\n - Complete current activities before initiating new ones\n - Remove obsolete tasks from tracking entirely\n\n3. **Completion Criteria**:\n - Mark tasks as done only when fully achieved\n - Keep status as in_progress if errors, blocks, or partial completion exist\n - Create new tasks for discovered issues or dependencies\n - Never mark done when:\n - Test suites are failing\n - Implementation remains incomplete\n - Unresolved errors persist\n - Required resources are unavailable\n\n4. **Task Organization**:\n - Write precise, actionable descriptions\n - Decompose complex work into manageable units\n - Use descriptive, clear naming conventions\n\nWhen uncertain, favor using this tool. Proactive task management demonstrates\nsystematic approach and ensures comprehensive requirement fulfillment.","action_type":"TaskTrackerAction","observation_type":"TaskTrackerObservation","annotations":{"readOnlyHint":false,"destructiveHint":false,"idempotentHint":true,"openWorldHint":false},"kind":"TaskTrackerTool","title":"task_tracker"},{"description":"Delegation tool for spawning sub-agents and delegating tasks to them.\n\nThis tool provides two commands:\n\n**spawn**: Initialize sub-agents with meaningful identifiers and optional types\n- Use descriptive identifiers that make sense for your use case (e.g., 'refactoring', 'run_tests', 'research')\n- Optionally specify agent types for specialized capabilities\n- Each identifier creates a separate sub-agent conversation\n- Examples:\n - Default agents: {\"command\": \"spawn\", \"ids\": [\"research\", \"implementation\"]}\n - Specialized agents: {\"command\": \"spawn\", \"ids\": [\"research\", \"code\"], \"agent_types\": [\"researcher\", \"programmer\"]}\n - Mixed types: {\"command\": \"spawn\", \"ids\": [\"research\", \"generic\"], \"agent_types\": [\"researcher\"]} # unspecified entries fall back to the default agent\n\n**delegate**: Send tasks to specific sub-agents and wait for results\n- Use a dictionary mapping sub-agent identifiers to task descriptions\n- This is a blocking operation - waits for all sub-agents to complete\n- Returns a single observation containing results from all sub-agents\n- Example: {\"command\": \"delegate\", \"tasks\": {\"research\": \"Find best practices for async code\", \"implementation\": \"Refactor the MyClass class\"}}\n\nAvailable agent factories:\n- **default**: Default general-purpose agent (used when no agent type is provided)\n- No user-registered agents yet. Call register_agent(...) to add custom agents.\n\n**Important Notes:**\n- Identifiers used in delegate must match those used in spawn\n- All operations are blocking and return comprehensive results\n- Sub-agents work in the same workspace as the main agent: /home/runner/work/extensions/extensions/plugins/python-type-annotations/examples/basic/after\n- If you omit an agent type for an ID, a default general-purpose agent is used","action_type":"DelegateAction","observation_type":"DelegateObservation","annotations":{"title":"delegate","readOnlyHint":false,"destructiveHint":false,"idempotentHint":false,"openWorldHint":true},"kind":"DelegateTool","title":"delegate"},{"description":"Signals the completion of the current task or conversation.\n\nUse this tool when:\n- You have successfully completed the user's requested task\n- You cannot proceed further due to technical limitations or missing information\n\nThe message should include:\n- A clear summary of actions taken and their results\n- Any next steps for the user\n- Explanation if you're unable to complete the task\n- Any follow-up questions if more information is needed\n","action_type":"FinishAction","observation_type":"FinishObservation","annotations":{"title":"finish","readOnlyHint":true,"destructiveHint":false,"idempotentHint":true,"openWorldHint":false},"kind":"FinishTool","title":"finish"},{"description":"Use the tool to think about something. It will not obtain new information or make any changes to the repository, but just log the thought. Use it when complex reasoning or brainstorming is needed.\n\nCommon use cases:\n1. When exploring a repository and discovering the source of a bug, call this tool to brainstorm several unique ways of fixing the bug, and assess which change(s) are likely to be simplest and most effective.\n2. After receiving test results, use this tool to brainstorm ways to fix failing tests.\n3. When planning a complex refactoring, use this tool to outline different approaches and their tradeoffs.\n4. When designing a new feature, use this tool to think through architecture decisions and implementation details.\n5. When debugging a complex issue, use this tool to organize your thoughts and hypotheses.\n\nThe tool simply logs your thought process for better transparency and does not execute any code or make changes.","action_type":"ThinkAction","observation_type":"ThinkObservation","annotations":{"readOnlyHint":true,"destructiveHint":false,"idempotentHint":true,"openWorldHint":false},"kind":"ThinkTool","title":"think"}],"dynamic_context":{"cache_prompt":false,"type":"text","text":"\nThe current date and time is: 2026-03-15T23:07:19.243746\n\n\n\n\n\nThe following skills are available and may be triggered by keywords or task types in your messages.\nWhen a skill is triggered, you will receive additional context and instructions.\nYou can also directly look up a skill's full content by reading its location path, and use the skill's guidance proactively when relevant to your task.\n\n\n \n type-annotations\n Add valid Python type annotations to functions, methods, and variables\n /home/runner/work/extensions/extensions/plugins/python-type-annotations/examples/basic/after/.agents/skills/type-annotations/SKILL.md\n \n \n flarglebargle\n A test skill that responds to the magic word \"flarglebargle\" with a compliment. Use for testing skill activation and trigger functionality.\n /home/runner/.openhands/cache/skills/public-skills/skills/flarglebargle/SKILL.md\n \n \n pdflatex\n Install and use pdflatex to compile LaTeX documents into PDFs on Linux. Use when generating academic papers, research publications, or any documents written in LaTeX.\n /home/runner/.openhands/cache/skills/public-skills/skills/pdflatex/SKILL.md\n \n \n github-pr-review\n Post PR review comments using the GitHub API with inline comments, suggestions, and priority labels.\n /home/runner/.openhands/cache/skills/public-skills/skills/github-pr-review/SKILL.md\n \n \n npm\n Handle npm package installation in non-interactive environments by piping confirmations. Use when installing Node.js packages that require user confirmation prompts.\n /home/runner/.openhands/cache/skills/public-skills/skills/npm/SKILL.md\n \n \n add-javadoc\n Add comprehensive JavaDoc documentation to Java classes and methods. Use when documenting Java code, adding API documentation, or improving code documentation.\n /home/runner/.openhands/cache/skills/public-skills/skills/add-javadoc/SKILL.md\n \n \n theme-factory\n Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors/fonts that you can apply to any artifact t... [62 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/theme-factory/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/theme-factory/SKILL.md\n \n \n onboarding-agent\n Interactive onboarding workflow that interviews users to understand their coding goals and generates PR-ready implementation plans. Use when starting a new development task to ensure clear requirement... [27 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/onboarding-agent/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/onboarding-agent/SKILL.md\n \n \n uv\n If the project uses uv, use this skill. Use this skill to create/manage Python projects and environments with `uv`, add/remove dependencies, sync a project from `uv.lock`, and run commands in the proj... [16 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/uv/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/uv/SKILL.md\n \n \n init\n Create an AGENTS.md contributor guide for a repository (or a subdirectory) following a concise, repo-specific template. Use when the user runs /init.\n /home/runner/.openhands/cache/skills/public-skills/skills/init/SKILL.md\n \n \n github\n Interact with GitHub repositories, pull requests, issues, and workflows using the GITHUB_TOKEN environment variable and GitHub CLI. Use when working with code hosted on GitHub or managing GitHub resou... [5 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/github/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/github/SKILL.md\n \n \n deno\n If the project uses deno, use this skill. Use this skill to initialize and work with Deno projects, add/remove dependencies (JSR and npm), run tasks and scripts with appropriate permissions, and use b... [32 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/deno/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/deno/SKILL.md\n \n \n azure-devops\n Interact with Azure DevOps repositories, pull requests, and APIs using the AZURE_DEVOPS_TOKEN environment variable. Use when working with code hosted on Azure DevOps or managing Azure DevOps resources... [1 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/azure-devops/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/azure-devops/SKILL.md\n \n \n vercel\n Deploy and manage applications on Vercel, including preview deployments and deployment protection. Use when working with Vercel-hosted projects or configuring Vercel deployments.\n /home/runner/.openhands/cache/skills/public-skills/skills/vercel/SKILL.md\n \n \n jupyter\n Read, modify, execute, and convert Jupyter notebooks programmatically. Use when working with .ipynb files for data science workflows, including editing cells, clearing outputs, or converting to other ... [8 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/jupyter/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/jupyter/SKILL.md\n \n \n learn-from-code-review\n Distill code review feedback from GitHub PRs into reusable skills and guidelines. This skill should be used when users ask to \"learn from code reviews\", \"distill PR feedback\", \"improve coding standard... [108 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/learn-from-code-review/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/learn-from-code-review/SKILL.md\n \n \n skill-creator\n This skill should be used when the user wants to \"create a skill\", \"write a new skill\", \"improve skill description\", \"organize skill content\", or needs guidance on skill structure, progressive disclos... [41 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/skill-creator/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/skill-creator/SKILL.md\n \n \n readiness-report\n Evaluate how well a codebase supports autonomous AI development. Analyzes repositories across eight technical pillars (Style & Validation, Build System, Testing, Documentation, Dev Environment, Debugg... [232 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/readiness-report/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/readiness-report/SKILL.md\n \n \n docker\n Run Docker commands within a container environment, including starting the Docker daemon and managing containers. Use when building, running, or managing Docker containers and images.\n /home/runner/.openhands/cache/skills/public-skills/skills/docker/SKILL.md\n \n \n openhands-api\n Use the OpenHands REST API (V0) to create and manage agent conversations programmatically. Includes minimal Python and TypeScript clients under scripts/.\n /home/runner/.openhands/cache/skills/public-skills/skills/openhands-api/SKILL.md\n \n \n notion\n Create, search, and update Notion pages/databases using the Notion API. Use for documenting work, generating runbooks, and automating knowledge base updates.\n /home/runner/.openhands/cache/skills/public-skills/skills/notion/SKILL.md\n \n \n discord\n Build and automate Discord integrations (bots, webhooks, slash commands, and REST API workflows). Use when the user mentions Discord, a Discord server/guild, channels, webhooks, bot tokens, slash comm... [53 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/discord/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/discord/SKILL.md\n \n \n security\n Security best practices for secure coding, authentication, authorization, and data protection. Use when developing features that handle sensitive data, user authentication, or require security review.\n /home/runner/.openhands/cache/skills/public-skills/skills/security/SKILL.md\n \n \n kubernetes\n Set up and manage local Kubernetes clusters using KIND (Kubernetes IN Docker). Use when testing Kubernetes applications locally or developing cloud-native workloads.\n /home/runner/.openhands/cache/skills/public-skills/skills/kubernetes/SKILL.md\n \n \n datadog\n Query and analyze Datadog logs, metrics, APM traces, and monitors using the Datadog API. Use when debugging production issues, monitoring application performance, or investigating alerts.\n /home/runner/.openhands/cache/skills/public-skills/skills/datadog/SKILL.md\n \n \n agent-memory\n Persist and retrieve repository-specific knowledge using AGENTS.md files. Use when you want to save important information about a codebase (build commands, code style, workflows) for future sessions.\n /home/runner/.openhands/cache/skills/public-skills/skills/agent-memory/SKILL.md\n \n \n releasenotes\n Generate formatted changelogs from git history since the last release tag. Use when preparing release notes that categorize changes into breaking changes, features, fixes, and other sections.\n /home/runner/.openhands/cache/skills/public-skills/skills/releasenotes/SKILL.md\n \n \n codereview-roasted\n Brutally honest code review in the style of Linus Torvalds, focusing on data structures, simplicity, and pragmatism. Use when you want critical, no-nonsense feedback that prioritizes engineering funda... [31 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/codereview-roasted/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/codereview-roasted/SKILL.md\n \n \n swift-linux\n Install and configure Swift programming language on Debian Linux for server-side development. Use when building Swift applications on Linux or setting up a Swift development environment.\n /home/runner/.openhands/cache/skills/public-skills/skills/swift-linux/SKILL.md\n \n \n code-review\n Structured code review covering style, readability, and security concerns with actionable feedback. Use when reviewing pull requests or merge requests to identify issues and suggest improvements.\n /home/runner/.openhands/cache/skills/public-skills/skills/code-review/SKILL.md\n \n \n gitlab\n Interact with GitLab repositories, merge requests, and APIs using the GITLAB_TOKEN environment variable. Use when working with code hosted on GitLab or managing GitLab resources.\n /home/runner/.openhands/cache/skills/public-skills/skills/gitlab/SKILL.md\n \n \n bitbucket\n Interact with Bitbucket repositories and pull requests using the BITBUCKET_TOKEN environment variable. Use when working with code hosted on Bitbucket or managing Bitbucket resources via API.\n /home/runner/.openhands/cache/skills/public-skills/skills/bitbucket/SKILL.md\n \n \n openhands-api-v1\n Minimal reference skill for the OpenHands Cloud REST API (V1) (app server /api/v1 + sandbox agent-server). Use when you need to automate common OpenHands Cloud actions; don't use for general sandbox/d... [40 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/openhands-api-v1/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/openhands-api-v1/SKILL.md\n \n \n agent-sdk-builder\n Guided workflow for building custom AI agents using the OpenHands Software Agent SDK. Use when you want to create a new agent through an interactive interview process that gathers requirements and gen... [28 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/agent-sdk-builder/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/agent-sdk-builder/SKILL.md\n \n \n babysit-pr\n Babysit a GitHub pull request by continuously polling CI checks/workflow runs, new review comments, and mergeability state until the PR is ready to merge (or merged/closed). Diagnose failures, retry l... [352 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/babysit-pr/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/babysit-pr/SKILL.md\n \n \n ssh\n Establish and manage SSH connections to remote machines, including key generation, configuration, and file transfers. Use when connecting to remote servers, executing remote commands, or transferring ... [14 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/ssh/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/ssh/SKILL.md\n \n \n frontend-design\n Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples inclu... [199 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/frontend-design/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/frontend-design/SKILL.md\n \n \n add-skill\n Add an external skill from a GitHub repository to the current workspace. Use when users want to import, install, or add a skill from a GitHub URL (e.g., `/add-skill https://github.com/OpenHands/extens... [181 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/add-skill/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/add-skill/SKILL.md\n \n \n linear\n Interact with Linear project management - query issues, update status, create tickets, and manage workflows using the Linear GraphQL API. Use when working with Linear tickets, sprints, or project trac... [5 characters truncated. View /home/runner/.openhands/cache/skills/public-skills/skills/linear/SKILL.md for complete information]\n /home/runner/.openhands/cache/skills/public-skills/skills/linear/SKILL.md\n \n\n\n\n\n\nYour current working directory is: /home/runner/work/extensions/extensions/plugins/python-type-annotations/examples/basic/after\nUser operating system: Linux (kernel 6.14.0-1017-azure)"},"kind":"SystemPromptEvent"}, +{"id":"6100af27-0a3e-44b6-b79f-961301c50d97","timestamp":"2026-03-15T23:07:20.393206","source":"user","llm_message":{"role":"user","content":[{"cache_prompt":false,"type":"text","text":"Starting this session with file context.\n\nFile path: ../prompt.md\n\nFile contents:\n--------------------\nAdd type annotations to all Python files in this directory.\n\n--------------------\n"}],"thinking_blocks":[]},"activated_skills":["type-annotations"],"extended_content":[{"cache_prompt":false,"type":"text","text":"\nThe following information has been included based on a keyword match for \"type annotations\".\nIt may or may not be relevant to the user's request.\n\nSkill location: /home/runner/work/extensions/extensions/plugins/python-type-annotations/examples/basic/after/.agents/skills/type-annotations/SKILL.md\n(Use this path to resolve relative file references in the skill content below)\n\n\n# Python Type Annotations\n\nAdd comprehensive, valid Python type annotations to Python files.\n\n## Instructions\n\nWhen asked to add type annotations to a Python file or directory:\n\n1. **Analyze the code** to understand:\n - Function parameters and their expected types\n - Return values\n - Class attributes and instance variables\n - Module-level variables\n\n2. **Add appropriate type annotations**:\n - Use built-in types: `str`, `int`, `float`, `bool`, `bytes`, `None`\n - Use `list[T]`, `dict[K, V]`, `set[T]`, `tuple[T, ...]` for collections (Python 3.9+)\n - Use `Optional[T]` or `T | None` for nullable types\n - Use `Union[A, B]` or `A | B` for multiple possible types\n - Use `Any` sparingly, only when the type is truly dynamic\n - Use `Callable[[Args], Return]` for function types\n - Import from `typing` module when needed: `from typing import Optional, Union, Any, Callable`\n\n3. **Follow best practices**:\n - Annotate all function parameters and return types\n - Annotate class attributes in `__init__` or as class variables\n - Use descriptive type aliases for complex types\n - Preserve existing annotations if they are correct\n - Do not change the logic or behavior of the code\n\n4. **Validate the annotations**:\n - Ensure the file still runs without syntax errors\n - Run `python -m py_compile ` to check syntax\n - If mypy is available, run `mypy ` to verify types\n\n## Example Transformation\n\n**Before:**\n```python\ndef greet(name):\n return f\"Hello, {name}!\"\n\ndef add_numbers(a, b):\n return a + b\n```\n\n**After:**\n```python\ndef greet(name: str) -> str:\n return f\"Hello, {name}!\"\n\ndef add_numbers(a: int, b: int) -> int:\n return a + b\n```\n\n## Notes\n\n- Prefer `X | None` over `Optional[X]` for Python 3.10+\n- Use `list` instead of `List` for Python 3.9+\n- Add `from __future__ import annotations` for forward references in older Python versions\n"}],"kind":"MessageEvent"}, +{"id":"630ad255-c19f-480b-ac9d-e17e1a2caacc","timestamp":"2026-03-15T23:07:20.611977","source":"environment","code":"LLMBadRequestError","detail":"litellm.BadRequestError: LLM Provider NOT provided. Pass in the LLM provider you are trying to call. You passed model=openhands/claude-sonnet-4-5-20250929\n Pass model as E.g. For 'Huggingface' inference endpoints pass in `completion(model='huggingface/starcoder',..)` Learn more: https://docs.litellm.ai/docs/providers","kind":"ConversationErrorEvent"}]}