triggers

• SKILL.mdcore · 16,242 bytes

# Self-Starter

A trigger is a small probe program that checks something, rules for when the result counts as "it happened", and what to do then. A background service runs the probe on a schedule and evaluates the rules; no model is involved until the trigger fires. Then the task goes to Codex: back into the thread where the trigger was created, or into a thread dedicated to the trigger.

## Creating a trigger

1. **Clarify first**, in one short question if anything important is ambiguous: the exact condition (intraday price or close? which log line means done?), how quickly the user needs to know, whether to act once or every time, and what should happen when it fires: only a notification, or a task for Codex (which one?).
2. **Check the ready-made recipes** with `trigger_recipes`. If one fits, use it: pass `recipe` to `trigger_draft` with only its parameters, and skip writing a probe.
3. **Otherwise, find where to look.** The probe runs on the user's machine with their permissions, so it can read files and logs, run the commands and CLIs the user has (`git`, `gh`, `docker`, the scripts of another skill), talk to local services, or call web APIs. Prefer output that is already structured: a JSON API, a command with `--json`. If an API key is needed, ask the user to store it in a terminal with `self-starter secret set NAME`. Never ask for a key in the chat, and never put one in the code or the params.
4. **Write the probe and the definition** following the contract below.
5. **Call `trigger_draft`.** It checks everything, saves the draft and runs the probe once. If the trial run fails or its result looks wrong, fix it and call `trigger_draft` again.
6. **Decide whether to ask before starting it.** A trigger keeps running on its own, possibly for weeks. Ask first, in one or two sentences (what it checks, how often, what you will do when it fires, then "Start it?"), when the task acts for the user when it fires (changes files, runs commands with side effects, sends messages, places orders), when it checks often or for a long time, or when the request left room for interpretation. When the user asked for exactly this and it only tells them or reports back ("let me know when the build finishes"), start it right away and say what you set up. Either way, mention warnings that matter, such as "the condition already holds, so it will fire right away".
7. **Call `trigger_activate`** with the draft id.