@openhands/extensions 0.0.1-alpha → 0.2.0

package/skills/agent-creator/references/fallback.md

@@ -0,0 +1,117 @@
+# Fallback Spec — OpenHands File-Based Agent
+
+> Use this file ONLY if fetching https://docs.openhands.dev/sdk/guides/agent-file-based fails.
+> When the website is reachable, always prefer the live documentation over this file.
+
+## Agent File Format
+
+A file-based sub-agent is a single `.md` file with YAML frontmatter and a Markdown body.
+The frontmatter configures the agent. The Markdown body becomes the agent's system prompt.
+
+## Frontmatter Fields
+
+| Field | Required | Default | Description |
+|---|---|---|---|
+| `name` | Yes | — | agent identifier,lowercase + hyphens, matches filename exactly |
+| `description` | No | `""` | What this agent does. Shown to orchestrator. Add `<example>` tags |
+| `tools` | No | `[]` | List of tools the agent can use (for example: `file_editor`, `terminal`, `browser_tool_set`, etc)|
+| `model` | No | `inherit` | LLM model profile to load and use for the subagent ("inherit" uses the parent agent’s model) |
+| `skills` | No | `[]` | List of skill names for this agent |
+| `max_iteration_per_run` | No | `None` | 	Maximum iterations per run. Must be strictly positive, or `None` for the default value.|
+| `color` | No | `None` | Rich color name (e.g., "blue", "green") used by visualizers to style this agent’s output in terminal panels |
+| `mcp_servers` | No | `None` | MCP server configs |
+| `hooks` | No | `None` | Hook configuration for lifecycle events |
+| `permission_mode` | No | `None` | `always_confirm` / `never_confirm` / `confirm_risky` |
+| `profile_store_dir` | No | `None` | Custom directory path for LLM profiles when using a named model|
+
+## Directory Conventions
+
+Place agent files in these directories, scanned in priority order (first match wins):
+
+| Priority | Path | Scope |
+|---|---|---|
+| 1 | `{project}/.agents/agents/<name>.md` | Project (primary) |
+| 2 | `{project}/.openhands/agents/<name>.md` | Project (secondary) |
+| 3 | `~/.agents/agents/<name>.md` | User (primary) |
+| 4 | `~/.openhands/agents/<name>.md` | User (secondary) |
+
+**Rules:**
+- Filename = agent name exactly (`name: code-reviewer` → `code-reviewer.md`)
+- Place file directly in `agents/` — do NOT create subdirectories
+- `README.md` is automatically skipped by the loader
+- Project-level takes priority over user-level when names conflict
+
+## \<example> Tags
+
+Add \<example> tags inside the description to help the orchestrating agent know when to delegate to this agent:
+
+For example
+```markdown
+description: >
+  Writes and improves technical documentation.
+  <example>Write docs for this module</example>
+  <example>Improve the README</example>
+```
+
+## Minimal Valid Example
+
+```markdown
+---
+name: code-reviewer
+description: >
+  Reviews code for quality, bugs, and best practices.
+  <example>Review this pull request for issues</example>
+  <example>Check this code for bugs</example>
+tools:
+  - file_editor
+  - terminal
+model: inherit
+---
+
+# Code Reviewer
+
+You are a meticulous code reviewer. When reviewing code:
+
+1. **Correctness** - Look for bugs, off-by-one errors, and race conditions.
+2. **Style** - Check for consistent naming and idiomatic usage.
+3. **Performance** - Identify unnecessary allocations or algorithmic issues.
+4. **Security** - Flag injection vulnerabilities or hardcoded secrets.
+
+Keep feedback concise and actionable. For each issue, suggest a fix.
+```
+
+## Generated File Template
+
+~~~markdown
+---
+name: <agent-name>
+description: >
+  <One imperative sentence — what this agent does and when to use it.>
+  <example>A concrete user request this agent handles</example>
+  <example>Another concrete delegation trigger</example>
+tools:
+  - <tool-name>
+model: inherit
+permission_mode: <always_confirm|never_confirm|confirm_risky>
+---
+
+# <Title>
+
+<One paragraph: role, approach, and primary constraint. Written in second person — "You are...">
+
+## How to Execute
+
+<Numbered steps — what the AGENT thinks and does, not what the user provides.>
+
+## Output Format
+
+<Concrete Markdown template — not a prose description.>
+
+## Gotchas
+
+- Do not <most likely wrong behavior specific to this domain>.
+
+## Edge Cases
+
+- **<Specific case>**: <Exact handling — not generic advice>.
+~~~

package/skills/agent-memory/.plugin/plugin.json

@@ -0,0 +1,18 @@
+{
+  "name": "agent-memory",
+  "version": "1.0.0",
+  "description": "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.",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "memory",
+    "knowledge",
+    "persistence",
+    "agents"
+  ]
+}

package/skills/agent-memory/README.md

@@ -0,0 +1,35 @@
+# Agent Memory
+
+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.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `/remember`
+
+## Details
+
+* Repository memory: Use AGENTS.md in each repository root to store and access important information.
+  - If this file exists, it will be added to your context automatically.
+  - If missing, you should create it unless the user has explicitly asked you to not do so.
+
+* Store and maintain **general knowledge** that will be helpful for most future tasks:
+  1. Repository structure
+  2. Common commands (build, lint, test, pre-commit, etc.)
+  3. Code style preferences
+  4. Workflows and best practices
+  5. Any other repository-specific knowledge you learn
+
+* IMPORTANT: ONLY LOG the information that would be helpful for different future tasks, for example, how to configure the settings, how to setup the repository. Do NOT add issue-specific information (e.g., what specific error you have ran into and how you fix it).
+
+* When adding new information:
+  - ALWAYS ask for user confirmation first by listing the exact items (numbered 1, 2, 3, etc.) you plan to save to repo.md
+  - Only save the items the user approves (they may ask you to save a subset)
+  - Ensure it integrates nicely with existing knowledge in repo.md
+  - Reorganize the content if needed to maintain clarity and organization
+  - Group related information together under appropriate sections or headings
+  - If you've only explored a portion of the codebase, clearly note this limitation in the repository structure documentation
+  - If you don't know the essential commands for working with the repository, such as lint or typecheck, ask the user and suggest adding them to repo.md for future reference (with permission)
+
+When you receive this message, please review and summarize your recent actions and observations, then present a list of valuable information that should be saved in AGENTS.md to the user.

package/skills/agent-memory/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: agent-memory
+description: 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.
+triggers:
+- /remember
+---
+
+* Repository memory: Use AGENTS.md in each repository root to store and access important information.
+  - If this file exists, it will be added to your context automatically.
+  - If missing, you should create it unless the user has explicitly asked you to not do so.
+
+* Store and maintain **general knowledge** that will be helpful for most future tasks:
+  1. Repository structure
+  2. Common commands (build, lint, test, pre-commit, etc.)
+  3. Code style preferences
+  4. Workflows and best practices
+  5. Any other repository-specific knowledge you learn
+
+* IMPORTANT: ONLY LOG the information that would be helpful for different future tasks, for example, how to configure the settings, how to setup the repository. Do NOT add issue-specific information (e.g., what specific error you have ran into and how you fix it).
+
+* When adding new information:
+  - ALWAYS ask for user confirmation first by listing the exact items (numbered 1, 2, 3, etc.) you plan to save to AGENTS.md
+  - Only save the items the user approves (they may ask you to save a subset)
+  - Ensure it integrates nicely with existing knowledge in AGENTS.md
+  - Reorganize the content if needed to maintain clarity and organization
+  - Group related information together under appropriate sections or headings
+  - If you've only explored a portion of the codebase, clearly note this limitation in the repository structure documentation
+  - If you don't know the essential commands for working with the repository, such as lint or typecheck, ask the user and suggest adding them to AGENTS.md for future reference (with permission)
+
+When you receive this message, please review and summarize your recent actions and observations, then present a list of valuable information that should be saved in AGENTS.md to the user.

package/skills/agent-memory/commands/remember.md

@@ -0,0 +1,8 @@
+---
+# auto-generated by sync_extensions.py
+description: 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.
+---
+
+Read and follow the complete instructions in the SKILL.md file located in this skill's directory.
+
+$ARGUMENTS

package/skills/agent-sdk-builder/.plugin/plugin.json

@@ -0,0 +1,18 @@
+{
+  "name": "agent-sdk-builder",
+  "version": "1.0.0",
+  "description": "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 ...",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "agent",
+    "sdk",
+    "builder",
+    "openhands"
+  ]
+}

package/skills/agent-sdk-builder/README.md

@@ -0,0 +1,40 @@
+# Initial_Prompt
+
+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 generates implementation plans.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `description: Initial SDK requirements`
+- `/agent-builder`
+
+## Details
+
+# Agent Builder and Interviewer Role
+
+You are an expert requirements gatherer and agent builder. You must progressively interview the user to understand what type of agent they are looking to build. You should ask one question at a time when interviewing to avoid overwhelming the user.
+
+Please refer to the user's initial promot: {INITIAL_PROMPT}
+
+If {INITIAL_PROMPT} is blank, your first interview question should be: "Please provide a brief description of the type of agent you are looking to build."
+
+# Understanding the OpenHands Software Agent SDK
+At the end of the interview, respond with a summary of the requirements. Then, proceed to thoroughly understand how the OpenHands Software Agent SDK works, it's various APIs, and examples. To do this:
+- First, research the OpenHands documentation which includes references to the Software Agent SDK: https://docs.openhands.dev/llms.txt
+- Then, clone the examples into a temporary workspace folder (under "temp/"): https://github.com/OpenHands/software-agent-sdk/tree/main/examples/01_standalone_sdk
+- Then, clone the SDK docs into the same temporary workspace folder: https://github.com/OpenHands/docs/tree/main/sdk
+
+After analyzing the OpenHands Agent SDK, you may optionally ask additional clarifying questions in case it's important for the technical design of the agent.
+
+# Generating the SDK Plan
+You can then proceed to build a technical implementation plan based on the user requirements and your understanding of how the OpenHands Agent SDK works.
+- The plan should be stored in "plan/SDK_PLAN.md" from the root of the workspace.
+- A visual representation of how the agent should work based on the SDK_PLAN.md. This should look like a flow diagram with nodes and edges. This should be generated using Javascript, HTML, and CSS and then be rendered using the built-in web server. Store this in the plan/ directory.
+
+# Implementing the Plan
+After the plan is generated, please ask the user if they are ready to generate the SDK implementation. When they approve, please make sure the code is stored in the "output/" directory. Make sure the code provides logging that a user can see in the terminal. Ideally, the SDK is a single python file.
+
+Additional guidelines:
+- Users can configure their LLM API Key using an environment variable named "LLM_API_KEY"
+- Unless otherwise specified, default to this model: openhands/claude-sonnet-4-5-20250929. This is configurable through the LLM_BASE_MODEL environment variable.

package/skills/agent-sdk-builder/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: agent-sdk-builder
+description: 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 generates implementation plans.
+inputs:
+- description: Initial SDK requirements
+  name: INITIAL_PROMPT
+triggers:
+- /agent-builder
+---
+
+# Agent Builder and Interviewer Role
+
+You are an expert requirements gatherer and agent builder. You must progressively interview the user to understand what type of agent they are looking to build. You should ask one question at a time when interviewing to avoid overwhelming the user.
+
+Please refer to the user's initial promot: {INITIAL_PROMPT}
+
+If {INITIAL_PROMPT} is blank, your first interview question should be: "Please provide a brief description of the type of agent you are looking to build."
+
+# Understanding the OpenHands Software Agent SDK
+At the end of the interview, respond with a summary of the requirements. Then, proceed to thoroughly understand how the OpenHands Software Agent SDK works, it's various APIs, and examples. To do this:
+- First, research the OpenHands documentation which includes references to the Software Agent SDK: https://docs.openhands.dev/llms.txt
+- Then, clone the examples into a temporary workspace folder (under "temp/"): https://github.com/OpenHands/software-agent-sdk/tree/main/examples/01_standalone_sdk
+- Then, clone the SDK docs into the same temporary workspace folder: https://github.com/OpenHands/docs/tree/main/sdk
+
+After analyzing the OpenHands Agent SDK, you may optionally ask additional clarifying questions in case it's important for the technical design of the agent.
+
+# Generating the SDK Plan
+You can then proceed to build a technical implementation plan based on the user requirements and your understanding of how the OpenHands Agent SDK works.
+- The plan should be stored in "plan/SDK_PLAN.md" from the root of the workspace.
+- A visual representation of how the agent should work based on the SDK_PLAN.md. This should look like a flow diagram with nodes and edges. This should be generated using Javascript, HTML, and CSS and then be rendered using the built-in web server. Store this in the plan/ directory.
+
+# Implementing the Plan
+After the plan is generated, please ask the user if they are ready to generate the SDK implementation. When they approve, please make sure the code is stored in the "output/" directory. Make sure the code provides logging that a user can see in the terminal. Ideally, the SDK is a single python file.
+
+Additional guidelines:
+- Users can configure their LLM API Key using an environment variable named "LLM_API_KEY"
+- Unless otherwise specified, default to this model: openhands/claude-sonnet-4-5-20250929. This is configurable through the LLM_BASE_MODEL environment variable.

package/skills/agent-sdk-builder/commands/agent-builder.md

@@ -0,0 +1,8 @@
+---
+# auto-generated by sync_extensions.py
+description: 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 generates implementation plans.
+---
+
+Read and follow the complete instructions in the SKILL.md file located in this skill's directory.
+
+$ARGUMENTS

package/skills/azure-devops/.plugin/plugin.json

@@ -0,0 +1,18 @@
+{
+  "name": "azure-devops",
+  "version": "1.0.0",
+  "description": "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 resour...",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "azure",
+    "devops",
+    "git",
+    "pull-request"
+  ]
+}

package/skills/azure-devops/README.md

@@ -0,0 +1,55 @@
+# Azure Devops
+
+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.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `azure_devops`
+- `azure`
+
+## Details
+
+You have access to an environment variable, `AZURE_DEVOPS_TOKEN`, which allows you to interact with
+the Azure DevOps API.
+
+<IMPORTANT>
+You can use `curl` with the `AZURE_DEVOPS_TOKEN` to interact with Azure DevOps's API.
+ALWAYS use the Azure DevOps API for operations instead of a web browser.
+</IMPORTANT>
+
+If you encounter authentication issues when pushing to Azure DevOps (such as password prompts or permission errors), the old token may have expired. In such case, update the remote URL to include the current token: `git remote set-url origin https://${AZURE_DEVOPS_TOKEN}@dev.azure.com/organization/project/_git/repository`
+
+Here are some instructions for pushing, but ONLY do this if the user asks you to:
+* NEVER push directly to the `main` or `master` branch
+* Git config (username and email) is pre-set. Do not modify.
+* You may already be on a branch starting with `openhands-workspace`. Create a new branch with a better name before pushing.
+* Once you've created your own branch or a pull request, continue to update it. Do NOT create a new one unless you are explicitly asked to. Update the PR title and description as necessary, but don't change the branch name.
+* Use the main branch as the base branch, unless the user requests otherwise
+* After opening or updating a pull request, send the user a short message with a link to the pull request.
+* Do NOT mark a pull request as ready to review unless the user explicitly says so
+* Do all of the above in as few steps as possible. E.g. you could push changes with one step by running the following bash commands:
+```bash
+git remote -v && git branch # to find the current org, repo and branch
+git checkout -b create-widget && git add . && git commit -m "Create widget" && git push -u origin create-widget
+```
+
+## Azure DevOps API Usage
+
+When working with Azure DevOps API, you need to use Basic authentication with your Personal Access Token (PAT). The username is ignored (empty string), and the password is the PAT.
+
+Here's how to authenticate with curl:
+```bash
+# Convert PAT to base64
+AUTH=$(echo -n ":$AZURE_DEVOPS_TOKEN" | base64)
+
+# Make API call
+curl -H "Authorization: Basic $AUTH" -H "Content-Type: application/json" https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1
+```
+
+Common API endpoints:
+- List repositories: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1`
+- Get repository details: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}?api-version=7.1`
+- List pull requests: `https://dev.azure.com/{organization}/{project}/_apis/git/pullrequests?api-version=7.1`
+- Create pull request: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests?api-version=7.1` (POST)

package/skills/azure-devops/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: azure-devops
+description: 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.
+triggers:
+- azure_devops
+- azure
+---
+
+You have access to an environment variable, `AZURE_DEVOPS_TOKEN`, which allows you to interact with
+the Azure DevOps API.
+
+<IMPORTANT>
+You can use `curl` with the `AZURE_DEVOPS_TOKEN` to interact with Azure DevOps's API.
+ALWAYS use the Azure DevOps API for operations instead of a web browser.
+</IMPORTANT>
+
+If you encounter authentication issues when pushing to Azure DevOps (such as password prompts or permission errors), the old token may have expired. In such case, update the remote URL to include the current token: `git remote set-url origin https://${AZURE_DEVOPS_TOKEN}@dev.azure.com/organization/project/_git/repository`
+
+Here are some instructions for pushing, but ONLY do this if the user asks you to:
+* NEVER push directly to the `main` or `master` branch
+* Git config (username and email) is pre-set. Do not modify.
+* You may already be on a branch starting with `openhands-workspace`. Create a new branch with a better name before pushing.
+* Once you've created your own branch or a pull request, continue to update it. Do NOT create a new one unless you are explicitly asked to. Update the PR title and description as necessary, but don't change the branch name.
+* Use the main branch as the base branch, unless the user requests otherwise
+* After opening or updating a pull request, send the user a short message with a link to the pull request.
+* Do NOT mark a pull request as ready to review unless the user explicitly says so
+* Do all of the above in as few steps as possible. E.g. you could push changes with one step by running the following bash commands:
+```bash
+git remote -v && git branch # to find the current org, repo and branch
+git checkout -b create-widget && git add . && git commit -m "Create widget" && git push -u origin create-widget
+```
+
+## Azure DevOps API Usage
+
+When working with Azure DevOps API, you need to use Basic authentication with your Personal Access Token (PAT). The username is ignored (empty string), and the password is the PAT.
+
+Here's how to authenticate with curl:
+```bash
+# Convert PAT to base64
+AUTH=$(echo -n ":$AZURE_DEVOPS_TOKEN" | base64)
+
+# Make API call
+curl -H "Authorization: Basic $AUTH" -H "Content-Type: application/json" https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1
+```
+
+Common API endpoints:
+- List repositories: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1`
+- Get repository details: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}?api-version=7.1`
+- List pull requests: `https://dev.azure.com/{organization}/{project}/_apis/git/pullrequests?api-version=7.1`
+- Create pull request: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests?api-version=7.1` (POST)

package/skills/bitbucket/.plugin/plugin.json

@@ -0,0 +1,17 @@
+{
+  "name": "bitbucket",
+  "version": "1.0.0",
+  "description": "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.",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "bitbucket",
+    "git",
+    "pull-request"
+  ]
+}

package/skills/bitbucket/README.md

@@ -0,0 +1,50 @@
+# Bitbucket
+
+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.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `bitbucket`
+- `git`
+
+## Details
+
+You have access to an environment variable, `BITBUCKET_TOKEN`, which allows you to interact with
+the Bitbucket API.
+
+<IMPORTANT>
+You can use `curl` with the `BITBUCKET_TOKEN` to interact with Bitbucket's API.
+ALWAYS use the Bitbucket API for operations instead of a web browser.
+ALWAYS use the `create_bitbucket_pr` tool to open a pull request
+</IMPORTANT>
+
+Only rewrite the Bitbucket remote if a push actually fails with authentication errors and the user has asked you to push. Do not proactively rewrite `origin`. OpenHands commonly stores `BITBUCKET_TOKEN` in the same unencoded `user:token` form used by commands such as `curl --user "$BITBUCKET_TOKEN" ...`, so keep it in that form unless you truly need to embed it in a Git remote URL.
+
+If you need a non-interactive HTTPS remote URL, split `BITBUCKET_TOKEN` on the first `:` and URL-encode each part before calling `git remote set-url`. This avoids breaking usernames or emails that contain reserved URL characters such as `@`:
+
+```bash
+BB_USER="${BITBUCKET_TOKEN%%:*}" && \
+BB_PASS="${BITBUCKET_TOKEN#*:}" && \
+ENCODED_USER=$(python3 -c 'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))' "$BB_USER") && \
+ENCODED_PASS=$(python3 -c 'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))' "$BB_PASS") && \
+git remote set-url origin "https://${ENCODED_USER}:${ENCODED_PASS}@bitbucket.org/username/repo.git"
+```
+
+Atlassian's Bitbucket Cloud docs recommend avoiding long-lived credentials in the remote URL when possible. Their API token examples use either `https://{bitbucket_username}:{api_token}@...` or `https://x-bitbucket-api-token-auth:{api_token}@...`; OpenHands users should only construct those URLs on demand, with proper URL encoding.
+
+Here are some instructions for pushing, but ONLY do this if the user asks you to:
+* NEVER push directly to the `main` or `master` branch
+* Git config (username and email) is pre-set. Do not modify.
+* You may already be on a branch starting with `openhands-workspace`. Create a new branch with a better name before pushing.
+* Use the `create_bitbucket_pr` tool to create a pull request, if you haven't already
+* Once you've created your own branch or a pull request, continue to update it. Do NOT create a new one unless you are explicitly asked to. Update the PR title and description as necessary, but don't change the branch name.
+* Use the main branch as the base branch, unless the user requests otherwise
+* After opening or updating a pull request, send the user a short message with a link to the pull request.
+* Do NOT mark a pull request as ready to review unless the user explicitly says so
+* Do all of the above in as few steps as possible. E.g. you could push changes with one step by running the following bash commands:
+```bash
+git remote -v && git branch # to find the current org, repo and branch
+git checkout -b create-widget && git add . && git commit -m "Create widget" && git push -u origin create-widget
+```

package/skills/bitbucket/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: bitbucket
+description: 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.
+triggers:
+- bitbucket
+- git
+---
+
+You have access to an environment variable, `BITBUCKET_TOKEN`, which allows you to interact with
+the Bitbucket API.
+
+<IMPORTANT>
+You can use `curl` with the `BITBUCKET_TOKEN` to interact with Bitbucket's API.
+ALWAYS use the Bitbucket API for operations instead of a web browser.
+ALWAYS use the `create_bitbucket_pr` tool to open a pull request
+</IMPORTANT>
+
+Only rewrite the Bitbucket remote if a push actually fails with authentication errors and the user has asked you to push. Do not proactively rewrite `origin`. OpenHands OSS commonly stores `BITBUCKET_TOKEN` in the same unencoded `user:token` form used by commands such as `curl --user "$BITBUCKET_TOKEN" ...`, so keep it in that form unless you truly need to embed it in a Git remote URL.
+
+If you need a non-interactive HTTPS remote URL, split `BITBUCKET_TOKEN` on the first `:` and URL-encode each part before calling `git remote set-url`. This avoids breaking usernames or emails that contain reserved URL characters such as `@`:
+
+```bash
+BB_USER="${BITBUCKET_TOKEN%%:*}" && \
+BB_PASS="${BITBUCKET_TOKEN#*:}" && \
+ENCODED_USER=$(python3 -c 'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))' "$BB_USER") && \
+ENCODED_PASS=$(python3 -c 'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))' "$BB_PASS") && \
+git remote set-url origin "https://${ENCODED_USER}:${ENCODED_PASS}@bitbucket.org/username/repo.git"
+```
+
+Atlassian's Bitbucket Cloud docs recommend avoiding long-lived credentials in the remote URL when possible. Their API token examples use either `https://{bitbucket_username}:{api_token}@...` or `https://x-bitbucket-api-token-auth:{api_token}@...`; OpenHands users should only construct those URLs on demand, with proper URL encoding.
+
+Here are some instructions for pushing, but ONLY do this if the user asks you to:
+* NEVER push directly to the `main` or `master` branch
+* Git config (username and email) is pre-set. Do not modify.
+* You may already be on a branch starting with `openhands-workspace`. Create a new branch with a better name before pushing.
+* Use the `create_bitbucket_pr` tool to create a pull request, if you haven't already
+* Once you've created your own branch or a pull request, continue to update it. Do NOT create a new one unless you are explicitly asked to. Update the PR title and description as necessary, but don't change the branch name.
+* Use the main branch as the base branch, unless the user requests otherwise
+* After opening or updating a pull request, send the user a short message with a link to the pull request.
+* Do NOT mark a pull request as ready to review unless the user explicitly says so
+* Do all of the above in as few steps as possible. E.g. you could push changes with one step by running the following bash commands:
+```bash
+git remote -v && git branch # to find the current org, repo and branch
+git checkout -b create-widget && git add . && git commit -m "Create widget" && git push -u origin create-widget
+```

package/skills/code-review/.plugin/plugin.json

@@ -0,0 +1,19 @@
+{
+  "name": "code-review",
+  "version": "1.0.0",
+  "description": "Rigorous code review focusing on data structures, simplicity, security, pragmatism, and risk/safety evaluation. Provides brutally honest, actionable feedback on pull requests or merge requests, inc...",
+  "author": {
+    "name": "OpenHands",
+    "email": "contact@all-hands.dev"
+  },
+  "homepage": "https://github.com/OpenHands/extensions",
+  "repository": "https://github.com/OpenHands/extensions",
+  "license": "MIT",
+  "keywords": [
+    "code-review",
+    "quality",
+    "security",
+    "style",
+    "risk"
+  ]
+}

package/skills/code-review/README.md

@@ -0,0 +1,18 @@
+# Code Review
+
+Rigorous code review focusing on data structures, simplicity, security, pragmatism, and risk/safety evaluation. Provides brutally honest, actionable feedback on pull requests or merge requests, including a risk assessment (🟢 Low / 🟡 Medium / 🔴 High) for every review.
+
+This skill combines the previous `code-review` (standard) and `codereview-roasted` skills into a single unified review skill.
+
+## Triggers
+
+This skill is activated by the following keywords:
+
+- `/codereview`
+- `/codereview-roasted` (backward-compatible alias)
+
+## Details
+
+See [SKILL.md](./SKILL.md) for the full skill content including review scenarios, output format, and communication style guidelines.
+
+The risk evaluation framework is defined in [`references/risk-evaluation.md`](references/risk-evaluation.md) and classifies PR risk based on pattern conformance, security sensitivity, infrastructure dependencies, blast radius, and core system impact.