@openhands/extensions 0.19.0 → 0.20.0

package/.release-please-manifest.json

@@ -1,3 +1,3 @@
 {
-  ".": "0.19.0"
+  ".": "0.20.0"
 }

package/AGENTS.md

@@ -106,7 +106,7 @@ When editing or adding skills in this repo, follow these rules (and add new skil
 - If you change a skill’s behavior or scope, update its `README.md` (if present) accordingly.
 - If you change top-level documentation, ensure links still resolve.
 - `integrations/catalog/*.json` is the single hand-authored source of truth consumed by `@openhands/extensions`; adding or editing an integration should require changing exactly one JSON file in that directory. Do not reintroduce `integrations/integration-catalog.json`, separate provider files, per-language catalog duplicates, or provider-specific runtime code. Run `npm run build:integrations` after catalog edits to regenerate `integrations/catalog-index.js`, which statically imports each individual JSON file for the JS package. The Python package includes the same individual JSON files via wheel data and reads them directly. Agent-canvas and integrations-hub import this package directly, so integration marketplace fixes belong here rather than in app-local constants. When upstream MCP projects move repos, verify both `docsUrl` and the connection option (`transport`, `command`/`args`, or URL), not just links. JS exposes `listIntegrationCatalog({ mcp, oauth })` / `getIntegrationCatalogEntry`; Python mirrors with `list_integration_catalog_models(mcp=, oauth=)` / `get_integration_catalog_entry_model`, which return validated Pydantic models (the raw-dict accessors were deprecated in 0.10.0 and removed in 0.12.0). The legacy provider-catalog compatibility layer and `managedConnectorMigration` / `legacyScopeBundles` / `canonicalServerUrl` / `errorHints` mechanisms were removed intentionally; providers declare only standard OAuth config as integration data.
-- `automations/catalog/<id>/` follows the same rule, as a directory per automation so an automation can ship the scripts it uploads to the automations service alongside its metadata. `manifest.json` is the single hand-authored file, carrying both the card metadata and an optional nested `setup` block (the extension-owned configuration experience). Every entry is validated against `automations/catalog.schema.json`. Run `npm run build:automations` after catalog edits to regenerate `automations/catalog-index.js`. JS exposes `listAutomationCatalog()` / `getAutomationCatalogEntry(id)` alongside `AUTOMATION_CATALOG`. The governing rule is that a manifest states only what varies between automations, and states it once; anything derivable is absent and the host generates it. Derived, so never written in a manifest: the command that launches the card (read from the `triggers:` frontmatter of the skill named by `skill`, which defaults to `id` and is stated only where the two differ - editing an automation must never require editing a skill), the setup route (`/automations/new/<id>`), the trigger kinds a deployment must support (the keys of `setup.form.triggers`), schedule limits and timezone lists (the `cron` and `timezone` field types), the preflight call, the create request's `name`/`repos`/`trigger` (rebuilt from the entry name, the repo-picker field and the keys and fields under `setup.form.triggers`, where a field is named after the property it fills), the mapping from a rejected payload path back to the input at fault, the review screen, the create endpoint, the post-success navigation, and the analytics stages. `requires.integrations` is keyed by integration id and lives on the entry, not in `setup`, because a card lists its integrations whether or not it ships a setup flow; there is no key anywhere for a credential, because the credential comes with the connection. `setup.form` splits inputs into `triggers` (keyed by trigger kind - what decides when the automation runs) and `args` (everything else), both keyed by field name. `setup` declares a `prompt` (plus a `filter` for an event trigger) when `mode` is `direct`, and a `message` when it is `assisted`. Contract fixtures are test vectors, not catalog data: they live in `tests/fixtures/automations/`, are optional per automation, and are reachable only through the `@openhands/extensions/testing/automations/*.json` subpath - never from the runtime entry point.
+- `automations/catalog/<id>/` follows the same rule, as a directory per automation so an automation can ship the scripts it uploads to the automations service alongside its metadata. `manifest.json` is the single hand-authored file, carrying both the card metadata and an optional nested `setup` block (the extension-owned configuration experience). Every entry is validated against `automations/catalog.schema.json`. Run `npm run build:automations` after catalog edits to regenerate `automations/catalog-index.js`. JS exposes `listAutomationCatalog()` / `getAutomationCatalogEntry(id)` alongside `AUTOMATION_CATALOG`. The governing rule is that a manifest states only what varies between automations, and states it once; anything derivable is absent and the host generates it. Derived, so never written in a manifest: the command that launches the card (read from the `triggers:` frontmatter of the skill named by `skill`, which defaults to `id` and is stated only where the two differ - editing an automation must never require editing a skill), the setup route (`/automations/new/<id>`), the trigger variants a deployment can offer (the keys of `setup.form.triggers`; multiple keys mean any supported selected variant can run), schedule limits, timezone lists, event choices, and model profiles (the `cron`, `timezone`, `event-source`, `event-type`, and `llm-profile` field types), the preflight call, the create request's `name`/`repos`/`model`/`timeout`/`trigger` (rebuilt from same-named form fields when present, the repo-picker field, and the selected key and fields under `setup.form.triggers`, where a field is named after the property it fills), the mapping from a rejected payload path back to the input at fault, the review screen, the create endpoint, the post-success navigation, and the analytics stages. `requires.integrations` is keyed by integration id and lives on the entry, not in `setup`, because a card lists its integrations whether or not it ships a setup flow; there is no key anywhere for a credential, because the credential comes with the connection. `setup.form` splits inputs into `triggers` (keyed by trigger kind - what decides when the automation runs) and `args` (everything else), both keyed by field name. `setup` declares a `prompt` (plus a `filter` for an event trigger) when `mode` is `direct`, and a `message` when it is `assisted`. Contract fixtures are test vectors, not catalog data: they live in `tests/fixtures/automations/`, are optional per automation, and are reachable only through the `@openhands/extensions/testing/automations/*.json` subpath - never from the runtime entry point.
 - For Python test runs, prefer `uv sync --group test` followed by `uv run pytest -q`; the full suite depends on `openhands-sdk`, which is not available in the base environment.
 - Agent-driven plugins (for example `plugins/pr-review` and `plugins/release-notes`) use `uv run --with openhands-sdk --with openhands-tools ...` and require an `LLM_API_KEY` in addition to `GITHUB_TOKEN`.
 - For OpenHands Cloud API guidance, automations, and CLI integration, use `plugins/openhands`. It is the canonical unified OpenHands plugin covering the V1 Cloud API, Automations API, and CLI. The individual skills (`skills/openhands-api`, `skills/openhands-automation`) are also available standalone.

package/automations/README.md

@@ -42,16 +42,17 @@ two records of the same fact from drifting apart, and it is why the file is as s
 | The setup route | `/automations/new/<id>` |
 | The integrations the card lists | `requires.integrations`, which every entry carries |
 | The capabilities endpoint | The host queries it for every automation |
-| The trigger kinds a deployment must support | The keys of `setup.form.triggers` |
-| Schedule limits and the timezone list | The `cron` and `timezone` field types |
-| Local validation rules | The `required` flag and `constraints` on each field |
+| The trigger variants a deployment can offer | The keys of `setup.form.triggers`; an entry with multiple keys is usable when at least one variant is supported |
+| Schedule limits, timezone list, event choices, and model profiles | The `cron`, `timezone`, `event-source`, `event-type`, and `llm-profile` field types |
+| Local validation rules | The `required` flag and `constraints` on each field, applied to the selected trigger variant |
 | The preflight call | `POST /v1/validate` with the entry id, the create endpoint, and the rendered payload |
-| The created automation's name | The entry's `name`, plus the repository that was picked |
-| `repos` in the create request | The repo-picker field, its declared `provider`, and a field named `ref` if there is one |
-| `trigger` in the create request | The key under `form.triggers`, and the fields under it named after trigger properties |
+| The created automation's name | A form field named `name`, or the entry's `name` plus the repository that was picked |
+| `repos` in the create request | The repo-picker field, its declared `provider`, and a non-empty field named `ref` if there is one |
+| `model` and `timeout` in the create request | Same-named form fields when they have values |
+| `trigger` in the create request | The selected key under `form.triggers`, and the fields under it named after trigger properties |
 | Which input a rejected payload path belongs to | Rebuilding that body with each field standing in for its own value |
 | The review screen | The fields and their labels |
-| The create endpoint | `POST /v1/preset/prompt`, or `POST /v1` for an entry that ships a bundle |
+| The create endpoint | `POST /v1/preset/prompt`, `POST /v1/preset/plugin`, or `POST /v1` for an uploaded or bundled tarball |
 | The files a bundle packs | `setup.bundle.files`, read from this repository at build time |
 | Where a success navigates | The created automation, or the started conversation |
 | The analytics stages | The same stages for every automation |
@@ -64,7 +65,7 @@ checks them against the recorded fixtures, so these deletions stay honest rather
 ```jsonc
 {
   "id": "github-pr-reviewer",
-  "name": "GitHub Code Review Agent",
+  "name": "GitHub code review",
   "category": "Code review",
   "description": "...",
   "requires": {
@@ -97,32 +98,40 @@ three entries whose names differ from their skill state it. The command that lau
 repeated here: it lives once, in the skill's own `triggers:` frontmatter, and the skills catalog exposes it.
 That way a skill can rename its trigger without leaving a stale copy behind in this catalog.
 
-`setup` is optional. Three of eight entries carry one today. It never repeats `id`, `name`, `category`, or
-`description`. `setup.version` selects how the block is interpreted; a future format ships a new constant.
+`setup` is optional. Entries that carry one never repeat `id`, `name`, `category`, or `description`.
+`setup.version` selects how the block is interpreted; a future format ships a new constant.
 
 ### Triggers and args
 
 `form` separates the two things a user is configuring, and both are keyed by field name:
 
 - **`form.triggers`** decides *when* the automation runs, keyed by trigger kind (`cron` or `event`).
-  `github-pr-reviewer` and `github-repo-monitor` each ask for a schedule and a timezone.
-- **`form.args`** is everything else: the arguments to the automation itself, such as the repository to
-  clone and the tone of the review.
+  If an entry declares more than one key, the host renders those keys as selectable variants and validates
+  only the selected variant's fields before building the payload.
+- **`form.args`** is everything else that is common to every creation path, such as the automation name,
+  model profile, or timeout.
+- **`setup.actions`** is optional and declares user-selectable creation paths for one card. The host renders
+  the common form plus the selected action's `args`, checks that action's `features`, and creates through
+  the endpoint implied by the action key: `prompt` -> `/v1/preset/prompt`, `plugin` -> `/v1/preset/plugin`,
+  and `upload` -> `/v1/uploads` followed by `/v1`.
 
 An assisted entry declares no triggers, because the trigger is settled during the conversation.
 
 ### What the form produces
 
-- **`mode: "direct"`** declares a `prompt`: what the automation is told to do. The rest of the create
-  request restates the form, so it is not written out. An event trigger also declares a `filter`, because
-  composing form values into a JMESPath expression is the one part of an event trigger that cannot be read
-  off the form.
+- **`mode: "direct"`** declares exactly one creation archetype: a `prompt`, a repository-shipped `bundle`,
+  or `actions`. A prompt creates through `/v1/preset/prompt`. A bundle is packed and uploaded by the host,
+  then creates through `/v1`. An actions block lets the user choose between prompt, plugin, and uploaded
+  tarball paths in one card. The rest of the create request restates the form, so it is not written out. A
+  form field named `name`, `model`, or `timeout` fills the matching top-level create property. An event
+  trigger may also declare a `filter`, because composing form values into a JMESPath expression is the one
+  part of an event trigger that cannot always be read off the form.
 - **`mode: "assisted"`** declares a `message`: setup context handed to an agent conversation that finishes
   the job. The command that opens that conversation comes from the skill, so it is not repeated here.
 
 A direct entry may also declare a `message`. It is the seed for the fallback conversation the host offers
-when the deployment cannot run the direct path - a deployment whose capabilities lack the entry's trigger
-kind or required features. The same 2000-character cap applies, and because the fallback fires before the
+when the deployment cannot run the direct path - a deployment whose capabilities lack every declared trigger
+variant or required features. The same 2000-character cap applies, and because the fallback fires before the
 form is trustworthy, a direct `message` should not reference `{{form.*}}`.
 
 A `repo-picker` may declare `multiple: true`, and then it collects several
@@ -135,17 +144,17 @@ repository when there is one and after the count when there are several, since a
 list of names does not fit a name.
 
 A form field is named after the property it fills. `schedule` and `timezone` under `triggers.cron` become
-`trigger.schedule` and `trigger.timezone`; `on` under `triggers.event` becomes `trigger.on`; a field named
-`ref` becomes `repos[].ref`. Any other field under a trigger kind, such as a phrase to match, is an input
-to `filter` rather than a trigger property.
+`trigger.schedule` and `trigger.timezone`; `source` and `on` under `triggers.event` become `trigger.source`
+and `trigger.on`; a field named `ref` becomes `repos[].ref` when it has a value. Any other field under a
+trigger kind, such as a phrase to match, is an input to `filter` rather than a trigger property.
 
 ### Entries that ship a script
 
-`mode: "direct"` produces either a `prompt` or a `bundle`, never both. A prompt
-is the right shape when the automation *is* the judgement: the agent reads the
-prompt and does the work. A bundle is the right shape when most of what the
-automation does is deterministic machinery - polling, dedupe, state, fixed API
-calls - and the agent is needed only for the part that genuinely needs judgement.
+`mode: "direct"` produces exactly one of `prompt`, `bundle`, or `actions`. A
+prompt is the right shape when the automation *is* the judgement: the agent
+reads the prompt and does the work. A bundle is the right shape when most of
+what the automation does is deterministic machinery - polling, dedupe, state,
+fixed API calls - and the agent is needed only for the part that genuinely needs judgement.
 `github-pr-reviewer` is the first: its script owns discovery, label-event
 dedupe, per-repo state and the review checkout, and starts a conversation only
 once a pull request actually needs reviewing.
@@ -188,7 +197,10 @@ Two things follow from the archetype rather than being stated:
 A bundle declares `requires.features: ["customTarball"]`: a deployment that
 cannot run a client-supplied tarball cannot run the entry, whatever trigger kinds
 it offers. It never declares `repos` - the raw create endpoint has no such field,
-and a bundle fetches what it needs itself.
+and a bundle fetches what it needs itself. In an `actions` entry, creation-path
+features move down to each action (`presetPrompt`, `presetPlugin`, or
+`customTarball`) so a deployment can offer the supported choices without needing
+every creation path.
 
 ### Format constraints
 
@@ -208,17 +220,19 @@ trust boundary. It enforces:
 Placeholders are namespaced and the schema rejects any other namespace: `{{form.*}}` for what the user
 entered and `{{automation.*}}` for the entry itself. There is deliberately no secrets namespace.
 
-### The three archetypes
+### The archetypes
 
 | Entry | Archetype | Trigger | Produces |
 | --- | --- | --- | --- |
 | `github-pr-reviewer` | Direct scheduled, script bundle | `cron` | an upload, then a create payload |
 | `github-repo-monitor` | Direct scheduled | `cron` | a create payload |
+| `qa-changes` | Direct event | `event` | a create payload |
+| `custom-automation` | Direct custom action with prompt, plugin, or upload variants | `cron` or `event` | a create payload, or an upload then create payload |
 | `incident-retrospective-drafter` | Assisted conversation | decided during the conversation | a seed message |
 
-An event archetype is still expressible - `github-repo-monitor` used one until its deployment could no
-longer receive webhooks, and was converted to the polled `cron` form. The schema keeps supporting `event`
-triggers for deployments that can. See the `event` key under `setup.form.triggers` in `catalog.schema.json`.
+An entry can declare both `cron` and `event` under `setup.form.triggers`. The host treats those keys as
+selectable variants and creates the payload from the selected one; a deployment that only supports one of
+the variants can still offer that supported path.
 
 The assisted archetype has no payload and no preflight, because at the end of its flow no automation exists
 yet. The agent creates it during the conversation, and the service validates it there. That is the defining
@@ -300,9 +314,11 @@ import scenarios from "@openhands/extensions/testing/automations/github-pr-revie
 must result. That pairing is the contract: form shape and API shape genuinely differ, the create endpoint
 is declared `extra="forbid"`, and a mapping mistake is a 422 discovered only at creation time.
 
-Each scenario carries whichever blocks apply: `formValues`, `integrationState`, `localValidation`,
-`preflight`, `create`, `conversation`, `expectedFieldErrors`, `expectedPrerequisiteOutcome`.
-`capabilities.json` holds three deployment shapes so the unsupported paths have coverage too.
+Each scenario carries whichever blocks apply: `formValues`, `selectedTrigger`, `integrationState`,
+`localValidation`, `preflight`, `create`, `conversation`, `expectedFieldErrors`,
+`expectedPrerequisiteOutcome`. `selectedTrigger` is required when an entry declares multiple trigger
+variants and the scenario records a create or preflight payload. `capabilities.json` holds deployment
+shapes so the unsupported paths have coverage too.
 
 Beyond the derivation checks, every request body here has been verified against the live Pydantic models in
 `OpenHands/automation`:
@@ -359,7 +375,7 @@ questions to this work. What changed and why:
 | `analytics` | Removed. The same stages fire for every automation, so they belong in shared host code. |
 | `workflow.steps` | Removed. It restated which keys were present, creating a second source of truth that could contradict the file. |
 | `form.intent: "seed"` | Removed. Derivable from `setup.mode: "assisted"`. |
-| `triggerKindsAnyOf` | Removed. The keys of `form.triggers` are the trigger kinds. |
+| `triggerKindsAnyOf` | Removed. The keys of `form.triggers` are the available trigger variants, and multiple keys already mean the host can offer any supported one. |
 | `{{form.filledCount}}` | Removed. It overloaded the `form` namespace with a computed value that names no field. |
 | `submit.message` | Kept as `setup.message`, capped at 2000 characters, so seed messages cannot grow back into the giant runtime prompts that recommended automation cards were already fixed to stop sending. |
 

package/automations/catalog/custom-automation/manifest.json

@@ -0,0 +1,229 @@
+{
+  "id": "custom-automation",
+  "name": "Custom automation",
+  "category": "Custom",
+  "icon": "sparkles",
+  "description": "Create a custom automation from a prompt, plugin-powered prompt, or uploaded script tarball.",
+  "requires": {
+    "integrations": {
+      "github": {
+        "message": "Optional. Used when you choose a GitHub repository to clone or trigger from GitHub events.",
+        "required": false
+      }
+    }
+  },
+  "popularityRank": 99,
+  "estimatedSetupMinutes": 5,
+  "skill": "openhands-automation",
+  "exampleImplementation": "Action: a user-selected prompt, plugin, or uploaded tarball creation path\nTrigger: a user-selected cron schedule or event source and event type\n\n1. Ask whether the automation should run a prompt, run a prompt with plugins, or upload a tarball.\n2. Render only the fields for the selected creation path.\n3. Create prompt automations through /v1/preset/prompt, plugin automations through /v1/preset/plugin, and uploaded tarball automations by uploading to /v1/uploads then creating through /v1.\n4. The selected trigger and common run settings are shared by all creation paths.",
+  "setup": {
+    "version": "1.0",
+    "mode": "direct",
+    "form": {
+      "note": "Choose whether this custom automation runs a plain prompt, a prompt with plugins, or your own uploaded tarball. Prompt and plugin runs use the LLM; uploaded tarballs are best for deterministic scripts.",
+      "triggers": {
+        "cron": {
+          "schedule": {
+            "type": "cron",
+            "label": "Schedule",
+            "help": "How often this automation should run.",
+            "default": "0 9 * * *",
+            "required": true
+          },
+          "timezone": {
+            "type": "timezone",
+            "label": "Timezone",
+            "help": "Timezone used to evaluate the schedule.",
+            "default": "UTC",
+            "required": true
+          }
+        },
+        "event": {
+          "source": {
+            "type": "event-source",
+            "label": "Event source",
+            "help": "Webhook source that starts the automation.",
+            "default": "github",
+            "required": true
+          },
+          "on": {
+            "type": "event-type",
+            "label": "Event type",
+            "help": "Event key or wildcard pattern that starts the automation.",
+            "placeholder": "issue_comment.created",
+            "required": true
+          },
+          "filter": {
+            "type": "textarea",
+            "label": "Event filter",
+            "help": "Optional JMESPath expression evaluated against the event payload.",
+            "placeholder": "glob(repository.full_name, 'OpenHands/*')",
+            "required": false,
+            "constraints": {
+              "maxLength": 2000
+            }
+          }
+        }
+      },
+      "args": {
+        "name": {
+          "type": "text",
+          "label": "Automation name",
+          "help": "Name shown in the automations list.",
+          "placeholder": "Daily repository summary",
+          "required": true,
+          "constraints": {
+            "minLength": 1,
+            "maxLength": 500
+          }
+        },
+        "model": {
+          "type": "llm-profile",
+          "label": "LLM profile",
+          "help": "Optional model profile used for automation runs. Leave blank to use the active profile.",
+          "required": false
+        },
+        "timeout": {
+          "type": "number",
+          "label": "Timeout (seconds)",
+          "help": "Maximum time a single run may take. Leave blank for the service default.",
+          "required": false,
+          "constraints": {
+            "min": 1,
+            "max": 1800
+          }
+        }
+      }
+    },
+    "actions": {
+      "prompt": {
+        "label": "Prompt",
+        "help": "Run a natural-language prompt with the default OpenHands agent.",
+        "features": [
+          "presetPrompt"
+        ],
+        "args": {
+          "prompt": {
+            "type": "textarea",
+            "label": "Prompt",
+            "help": "Instructions the agent follows every time the automation runs.",
+            "placeholder": "Summarize recent repository activity and post the result to Slack.",
+            "required": true,
+            "constraints": {
+              "minLength": 1,
+              "maxLength": 50000
+            }
+          },
+          "repository": {
+            "type": "repo-picker",
+            "label": "Repository",
+            "help": "Optional GitHub repository to clone before each run.",
+            "provider": "github",
+            "required": false
+          },
+          "ref": {
+            "type": "text",
+            "label": "Branch or ref",
+            "help": "Branch, tag, or commit to check out when a repository is selected.",
+            "placeholder": "main",
+            "required": false,
+            "constraints": {
+              "minLength": 1,
+              "maxLength": 255
+            }
+          }
+        },
+        "prompt": "{{form.prompt}}"
+      },
+      "plugin": {
+        "label": "Plugin",
+        "help": "Run a prompt with one or more OpenHands plugins loaded.",
+        "features": [
+          "presetPlugin"
+        ],
+        "args": {
+          "plugins": {
+            "type": "plugin-sources",
+            "label": "Plugins",
+            "help": "One or more plugin sources to load. Each source may include an optional ref and repository path.",
+            "required": true
+          },
+          "prompt": {
+            "type": "textarea",
+            "label": "Prompt",
+            "help": "Instructions the agent follows after loading the plugins.",
+            "placeholder": "Use the plugin commands to inspect the repository and summarize findings.",
+            "required": true,
+            "constraints": {
+              "minLength": 1,
+              "maxLength": 50000
+            }
+          },
+          "repository": {
+            "type": "repo-picker",
+            "label": "Repository",
+            "help": "Optional GitHub repository to clone before each run.",
+            "provider": "github",
+            "required": false
+          },
+          "ref": {
+            "type": "text",
+            "label": "Branch or ref",
+            "help": "Branch, tag, or commit to check out when a repository is selected.",
+            "placeholder": "main",
+            "required": false,
+            "constraints": {
+              "minLength": 1,
+              "maxLength": 255
+            }
+          }
+        },
+        "prompt": "{{form.prompt}}",
+        "plugins": "{{form.plugins}}"
+      },
+      "upload": {
+        "label": "Upload tarball",
+        "help": "Upload a .tar or .tar.gz containing the automation code to run.",
+        "features": [
+          "customTarball"
+        ],
+        "args": {
+          "tarball": {
+            "type": "tarball-upload",
+            "label": "Tarball",
+            "help": "A .tar or .tar.gz archive containing the automation code. Maximum size is enforced by the automation service.",
+            "required": true
+          },
+          "entrypoint": {
+            "type": "text",
+            "label": "Entrypoint",
+            "help": "Command to run after the tarball is extracted.",
+            "default": "python3 main.py",
+            "placeholder": "python3 main.py",
+            "required": true,
+            "constraints": {
+              "minLength": 1,
+              "maxLength": 500
+            }
+          },
+          "setupScript": {
+            "type": "text",
+            "label": "Setup script",
+            "help": "Optional path inside the tarball to run before the entrypoint.",
+            "placeholder": "setup.sh",
+            "required": false,
+            "constraints": {
+              "minLength": 1,
+              "maxLength": 255
+            }
+          }
+        },
+        "tarballPath": "{{form.tarball}}",
+        "entrypoint": "{{form.entrypoint}}",
+        "setupScript": "{{form.setupScript}}"
+      }
+    },
+    "filter": "{{form.filter}}",
+    "message": "This deployment cannot create custom automations directly. Set it up in this conversation instead: choose prompt, plugin, or uploaded tarball mode; confirm the selected trigger, model profile, timeout, and mode-specific fields; then create the automation."
+  }
+}

package/automations/catalog/github-issue-to-pr/manifest.json

@@ -1,6 +1,6 @@
 {
   "id": "github-issue-to-pr",
-  "name": "GitHub Issue to PR Agent",
+  "name": "GitHub issue to PR",
   "category": "Software development",
   "description": "Watch for a configurable label on GitHub issues, implement the issue in a clone of the default branch, and open a pull request for each label event.",
   "requires": {

package/automations/catalog/github-pr-reviewer/manifest.json

@@ -1,7 +1,7 @@
 {
   "id": "github-pr-reviewer",
   "version": "1.0.0",
-  "name": "GitHub Code Review Agent",
+  "name": "GitHub code review",
   "category": "Code review",
   "description": "Watch for a configurable label on GitHub pull requests, inspect full PR and repository context, and post an AI review comment once per label event.",
   "requires": {

package/automations/catalog/qa-changes/manifest.json

@@ -1,6 +1,6 @@
 {
   "id": "qa-changes",
-  "name": "QA Changes Agent",
+  "name": "QA changes",
   "category": "Code review",
   "description": "When a pull request is opened for review, run the QA changes methodology — set up the environment, exercise the changed behavior as a real user would, and post the outcome by editing the PR description with a QA Agent section.",
   "requires": {

package/automations/catalog-index.js

@@ -3,23 +3,24 @@
 // run: npm run build:automations
 
 import entry0 from "./catalog/github-pr-reviewer/manifest.json" with { type: "json" };
-import entry1 from "./catalog/github-repo-monitor/manifest.json" with { type: "json" };
-import entry2 from "./catalog/github-issue-to-pr/manifest.json" with { type: "json" };
-import entry3 from "./catalog/slack-standup-digest/manifest.json" with { type: "json" };
-import entry4 from "./catalog/slack-channel-monitor/manifest.json" with { type: "json" };
-import entry5 from "./catalog/linear-triage-assistant/manifest.json" with { type: "json" };
-import entry6 from "./catalog/linear-issue-to-github-pr/manifest.json" with { type: "json" };
-import entry7 from "./catalog/linear-issue-to-gitlab-mr/manifest.json" with { type: "json" };
-import entry8 from "./catalog/linear-issue-to-bitbucket-pr/manifest.json" with { type: "json" };
-import entry9 from "./catalog/jira-issue-to-pr/manifest.json" with { type: "json" };
-import entry10 from "./catalog/qa-changes/manifest.json" with { type: "json" };
-import entry11 from "./catalog/jira-issue-to-gitlab-mr/manifest.json" with { type: "json" };
-import entry12 from "./catalog/research-brief-writer/manifest.json" with { type: "json" };
-import entry13 from "./catalog/jira-issue-to-bitbucket-pr/manifest.json" with { type: "json" };
-import entry14 from "./catalog/github-agents-md-maintainer/manifest.json" with { type: "json" };
-import entry15 from "./catalog/upstream-fork-sync/manifest.json" with { type: "json" };
-import entry16 from "./catalog/incident-retrospective-drafter/manifest.json" with { type: "json" };
-import entry17 from "./catalog/news-digest/manifest.json" with { type: "json" };
+import entry1 from "./catalog/custom-automation/manifest.json" with { type: "json" };
+import entry2 from "./catalog/github-repo-monitor/manifest.json" with { type: "json" };
+import entry3 from "./catalog/github-issue-to-pr/manifest.json" with { type: "json" };
+import entry4 from "./catalog/slack-standup-digest/manifest.json" with { type: "json" };
+import entry5 from "./catalog/slack-channel-monitor/manifest.json" with { type: "json" };
+import entry6 from "./catalog/linear-triage-assistant/manifest.json" with { type: "json" };
+import entry7 from "./catalog/linear-issue-to-github-pr/manifest.json" with { type: "json" };
+import entry8 from "./catalog/linear-issue-to-gitlab-mr/manifest.json" with { type: "json" };
+import entry9 from "./catalog/linear-issue-to-bitbucket-pr/manifest.json" with { type: "json" };
+import entry10 from "./catalog/jira-issue-to-pr/manifest.json" with { type: "json" };
+import entry11 from "./catalog/qa-changes/manifest.json" with { type: "json" };
+import entry12 from "./catalog/jira-issue-to-gitlab-mr/manifest.json" with { type: "json" };
+import entry13 from "./catalog/research-brief-writer/manifest.json" with { type: "json" };
+import entry14 from "./catalog/jira-issue-to-bitbucket-pr/manifest.json" with { type: "json" };
+import entry15 from "./catalog/github-agents-md-maintainer/manifest.json" with { type: "json" };
+import entry16 from "./catalog/upstream-fork-sync/manifest.json" with { type: "json" };
+import entry17 from "./catalog/incident-retrospective-drafter/manifest.json" with { type: "json" };
+import entry18 from "./catalog/news-digest/manifest.json" with { type: "json" };
 
 export const AUTOMATION_CATALOG_ENTRIES = [
   entry0,
@@ -40,4 +41,5 @@ export const AUTOMATION_CATALOG_ENTRIES = [
   entry15,
   entry16,
   entry17,
+  entry18,
 ];