openhands-extensions 0.33.0__tar.gz → 0.34.0__tar.gz

openhands_extensions-0.34.0/.release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.34.0"
+}

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: openhands-extensions
-Version: 0.33.0
+Version: 0.34.0
 Summary: OpenHands extensions, plugins, and skills (Python bindings for the integration catalog)
 License-File: LICENSE
 Requires-Python: >=3.12

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/integrations/catalog/sentry.json

@@ -50,6 +50,54 @@
         "apiBaseUrl": "https://sentry.io/api/0",
         "openApiUrl": "https://raw.githubusercontent.com/getsentry/sentry/master/api-docs/openapi.json"
       }
+    },
+    {
+      "id": "mcp",
+      "provider": "mcp",
+      "transport": {
+        "kind": "shttp",
+        "url": "https://mcp.sentry.dev/mcp"
+      },
+      "auth": {
+        "strategy": "oauth2",
+        "oauth": {
+          "clientAuthentication": "none"
+        }
+      }
+    },
+    {
+      "id": "api",
+      "provider": "mcp",
+      "transport": {
+        "kind": "stdio",
+        "serverName": "sentry",
+        "command": "npx",
+        "args": [
+          "-y",
+          "@sentry/mcp-server"
+        ],
+        "envFields": [
+          {
+            "key": "SENTRY_ACCESS_TOKEN",
+            "label": "Personal auth token",
+            "type": "password",
+            "placeholder": "sntryu_...",
+            "required": true,
+            "helperText": "Create a [personal auth token](https://docs.sentry.io/account/auth-tokens/) with org:read, project:read, project:write, team:read, team:write, event:read and event:write. With read scopes only, tools that change issues or projects fail. On a self-hosted server, create it there."
+          },
+          {
+            "key": "SENTRY_HOST",
+            "label": "Self-hosted Sentry host",
+            "type": "text",
+            "placeholder": "sentry.example.com",
+            "required": false,
+            "helperText": "Leave empty for sentry.io. For a self-hosted server, enter its hostname without https://."
+          }
+        ]
+      },
+      "auth": {
+        "strategy": "api_key"
+      }
     }
   ],
   "iconBg": "#362D59",

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@openhands/extensions",
-  "version": "0.33.0",
+  "version": "0.34.0",
   "description": "Public OpenHands extension catalogs for skills, plugins, integrations, and automation templates.",
   "license": "MIT",
   "type": "module",

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "openhands-extensions"
-version = "0.33.0"
+version = "0.34.0"
 description = "OpenHands extensions, plugins, and skills (Python bindings for the integration catalog)"
 requires-python = ">=3.12"
 dependencies = [

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/python/openhands_extensions/_version.py

@@ -18,7 +18,7 @@ from importlib.metadata import PackageNotFoundError, version
 #: Kept in lock-step with pyproject.toml/package.json by the version test.
 #: release-please only rewrites a semver found on the annotated line itself, so
 #: the annotation must stay on the assignment; on its own line it is a no-op.
-_FALLBACK_VERSION = "0.33.0"  # x-release-please-version
+_FALLBACK_VERSION = "0.34.0"  # x-release-please-version
 
 try:
     __version__: str = version("openhands-extensions")

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/skills/azure-devops/README.md

@@ -21,7 +21,17 @@ You can use `curl` with the `AZURE_DEVOPS_TOKEN` to interact with Azure DevOps's
 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`
+### Git
+
+Use plain `git clone`, `git fetch`, `git pull` and `git push`. OpenHands sets up git credentials for each Azure DevOps organization the user belongs to, so these commands work for any repository in those organizations, not only the one that was opened. Run them with `GIT_TERMINAL_PROMPT=0` so git fails at once instead of waiting at a username or password prompt.
+
+A repository written as `ORG/PROJECT/REPO` is cloned from `https://dev.azure.com/ORG/PROJECT/_git/REPO`:
+
+```bash
+GIT_TERMINAL_PROMPT=0 git clone https://dev.azure.com/ORG/PROJECT/_git/REPO
+```
+
+Do not put `AZURE_DEVOPS_TOKEN` in a remote URL or pass it to git as an option: a token saved in `.git/config` stays on disk and stops working when it expires. If git fails because it needs a username or password, credentials are not set up for that organization; tell the user instead of embedding the token.
 
 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
@@ -34,17 +44,17 @@ Here are some instructions for pushing, but ONLY do this if the user asks you to
 * 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
+git checkout -b create-widget && git add . && git commit -m "Create widget" && GIT_TERMINAL_PROMPT=0 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.
+`AZURE_DEVOPS_TOKEN` is either a Personal Access Token (PAT) or, for users who sign in with Microsoft Entra ID, an Entra access token. Basic authentication works with both: leave the username empty and use the token as the password. An Entra access token can also be sent as `Authorization: Bearer $AZURE_DEVOPS_TOKEN`.
 
 Here's how to authenticate with curl:
 ```bash
-# Convert PAT to base64
-AUTH=$(echo -n ":$AZURE_DEVOPS_TOKEN" | base64)
+# Base64-encode ":<token>" on one line (Entra tokens are long enough to wrap)
+AUTH=$(echo -n ":$AZURE_DEVOPS_TOKEN" | base64 | tr -d '\n')
 
 # 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

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/skills/azure-devops/SKILL.md

@@ -18,7 +18,17 @@ You can use `curl` with the `AZURE_DEVOPS_TOKEN` to interact with Azure DevOps's
 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`
+## Git
+
+Use plain `git clone`, `git fetch`, `git pull` and `git push`. OpenHands sets up git credentials for each Azure DevOps organization the user belongs to, so these commands work for any repository in those organizations, not only the one that was opened. Run them with `GIT_TERMINAL_PROMPT=0` so git fails at once instead of waiting at a username or password prompt.
+
+A repository written as `ORG/PROJECT/REPO` is cloned from `https://dev.azure.com/ORG/PROJECT/_git/REPO`:
+
+```bash
+GIT_TERMINAL_PROMPT=0 git clone https://dev.azure.com/ORG/PROJECT/_git/REPO
+```
+
+Do not put `AZURE_DEVOPS_TOKEN` in a remote URL or pass it to git as an option: a token saved in `.git/config` stays on disk and stops working when it expires. If git fails because it needs a username or password, credentials are not set up for that organization; tell the user instead of embedding the token.
 
 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
@@ -31,25 +41,25 @@ Here are some instructions for pushing, but ONLY do this if the user asks you to
 * 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
+git checkout -b create-widget && git add . && git commit -m "Create widget" && GIT_TERMINAL_PROMPT=0 git push -u origin create-widget
 ```
 
-On Windows PowerShell, run those `git` commands as separate commands if `&&` is not supported by the installed shell.
+On Windows PowerShell, set `$env:GIT_TERMINAL_PROMPT = "0"` and run those `git` commands as separate commands if `&&` is not supported by the installed shell.
 
 ## 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.
+`AZURE_DEVOPS_TOKEN` is either a Personal Access Token (PAT) or, for users who sign in with Microsoft Entra ID, an Entra access token. Basic authentication works with both: leave the username empty and use the token as the password. An Entra access token can also be sent as `Authorization: Bearer $AZURE_DEVOPS_TOKEN`.
 
 Here's how to authenticate with curl:
 ```bash
-# Convert PAT to base64
-AUTH=$(echo -n ":$AZURE_DEVOPS_TOKEN" | base64)
+# Base64-encode ":<token>" on one line (Entra tokens are long enough to wrap)
+AUTH=$(echo -n ":$AZURE_DEVOPS_TOKEN" | base64 | tr -d '\n')
 
 # 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
 ```
 
-PowerShell equivalent for the PAT header:
+PowerShell equivalent for the Basic header:
 
 ```powershell
 $auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$env:AZURE_DEVOPS_TOKEN"))

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/skills/index.js

@@ -75,7 +75,7 @@ export const SKILLS_CATALOG = [
       "azure_devops",
       "azure"
     ],
-    "content": "## Connection selection\n\nUse authenticated Azure DevOps MCP tools first when they are available in the agent's environment. Detect this by tool availability, without depending on a particular MCP server name. Use the token and direct API instructions below only when Azure DevOps MCP tools are unavailable or when raw API or `curl` access is explicitly needed.\n\nYou have access to an environment variable, `AZURE_DEVOPS_TOKEN`, which allows you to interact with\nthe Azure DevOps API.\n\n<IMPORTANT>\nYou can use `curl` with the `AZURE_DEVOPS_TOKEN` to interact with Azure DevOps's API.\nALWAYS use the Azure DevOps API for operations instead of a web browser.\n</IMPORTANT>\n\nIf 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`\n\nHere are some instructions for pushing, but ONLY do this if the user asks you to:\n* NEVER push directly to the `main` or `master` branch\n* Git config (username and email) is pre-set. Do not modify.\n* You may already be on a branch starting with `openhands-workspace`. Create a new branch with a better name before pushing.\n* 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.\n* Use the main branch as the base branch, unless the user requests otherwise\n* After opening or updating a pull request, send the user a short message with a link to the pull request.\n* Do NOT mark a pull request as ready to review unless the user explicitly says so\n* 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:\n```bash\ngit remote -v && git branch # to find the current org, repo and branch\ngit checkout -b create-widget && git add . && git commit -m \"Create widget\" && git push -u origin create-widget\n```\n\nOn Windows PowerShell, run those `git` commands as separate commands if `&&` is not supported by the installed shell.\n\n## Azure DevOps API Usage\n\nWhen 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.\n\nHere's how to authenticate with curl:\n```bash\n# Convert PAT to base64\nAUTH=$(echo -n \":$AZURE_DEVOPS_TOKEN\" | base64)\n\n# Make API call\ncurl -H \"Authorization: Basic $AUTH\" -H \"Content-Type: application/json\" https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1\n```\n\nPowerShell equivalent for the PAT header:\n\n```powershell\n$auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(\":$env:AZURE_DEVOPS_TOKEN\"))\nInvoke-RestMethod `\n  -Headers @{ Authorization = \"Basic $auth\"; \"Content-Type\" = \"application/json\" } `\n  -Uri \"https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1\"\n```\n\nCommon API endpoints:\n- List repositories: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1`\n- Get repository details: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}?api-version=7.1`\n- List pull requests: `https://dev.azure.com/{organization}/{project}/_apis/git/pullrequests?api-version=7.1`\n- Create pull request: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests?api-version=7.1` (POST)",
+    "content": "## Connection selection\n\nUse authenticated Azure DevOps MCP tools first when they are available in the agent's environment. Detect this by tool availability, without depending on a particular MCP server name. Use the token and direct API instructions below only when Azure DevOps MCP tools are unavailable or when raw API or `curl` access is explicitly needed.\n\nYou have access to an environment variable, `AZURE_DEVOPS_TOKEN`, which allows you to interact with\nthe Azure DevOps API.\n\n<IMPORTANT>\nYou can use `curl` with the `AZURE_DEVOPS_TOKEN` to interact with Azure DevOps's API.\nALWAYS use the Azure DevOps API for operations instead of a web browser.\n</IMPORTANT>\n\n## Git\n\nUse plain `git clone`, `git fetch`, `git pull` and `git push`. OpenHands sets up git credentials for each Azure DevOps organization the user belongs to, so these commands work for any repository in those organizations, not only the one that was opened. Run them with `GIT_TERMINAL_PROMPT=0` so git fails at once instead of waiting at a username or password prompt.\n\nA repository written as `ORG/PROJECT/REPO` is cloned from `https://dev.azure.com/ORG/PROJECT/_git/REPO`:\n\n```bash\nGIT_TERMINAL_PROMPT=0 git clone https://dev.azure.com/ORG/PROJECT/_git/REPO\n```\n\nDo not put `AZURE_DEVOPS_TOKEN` in a remote URL or pass it to git as an option: a token saved in `.git/config` stays on disk and stops working when it expires. If git fails because it needs a username or password, credentials are not set up for that organization; tell the user instead of embedding the token.\n\nHere are some instructions for pushing, but ONLY do this if the user asks you to:\n* NEVER push directly to the `main` or `master` branch\n* Git config (username and email) is pre-set. Do not modify.\n* You may already be on a branch starting with `openhands-workspace`. Create a new branch with a better name before pushing.\n* 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.\n* Use the main branch as the base branch, unless the user requests otherwise\n* After opening or updating a pull request, send the user a short message with a link to the pull request.\n* Do NOT mark a pull request as ready to review unless the user explicitly says so\n* 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:\n```bash\ngit remote -v && git branch # to find the current org, repo and branch\ngit checkout -b create-widget && git add . && git commit -m \"Create widget\" && GIT_TERMINAL_PROMPT=0 git push -u origin create-widget\n```\n\nOn Windows PowerShell, set `$env:GIT_TERMINAL_PROMPT = \"0\"` and run those `git` commands as separate commands if `&&` is not supported by the installed shell.\n\n## Azure DevOps API Usage\n\n`AZURE_DEVOPS_TOKEN` is either a Personal Access Token (PAT) or, for users who sign in with Microsoft Entra ID, an Entra access token. Basic authentication works with both: leave the username empty and use the token as the password. An Entra access token can also be sent as `Authorization: Bearer $AZURE_DEVOPS_TOKEN`.\n\nHere's how to authenticate with curl:\n```bash\n# Base64-encode \":<token>\" on one line (Entra tokens are long enough to wrap)\nAUTH=$(echo -n \":$AZURE_DEVOPS_TOKEN\" | base64 | tr -d '\\n')\n\n# Make API call\ncurl -H \"Authorization: Basic $AUTH\" -H \"Content-Type: application/json\" https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1\n```\n\nPowerShell equivalent for the Basic header:\n\n```powershell\n$auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(\":$env:AZURE_DEVOPS_TOKEN\"))\nInvoke-RestMethod `\n  -Headers @{ Authorization = \"Basic $auth\"; \"Content-Type\" = \"application/json\" } `\n  -Uri \"https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1\"\n```\n\nCommon API endpoints:\n- List repositories: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories?api-version=7.1`\n- Get repository details: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}?api-version=7.1`\n- List pull requests: `https://dev.azure.com/{organization}/{project}/_apis/git/pullrequests?api-version=7.1`\n- Create pull request: `https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests?api-version=7.1` (POST)",
     "category": "code-hosting"
   },
   {
@@ -615,7 +615,7 @@ export const SKILLS_CATALOG = [
       "/software-factory",
       "software factory"
     ],
-    "content": "# Software Factory\n\nBuild a GitHub software factory from unmodified automation catalog bundles\n(`automations/catalog/<id>/manifest.json`); a Jira or Linear station is created\nby its own skill. This skill adds no automation logic.\n\nTwo phases: **Phase 1** gets a working factory after one question. **Phase 2**\nextends it in short rounds, only as far as the user wants. After Phase 1 and\nafter every round, the **Checkpoint** shows what exists and lets the user stop.\n\nCode lives on GitHub. Tickets can come from GitHub issues (default), Jira or\nLinear: only the issue to PR station changes (see \"Ticket source\"). GitLab and\nBitbucket code hosts are not part of this flow.\n\n## Stations\n\n| Station | Catalog id | Phase | Needs agent profile |\n|---|---|---|---|\n| Issue to PR | `github-issue-to-pr`, or the Jira or Linear station | 1 | yes (GitHub issues only) |\n| PR reviewer | `github-pr-reviewer` | 1 | yes |\n| Issue triage | `github-issue-triage`, or `linear-triage-assistant` | 1 | yes (GitHub issues only) |\n| AGENTS.md maintainer | `github-agents-md-maintainer` | add-on | no |\n| Auto-merge watchdog | `github-delivery-watchdog` | add-on | no |\n| Stale-CI PR closer | `github-stale-ci-pr-closer` | add-on | no |\n| QA changes | `qa-changes` | add-on | no |\n\n## Helper script\n\n`scripts/factory.py` in this skill's directory does every catalog and API step\nand prints one JSON document; it exits non-zero with `{\"error\": ...}` on\nfailure. Its usage is below: do not read its source, and do not load the\n`openhands-automation` skill for Phase 1.\n\nSet `OPENHANDS_HOST` to the **Ingress** URL in `<RUNTIME_SERVICES>` on a local\nAgent Canvas (it serves both `/api/automation` and `/api`; the automation\nbackend URL does not), or to `<HOST>` on OpenHands Cloud. Run every command as:\n\n```bash\nGITHUB_PERSONAL_ACCESS_TOKEN=\"$GITHUB_PERSONAL_ACCESS_TOKEN\" \\\nOPENHANDS_AUTOMATION_API_KEY=\"$OPENHANDS_AUTOMATION_API_KEY\" \\\nOPENHANDS_API_KEY=\"$OPENHANDS_API_KEY\" \\\npython3 <this skill's directory>/scripts/factory.py <command> ...\n```\n\n`$F` below stands for that whole line. Keep the secret names in it: the agent\nserver passes a saved secret into a command only when the command names it.\nThe script reads the token and never prints it.\n\n| Command | Does |\n|---|---|\n| `$F preflight --repos a/b,c/d` | Which stations this deployment supports, the agent profile, the GitHub login, push access per repository. |\n| `$F create --repos a/b --ids ID,ID [--set FIELD=VALUE] [--set ID.FIELD=VALUE]` | Fills each station's form (answers, then derived values, then manifest defaults), uploads the bundle and creates it disabled. `FIELD=VALUE` applies to every listed station with that field. Stations that already exist are reported under `existing`, not recreated. |\n| `$F tune --repos a/b --ids ID,ID [--set FIELD=VALUE] [--set ID.FIELD=VALUE]` | Applies new settings to an existing station by updating it in place. Use this to change a value that is fixed at creation. |\n| `$F verify ID... [--no-wait ID...]` | Dispatches once, enables the ones whose run `COMPLETED` and disables the rest, reporting their `error_detail`. `--no-wait` enables without waiting. |\n| `$F status ID...` | The latest run of each. |\n| `$F prs --repos a/b [--branch-prefix P]` | Open pull requests whose branch starts with `P` (default `openhands/agents-md`, the AGENTS.md maintainer's). |\n| `$F reset-token` | Deletes the saved `GITHUB_PERSONAL_ACCESS_TOKEN` (local Agent Canvas), so `request_secret` opens its form again. |\n\n`create` and `verify` return each automation's `url`, its page in Agent Canvas.\nTrust the script's output: do not open pages in the browser to check them, and\ndo not use the task tracker for this flow.\n\nAdd `--profile NAME` to `preflight` or `create` to use a profile other than the\nactive one.\n\n## Rules\n\n- **Supported stations**: create only those `preflight` reports `ok`; say why\n  the others are skipped.\n- **Derived values** (the script fills them; never ask): every\n  `githubTokenSecret` is `GITHUB_PERSONAL_ACCESS_TOKEN`. The watchdog's\n  `branchPrefix` must equal issue to PR's: when it was changed, pass\n  `--set github-delivery-watchdog.branchPrefix=<same value>`.\n- **Agent profile**: if `preflight` reports a profile error, skip the stations\n  that need one and point the user to the station's catalog card in Agent\n  Canvas (Automations), which has a profile picker.\n- **Token**: never ask for its value in chat, echo it, or put it in a tool\n  argument or file.\n- **Failures**: if `create` fails, its output lists the stations it already\n  created; report them with the error and ask whether to retry or delete them\n  (`DELETE ${OPENHANDS_HOST}/api/automation/v1/{id}`).\n- **Existing stations**: a station `create` reports under `existing` was already\n  set up by an earlier run and was left unchanged. Say so rather than presenting\n  it as new, and change it with `$F tune` if the user wants different settings.\n\n## Phase 1 - Working factory\n\n1. Ask, in one message: \"Which GitHub repositories (`owner/repo`)? Where do\n   tickets live: GitHub issues (default), Jira or Linear?\" Say that everything\n   else uses defaults that can be changed afterwards. If the answer names only\n   repositories, use GitHub issues; do not ask again.\n2. Run `$F preflight --repos <repos>`. Drop repositories without `push`, and\n   say which.\n3. If `github_login` is null, act on `token_error`:\n   - `not_set`, and the `request_secret` tool is available: call it once with\n     `name: \"GITHUB_PERSONAL_ACCESS_TOKEN\"` and a `reason` asking for Contents,\n     Issues, Pull requests and Workflows read and write (classic PAT: `repo`,\n     `workflow`). End your turn, wait for the `[secret-request]` message,\n     then rerun `preflight`.\n   - `rejected`: GitHub refuses the saved token (invalid or expired), and\n     `request_secret` cannot replace it: it answers `saved` at once for a name\n     that exists. Say so in one sentence and ask \"Shall I remove it and open\n     the form for a new one?\" On yes, run `$F reset-token`, then handle it as\n     `not_set`. If `reset-token` fails, tell the user to replace it in\n     Settings -> Secrets and say when done.\n   - `not_set` without the tool: tell the user to add it in Settings ->\n     Secrets and stop.\n4. `$F create --repos <repos> --ids github-pr-reviewer`, adding\n   `github-issue-to-pr,github-issue-triage` for GitHub issues. For Jira or\n   Linear, also set up the issue to PR station as \"Ticket source\" describes;\n   for Linear, set up triage with the `linear-triage` skill (Jira has none).\n5. `$F verify <reviewer id> [<issue to PR id>] [<triage id>]`.\n6. Go to the Checkpoint.\n\n## Checkpoint\n\nWrite one short message, in this order:\n\n1. One plain sentence on what runs and how to use it: \"Your factory is running\n   on `<repos>`. Add the `<trigger label>` label to a ticket to get a draft pull\n   request; the reviewer reviews it and you merge it.\" (On Jira, add that the\n   ticket body must name the `owner/repo`.)\n2. If the AGENTS.md maintainer was added, the `AGENTS.md` pull requests from\n   `$F prs --repos <repos>`, asking the user to merge them: they give the build\n   agent the repository's build, test and lint commands. One opened before\n   this setup started (`created_at`) is \"still open from an earlier run\", not\n   new; the maintainer works once a week per repository. If there are none\n   yet, say they are on their way.\n3. A small table of the automations, each linked to its `url`:\n\n   | Automation | Schedule | Status |\n   |---|---|---|\n   | [Issue to PR](<url>) | every 15 minutes | on |\n\n   Status is `on`, or `off` with the reason in a few words. No automation ids.\n4. The settings in effect, as a short list (the Tune table's current values).\n   Mention that the reviewer also reviews any open, non-draft, green pull\n   request with no review yet (at most 2 new per scan).\n5. End with only a list of possible next steps, one line each, and nothing\n   after it. Mark the first one not done yet as recommended:\n   - **Try it**: I open a small test issue with the `<trigger label>` label in\n     `<repo>`, only if you say so, and report the pull request.\n   - **Tune**: change a setting from the list above.\n   - **Add a station**: AGENTS.md maintainer, auto-merge watchdog, stale-CI closer (QA only\n     if `preflight` reports it `ok`).\n   - **Stop here**: the factory keeps running as it is.\n\n## Phase 2 - Extend, one round at a time\n\nDo only what the user picked. Ask only the questions for it, in one message,\neach with its current value. Apply, then return to the Checkpoint.\n\n### Tune\n\n| Setting | Default | `--set` |\n|---|---|---|\n| Issue trigger label (GitHub issues) | `openhands` | `github-issue-to-pr.triggerLabel` |\n| Draft or ready pull requests | `draft` | `pullRequestMode` (issue to PR, AGENTS.md maintainer) |\n| Branch prefix (GitHub issues) | `openhands/issue` | `github-issue-to-pr.branchPrefix` (and the watchdog's, if present) |\n| Which pull requests get reviewed | label `openhands-review`, reviewer `all-hands-bot` | `github-pr-reviewer.triggerLabel`, `triggerReviewer` |\n| Review tone: concise, thorough, friendly | `concise` | `reviewTone` |\n| Human reviewers requested after agent approval (two or more logins) | none | `maintainers` |\n| Schedules and timezone | issue to PR `*/15 * * * *`, reviewer `*/5 * * * *`, triage `*/5 * * * *`, add-ons per manifest; `UTC` | `ID.schedule`, `timezone` |\n| Agent profile | active profile | `--profile NAME` |\n\nApply:\n\n- Schedule or timezone only:\n  `PATCH ${OPENHANDS_HOST}/api/automation/v1/{id}` with `{\"trigger\": {...}}`.\n- Jira or Linear station settings: change them as its skill describes.\n- Anything else is fixed at creation: `$F tune --repos <repos> --ids <id>` with\n  the new `--set` values (repeat every earlier non-default value), then\n  `$F verify <id>`. `tune` updates the station in place, so there is no\n  replacement to delete and no template-id collision.\n\n### Add a station\n\nAsk only the question below, then `$F create` it and `$F verify` it.\n\n- **Auto-merge watchdog** (`github-delivery-watchdog`, GitHub issues only,\n  since it merges only branches with the issue to PR prefix): confirm the user\n  wants the agent to merge pull requests itself once review, tests and CI are\n  green.\n- **Stale-CI closer** (`github-stale-ci-pr-closer`): confirm it may warn on,\n  then close, pull requests whose CI keeps failing.\n- **AGENTS.md maintainer** (`github-agents-md-maintainer`): nothing. Verify it\n  with `--no-wait`; its run opens one `AGENTS.md` pull request per repository.\n- **QA changes**: which base branch (default `main`). Offer QA only if\n  `preflight` reports it `ok` and the `openhands-automation` webhook\n  reachability check passes. It has no bundle, so the script cannot create it:\n  create it as the `openhands-automation` skill describes for an\n  event-triggered prompt preset, with its manifest `prompt` and `filter`, one\n  per repository (it takes a single `repository`). It runs only on pull request\n  events, so leave it enabled and skip `verify`.\n\n## Ticket source\n\n- **GitHub issues**: `github-issue-to-pr`, created with the others in Phase 1.\n- **Jira**: follow the `jira-issue-to-pr` skill with `git_provider` `github`\n  and its defaults (label `create-pr`, `*/5 * * * *`). Ask only what it cannot\n  look up (the Jira site if several, or the API-token details when Atlassian\n  Rovo is not connected). Tell the user each ticket body must name its\n  `owner/repo`.\n- **Linear**: follow the `ticket-to-code-change` skill with GitHub as the\n  provider. Ask its questions in one message, proposing the repositories above\n  and `*/15 * * * *` as defaults.\n\nOnce its skill has created the station, run `$F verify <id>` on it.\n\n## Troubleshooting\n\n| Symptom | Cause and fix |\n|---|---|\n| Create returns 422 | A value does not match the manifest `setup` block; fix the field at the path the error names. |\n| Issue to PR fails at push | The token lacks Contents or Workflows write, or does not cover that repository. |\n| Reviewer never reviews | The pull request has neither the trigger label nor a request for the trigger reviewer, and is not green. |\n| Watchdog never merges | Its branch prefix differs from issue to PR's, or the pull request lacks an independent approval or green CI. |",
+    "content": "# Software Factory\n\nBuild a GitHub software factory from unmodified automation catalog bundles\n(`automations/catalog/<id>/manifest.json`); a Jira or Linear station is created\nby its own skill. This skill adds no automation logic.\n\nTwo phases: **Phase 1** gets a working factory after one question. **Phase 2**\nextends it in short rounds, only as far as the user wants. After Phase 1 and\nafter every round, the **Checkpoint** shows what exists and lets the user stop.\n\nCode lives on GitHub. Tickets can come from GitHub issues (default), Jira or\nLinear: only the issue to PR station changes (see \"Ticket source\"). GitLab and\nBitbucket code hosts are not part of this flow.\n\n## Stations\n\n| Station | Catalog id | Phase | Needs agent profile |\n|---|---|---|---|\n| Issue to PR | `github-issue-to-pr`, or the Jira or Linear station | 1 | yes (GitHub issues only) |\n| PR reviewer | `github-pr-reviewer` | 1 | yes |\n| Issue triage | `github-issue-triage`, or `linear-triage-assistant` | 1 | yes (GitHub issues only) |\n| AGENTS.md maintainer | `github-agents-md-maintainer` | add-on | no |\n| Auto-merge watchdog | `github-delivery-watchdog` | add-on | no |\n| Stale-CI PR closer | `github-stale-ci-pr-closer` | add-on | no |\n| QA changes | `qa-changes` | add-on | no |\n\n## Helper script\n\n`scripts/factory.py` in this skill's directory does every catalog and API step\nand prints one JSON document; it exits non-zero with `{\"error\": ...}` on\nfailure. Its usage is below: do not read its source, and do not load the\n`openhands-automation` skill for Phase 1.\n\nSet `OPENHANDS_HOST` to the **Ingress** URL in `<RUNTIME_SERVICES>` on a local\nAgent Canvas (it serves both `/api/automation` and `/api`; the automation\nbackend URL does not), or to `<HOST>` on OpenHands Cloud. Run every command as:\n\n```bash\nGITHUB_PERSONAL_ACCESS_TOKEN=\"$GITHUB_PERSONAL_ACCESS_TOKEN\" \\\nOPENHANDS_AUTOMATION_API_KEY=\"$OPENHANDS_AUTOMATION_API_KEY\" \\\nOPENHANDS_API_KEY=\"$OPENHANDS_API_KEY\" \\\npython3 <this skill's directory>/scripts/factory.py <command> ...\n```\n\n`$F` below stands for that whole line. Keep the secret names in it: the agent\nserver passes a saved secret into a command only when the command names it.\nThe script reads the token and never prints it.\n\n| Command | Does |\n|---|---|\n| `$F preflight --repos a/b,c/d` | Which stations this deployment supports, the agent profile, the GitHub login, push access per repository. |\n| `$F create --repos a/b --ids ID,ID [--set FIELD=VALUE] [--set ID.FIELD=VALUE]` | Fills each station's form (answers, then derived values, then manifest defaults), uploads the bundle and creates it disabled. `FIELD=VALUE` applies to every listed station with that field. Stations that already exist are reported under `existing`, not recreated. |\n| `$F tune --repos a/b --ids ID,ID [--set FIELD=VALUE] [--set ID.FIELD=VALUE]` | Applies new settings to an existing station by updating it in place. Use this to change a value that is fixed at creation. |\n| `$F verify ID... [--no-wait ID...]` | Dispatches once, enables the ones whose run `COMPLETED` and disables the rest, reporting their `error_detail`. `--no-wait` enables without waiting. |\n| `$F status ID...` | The latest run of each. |\n| `$F prs --repos a/b [--branch-prefix P]` | Open pull requests whose branch starts with `P` (default `openhands/agents-md`, the AGENTS.md maintainer's). |\n| `$F reset-token` | Deletes the saved `GITHUB_PERSONAL_ACCESS_TOKEN` (local Agent Canvas), so `request_secret` opens its form again. |\n\n`create` and `verify` return each automation's `url`, its page in Agent Canvas.\nTrust the script's output: do not open pages in the browser to check them, and\ndo not use the task tracker for this flow.\n\nAdd `--profile NAME` to `preflight` or `create` to use a profile other than the\nactive one.\n\n## Rules\n\n- **Supported stations**: create only those `preflight` reports `ok`; say why\n  the others are skipped.\n- **Derived values** (the script fills them; never ask): every\n  `githubTokenSecret` is `GITHUB_PERSONAL_ACCESS_TOKEN`. The watchdog's\n  `branchPrefix` must equal issue to PR's: when it was changed, pass\n  `--set github-delivery-watchdog.branchPrefix=<same value>`.\n- **Agent profile**: if `preflight` reports a profile error, skip the stations\n  that need one and point the user to the station's catalog card in Agent\n  Canvas (Automations), which has a profile picker.\n- **Token**: never ask for its value in chat, echo it, or put it in a tool\n  argument or file.\n- **Failures**: if `create` fails, its output lists the stations it already\n  created; report them with the error and ask whether to retry or delete them\n  (`DELETE ${OPENHANDS_HOST}/api/automation/v1/{id}`).\n- **Existing stations**: a station `create` reports under `existing` was already\n  set up by an earlier run and was left unchanged. Say so rather than presenting\n  it as new, and change it with `$F tune` if the user wants different settings.\n\n## Phase 1 - Working factory\n\n1. Ask, in one message: \"Which GitHub repositories (`owner/repo`)? Where do\n   tickets live: GitHub issues (default), Jira or Linear?\" Say that everything\n   else uses defaults that can be changed afterwards. If the answer names only\n   repositories, use GitHub issues; do not ask again.\n2. Run `$F preflight --repos <repos>`. Drop repositories without `push`, and\n   say which.\n3. If `github_login` is null, act on `token_error`:\n   - `not_set`, and the `request_secret` tool is available: call it once with\n     `name: \"GITHUB_PERSONAL_ACCESS_TOKEN\"` and a `reason` asking for Contents,\n     Issues, Pull requests and Workflows read and write (classic PAT: `repo`,\n     `workflow`), and saying a token can be created at\n     https://github.com/settings/personal-access-tokens. End your turn, wait\n     for the `[secret-request]` message, then rerun `preflight`.\n   - `rejected`: GitHub refuses the saved token (invalid or expired), and\n     `request_secret` cannot replace it: it answers `saved` at once for a name\n     that exists. Say so in one sentence and ask \"Shall I remove it and open\n     the form for a new one?\" On yes, run `$F reset-token`, then handle it as\n     `not_set`. If `reset-token` fails, tell the user to create a token at\n     https://github.com/settings/personal-access-tokens, replace it in\n     Settings -> Secrets, and say when done.\n   - `not_set` without the tool: tell the user to create a token at\n     https://github.com/settings/personal-access-tokens and add it in\n     Settings -> Secrets, then stop.\n4. `$F create --repos <repos> --ids github-pr-reviewer`, adding\n   `github-issue-to-pr,github-issue-triage` for GitHub issues. For Jira or\n   Linear, also set up the issue to PR station as \"Ticket source\" describes;\n   for Linear, set up triage with the `linear-triage` skill (Jira has none).\n5. `$F verify <reviewer id> [<issue to PR id>] [<triage id>]`.\n6. Go to the Checkpoint.\n\n## Checkpoint\n\nWrite one short message, in this order:\n\n1. One plain sentence on what runs and how to use it: \"Your factory is running\n   on `<repos>`. Add the `<trigger label>` label to a ticket to get a draft pull\n   request; the reviewer reviews it and you merge it.\" (On Jira, add that the\n   ticket body must name the `owner/repo`.)\n2. If the AGENTS.md maintainer was added, the `AGENTS.md` pull requests from\n   `$F prs --repos <repos>`, asking the user to merge them: they give the build\n   agent the repository's build, test and lint commands. One opened before\n   this setup started (`created_at`) is \"still open from an earlier run\", not\n   new; the maintainer works once a week per repository. If there are none\n   yet, say they are on their way.\n3. A small table of the automations, each linked to its `url`:\n\n   | Automation | Schedule | Status |\n   |---|---|---|\n   | [Issue to PR](<url>) | every 15 minutes | on |\n\n   Status is `on`, or `off` with the reason in a few words. No automation ids.\n4. The settings in effect, as a short list (the Tune table's current values).\n   Mention that the reviewer also reviews any open, non-draft, green pull\n   request with no review yet (at most 2 new per scan).\n5. End with only a list of possible next steps, one line each, and nothing\n   after it. Mark the first one not done yet as recommended:\n   - **Try it**: I open a small test issue with the `<trigger label>` label in\n     `<repo>`, only if you say so, and report the pull request.\n   - **Tune**: change a setting from the list above.\n   - **Add a station**: AGENTS.md maintainer, auto-merge watchdog, stale-CI closer (QA only\n     if `preflight` reports it `ok`).\n   - **Stop here**: the factory keeps running as it is.\n\n## Phase 2 - Extend, one round at a time\n\nDo only what the user picked. Ask only the questions for it, in one message,\neach with its current value. Apply, then return to the Checkpoint.\n\n### Tune\n\n| Setting | Default | `--set` |\n|---|---|---|\n| Issue trigger label (GitHub issues) | `openhands` | `github-issue-to-pr.triggerLabel` |\n| Draft or ready pull requests | `draft` | `pullRequestMode` (issue to PR, AGENTS.md maintainer) |\n| Branch prefix (GitHub issues) | `openhands/issue` | `github-issue-to-pr.branchPrefix` (and the watchdog's, if present) |\n| Which pull requests get reviewed | label `openhands-review`, reviewer `all-hands-bot` | `github-pr-reviewer.triggerLabel`, `triggerReviewer` |\n| Review tone: concise, thorough, friendly | `concise` | `reviewTone` |\n| Human reviewers requested after agent approval (two or more logins) | none | `maintainers` |\n| Schedules and timezone | issue to PR `*/15 * * * *`, reviewer `*/5 * * * *`, triage `*/5 * * * *`, add-ons per manifest; `UTC` | `ID.schedule`, `timezone` |\n| Agent profile | active profile | `--profile NAME` |\n\nApply:\n\n- Schedule or timezone only:\n  `PATCH ${OPENHANDS_HOST}/api/automation/v1/{id}` with `{\"trigger\": {...}}`.\n- Jira or Linear station settings: change them as its skill describes.\n- Anything else is fixed at creation: `$F tune --repos <repos> --ids <id>` with\n  the new `--set` values (repeat every earlier non-default value), then\n  `$F verify <id>`. `tune` updates the station in place, so there is no\n  replacement to delete and no template-id collision.\n\n### Add a station\n\nAsk only the question below, then `$F create` it and `$F verify` it.\n\n- **Auto-merge watchdog** (`github-delivery-watchdog`, GitHub issues only,\n  since it merges only branches with the issue to PR prefix): confirm the user\n  wants the agent to merge pull requests itself once review, tests and CI are\n  green.\n- **Stale-CI closer** (`github-stale-ci-pr-closer`): confirm it may warn on,\n  then close, pull requests whose CI keeps failing.\n- **AGENTS.md maintainer** (`github-agents-md-maintainer`): nothing. Verify it\n  with `--no-wait`; its run opens one `AGENTS.md` pull request per repository.\n- **QA changes**: which base branch (default `main`). Offer QA only if\n  `preflight` reports it `ok` and the `openhands-automation` webhook\n  reachability check passes. It has no bundle, so the script cannot create it:\n  create it as the `openhands-automation` skill describes for an\n  event-triggered prompt preset, with its manifest `prompt` and `filter`, one\n  per repository (it takes a single `repository`). It runs only on pull request\n  events, so leave it enabled and skip `verify`.\n\n## Ticket source\n\n- **GitHub issues**: `github-issue-to-pr`, created with the others in Phase 1.\n- **Jira**: follow the `jira-issue-to-pr` skill with `git_provider` `github`\n  and its defaults (label `create-pr`, `*/5 * * * *`). Ask only what it cannot\n  look up (the Jira site if several, or the API-token details when Atlassian\n  Rovo is not connected). Tell the user each ticket body must name its\n  `owner/repo`.\n- **Linear**: follow the `ticket-to-code-change` skill with GitHub as the\n  provider. Ask its questions in one message, proposing the repositories above\n  and `*/15 * * * *` as defaults.\n\nOnce its skill has created the station, run `$F verify <id>` on it.\n\n## Troubleshooting\n\n| Symptom | Cause and fix |\n|---|---|\n| Create returns 422 | A value does not match the manifest `setup` block; fix the field at the path the error names. |\n| Issue to PR fails at push | The token lacks Contents or Workflows write, or does not cover that repository. |\n| Reviewer never reviews | The pull request has neither the trigger label nor a request for the trigger reviewer, and is not green. |\n| Watchdog never merges | Its branch prefix differs from issue to PR's, or the pull request lacks an independent approval or green CI. |",
     "category": "automations",
     "defaultEnabled": true
   },

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/skills/software-factory/README.md

@@ -50,7 +50,8 @@ or Linear issue to PR station is created by its own skill instead.
   features each station's manifest requires (`customTarball`, plus
   `agentProfiles` for issue to PR, reviewer and triage; QA needs webhook delivery).
 - A GitHub token with Contents, Issues, Pull requests and Workflows read and
-  write on every selected repository.
+  write on every selected repository, created at
+  [GitHub settings](https://github.com/settings/personal-access-tokens).
 - An OpenHands (not ACP) agent profile that may use that token.
 - Jira tickets: a connected Atlassian Rovo server or a Jira API token. Linear
   tickets: a Linear connection.

{openhands_extensions-0.33.0 → openhands_extensions-0.34.0}/skills/software-factory/SKILL.md

@@ -108,16 +108,19 @@ active one.
    - `not_set`, and the `request_secret` tool is available: call it once with
      `name: "GITHUB_PERSONAL_ACCESS_TOKEN"` and a `reason` asking for Contents,
      Issues, Pull requests and Workflows read and write (classic PAT: `repo`,
-     `workflow`). End your turn, wait for the `[secret-request]` message,
-     then rerun `preflight`.
+     `workflow`), and saying a token can be created at
+     https://github.com/settings/personal-access-tokens. End your turn, wait
+     for the `[secret-request]` message, then rerun `preflight`.
    - `rejected`: GitHub refuses the saved token (invalid or expired), and
      `request_secret` cannot replace it: it answers `saved` at once for a name
      that exists. Say so in one sentence and ask "Shall I remove it and open
      the form for a new one?" On yes, run `$F reset-token`, then handle it as
-     `not_set`. If `reset-token` fails, tell the user to replace it in
-     Settings -> Secrets and say when done.
-   - `not_set` without the tool: tell the user to add it in Settings ->
-     Secrets and stop.
+     `not_set`. If `reset-token` fails, tell the user to create a token at
+     https://github.com/settings/personal-access-tokens, replace it in
+     Settings -> Secrets, and say when done.
+   - `not_set` without the tool: tell the user to create a token at
+     https://github.com/settings/personal-access-tokens and add it in
+     Settings -> Secrets, then stop.
 4. `$F create --repos <repos> --ids github-pr-reviewer`, adding
    `github-issue-to-pr,github-issue-triage` for GitHub issues. For Jira or
    Linear, also set up the issue to PR station as "Ticket source" describes;

openhands_extensions-0.34.0/tests/test_azure_devops_skill.py

@@ -0,0 +1,40 @@
+"""The azure-devops skill describes plain git, not token-in-URL workarounds."""
+
+from pathlib import Path
+
+import pytest
+
+SKILL_DIR = Path(__file__).parent.parent / "skills" / "azure-devops"
+
+
+@pytest.fixture(params=["SKILL.md", "README.md"])
+def skill_text(request):
+    return (SKILL_DIR / request.param).read_text()
+
+
+def test_git_uses_plain_commands_and_clone_url(skill_text):
+    assert "Use plain `git clone`" in skill_text
+    assert (
+        "GIT_TERMINAL_PROMPT=0 git clone https://dev.azure.com/ORG/PROJECT/_git/REPO"
+        in skill_text
+    )
+
+
+def test_no_token_in_remote_url(skill_text):
+    assert "git remote set-url" not in skill_text
+    assert "${AZURE_DEVOPS_TOKEN}@" not in skill_text
+    assert "$AZURE_DEVOPS_TOKEN@" not in skill_text
+
+
+def test_no_credential_helper_token_file(skill_text):
+    assert "azure-devops-access-token" not in skill_text
+
+
+def test_token_is_not_described_as_pat_only(skill_text):
+    assert "Microsoft Entra" in skill_text
+    assert "with your Personal Access Token (PAT)" not in skill_text
+
+
+def test_basic_auth_header_is_a_single_line(skill_text):
+    # GNU base64 wraps at 76 columns, which splits long Entra tokens.
+    assert "base64 | tr -d '\\n'" in skill_text

openhands_extensions-0.33.0/.release-please-manifest.json

@@ -1,3 +0,0 @@
-{
-  ".": "0.33.0"
-}