@openhands/extensions 0.28.0 → 0.30.0

package/skills/jira-issue-to-pr/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "jira-issue-to-pr",
   "version": "1.0.0",
-  "description": "Deploy 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 repo is read from the ticket body - no repo parameter required at deploy time.",
+  "description": "Deploy a cron-based OpenHands automation that opens a GitHub pull request, a GitLab merge request or a Bitbucket pull request for each Jira issue carrying a configurable label (default: create-pr). The target repository is read from the ticket body - no repo parameter required at deploy time.",
   "author": {
     "name": "OpenHands",
     "email": "contact@all-hands.dev"
@@ -13,7 +13,10 @@
     "jira",
     "atlassian",
     "github",
+    "gitlab",
+    "bitbucket",
     "pull-request",
+    "merge-request",
     "automation"
   ]
 }

package/skills/jira-issue-to-pr/.codex-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "jira-issue-to-pr",
   "version": "1.0.0",
-  "description": "Deploy 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 repo is read from the ticket body - no repo parameter required at deploy time.",
+  "description": "Deploy a cron-based OpenHands automation that opens a GitHub pull request, a GitLab merge request or a Bitbucket pull request for each Jira issue carrying a configurable label (default: create-pr). The target repository is read from the ticket body - no repo parameter required at deploy time.",
   "author": {
     "name": "OpenHands",
     "email": "contact@all-hands.dev"
@@ -13,7 +13,10 @@
     "jira",
     "atlassian",
     "github",
+    "gitlab",
+    "bitbucket",
     "pull-request",
+    "merge-request",
     "automation"
   ]
 }

package/skills/jira-issue-to-pr/.plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "jira-issue-to-pr",
   "version": "1.0.0",
-  "description": "Deploy 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 repo is read from the ticket body - no repo parameter required at deploy time.",
+  "description": "Deploy a cron-based OpenHands automation that opens a GitHub pull request, a GitLab merge request or a Bitbucket pull request for each Jira issue carrying a configurable label (default: create-pr). The target repository is read from the ticket body - no repo parameter required at deploy time.",
   "author": {
     "name": "OpenHands",
     "email": "contact@all-hands.dev"
@@ -13,7 +13,10 @@
     "jira",
     "atlassian",
     "github",
+    "gitlab",
+    "bitbucket",
     "pull-request",
+    "merge-request",
     "automation"
   ]
 }

package/skills/jira-issue-to-pr/README.md

@@ -1,10 +1,12 @@
-# Jira Issue to GitHub PR
+# Jira Issue to Pull Request (GitHub, GitLab, Bitbucket)
 
 Deploy a cron-based OpenHands automation that polls a Jira Cloud project for
 open issues carrying a configurable label (default: `create-pr`) and, for each
-new issue, starts an OpenHands agent conversation that clones the GitHub
-repository named in the ticket body, creates a branch, implements the requested
-change, and opens a pull request. Once the conversation starts, it posts a
+new issue, starts an OpenHands agent conversation that clones the repository
+named in the ticket body on the configured git provider (GitHub by default,
+GitLab or Bitbucket with `git_provider`), creates a branch, implements the
+requested change, and opens a pull request (a merge request on GitLab). Once the
+conversation starts, it posts a
 comment on the Jira ticket: "I'm on it: `<conversation URL>`".
 
 ## Triggers
@@ -16,12 +18,16 @@ This skill is activated by keywords:
 - `automatically create GitHub PRs from Jira tickets`
 - `deploy a Jira issue-to-PR automation`
 - `create a Jira to GitHub PR workflow`
+- `set up the Jira issue to GitLab MR automation`
+- `set up the Jira issue to Bitbucket PR automation`
 - `automate GitHub PR creation from a Jira label`
 
 ## How It Works
 
-1. **Poll** - every N minutes, the script calls `POST /rest/api/3/search/jql`
-   on the Jira Cloud instance to find open issues with the configured label.
+1. **Poll** - every N minutes, the script searches the Jira Cloud instance for
+   open issues with the configured label: through the user's connected
+   Atlassian Rovo MCP server on OpenHands Cloud and Enterprise, or with
+   `POST /rest/api/3/search/jql` and an API token.
 2. **Deduplicate** - on the first run the script records a `first_run_at`
    baseline timestamp in the KV store; issues whose `updated` timestamp
    predates that baseline are skipped (no backfill blast on first deploy).
@@ -32,7 +38,8 @@ This skill is activated by keywords:
    conversation with a PR-creation prompt: `POST /api/conversations` on the
    agent server when running locally, `POST /api/v1/app-conversations` on
    OpenHands Cloud and Enterprise. The prompt instructs the agent to extract the
-   target GitHub repository (`owner/repo`) from the ticket body. On Cloud the
+   target repository (`owner/repo` on GitHub; `group/project` or a URL on
+   GitLab; `workspace/repo` on Bitbucket) from the ticket body. On Cloud the
    next poll confirms the conversation came up and starts it again when it did
    not.
 4. **Comment** - immediately after the conversation is created, the script
@@ -52,13 +59,13 @@ OpenHands and Jira. See "Event-Based Alternative" in `SKILL.md`.
 
 | Requirement | Details |
 |---|---|
-| **Jira API token** | Stored as an OpenHands secret (see `references/setup.md`) |
-| **GitHub token** | Stored as an OpenHands secret with `repo` + `workflow` scope so the spawned conversation can push branches and open PRs |
+| **Jira access** | OpenHands Cloud and Enterprise: the user's connected Atlassian Rovo MCP server, with no API token. Local, or without that connection: a Jira API token stored as an OpenHands secret (see `references/setup.md`) |
+| **Git provider access** | OpenHands Cloud and Enterprise: the connected GitHub, GitLab or Bitbucket integration named by `git_provider`, or a connected MCP server (GitHub's, GitLab's, or Atlassian Rovo for Bitbucket). Local: that provider's token stored as an OpenHands secret so the spawned conversation can push branches and open the request |
 | **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 |
+| **Target repository** | Must exist on the configured provider; the connected integration or token must have write access |
 
 ## Quick Start
 
 See `SKILL.md` for the full step-by-step deployment guide, and
-`references/setup.md` for Jira API token creation, GitHub token scopes, cron
+`references/setup.md` for Jira API token creation, git provider tokens, cron
 schedule reference, and troubleshooting.

package/skills/jira-issue-to-pr/SKILL.md

@@ -4,25 +4,31 @@ 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.
+  "set up the Jira issue to GitLab MR automation", "set up the Jira issue to Bitbucket PR automation",
+  "open GitLab merge requests from Jira tickets", "open Bitbucket pull requests from Jira tickets",
+  or mentions automating pull request or merge request 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.
+  that opens a pull request on GitHub (the default), a merge request on GitLab, or a pull
+  request on Bitbucket for each new issue found, chosen with git_provider. The target
+  repository is read from the body of the Jira ticket - no repo parameter is required at deploy time.
 ---
 
-# Jira → GitHub PR Automation
+# Jira → Pull Request Automation (GitHub, GitLab, Bitbucket)
 
 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
+clones the repository specified in the ticket body on the configured git provider (GitHub
+by default, GitLab or Bitbucket with `git_provider`), creates a branch, implements or
+placeholders the requested change, and opens a pull request (a merge request on GitLab).
+Once the conversation
 starts, it also posts a comment on the Jira ticket: "I'm on it: <conversation URL>".
 
 ## 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.
+1. **Poll** - every N minutes, search the Jira Cloud instance for open issues with the
+   configured label: through the user's connected Atlassian Rovo MCP server on OpenHands
+   Cloud and Enterprise, or with `POST /rest/api/3/search/jql` and an API token.
 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`
@@ -33,7 +39,8 @@ starts, it also posts a comment on the Jira ticket: "I'm on it: <conversation
 3. **Dispatch** - for each new issue, start an independent agent conversation with a
    PR-creation prompt: `POST /api/conversations` on the agent server when running locally,
    or `POST /api/v1/app-conversations` on OpenHands Cloud. The prompt instructs the agent
-   to extract the target GitHub repository (`owner/repo`) from the ticket body.
+   to extract the target repository (`owner/repo` on GitHub; `group/project` or a URL on GitLab;
+   `workspace/repo` on Bitbucket) 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.
@@ -47,11 +54,11 @@ 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 access** | Local: a GitHub token stored as an OpenHands secret with `repo` + `workflow` scope so the spawned conversation can push branches and open PRs. OpenHands Cloud: the spawned conversation uses the user's connected GitHub integration (native integration recommended, or the GitHub MCP server) |
+| **Jira access** | OpenHands Cloud and Enterprise: the user's connected Atlassian Rovo MCP server, with no API token. Local, or without that connection: a Jira API token stored as an OpenHands secret (see [Jira API token setup](#jira-api-token)) |
+| **Git provider access** | OpenHands Cloud and Enterprise: the user's connected GitHub, GitLab or Bitbucket integration, whichever `git_provider` names. A connected MCP server also works - GitHub's (with the saved access token), GitLab's, or Atlassian Rovo for Bitbucket - with a private repository read through the tools rather than cloned. Local: a token for that provider stored as an OpenHands secret (`GITHUB_TOKEN` with `repo` + `workflow`, `GITLAB_TOKEN` with `api`, `BITBUCKET_TOKEN`) so the spawned conversation can push branches and open the request |
 | **KV store** (OpenHands Cloud only) | The automation service must have its KV store enabled (`kvStore` in `GET /api/automation/v1/capabilities`); each cloud run starts in a fresh sandbox, so processed issues are remembered there |
 | **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 |
+| **Target repository** | Must exist on the configured provider; the connected integration or token must have write access |
 
 ## Deploying the Automation
 
@@ -72,24 +79,53 @@ Set `OPENHANDS_HOST` and `AUTH_HEADER` for the curl commands below:
 
 ### Step 1 - Collect parameters
 
-Gather the following from the user before proceeding:
+First decide how the poller reaches Jira:
+
+- **Connected Atlassian Rovo MCP server** - on OpenHands Cloud and Enterprise, when the
+  user has connected it. OpenHands calls Jira for the poller through that connection, so
+  do not ask for a Jira email or an API token and do not create a secret.
+- **Jira API token** - on a local Agent Canvas, or when the Rovo server is not connected.
+
+Then pick `git_provider` from the automation the user asked for: `github` for *Jira issue to
+GitHub PR* (the default, so it can be left out), `gitlab` for *Jira issue to GitLab MR*,
+`bitbucket` for *Jira issue to Bitbucket PR*. It changes only what the conversation is told;
+the conversation pushes with the user's connected integration for that provider, or delivers
+through the connected MCP server's tools when it has no token.
+
+Then gather the parameters for that route, plus the shared ones, 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_mcp_server` | `atlassian-rovo` | Rovo connection only. The name the server is stored under: the key in `agent_settings.mcp_config` of `GET ${OPENHANDS_HOST}/api/v1/settings` whose `url` is on `mcp.atlassian.com`. Look it up; do not ask the user |
+| `jira_cloud_id` | `1324a887-45db-1bf4-1e99-ef0ff456d421` | Rovo connection only. The `id` of the Jira site, from the Rovo tool `getAccessibleAtlassianResources`. Ask which site only when it lists several |
+| `jira_base_url` | `https://acme.atlassian.net` | API token only. No trailing slash |
+| `jira_email` | `alice@acme.com` | API token only. Atlassian account email for Basic auth |
+| `jira_token_secret` | `JIRA_CLOUD_KEY` | API token only. Name of the OpenHands secret holding the API token |
 | `jira_label` | `create-pr` | Label to watch for (optional, defaults to `create-pr`) |
+| `git_provider` | `gitlab` | `github` (default), `gitlab` or `bitbucket` - the provider the ticket names its repository on (optional) |
 | `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.
+> **Note**: The repository is not configured here. Each Jira ticket body must name it:
+> `owner/repo` on GitHub, `group/subgroup/project` or a full URL on GitLab (self-managed
+> hosts included), `workspace/repo` on bitbucket.org. The spawned agent extracts it from
+> the ticket text.
 
 ### Step 2 - Create config.json
 
-Create `config.json` next to `scripts/main.py` when packaging:
+Create `config.json` next to `scripts/main.py` when packaging. With the connected
+Atlassian Rovo MCP server:
+
+```json
+{
+  "jira_mcp_server": "atlassian-rovo",
+  "jira_cloud_id":   "1324a887-45db-1bf4-1e99-ef0ff456d421",
+  "jira_label":      "create-pr",
+  "max_new_per_run": 5
+}
+```
+
+With a Jira API token:
 
 ```json
 {
@@ -101,6 +137,9 @@ Create `config.json` next to `scripts/main.py` when packaging:
 }
 ```
 
+For the GitLab and Bitbucket templates add `"git_provider": "gitlab"` or
+`"git_provider": "bitbucket"` to either example; it is `github` when omitted.
+
 ### Step 3 - Package the tarball
 
 Copy `scripts/main.py` from this skill and package it with the `config.json`:
@@ -143,7 +182,8 @@ curl -s -X POST "${OPENHANDS_HOST}/api/automation/v1" \
   }" | python3 -m json.tool
 ```
 
-Save the returned `id` - use it for updates and monitoring.
+Save the returned `id` - use it for updates and monitoring. Name the automation after the
+template the user picked, for example `Jira issue-to-MR Poller` for GitLab.
 
 ### Step 6 - Verify with a test dispatch
 
@@ -158,6 +198,14 @@ curl -s "${OPENHANDS_HOST}/api/automation/v1/<AUTOMATION_ID>/runs?limit=1" \
   | python3 -c "import sys,json; r=json.load(sys.stdin)['runs'][0]; print(r['status'], r.get('error_detail'))"
 ```
 
+With the Rovo connection, a run that fails on `/api/v1/mcp/servers/<name>/call-tool` says why:
+
+- `404` with `No connected MCP server is named ...` - `jira_mcp_server` is not the name the
+  server is stored under, or the user switched the server off.
+- `404` with `Not Found` - this deployment cannot call a connected MCP server for a run yet.
+  Set the automation up with a Jira API token instead.
+- `502` - the server could not be reached, or the user has to reconnect it in the settings.
+
 ## Event-Based Alternative
 
 Where Jira can reach the deployment over the internet (OpenHands Cloud and Enterprise),
@@ -287,7 +335,8 @@ The automation script lives at `scripts/main.py`. Key behaviors:
 - **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 local dev environments where `AUTOMATION_KV_TOKEN` is absent (on OpenHands Cloud the run fails instead, since its sandbox does not persist).
-- **Jira API** - uses `POST /rest/api/3/search/jql` (the current non-deprecated endpoint).
+- **Jira access** - with `jira_mcp_server` set, searches and comments through the user's connected Atlassian Rovo MCP server (`POST /api/v1/mcp/servers/<name>/call-tool` on OpenHands Cloud, tools `searchJiraIssuesUsingJql` and `addOrEditJiraIssueComment`, or `addCommentToJiraIssue` on a server that still offers the v1 tools), so the run reads no Jira credential. Otherwise uses the Jira REST API with the token secret: `POST /rest/api/3/search/jql` (the current non-deprecated endpoint).
+- **Git provider** - `git_provider` selects the prompt's wording (GitHub pull request, GitLab merge request, Bitbucket pull request), the repository formats the agent looks for, and how it delivers without a token (GitLab's MCP tools, Rovo's Bitbucket tools); nothing else differs between the three templates.
 - **Conversation dispatch** - locally, calls `POST /api/conversations` on the agent server with the current user's LLM/agent settings forwarded to the new conversation; on OpenHands Cloud, calls `POST /api/v1/app-conversations`, which runs each conversation in its own sandbox with the user's settings, secrets and connected git provider.
 - **Start confirmation** (OpenHands Cloud only) - the API answers a start request before the conversation exists, so the next run checks each one. A start that failed is made again, up to three times, and after that the failure is posted on the Jira issue.
 - **Error transparency** - captures Jira HTTP response bodies in error messages for fast diagnosis.
@@ -324,4 +373,4 @@ that issue again.
 
 ## Additional Resources
 
-- **`references/setup.md`** - Jira API token creation, GitHub token scopes, cron schedule reference, and troubleshooting guide.
+- **`references/setup.md`** - Jira API token creation, git provider tokens, cron schedule reference, and troubleshooting guide.

package/skills/jira-issue-to-pr/references/setup.md

@@ -2,6 +2,9 @@
 
 ## Jira API Token
 
+The poller needs this token only when it does not reach Jira through a connected
+Atlassian Rovo MCP server (see Step 1 in `SKILL.md`).
+
 ### Create a token
 
 1. Log in to [id.atlassian.com](https://id.atlassian.com/manage-profile/security/api-tokens).
@@ -38,11 +41,19 @@ The Jira Cloud REST API v3 requires this for all authenticated requests.
 
 ---
 
-## GitHub Token
+## Git Provider Access
 
 The spawned agent conversation clones the target repository, pushes a new branch, and
-opens a pull request. The GitHub token must be stored as an OpenHands secret and must
-have the following scopes:
+opens the pull or merge request. On OpenHands Cloud and Enterprise it uses the connected
+integration for the provider named by `git_provider` (GitHub, GitLab or Bitbucket). With
+only an MCP connection (GitHub's with its saved token, GitLab's, or Atlassian Rovo for
+Bitbucket) it commits through the tools instead, and reads a private repository through
+them rather than cloning it. On a local Agent Canvas a token for the provider must be
+stored as an OpenHands secret.
+
+### GitHub
+
+The GitHub token must have the following scopes:
 
 | Scope | Required for |
 |---|---|
@@ -57,20 +68,39 @@ inherits the user's configured secrets automatically through the agent server.
 Navigate to **Settings → Secrets** and store the token under the name `GITHUB_TOKEN`
 (or whatever name is expected by the agent's GitHub skill).
 
+### GitLab
+
+Store a personal access token with the `api` scope and at least the Developer role on the
+target projects under the name `GITLAB_TOKEN`.
+
+Calling GitLab MCP directly, to commit without a token, needs GitLab 19.4 or later, where its
+branch, commit and repository tools first appear. On OpenHands Cloud and Enterprise the token
+of the user's GitLab sign-in or connected integration reaches the conversation as
+`GITLAB_TOKEN`, so on an older GitLab sign in with GitLab or connect it under Settings ->
+Integrations, and store this secret only if neither is possible.
+
+### Bitbucket
+
+Store the token under the name `BITBUCKET_TOKEN`; the `bitbucket` skill describes the token
+type and permissions.
+
 ---
 
 ## config.json Field Reference
 
 | Field | Required | Default | Description |
 |---|---|---|---|
-| `jira_base_url` | ✅ | - | Full URL of your Atlassian instance, e.g. `https://acme.atlassian.net` |
-| `jira_email` | ✅ | - | Email address of the Atlassian account that owns the API token |
+| `jira_mcp_server` | ❌ | - | Name the connected Atlassian Rovo MCP server is stored under. When set, the poller reaches Jira through it (OpenHands Cloud and Enterprise only) and the three fields after `jira_cloud_id` are not used |
+| `jira_cloud_id` | with `jira_mcp_server` | - | Atlassian cloud id of the Jira site |
+| `jira_base_url` | without `jira_mcp_server` | - | Full URL of your Atlassian instance, e.g. `https://acme.atlassian.net` |
+| `jira_email` | without `jira_mcp_server` | - | Email address of the Atlassian account that owns the API token |
 | `jira_token_secret` | ❌ | `"JIRA_CLOUD_KEY"` | Name of the OpenHands secret holding the Jira API token |
 | `jira_label` | ❌ | `"create-pr"` | Jira issue label to watch for |
+| `git_provider` | ❌ | `"github"` | `github`, `gitlab` or `bitbucket` - the provider the ticket names its repository on; changes only the prompt |
 
-> **GitHub repo**: not a config field. The target repository is read from the body of each
-> Jira ticket. Ticket authors must include the repo in `owner/repo` format or as a full
-> GitHub URL (e.g. `https://github.com/acme-org/backend`).
+> **Repository**: not a config field. The target repository is read from the body of each
+> Jira ticket: `owner/repo` or a GitHub URL on GitHub, `group/subgroup/project` or a full
+> URL on GitLab, `workspace/repo` on bitbucket.org.
 
 ---
 
@@ -142,11 +172,12 @@ The response is `SearchAndReconcileResults`; the script reads the `issues` array
 - The Jira project has issues with the label but all are in a Done status category.
   The JQL filter is `statusCategory != Done` - reopen or create a fresh issue.
 
-### Conversation started but no PR appears
+### Conversation started but no PR or MR appears
 
 - The spawned conversation inherits the user's agent/LLM settings. Check the conversation
   in the OpenHands UI (it appears in the conversations list under the automation run).
-- The GitHub token may lack `repo` scope to push or open PRs.
+- The connected integration or token may lack the scope to push or open the request
+  (GitHub `repo`, GitLab `api` with the Developer role).
 - The target repo's default branch may be protected; the token must have bypass permission,
   or the PR should be created against a different base branch.
 
@@ -166,13 +197,13 @@ The response is `SearchAndReconcileResults`; the script reads the `issues` array
 
 ## Multiple Deployments
 
-To watch multiple Jira projects or multiple GitHub repos, deploy separate automations —
+To watch multiple Jira projects or multiple repositories, deploy separate automations —
 one per `config.json`. Each automation has its own KV-store namespace (keyed by
 automation ID), so processed-key sets do not cross-contaminate.
 
 Example: two automations, one per project:
 
-| Automation name | `jira_base_url` | `jira_label` | GitHub repo (in ticket body) |
+| Automation name | `jira_base_url` | `jira_label` | Repository (in ticket body) |
 |---|---|---|---|
 | `Jira issue-to-PR - frontend` | `https://acme.atlassian.net` | `create-pr` | `acme/frontend` (written by ticket author) |
 | `Jira issue-to-PR - backend` | `https://acme.atlassian.net` | `create-pr-backend` | `acme/backend` (written by ticket author) |