Menu
Use when adding webhook events to make sure integrations properly register the webhook events they carry
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when creating, updating, or reviewing a Workforce cloud persona (`persona.ts` + `agent.ts`) for the current deploy/runtime shape. Covers cloud, useSubscription, integrations with scope mounting/enabledByInput gating/adapter config passthrough, inputs, memory, sandbox modes, onEvent, runtime fields, capabilities, defineAgent triggers/schedules/watch/team-dispatcher launch, provider IO via @relayfile/relay-helpers, multi-transport delivery, ctx.relay messaging, and the deploy flow.
Use when you are a registered relay agent (a spawned worker, or a lead that called register_agent) coordinating with peers in real time over current Agent Relay MCP tools - messaging, channels, threads, reactions, search, inbox, actions, and worker spawn/release. For role selection and orchestrator startup instructions, use https://agentrelay.com/skill and the orchestrating-agent-relay skill.
The canonical way to run agent-relay - self-bootstrap the local broker and autonomously spawn, monitor, and coordinate a team of worker agents without human intervention. Covers infrastructure startup, agent spawning, lifecycle monitoring, message-based reading via the relay MCP, and team coordination.
Use when creating, editing, or validating an Agent Relay Factory factory.config.json file, including repo routing, Linear state/team settings, GitHub issue ingestion, live mode, babysitter options, and Relayflows dispatch wiring boundaries.
Use when an agent or human needs to set up relayfile end-to-end so agents can read and write provider files through a local mount. Covers `relayfile setup`, dynamic integration discovery with `relayfile integration available/search`, Nango and Composio backend selection, Atlassian site selection and metadata, cloud login, OAuth/connect flows, mount verification, `RELAYFILE_LOCAL_DIR` handoff, writeback status and retry commands, and key May 2026 cloud-mount gotchas.
Use when an agent is exploring a relayfile mount for the first time or trying to locate a specific resource (Notion page, Linear issue, Slack channel, GitHub PR). Tells the agent to start with `<mount>/LAYOUT.md` and `<provider>/LAYOUT.md` rather than guessing paths from memory, and to use the `by-title/`, `by-id/`, `by-name/`, `by-edited/<date>/`, `by-state/` alias subtrees instead of recursively grepping. Filename convention is `<identifier>__<uuid>` (ticket number / slug first so listings are scannable). NOT for activity-summary questions, which should use the `activity-summary` skill instead.
| name | trigger-autocomplete-catalog |
| description | Use when adding webhook events to make sure integrations properly register the webhook events they carry |
Use this whenever a provider has webhook/event triggers.
The trigger catalog is owned by @relayfile/adapter-core and generated from
adapter sources. It does not live in this (cloud) repo's packages/core -
that's a different package.
import("@relayfile/adapter-core/triggers") exposes
KNOWN_TRIGGER_CATALOG and ADAPTERS_WITHOUT_KNOWN_TRIGGERS.@relayfile/adapter-<provider> package you already work in when wiring a
provider (the relayfile-adapters checkout from the persona's adapter-package
steps). Declaring events is one more edit in that package - no separate
location to track.Ensure persona trigger autocomplete and deploy-time lint include the provider via KNOWN_TRIGGER_CATALOG.
Only providers that actually emit webhook/event triggers belong in the catalog.
Pure storage / polling providers with no event source (e.g. s3, gcs, postgres)
legitimately remain in adapters-without-known-triggers.generated.json - do not
fabricate events for them.
KNOWN_TRIGGER_CATALOG (regenerated catalog.generated.ts).adapters-without-known-triggers.generated.json for missing trigger metadata.eventType and/or the events the cloud
nango-integrations/<provider>-relay syncs subscribe to).supportedEvents(): string[] to the adapter class, or<provider>.mapping.yaml with a top-level webhooks: block whose keys
are the event names (mirror packages/granola/granola.mapping.yaml). The
generator only reads the keys.# Build ALL workspaces first. The generator imports each adapter's
# supportedEvents(); if dependencies/dist are missing, those providers fail to
# import and are silently dropped from the catalog into the gap list. A core-only
# build is NOT enough.
npm ci
npm run build
node --import tsx packages/core/src/cli.ts triggers generate --repo-root .
node --import tsx packages/core/src/cli.ts triggers check --repo-root .
npm run build --workspace=packages/core
node --import tsx --test packages/core/tests/triggers/catalog-generator.test.ts
After the change merges, publish @relayfile/adapter-core (the Publish Package
workflow, e.g. package=core, version=patch). Publishing is what makes the
catalog change take effect - the trigger-autocomplete / deploy-time lint tooling
reads it via its @relayfile/adapter-core dependency. Cloud's
packages/core also depends on @relayfile/adapter-core and has tests that
import KNOWN_TRIGGER_CATALOG; normally no cloud package.json edit is
required because the dependency is a caret range that accepts new patch
releases. Bump Cloud's dependency only when the catalog fix requires a new
minor/major adapter-core version or Cloud needs to pin a specific published
version for CI.
relayfile-adapters#115 when closing missing-provider autocomplete gaps.without-known-triggers list.