Sets up triggers from webhooks, emails, or database changes to execute Windmill scripts.

Install

mkdir -p .claude/skills/triggers && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/5262" && unzip -o skill.zip -d .claude/skills/triggers && rm skill.zip

Installs to .claude/skills/triggers

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

MUST use when configuring triggers.
35 chars✓ has a “when” trigger
Beginner

Key capabilities

  • Configure email triggers to route incoming emails to scripts or flows
  • Process email payloads including headers, body, and attachments
  • Extract URL-style extras from email local-parts as `email_extra_args`
  • Handle large raw email messages and binary attachments as S3 objects
  • Deploy local trigger configurations to the workspace
  • Pull remote trigger configurations to local files

How it works

Triggers route external events, such as emails, to scripts or flows, providing parsed event data as input.

Inputs & outputs

You give it
External events or incoming emails
You get back
Invocation of scripts or flows with parsed email data

When to use triggers

  • Configure an email trigger for a workflow
  • Setup a Postgres CDC trigger
  • Define a webhook trigger for external events

About this skill

Windmill Triggers

Triggers allow external events to invoke your scripts and flows.

File Naming

Trigger configuration files use the pattern: {path}.{trigger_type}_trigger.yaml

Examples:

  • u/user/webhook.http_trigger.yaml
  • f/data/kafka_consumer.kafka_trigger.yaml
  • f/sync/postgres_cdc.postgres_trigger.yaml
  • f/inbound/orders.email_trigger.yaml

Email Triggers

An email trigger routes incoming emails to a script or flow. Each trigger reserves a local-part: emails sent to <local_part>@<windmill_email_domain> are delivered to the configured runnable. Set workspaced_local_part: true to namespace it per workspace (the actual recipient becomes <workspace_id>-<local_part>@…); on Windmill Cloud this is required.

Senders may append URL-style extras to the local-part with +: mytrigger+foo=bar+baz=qux@…. They flow through to the script as email_extra_args (see below).

Payload

The runnable receives:

  • parsed_email{ headers, text_body, html_body, attachments[] }. Each attachment has { headers, body }.
  • raw_email — the raw RFC 822 message as a string, or an S3 object ({ s3: "windmill_emails/<job_id>/raw.eml" }) if the message exceeds 1 MiB.
  • email_extra_args (optional, only when sender appended +key=value extras) — a flat object of the parsed extras.

With a preprocessor, all of the above are nested under event along with event.kind = "email" and event.trigger_path (the trigger's path). Without a preprocessor, trigger_path is not exposed — add a preprocessor if you need it.

Attachments are S3 objects

Binary attachments are uploaded to the workspace S3 bucket and surface in parsed_email.attachments[i].body as:

{ "s3": "windmill_emails/<job_id>/attachments/<filename>" }

To read the bytes inside a script, use the wmill SDK:

// TypeScript
import * as wmill from "windmill-client"
const file = await wmill.loadS3File(parsed_email.attachments[0].body)
# Python
import wmill
data = wmill.load_s3_file(parsed_email["attachments"][0]["body"])

If the workspace has no S3 resource configured (Workspace Settings → Object storage), body falls back to the string "configure s3 in the workspace settings to handle attachments". The same applies to large raw_email bodies. Email attachment storage requires the server to be built with the parquet feature.

Text/HTML/inline parts are placed inline in body as strings.

CLI Commands

Deploying local changes to the workspace can be destructive to remote state — only suggest/run a deploy when the user explicitly asks to deploy/publish/push, not when they say "run", "try", or "test". Deploy via git push or wmill sync push depending on how the repo is wired (see the Deploying section in AGENTS.wmill.md). sync pull is safe to run yourself — it never mutates remote state, though it does overwrite local files to match the remote (use sync pull --dry-run to only preview).

# Push trigger configuration — only when the user explicitly asks to deploy
wmill sync push

# Pull triggers from Windmill
wmill sync pull

When not to use it

  • When the user asks to deploy, publish, or push without explicitly asking for `wmill sync push`
  • When the user asks to run, try, or test a trigger

Prerequisites

S3 resource configured in Workspace Settings for attachment handlingServer built with the `parquet` feature for email attachment storage

Limitations

  • Trigger configuration files must follow the `{path}.{trigger_type}_trigger.yaml` pattern
  • Email attachment storage requires S3 configuration and the `parquet` feature
  • The `trigger_path` is not exposed without a preprocessor

How it compares

This skill enables external events to directly invoke Windmill scripts, unlike manual execution or polling for events.

Compared to similar skills

triggers side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
triggers (this skill)12moReviewBeginner
bazel-build-optimization142moNo flagsAdvanced
github-actions-templates73moNo flagsIntermediate
monitor-ci15moReviewAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

Search skills

Search the agent skills registry