@openhands/agent-canvas 1.2.0 → 1.3.0

package/build/assets/{vendor~root-layout~home~conversation-panel~conversation~launch~skills-settings~automations-~ki5qnp0d-DJHl5b-B.js → vendor~root-layout~home~conversation-panel~conversation~launch~skills-settings~automations-~ki5qnp0d-rV6d1Iv_.js}

@@ -56,6 +56,8 @@ python3 scripts/fetch_skill.py "https://github.com/OpenHands/extensions/tree/mai
 ls /path/to/workspace/.agents/skills/codereview/SKILL.md
 \`\`\`
 
+On Windows, use \`python\` if \`python3\` is not available and verify with PowerShell, for example: \`Test-Path C:\\path\\to\\workspace\\.agents\\skills\\codereview\\SKILL.md\`.
+
 Response: "✅ Added \`codereview\` to your workspace. The skill is now available."
 
 ## Notes
@@ -500,6 +502,8 @@ 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
 \`\`\`
 
+On Windows PowerShell, 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.
@@ -513,6 +517,15 @@ AUTH=$(echo -n ":$AZURE_DEVOPS_TOKEN" | base64)
 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
+$auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(":$env:AZURE_DEVOPS_TOKEN"))
+Invoke-RestMethod \`
+  -Headers @{ Authorization = "Basic $auth"; "Content-Type" = "application/json" } \`
+  -Uri "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\`
@@ -565,7 +578,7 @@ Bitbucket API (not a web browser) and always use the listed PR tool to open a pu
 | Host | \`bitbucket.org\` | self-hosted domain |
 | REST API base | \`https://api.bitbucket.org/2.0\` | \`https://<host>/rest/api/1.0\` |
 | Repository identifier | \`workspace/repo_slug\` | \`PROJECT/repo_slug\` (project key) |
-| Pull request tool | \`create_bitbucket_pr\` | \`create_bitbucket_data_center_pr\` |`},{name:`bitbucket-cloud`,description:`Bitbucket Cloud (bitbucket.org) specifics — authenticate with BITBUCKET_TOKEN, use the REST API v2, workspace/repo_slug repositories, and the create_bitbucket_pr tool. Loaded on demand by the bitbucket skill once a Cloud environment is detected.`,triggers:[],content:'You are working with **Bitbucket Cloud** (`bitbucket.org`). You have access to an\nenvironment variable, `BITBUCKET_TOKEN`, which allows you to interact with the Bitbucket\nCloud API.\n\n- REST API base URL: `https://api.bitbucket.org/2.0`\n- Repository identifier format: `workspace/repo_slug`\n\n<IMPORTANT>\nYou can use `curl` with the `BITBUCKET_TOKEN` to interact with Bitbucket\'s API.\nALWAYS use the Bitbucket API for operations instead of a web browser.\nALWAYS use the `create_bitbucket_pr` tool to open a pull request\n</IMPORTANT>\n\nOnly 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.\n\nIf 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 `@`:\n\n```bash\nBB_USER="${BITBUCKET_TOKEN%%:*}" && \\\nBB_PASS="${BITBUCKET_TOKEN#*:}" && \\\nENCODED_USER=$(python3 -c \'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))\' "$BB_USER") && \\\nENCODED_PASS=$(python3 -c \'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))\' "$BB_PASS") && \\\ngit remote set-url origin "https://${ENCODED_USER}:${ENCODED_PASS}@bitbucket.org/username/repo.git"\n```\n\nAtlassian\'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.\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* Use the `create_bitbucket_pr` tool to create a pull request, if you haven\'t already\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```'},{name:`bitbucket-data-center`,description:`Bitbucket Data Center (self-hosted Bitbucket Server) specifics — authenticate with BITBUCKET_DATA_CENTER_TOKEN, use the REST API 1.0, PROJECT/repo_slug repositories, scm/ git remotes, and the create_bitbucket_data_center_pr tool. Loaded on demand by the bitbucket skill once a Data Center environment is detected.`,triggers:[],content:`You are working with **Bitbucket Data Center** (self-hosted Bitbucket Server). You have
+| Pull request tool | \`create_bitbucket_pr\` | \`create_bitbucket_data_center_pr\` |`},{name:`bitbucket-cloud`,description:`Bitbucket Cloud (bitbucket.org) specifics — authenticate with BITBUCKET_TOKEN, use the REST API v2, workspace/repo_slug repositories, and the create_bitbucket_pr tool. Loaded on demand by the bitbucket skill once a Cloud environment is detected.`,triggers:[],content:'You are working with **Bitbucket Cloud** (`bitbucket.org`). You have access to an\nenvironment variable, `BITBUCKET_TOKEN`, which allows you to interact with the Bitbucket\nCloud API.\n\n- REST API base URL: `https://api.bitbucket.org/2.0`\n- Repository identifier format: `workspace/repo_slug`\n\n<IMPORTANT>\nYou can use `curl` with the `BITBUCKET_TOKEN` to interact with Bitbucket\'s API.\nALWAYS use the Bitbucket API for operations instead of a web browser.\nALWAYS use the `create_bitbucket_pr` tool to open a pull request\n</IMPORTANT>\n\nOnly 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.\n\nIf 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 `@`:\n\n```bash\nBB_USER="${BITBUCKET_TOKEN%%:*}" && \\\nBB_PASS="${BITBUCKET_TOKEN#*:}" && \\\nENCODED_USER=$(python3 -c \'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))\' "$BB_USER") && \\\nENCODED_PASS=$(python3 -c \'import sys, urllib.parse; print(urllib.parse.quote(sys.argv[1], safe=""))\' "$BB_PASS") && \\\ngit remote set-url origin "https://${ENCODED_USER}:${ENCODED_PASS}@bitbucket.org/username/repo.git"\n```\n\nPowerShell equivalent for the remote URL encoding:\n\n```powershell\n$parts = $env:BITBUCKET_TOKEN -split ":", 2\n$encodedUser = [Uri]::EscapeDataString($parts[0])\n$encodedPass = [Uri]::EscapeDataString($parts[1])\ngit remote set-url origin "https://${encodedUser}:${encodedPass}@bitbucket.org/username/repo.git"\n```\n\nAtlassian\'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.\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* Use the `create_bitbucket_pr` tool to create a pull request, if you haven\'t already\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.'},{name:`bitbucket-data-center`,description:`Bitbucket Data Center (self-hosted Bitbucket Server) specifics — authenticate with BITBUCKET_DATA_CENTER_TOKEN, use the REST API 1.0, PROJECT/repo_slug repositories, scm/ git remotes, and the create_bitbucket_data_center_pr tool. Loaded on demand by the bitbucket skill once a Data Center environment is detected.`,triggers:[],content:`You are working with **Bitbucket Data Center** (self-hosted Bitbucket Server). You have
 access to an environment variable, \`BITBUCKET_DATA_CENTER_TOKEN\`, which contains a basic
 auth token in the format \`username:your-token\` that allows you to interact with the git
 repository and the REST API.
@@ -641,6 +654,7 @@ The prompt includes a **Files Changed** manifest listing every file in the PR, f
 3. Only after both checks come up empty should you flag something as missing. Even then, prefer "I could not locate X" over "X is missing" — the file may be in a path you haven't searched.
 
 Before posting an **inline review comment that names a specific line number**, verify the line maps to what you think it does (\`sed -n 'X,Yp' <file>\` or \`view\`). Line numbers derived by counting \`+\`/\`-\`/context lines from a \`@@\` hunk header are not reliable; ground them against the file.
+On Windows PowerShell, use \`Get-Content\`, \`Select-String\`, or \`(Get-Content <file>)[($start - 1)..($end - 1)]\` for the same file and line checks.
 
 CODE REVIEW SCENARIOS:
 
@@ -896,6 +910,8 @@ When a review aspect has no findings, include it with an explicit "no issues fou
 - **\`references/code-quality-review.md\`** - Detailed criteria for naming, complexity, error handling, and project standards compliance
 - **\`references/efficiency-review.md\`** - Detailed criteria for algorithmic complexity, unnecessary work, resource usage, and I/O patterns`},{name:`datadog`,description:`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.`,triggers:[`datadog`],content:`# Datadog
 
+Windows PowerShell equivalents for the Datadog \`curl\`, environment-variable, timestamp, and JSON formatting snippets are in \`references/windows.md\`.
+
 <IMPORTANT>
 Before performing any Datadog operations, first check if the required environment variables are set:
 
@@ -1108,6 +1124,8 @@ Use this skill when implementing or automating Discord integrations.
 
 ## Quick recipes
 
+The shell snippets below use POSIX-style environment variables and line continuations. On Windows PowerShell, use \`curl.exe\` for the shown flags and \`$env:DISCORD_WEBHOOK_URL\` / \`$env:DISCORD_BOT_TOKEN\` for environment variables, or translate the request to \`Invoke-RestMethod\`.
+
 ### Post a message via an incoming webhook (recommended)
 
 Discord requires at least one of \`content\`, \`embeds\`, \`components\`, \`file\`, or \`poll\`.
@@ -1179,13 +1197,17 @@ sudo dockerd > /tmp/docker.log 2>&1 &
 sleep 5
 \`\`\`
 
+On Windows, start Docker Desktop or the Docker service instead of running \`sudo dockerd\`; then run Docker commands from PowerShell without \`sudo\`.
+
 ## Verifying Docker Installation
 
 To verify Docker is working correctly, run the hello-world container:
 
 \`\`\`bash
 sudo docker run hello-world
-\`\`\``},{name:`evidence-based-citations`,description:`Back factual claims and field values with official, verifiable sources. Use when the user asks to fill fields, answer questions, or make claims that must be supported by an exact quote and an official link.`,triggers:[`evidence-based`,`cite source`,`cite sources`,`official source`,`official link`,`official links`,`official docs`,`official documentation`,`verifiable source`],content:`The user wants every field value or factual claim you produce in the current response to be backed by an official, verifiable source. Apply this skill to the response that triggered it; do not assume it stays active for the rest of the conversation unless the user clearly asks for it to.
+\`\`\`
+
+PowerShell equivalent after Docker Desktop is running: \`docker run hello-world\`.`},{name:`evidence-based-citations`,description:`Back factual claims and field values with official, verifiable sources. Use when the user asks to fill fields, answer questions, or make claims that must be supported by an exact quote and an official link.`,triggers:[`evidence-based`,`cite source`,`cite sources`,`official source`,`official link`,`official links`,`official docs`,`official documentation`,`verifiable source`],content:`The user wants every field value or factual claim you produce in the current response to be backed by an official, verifiable source. Apply this skill to the response that triggered it; do not assume it stays active for the rest of the conversation unless the user clearly asks for it to.
 
 ## Output format
 
@@ -1277,6 +1299,8 @@ Examples:
 - \`gh pr checks 200 --watch --interval 10\` to check until completed.
 </IMPORTANT>
 
+Windows PowerShell equivalents for the multi-line shell snippets below are in \`references/windows.md\`.
+
 If you encounter authentication issues when pushing to GitHub (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://\${GITHUB_TOKEN}@github.com/username/repo.git\`
 
 Here are some instructions for pushing, but ONLY do this if the user asks you to:
@@ -1396,6 +1420,7 @@ See [README.md](README.md) for the full debugging workflow, \`gh\` commands, and
 4. **Artifacts for job-to-job data** - Files don't persist between jobs without \`upload-artifact\`/\`download-artifact\``},{name:`github-pr-review`,description:`Post PR review comments using the GitHub API with inline comments, suggestions, and priority labels.`,triggers:[`/github-pr-review`],content:`# GitHub PR Review
 
 Post structured code review feedback using the GitHub API with inline comments on specific lines.
+Windows PowerShell equivalents for JSON file creation, temp paths, line lookup, and fallback \`curl\` are in \`references/windows.md\`.
 
 ## Key Rule: One API Call
 
@@ -1576,6 +1601,7 @@ curl -X POST \\
 Create a cron automation that watches a GitHub repository for pull requests
 with a review trigger label, starts an OpenHands review conversation once per
 label event, and posts the AI review as a GitHub comment.
+Windows PowerShell equivalents for the setup, packaging, upload, and API-check shell snippets are in \`references/windows.md\`.
 
 The automation script is deterministic: PR discovery, label-event tracking,
 state persistence, stale-result suppression, and GitHub comment posting are
@@ -1814,6 +1840,7 @@ Each cron run executes \`main.py\`, which:
 
 Create a cron automation that polls a single GitHub repository on a
 configurable schedule (default: every minute).
+Windows PowerShell equivalents for the setup, packaging, upload, and API-check shell snippets are in \`references/windows.md\`.
 
 When a comment on an issue or PR contains the **trigger phrase**
 (default: \`@OpenHands\`) it:
@@ -2111,30 +2138,7 @@ Each cron run executes \`main.py\`, which:
 | Comments posted but no conversation created | Agent server URL wrong | Check \`OPENHANDS_URL\` secret and \`AGENT_SERVER_URL\` env var |
 | Same comment processed twice | \`processed_comment_ids\` cleared | State file was deleted; harmless but duplicate comment may appear |
 | Summary never posted | Conversation stuck in \`running\` | Open the conversation in the OpenHands UI; agent may need input |
-| No events detected after first run | \`last_poll\` in the future | Delete the state file to reset; it will be recreated on next run |`},{name:`gitlab`,description:`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.`,triggers:[`gitlab`,`git`],content:`You have access to an environment variable, \`GITLAB_TOKEN\`, which allows you to interact with
-the GitLab API.
-
-<IMPORTANT>
-You can use \`curl\` with the \`GITLAB_TOKEN\` to interact with GitLab's API.
-ALWAYS use the GitLab API for operations instead of a web browser.
-ALWAYS use the \`create_mr\` tool to open a merge request
-</IMPORTANT>
-
-If you encounter authentication issues when pushing to GitLab (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://oauth2:\${GITLAB_TOKEN}@gitlab.com/username/repo.git\`
-
-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_mr\` tool to create a merge request, if you haven't already
-* Once you've created your own branch or a merge 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 merge request, send the user a short message with a link to the merge request.
-* 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
-\`\`\``},{name:`incident-retrospective`,description:`Create an automation that drafts incident retrospectives. Gathers incident-channel messages from Slack, collects linked tickets and follow-ups from Linear, and publishes a retrospective draft to Notion with a timeline, impact summary, root-cause hypotheses, and action items.`,triggers:[`/incident-retro:setup`],content:`# Incident Retrospective Drafter Automation
+| No events detected after first run | \`last_poll\` in the future | Delete the state file to reset; it will be recreated on next run |`},{name:`gitlab`,description:`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.`,triggers:[`gitlab`,`git`],content:"You have access to an environment variable, `GITLAB_TOKEN`, which allows you to interact with\nthe GitLab API.\n\n<IMPORTANT>\nYou can use `curl` with the `GITLAB_TOKEN` to interact with GitLab's API.\nALWAYS use the GitLab API for operations instead of a web browser.\nALWAYS use the `create_mr` tool to open a merge request\n</IMPORTANT>\n\nIf you encounter authentication issues when pushing to GitLab (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://oauth2:${GITLAB_TOKEN}@gitlab.com/username/repo.git`\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* Use the `create_mr` tool to create a merge request, if you haven't already\n* Once you've created your own branch or a merge 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 merge request, send the user a short message with a link to the merge request.\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, use `$env:GITLAB_TOKEN` in remote URLs and run the `git` commands as separate commands if `&&` is not supported by the installed shell."},{name:`incident-retrospective`,description:`Create an automation that drafts incident retrospectives. Gathers incident-channel messages from Slack, collects linked tickets and follow-ups from Linear, and publishes a retrospective draft to Notion with a timeline, impact summary, root-cause hypotheses, and action items.`,triggers:[`/incident-retro:setup`],content:`# Incident Retrospective Drafter Automation
 
 Set up an automation that drafts incident retrospectives by pulling data from
 Slack, Linear, and Notion.
@@ -2210,6 +2214,8 @@ curl -s -X POST "\${OPENHANDS_HOST}/api/automation/v1/preset/prompt" \\
   }'
 \`\`\`
 
+PowerShell note: use \`curl.exe\` for this exact flag syntax, and replace \`\${OPENHANDS_HOST}\` / \`$OPENHANDS_AUTOMATION_API_KEY\` with \`$env:OPENHANDS_HOST\` / \`$env:OPENHANDS_AUTOMATION_API_KEY\` if running it natively.
+
 ### Step 5 — Confirm
 
 Tell the user:
@@ -2230,6 +2236,7 @@ No scripts — you are the orchestration loop. Uses only standard \`gh\` CLI
 commands that work on any GitHub repo.
 
 Requires: \`gh\` CLI authenticated with repo access, a PR branch.
+Windows PowerShell equivalents for Bash-only assignment, redirection, and quoting patterns in this skill are in \`references/windows.md\`.
 
 ## Discover what the repo has
 
@@ -2605,7 +2612,209 @@ Final summary should include:
 ## References
 
 - Verification stack (layers, signals, retriggering): \`references/verification.md\`
-- CI/review heuristics and decision tree: \`references/heuristics.md\``},{name:`jupyter`,description:`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 formats.`,triggers:[`ipynb`,`jupyter`],content:`# Jupyter Notebook Guide
+- CI/review heuristics and decision tree: \`references/heuristics.md\``},{name:`jira-issue-to-pr`,description:`This skill should be used when the user asks to "set up a Jira automation to create pull requests", "poll Jira for create-pr issues", "automatically create GitHub PRs from Jira tickets", "deploy a Jira issue-to-PR automation", "create a Jira to GitHub PR workflow", or mentions automating GitHub PR creation from a Jira label. Deploys a cron-based OpenHands automation that watches a Jira Cloud project for issues labeled with a configurable label (default: "create-pr") and spawns an agent conversation to create a GitHub pull request for each new issue found. The target GitHub repository is read from the body of the Jira ticket - no repo parameter is required at deploy time.`,triggers:[],content:`# Jira → GitHub PR Automation
+
+Deploys a cron automation that polls a Jira Cloud instance for open issues carrying a
+configurable label and, for each new issue, starts an OpenHands agent conversation that
+clones the GitHub repository specified in the ticket body, creates a branch, implements
+or placeholders the requested change, and opens a pull request. Once the conversation
+starts, it also posts a comment on the Jira ticket: "I'm on it: &lt;conversation URL&gt;".
+
+## How It Works
+
+1. **Poll** - every N minutes, \`POST /rest/api/3/search/jql\` on the Jira Cloud instance
+   to find open issues with the configured label.
+2. **Deduplicate** - on the very first run the script records a \`first_run_at\` baseline
+   timestamp in the KV store; any issue whose \`updated\` timestamp predates that baseline
+   is skipped (no backfill blast on first deploy). Using \`updated\` rather than \`created\`
+   means an old issue that has its label added after the automation is deployed will still
+   be picked up. Subsequent runs filter by both \`first_run_at\` and a KV-backed set of
+   already-processed issue keys. A \`max_new_per_run\` cap (default 5) limits conversations
+   started per cron firing as additional defense-in-depth.
+3. **Dispatch** - for each new issue, call \`POST /api/conversations\` on the agent server
+   to start an independent agent conversation with a PR-creation prompt. The prompt
+   instructs the agent to extract the target GitHub repository (\`owner/repo\`) from the
+   ticket body.
+4. **Comment** - immediately after the conversation is created, post a Jira comment on the
+   issue: \`I'm on it: <conversation URL>\`.
+5. **Persist** - record the processed issue key so re-runs never duplicate work.
+
+The polling run is lightweight (stdlib only, no SDK install); LLM costs are incurred only
+when new issues are actually found.
+
+## Prerequisites
+
+Before deploying, ensure the following are in place:
+
+| Requirement | Details |
+|---|---|
+| **Jira API token** | Stored as an OpenHands secret (see [Jira API token setup](#jira-api-token)) |
+| **GitHub token** | Must be stored as an OpenHands secret with \`repo\` + \`workflow\` scope so the spawned conversation can push branches and open PRs |
+| **Jira label** | The label to watch for (default: \`create-pr\`) must exist in the Jira project |
+| **GitHub repo** | The target repository must exist and the GitHub token must have write access |
+
+## Deploying the Automation
+
+### Step 1 - Collect parameters
+
+Gather the following from the user before proceeding:
+
+| Parameter | Example | Notes |
+|---|---|---|
+| \`jira_base_url\` | \`https://acme.atlassian.net\` | No trailing slash |
+| \`jira_email\` | \`alice@acme.com\` | Atlassian account email for Basic auth |
+| \`jira_token_secret\` | \`JIRA_CLOUD_KEY\` | Name of the OpenHands secret holding the API token |
+| \`jira_label\` | \`create-pr\` | Label to watch for (optional, defaults to \`create-pr\`) |
+| \`max_new_per_run\` | \`5\` | Max conversations dispatched per cron firing (optional, defaults to \`5\`) |
+| \`cron_schedule\` | \`*/5 * * * *\` | Polling frequency in cron syntax |
+
+> **Note**: The GitHub repository is not configured here. Each Jira ticket body must include
+> a reference to the target GitHub repo in \`owner/repo\` format (e.g. \`acme-org/backend\`).
+> The spawned agent extracts it from the ticket text.
+
+### Step 2 - Create config.json
+
+Create \`config.json\` next to \`scripts/main.py\` when packaging:
+
+\`\`\`json
+{
+  "jira_base_url":     "https://acme.atlassian.net",
+  "jira_email":        "alice@acme.com",
+  "jira_token_secret": "JIRA_CLOUD_KEY",
+  "jira_label":        "create-pr",
+  "max_new_per_run":   5
+}
+\`\`\`
+
+### Step 3 - Package the tarball
+
+Copy \`scripts/main.py\` from this skill and package it with the \`config.json\`:
+
+\`\`\`bash
+WORK=$(mktemp -d)
+cp <skill-dir>/scripts/main.py "$WORK/main.py"
+# write config.json into $WORK/config.json (see Step 2)
+tar -czf /tmp/jira-issue-to-pr.tar.gz -C "$WORK" .
+python3 -m py_compile "$WORK/main.py"   # validate syntax before uploading
+\`\`\`
+
+### Step 4 - Upload the tarball
+
+\`\`\`bash
+TARBALL_PATH=$(curl -s -X POST \\
+  "http://localhost:8000/api/automation/v1/uploads?name=jira-issue-to-pr" \\
+  -H "X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY" \\
+  -H "Content-Type: application/gzip" \\
+  --data-binary @/tmp/jira-issue-to-pr.tar.gz \\
+  | python3 -c "import sys,json; print(json.load(sys.stdin)['tarball_path'])")
+\`\`\`
+
+### Step 5 - Create the automation
+
+\`\`\`bash
+curl -s -X POST "http://localhost:8000/api/automation/v1" \\
+  -H "X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d "{
+    \\"name\\": \\"Jira issue-to-PR Poller\\",
+    \\"trigger\\": {
+      \\"type\\":     \\"cron\\",
+      \\"schedule\\": \\"*/5 * * * *\\",
+      \\"timezone\\": \\"UTC\\"
+    },
+    \\"tarball_path\\": \\"$TARBALL_PATH\\",
+    \\"entrypoint\\":   \\"python3 main.py\\",
+    \\"timeout\\":      540
+  }" | python3 -m json.tool
+\`\`\`
+
+Save the returned \`id\` - use it for updates and monitoring.
+
+### Step 6 - Verify with a test dispatch
+
+\`\`\`bash
+curl -s -X POST \\
+  "http://localhost:8000/api/automation/v1/<AUTOMATION_ID>/dispatch" \\
+  -H "X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY" | python3 -m json.tool
+
+# After ~30 seconds, check the run status:
+curl -s "http://localhost:8000/api/automation/v1/<AUTOMATION_ID>/runs?limit=1" \\
+  -H "X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY" \\
+  | python3 -c "import sys,json; r=json.load(sys.stdin)['runs'][0]; print(r['status'], r.get('error_detail'))"
+\`\`\`
+
+## Updating an Existing Deployment
+
+To change configuration or update the script:
+
+1. Edit \`config.json\` with new values.
+2. Repackage and upload a new tarball (Steps 3-4 above).
+3. PATCH the existing automation with the new \`tarball_path\`:
+
+\`\`\`bash
+curl -s -X PATCH \\
+  "http://localhost:8000/api/automation/v1/<AUTOMATION_ID>" \\
+  -H "X-Session-API-Key: $OPENHANDS_AUTOMATION_API_KEY" \\
+  -H "Content-Type: application/json" \\
+  -d "{\\"tarball_path\\": \\"<NEW_TARBALL_PATH>\\"}"
+\`\`\`
+
+## Resetting Processed State
+
+To reprocess issues that were already handled (e.g., after testing), clear the KV store:
+
+\`\`\`bash
+curl -s -X DELETE \\
+  "http://localhost:8000/api/automation/v1/<KV_BASE>/v1/kv/state" \\
+  -H "Authorization: Bearer $AUTOMATION_KV_TOKEN"
+\`\`\`
+
+Or delete and recreate the automation to start with a clean state.
+
+## Script Reference
+
+The automation script lives at \`scripts/main.py\`. Key behaviors:
+
+- **No SDK dependencies** - pure Python stdlib; no \`setup.sh\` or \`uv\` install needed.
+- **Config file** - reads all parameters from \`config.json\` co-located with the script.
+- **First-run baseline** - on the very first execution the script writes \`first_run_at\` (UTC timestamp) into the KV store and exits without dispatching; issues whose \`updated\` timestamp predates that baseline are skipped on all subsequent runs. Using \`updated\` (not \`created\`) means an old issue that has its label applied after deployment is correctly treated as new.
+- **Per-run cap** - \`max_new_per_run\` (default 5) limits how many conversations are started per cron firing; any remaining new issues are dispatched on the next run.
+- **KV store** - persists \`{"processed_keys": [...], "first_run_at": "..."}\` between runs; falls back to a local file in dev environments where \`AUTOMATION_KV_TOKEN\` is absent.
+- **Jira API** - uses \`POST /rest/api/3/search/jql\` (the current non-deprecated endpoint).
+- **Conversation dispatch** - calls \`POST /api/conversations\` on the agent server with the current user's LLM/agent settings forwarded to the new conversation.
+- **Error transparency** - captures Jira HTTP response bodies in error messages for fast diagnosis.
+
+## Known Limitations
+
+### Pre-existing issues updated after deployment
+
+The deduplication filter compares each issue's \`fields.updated\` timestamp against
+\`first_run_at\`. \`updated\` is Jira's last-modified timestamp for the issue as a whole —
+it advances whenever **any** field changes (comments, priority, description, status, etc.),
+not only when the \`create-pr\` label is applied.
+
+This means a pre-existing issue that already carried the label at deployment time can
+slip through the filter if it is later updated for an unrelated reason (e.g. someone adds
+a comment), because its \`updated\` timestamp will have advanced past \`first_run_at\` while
+its key is not yet in \`processed_keys\`.
+
+**Workaround:** The only fully reliable way to detect exactly when a label was applied
+is the Jira changelog API (\`GET /rest/api/3/issue/{key}/changelog\`), which requires an
+extra HTTP call per issue. To avoid that overhead, keep the automation's scope narrow:
+use a label that is exclusively added as a PR-creation signal and is not already present
+on issues at the time of deployment.
+
+Once an issue is successfully dispatched its key is written to \`processed_keys\` in the
+KV store and is **permanently skipped on every future run** — regardless of subsequent
+label changes, comments, or any other updates to the issue. The only way to re-trigger a
+previously processed issue is to manually clear the KV store or delete and recreate the
+automation. This means the risk window described above is finite: as soon as the
+automation processes a pre-existing issue (even accidentally), it will never dispatch
+that issue again.
+
+## Additional Resources
+
+- **\`references/setup.md\`** - Jira API token creation, GitHub token scopes, cron schedule reference, and troubleshooting guide.`},{name:`jupyter`,description:`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 formats.`,triggers:[`ipynb`,`jupyter`],content:`# Jupyter Notebook Guide
 
 Notebooks are JSON files. Cells are in \`nb['cells']\`, each has \`source\` (list of strings) and \`cell_type\` ('code', 'markdown', or 'raw').
 
@@ -2632,6 +2841,12 @@ jupyter nbconvert --to markdown notebook.ipynb  # Convert to Markdown
 grep -n "search_term" notebook.ipynb
 \`\`\`
 
+PowerShell equivalent:
+
+\`\`\`powershell
+Select-String -Path notebook.ipynb -Pattern "search_term"
+\`\`\`
+
 ## Cell Structure
 \`\`\`python
 # Code cell
@@ -2653,6 +2868,7 @@ for cell in nb['cells']:
 KIND (Kubernetes IN Docker) is a tool for running local Kubernetes clusters using Docker containers as nodes. It's designed for testing Kubernetes applications locally.
 
 IMPORTANT: Before you proceed with installation, make sure you have docker installed locally.
+Windows PowerShell equivalents for installing KIND and kubectl are in \`references/windows.md\`.
 
 ### Installation
 
@@ -2862,6 +3078,8 @@ Handle these common edge cases gracefully:
 For posting structured code reviews, see the \`github-pr-review\` skill.
 For creating new skills, see the \`skill-creator\` skill.`},{name:`linear`,description:`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 tracking.`,triggers:[`linear`,`ticket`,`issue tracking`],content:`# Linear
 
+Windows PowerShell equivalents for the repeated Linear GraphQL \`curl\` and environment-variable snippets are in \`references/windows.md\`.
+
 <IMPORTANT>
 Before performing any Linear operations, check if the required environment variable is set:
 
@@ -3134,6 +3352,8 @@ curl -s -X POST "\${OPENHANDS_HOST}/api/automation/v1/preset/prompt" \\
   }'
 \`\`\`
 
+PowerShell note: use \`curl.exe\` for this exact flag syntax, and replace \`\${OPENHANDS_HOST}\` / \`$OPENHANDS_AUTOMATION_API_KEY\` with \`$env:OPENHANDS_HOST\` / \`$env:OPENHANDS_AUTOMATION_API_KEY\` if running it natively.
+
 ### Step 5 — Confirm
 
 Tell the user:
@@ -3144,6 +3364,8 @@ Tell the user:
 > - Mode: \`{auto-apply or suggest}\`
 > - Trigger: \`{trigger description}\``},{name:`notion`,description:`Create, search, and update Notion pages/databases using the Notion API. Use for documenting work, generating runbooks, and automating knowledge base updates.`,triggers:[`notion`],content:`# Notion
 
+Windows PowerShell equivalents for the repeated Notion REST \`curl\`, environment-variable, and JSON-body snippets are in \`references/windows.md\`.
+
 <IMPORTANT>
 If authenticated Notion MCP tools are available in the environment, use them first. MCP tools do not require passing \`NOTION_INTEGRATION_KEY\` as a tool argument; authentication is handled by the configured MCP integration.
 
@@ -3245,6 +3467,7 @@ curl -s -X PATCH "https://api.notion.com/v1/blocks/\${PAGE_ID}/children" \\
 - Create a page: https://developers.notion.com/reference/post-page
 - Append block children: https://developers.notion.com/reference/patch-block-children`},{name:`npm`,description:`Handle npm package installation in non-interactive environments by piping confirmations. Use when installing Node.js packages that require user confirmation prompts.`,triggers:[`npm`],content:`When using npm to install packages, you will not be able to use an interactive shell, and it may be hard to confirm your actions.
 As an alternative, you can pipe in the output of the unix "yes" command to confirm your actions.`},{name:`openhands-api`,description:`Reference skill for the OpenHands Cloud REST API (V1) and agent-server APIs, including how to start additional cloud or local backend conversations for fresh-context or delegated work.`,triggers:[`openhands-api`,`openhands-api-v1`,`openhands-cloud`,`openhands-cloud-api-v1`,`oh-api-v1`,`oh-cloud-api-v1`],content:`This skill documents the **OpenHands Cloud API** (V1), commonly used **agent-server APIs**, and small, easy-to-copy clients.
+Windows PowerShell equivalents for the shell examples in this skill are in \`references/windows.md\`.
 
 It is intentionally focused on common OpenHands API workflows:
 
@@ -3702,6 +3925,7 @@ This skill is aligned against the current OpenHands API docs and implementation:
 - \`OpenHands/OpenHands/openhands/app_server/app_conversation/app_conversation_models.py\``},{name:`openhands-automation`,description:`This skill should be used when the user asks to "create an automation", "schedule a task", "set up a cron job", "webhook integration", "event-triggered automation", or mentions automations, scheduled tasks, cron scheduling, or webhook events in OpenHands Cloud.`,triggers:[`automation`,`automations`,`scheduled task`,`cron job`,`cron schedule`,`webhook`,`webhooks`,`event trigger`,`github event`,`pull request automation`,`issue automation`,`/automation:create`],content:`# OpenHands Automations
 
 Create and manage automations that run inside an OpenHands agent server — triggered by cron schedules or webhook events (GitHub, custom services).
+Windows PowerShell equivalents for the automation API \`curl\` examples and shell-variable conventions are in \`references/windows.md\`.
 
 ## Automation Creation Process
 The agent must follow these steps when creating an automation:
@@ -4786,6 +5010,8 @@ Source: [\`examples/\`](https://github.com/OpenHands/software-agent-sdk/tree/mai
 apt-get install texlive-latex-base
 \`\`\`
 
+On Windows, install MiKTeX or TeX Live with the native installer or a package manager such as \`winget\`. The \`apt-get\` commands only work in Linux or WSL.
+
 * Also install the recommended and extra fonts to avoid running into errors, when trying to use pdflatex on latex files with more fonts.
 
 \`\`\`
@@ -5403,6 +5629,8 @@ curl -s -X POST "\${OPENHANDS_HOST}/api/automation/v1/preset/prompt" \\
   }'
 \`\`\`
 
+PowerShell note: use \`curl.exe\` for this exact flag syntax, and replace \`\${OPENHANDS_HOST}\` / \`$OPENHANDS_AUTOMATION_API_KEY\` with \`$env:OPENHANDS_HOST\` / \`$env:OPENHANDS_AUTOMATION_API_KEY\` if running it natively.
+
 ### Step 5 — Confirm
 
 Tell the user:
@@ -5436,6 +5664,7 @@ You should always complete the task requested. If there are security concerns pl
 - Use secure error reporting mechanisms`},{name:`skill-creator`,description:`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 disclosure, or skill development best practices.`,triggers:[],content:`# Skill Creator
 
 This skill provides guidance for creating effective skills.
+Windows PowerShell equivalents for the Unix shell commands used in examples are in \`references/windows.md\`.
 
 ## About Skills
 
@@ -5975,6 +6204,7 @@ To create a skill:
 Focus on strong trigger descriptions, progressive disclosure, and imperative writing style for effective skills that load when needed and provide targeted guidance.`},{name:`slack-channel-monitor`,description:`This skill should be used when the user asks to "monitor a Slack channel", "watch Slack for messages", "create a Slack bot that responds to mentions", "set up an OpenHands Slack integration", "trigger OpenHands from Slack", "respond to @openhands in Slack", or "poll Slack channels for a trigger phrase". Guides the user through creating a cron automation that watches up to 10 Slack channels and starts an OpenHands conversation whenever a configurable trigger phrase is detected.`,triggers:[`/slack-monitor:poll`],content:`# Slack Channel Monitor
 
 Create a cron automation that polls up to 10 Slack channels every minute.
+Windows PowerShell equivalents for the setup, packaging, upload, and API-check shell snippets are in \`references/windows.md\`.
 When a message containing the **trigger phrase** (default: \`@openhands\`) is
 detected it:
 
@@ -6332,6 +6562,8 @@ curl -s -X POST "\${OPENHANDS_HOST}/api/automation/v1/preset/prompt" \\
   }'
 \`\`\`
 
+PowerShell note: use \`curl.exe\` for this exact flag syntax, and replace \`\${OPENHANDS_HOST}\` / \`$OPENHANDS_AUTOMATION_API_KEY\` with \`$env:OPENHANDS_HOST\` / \`$env:OPENHANDS_AUTOMATION_API_KEY\` if running it natively.
+
 ### Step 5 — Confirm
 
 Tell the user:
@@ -6372,6 +6604,7 @@ https://spark.apache.org/docs/latest/migration-guide.html
 - [ ] Identify target Spark version
 - [ ] Search for deprecated APIs: \`grep -rn 'import org.apache.spark' --include='*.scala' --include='*.java' --include='*.py'\`
 - [ ] List all Spark config properties: \`grep -rn 'spark\\.' --include='*.conf' --include='*.properties' --include='*.scala' --include='*.java' --include='*.py' | grep -v 'test'\`
+- [ ] On Windows PowerShell, use \`Get-ChildItem -Recurse -Include *.scala,*.java,*.py | Select-String 'import org.apache.spark'\` and adjust the extensions/pattern for config searches.
 - [ ] Check for custom \`SparkSession\` or \`SparkContext\` extensions
 - [ ] Identify connector dependencies (Hive, Kafka, Cassandra, Delta, Iceberg)
 - [ ] Document findings in \`spark_upgrade_impact.md\`
@@ -6561,6 +6794,7 @@ Spark SQL behavior changes between versions can silently alter query results.
 ✓ Upgrade impact documented in \`spark_upgrade_impact.md\``,license:`MIT`,compatibility:`Requires Java 8+/11+/17+, Scala 2.12/2.13, Maven/Gradle/SBT, Apache Spark`},{name:`ssh`,description:`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 files via SCP.`,triggers:[`ssh`,`remote server`,`remote machine`,`remote host`,`remote connection`,`secure shell`,`ssh keys`],content:`# SSH Skill
 
 This skill provides capabilities for establishing and managing SSH connections to remote machines.
+Windows PowerShell equivalents for SSH config creation, key paths, ssh-agent, and permissions are in \`references/windows.md\`.
 
 ## Capabilities
 
@@ -6684,6 +6918,7 @@ chmod 700 ~/.ssh
 This document provides instructions for installing Swift on Debian 12 (Bookworm).
 
 > This setup is intended for non-UI development tasks on Swift on Linux.
+> On Windows, run these Debian commands inside WSL2 or a Linux container. For native Windows Swift, use the Windows toolchain from Swift.org instead.
 
 ## Prerequisites
 
@@ -6921,6 +7156,11 @@ To allow agents and automated systems to access protected deployments, users nee
    \`\`\`bash
    curl -H "x-vercel-protection-bypass: <secret>" https://your-preview-url.vercel.app
    \`\`\`
+
+   PowerShell equivalent:
+   \`\`\`powershell
+   Invoke-WebRequest -Headers @{ "x-vercel-protection-bypass" = "<secret>" } -Uri https://your-preview-url.vercel.app
+   \`\`\`
    
    **As a Query Parameter:**
    \`\`\`