MUST use when configuring triggers.
60
68%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Low
Low-risk findings worth noting
Fix and improve this skill with Tessl
tessl review fix ./system_prompts/auto-generated/skills/triggers/SKILL.mdTriggers allow external events to invoke your scripts and flows.
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.yamlAn 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).
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.
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.
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 pull33d2845
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.