triggers
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.zipInstalls 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.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
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.yamlf/data/kafka_consumer.kafka_trigger.yamlf/sync/postgres_cdc.postgres_trigger.yamlf/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[] }. Eachattachmenthas{ 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=valueextras) — 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
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.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| triggers (this skill) | 1 | 2mo | Review | Beginner |
| bazel-build-optimization | 14 | 2mo | No flags | Advanced |
| github-actions-templates | 7 | 3mo | No flags | Intermediate |
| monitor-ci | 1 | 5mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by windmill-labs
View all by windmill-labs →You might also like
bazel-build-optimization
wshobson
Optimize Bazel builds for large-scale monorepos. Use when configuring Bazel, implementing remote execution, or optimizing build performance for enterprise codebases.
github-actions-templates
wshobson
Create production-ready GitHub Actions workflows for automated testing, building, and deploying applications. Use when setting up CI/CD with GitHub Actions, automating development workflows, or creating reusable workflow templates.
monitor-ci
nrwl
Monitor Nx Cloud CI pipeline and handle self-healing fixes. USE WHEN user says "monitor ci", "watch ci", "ci monitor", wants to track CI status, or needs help with self-healing CI fixes
nx-run-tasks
nrwl
Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
customerio-deploy-pipeline
jeremylongshore
Deploy Customer.io integrations to production. Use when deploying to cloud platforms, setting up production infrastructure, or automating deployments. Trigger with phrases like "deploy customer.io", "customer.io production", "customer.io cloud run", "customer.io kubernetes".
prowler-ci
prowler-cloud
Helps with Prowler repository CI and PR gates (GitHub Actions workflows). Trigger: When investigating CI checks failing on a PR, PR title validation, changelog gate/no-changelog label, conflict marker checks, secret scanning, CODEOWNERS/labeler automation, or anything under .github/workflows.