Skip to main content

Triggers

Triggers come with the Celeris desktop app, with nothing to switch on. The Mac App Store version does not include them.

A trigger is a saved way to start a session. It packages everything you would otherwise retype into the first prompt: the intent, where it runs, the standing context, and what to capture at the moment you pull it. All of that sits behind a single click or key.

Pulling a trigger starts an ordinary session whose first turn is that package. Nothing else changes. Same tools, same approvals, same history.

What a trigger holds​

  • Intent. The prompt. It can be fully specific ("file a bug for what I'm looking at, in the Celeris project") or a bare verb ("report an issue about the active app").
  • Working folder. Where the session runs.
  • Standing context. Text baked into the trigger, such as conventions, team norms, or how to find a version number.
  • Live captures. A fresh screenshot, the active app, or the clipboard, resolved when you pull the trigger rather than when you saved it.

Creating one​

There are two routes. To build a trigger from scratch, open the trigger bar (Cmd/Ctrl+Shift+B) and create one there. To build one from a session that already worked, choose Save as trigger in your history. The prompt and the folder come across already filled in.

Pulling one​

  • Click it in the trigger bar.
  • Type /trigger in the composer and search by name.
  • Give it a global hotkey and pull it from anywhere. Celeris's built-in hotkeys are reserved and cannot be reassigned to a trigger.

A trigger can open in whichever surface suits it. It can run immediately, open in mini mode, open the full window, or prefill the composer so you can adjust the prompt before sending.

New triggers send automatically by default. In the trigger editor, turn off Send prompt automatically when clicked when the prompt is a template that needs your input or review first. Two things still open the composer even with the box ticked, because the prompt cannot be sent as written: a prompt with an {input} slot, and an input field marked required. An optional one-liner does not, so with the box ticked the trigger sends.

Editing and removing​

Triggers live on the device that made them. Edit or delete them from the trigger bar. Changes take effect on the next pull.

Event-started triggers​

A trigger you pull is one you start yourself. An event-started trigger is the same saved task with something other than you starting it. (These were called Hooks in earlier builds.)

A file lands in a watched folder and gets filed. Nine o'clock comes round and the overnight failures get summarised. Something happens, and the follow-on work has already happened by the time you look.

How one is put together​

An event-started trigger is a trigger with an event start, so you build it in the same place: Settings → Tools → Triggers. Give it the instruction, the working folder and the context as usual, then add the event that should start it.

The event sources available today are:

  • A schedule. Every weekday morning, every hour, the first of the month.
  • A file appearing. A path on this computer is watched, and the new file becomes the context of the task.

A connected service can add its own events where it supports them, and those appear alongside these once the connector is set up.

What happens when it fires​

An ordinary Celeris session starts. It gets your saved instruction, plus what the event carried, the file that appeared or the payload the service sent, and runs with whatever tools are available at that moment.

That session is a normal session in every way that matters. It appears in your history, it can be read, interrupted and continued, and it obeys the same approval rules. An event start is a reason for a task to begin; it is not permission for that task to do more than you would have allowed. Anything that writes, sends or deletes still stops and asks, so a trigger that fires while you are away leaves a question waiting rather than a mess.

Event payloads are data. Text arriving in a webhook or a filename is not read as an instruction to Celeris, however it is phrased.

Keeping an eye on them​

All the runs of one event-started trigger are collected into a single row in your history, rather than scattering a new entry across the list every time it fires. Open the row to see the individual runs, what each one did, and which ones needed you.

From the trigger itself you can send a test event to see what a run would look like, pause it without deleting it, and resume it later. Pausing is the right move for a trigger that has started doing the wrong thing: it stops firing and keeps its definition, its history and its approval record.

Where they belong, and where they do not​

Event-started triggers are for quiet, repetitive work with a clear starting event. They are a poor fit for anything that needs a decision about whether it should happen at all. That is what Lex is for, which proposes rather than starts.

They are also local to the device that runs them. One watching a folder watches that computer's folder. Scheduled ones follow your account between signed-in devices by name, instruction and schedule; their run history and approvals stay on each device.