2392772541/ai-skills/automate

Create Automation (Interactive)

Use this skill when the user explicitly wants to make, build, set up, or create a new Cursor Automation — for example "create a Cursor automation", "open the Automations editor with this draft", or "set up a scheduled Cursor agent".

Disambiguation. "Automation" in a user workspace can mean many things (.github/workflows, CI pipelines, scheduled jobs, scripts, dbt, browser automation, shell scripts, workflow engines). Do not assume generic phrases like "automate this", "help me automate my deploys", or "make an automation" mean Cursor Automation. Route to the named surface when the user mentions one, use normal repo/product exploration when the context points elsewhere, or ask a short clarifying question when the target surface is ambiguous. Start this spine only when the user explicitly asks for Cursor Automations or confirms that Cursor Automations is the intended surface.

Execution spine (every run)

1. Finish-path check. First, check whether the in-app Automations editor handoff is available (see Finish availability below). If neither the Automations editor tool nor the resource opener is available, immediately say "Please use this skill in the Agents Window." and stop.
2. Capture intent + proactive integration discovery. After the finish-path check passes, if the prompt is missing 2+ of {what kicks it off, what should happen, what outcome}, send one short plain-chat message asking for a 1–2 sentence description and wait. Skip when the prompt already names trigger + action + outcome. Proactively run discovery for any integration the user named or implied — gh repo view on cwd; Slack MCP channels; PagerDuty MCP services; Linear/Sentry MCP teams/projects. Use the results to skip questions later.
3. Completeness gates. Work through the trigger, tool, prompt, naming, and PCD checks below. Do not jump to a summary while required picker-backed fields are still unknown unless the user explicitly deferred them to the Automations editor.
4. One consolidated question. Ask inline for whatever integration discovery couldn't resolve — trigger details, repo / channel / service when ambiguous, tools when not obvious. Default to plain-chat inline. Only escalate to AskQuestion for (a) the tools multi-select and (b) integration discovery candidate lists with 3+ matches.
5. Draft table → approval → finish handoff. Show a compact Markdown table (plain language, no YAML) recapping name / description, trigger, tools, instructions, resolved settings, and "to finish in editor". User approves, then ask whether they are ready for you to open the Automations editor so they can finish any deferred values there. When they say yes, use the finish path from the availability check.

House rules

• Plain language only. Never show or talk about MCP / tool / proto names, request types, enum values, stage labels, or raw CLI output in user-visible chat. Say "open the editor with the draft", "the Slack channel", "the repo and branch". Exception: the user explicitly asks to see internals.
• No YAML in finalization. The draft table = compact Markdown only in plain language. Build and validate YAML / JSON internally; surface the wire payload only when the user asks for it.
• No automatic fallbacks. Never submit, open a URL, paste a browser prefill link, or switch buckets. The only finish path is the reviewed draft table, user approval, user readiness confirmation, then opening the Automations editor. If neither the Automations editor tool nor the resource opener is available, stop immediately and tell the user to use this skill in the Agents Window.
• Creation-only. This skill prepares new automations only. Do not list, get, inspect, update, or search existing Cursor Automations from chat.
• Integration discovery is allowed. Use connected integration MCP read / list / search tools for picker-backed integration values such as Slack channels, PagerDuty services, Linear teams, and Sentry projects. This does not include backend automation tools that list, get, inspect, create, update, finish, or prefill Cursor Automations.
• Repo file references. Only reference a file from the chat's current repo (path, excerpt, or @file mention) in any draft field — prompt, instructions, name, or description — when both are true: (1) the automation will run in that same repo (its git trigger scope or workflow.gitConfig.repo is the chat's repo) and (2) the file is committed to that repo (tracked by git on the branch the automation will check out, not just present in the working tree). If either condition fails, paraphrase the intent instead, or ask the user to commit and push the file first — do not embed the path or content. Untracked / staged-only / dirty-only files, files outside the automation's repo, and files in a different repo from the chat's checkout never qualify.

PCD — Portal completeness & deferral

Use these checks to keep the draft complete before opening the editor. Do not show the ids to the user.

PCD matrix

PCD notes

• Slack trigger and Slack action destinations are separate questions. A Slack trigger does not imply a Slack action destination, and a Slack action does not imply a Slack trigger channel.
• Do not prefill empty Slack channel values after the user chose "specify now" unless discovery ran or the user explicitly switched to editor deferral.
• For Slack replies, offer "respond in the triggering thread" separately from "send to a specific channel or DM".
• When mcp is enabled, the server must pass the MCP existence gate and MCP auth gate below. Prefer discovering and selecting the exact catalog server name yourself; ask the user only when multiple usable catalog matches fit the request or the requested integration is ambiguous. Do not call it a Cursor plugin. Do not invent server names.

MCP existence gate

An MCP server is eligible only when the current user's available MCP/tool catalog proves it exists and is usable in this session. Before using an MCP for integration discovery or adding an mcp action to the draft, inspect the actual catalog exposed to the agent session and pick the right value to put into mcp.server.name.

Read the right field from the catalog. Each agent-side catalog entry lives at ~/.cursor/mcps/<folder>/SERVER_METADATA.json and carries two distinct values:

• serverIdentifier — the scoped folder name the agent runtime uses (e.g. dashboard-team-1-Linear, plugin-pagerduty-pagerduty-mcp, cursor-app-control).
• serverName — the plain name the user configured on cursor.com (e.g. Linear, pagerduty-mcp, Databricks SQL).

Write serverName into workflow.actions[].mcp.server.name and any @[MCP: ...] prompt mentions. Never write serverIdentifier / the folder name, never invent or paraphrase a prefix (team-…, user-…, <orgId>-…), and never hand-strip prefixes from the folder name — many serverNames contain spaces (e.g. Databricks SQL, statsig read only console), so string-munging the identifier is fragile. The Automations editor matches on trim + lowercase, so casing does not matter, but pass the exact serverName from SERVER_METADATA.json anyway. When you have a useful URL, you may also pass templateMcpHints: [{ name: <serverName>, url: <serverUrl> }] so a URL match can rescue a name drift.

Eligibility — dashboard-backed servers only. Only dashboard-backed servers appear in the Automations editor's GetAvailableMcpServers response, which is what the editor uses to resolve a prefilled mcp action to a connected server. Their serverIdentifier always begins with one of these prefixes:

• dashboard-team-<teamId>- (team-shared servers)
• dashboard- (personal user-configured servers on cursor.com)
• plugin-<slug>- (marketplace plugin servers)

Everything else in the agent catalog — cursor-ide-browser, cursor-app-control, extension-…, project mcp.json servers, and other local servers — does NOT appear in the dashboard catalog. Treat those as ineligible for the mcp action: do not add them to workflow.actions, do not reference them in @[MCP: ...] prompt mentions, and do not assume they will resolve when the editor opens. Prefilling an ineligible server lands the row in the blocked "Set up MCP" state and prevents the user from saving.

If one usable, dashboard-eligible catalog server clearly matches the user's requested integration, use it without asking the user to spell the server name. A name from the user prompt, a screenshot, a skill file, a workflow template, marketplace docs, or company convention is not proof.

If the catalog does not contain a usable, dashboard-eligible server, do not call that MCP, do not add an mcp action for it, and do not include @[MCP: ...] prompt mentions. Servers that are missing, disabled, or still need setup count as unavailable for prefill. Ask the user to set it up first, or leave the MCP out of the draft and record "Set up/select <integration> in the Automations editor" in To finish in editor. Unknown MCP server names are not valid deferred tool rows because prefilled missing MCPs block save.

MCP auth gate

Why this exists. The Automations editor can prompt for MCP OAuth, but that flow navigates away from the draft and the user loses in-progress changes. Authenticate MCPs here in chat before you add an mcp action, show the draft table, or open the editor.

When it applies. Run this gate whenever you plan to add an mcp action or @[MCP: ...] prompt mention for a dashboard-eligible server — including after integration discovery for picker-backed values.

Detect unauthenticated servers from the current session catalog (do not guess). STATUS.md is written for both auth and generic error states, so its mere existence is not an auth signal — read the file and check its content:

• ~/.cursor/mcps/<folder>/STATUS.md exists and its content says the server needs authentication (e.g. "needs authentication" / instructs calling mcp_auth). A STATUS.md that only reports a generic error is not an auth signal.
• GetMcpTools (or equivalent catalog inspection) reports serverStatus: "needsAuth" for that server's serverIdentifier.
• The server's live tool list is only mcp_auth (no other usable tools yet).
• Integration discovery against that server fails with an authentication / authorization error.

A server that passes the existence gate but matches any auth signal above is not authenticated — treat it separately from "missing", "not set up", or generic error.

Hard stop until authed. If the target MCP is not authenticated: