Menü
Create, edit, validate, and test ZDX automations stored in `$ZDX_HOME/automations/*.md`. Use when users ask to add or modify automation files, recurring jobs, scheduled prompts, or YAML-frontmatter automation definitions.
| name | automations |
| description | Create, edit, validate, and test ZDX automations stored in `$ZDX_HOME/automations/*.md`. Use when users ask to add or modify automation files, recurring jobs, scheduled prompts, or YAML-frontmatter automation definitions. |
Create and maintain ZDX automation files.
An automation is a headless agent that runs unattended — no human in the loop. It always produces a visible effect (a report, a message, a file, a PR). It must handle errors on its own: retry, degrade gracefully, or report what failed. Every automation is a single markdown file with YAML frontmatter and a prompt body.
$ZDX_HOME/automations/ (usually $HOME/.zdx/automations/).id field).
~/.zdx/automations/morning-report.md → morning-report.---.schedule (string, optional cron)model (string, optional)timeout_secs (int, optional, must be > 0)max_retries (int, optional, default 0)Do not add extra keys unless explicitly requested.
Include only the instructions needed to execute the task.
Use explicit expected output shape (sections/bullets/constraints) so runs are easy to review.
Only modify automation files and only the fields needed for the request.
Every run must produce something the user can see — a thread entry, a message, a file. If the main output fails, produce a degraded result that explains what happened.
Prompts must say what to do when there's nothing to report (e.g., "If no PRs are open, return: No open PRs today."). Never produce a blank run.
When external delivery is needed, reference specific skills/tools (e.g., gog for email, wacli for WhatsApp). Don't reinvent what a skill already does.
When prompt instructions involve external systems, prefer staged steps with clear checkpoints and fallback behavior.
ZDX persists automation output to the automation run thread by default.
Delivery section only when external notification/delivery is requested or implied (email, WhatsApp, Telegram, Slack, file, PR, etc.).Secondary: none.When updating an existing automation, preserve its delivery behavior unless user asks to change it.
For detailed delivery patterns (Telegram topics, shell reliability, multi-channel fallback), see references/delivery-patterns.md in this skill directory.
| Command | Description |
|---|---|
zdx automations list | List discovered automations (name, source, schedule) |
zdx automations validate | Validate all automation files (frontmatter + body) |
zdx automations run <name> | Run one automation by file stem (manual trigger) |
zdx automations runs [name] | Show run history (oldest first). Supports --date, --date-start, --date-end, --json |
zdx automations daemon | Start the scheduled automations daemon (optional --poll-interval-secs, default 30) |
Reading latest run output: zdx automations runs <name> | tail -1 to get the latest run, then use the thread ID to read results.
| Pattern | When to use | Key trait |
|---|---|---|
| Report | Summarize data on a schedule | Read-only, structured output |
| Action | Change something (create PR, update file) | Side effects, status reporting |
| Artifact | Generate/update a file or document | File path + validation in output |
zdx automations validate
If user asks to test:
zdx automations run <name>
Review output, tighten constraints, adjust model/timeout if needed.
Headless prompts differ from interactive ones: there's no human to ask for clarification. Every prompt must be self-contained.
Write prompts as executable runbooks with these sections:
references/delivery-patterns.md.Every headless prompt should address:
[GitHub unavailable]."Nothing to report."Default policy (use unless user specifies otherwise): continue with available data, clearly state what failed.
When automations need external tools, reference the correct skill:
gog skill (Gmail)wacli skillapple-reminders skillscreenshot skillDon't hardcode API calls when a skill exists.
model (uses system default).model: "gemini-cli:gemini-3.1-pro-preview" or similar.model: "stepfun:step-3.5-flash" or model: "mimo:mimo-v2-flash".model when the default won't work well for the task.See references/examples.md for full examples: daily thread summary (report, scheduled), PR drafter (action, manual), weekly email digest (report + delivery, scheduled).
See references/templates.md for starter templates: scheduled automation and manual-only automation.
$ZDX_HOME/automations/ unless explicitly requested.Before finishing, ensure:
$ZDX_HOME/automations/<name>.mdDelivery block includes target + policy + fallbackzdx automations validate was runAdd, update, or remove models and providers in the zdx LLM registry. Use when the user asks to add a new model, add a new provider, update model pricing or context limits, regenerate default models/config, or says things like "add support for X model", "add the new Y provider", "update pricing for Z", "regenerate models", or "run models update".
Explore options and pick a direction before committing to a goal or plan. Use when the user wants to think through approaches, weigh trade-offs, or decide between alternatives — not yet ready to define success criteria or slice work. Hard rule: no code, files, or implementation until the user explicitly approves a direction.
Shape a fuzzy intention into a concrete, measurable goal with explicit success evidence before starting work. Use when the user asks to define a goal, clarify success criteria, sharpen an objective, or turn "make X better" into something verifiable. Useful as a quick pre-step before planning, debugging, performance work, research, or operations work.
Create a ship-first (ship-shaped) implementation plan with demoable MVP slices. Use when a user asks for an implementation plan, MVP plan, shipping plan, or wants to break down a feature into incremental, demoable slices. Emphasizes user journey order and daily-usable increments over polished completeness.
Use for memory-related tasks: saved notes, factual questions that may already be documented, and saving durable information. Prefer Memory_Search and Memory_Get for discovery; use this skill for routing, note-saving, and filing conventions.
Generate and edit images. Outputs PNG files. Use when the user wants any visual creative output, an image generated from a description, or wants to modify an existing image in any way — editing, transforming, or adding visual elements.