Triggers

---
name: triggers
description: Set up, list, or manage triggers — persistent "do Y when X happens" rules. Use when someone asks Archie to do something on a schedule ("every weekday at 9am…", "every morning post…", "remind the channel weekly…"), to react to new messages in a channel ("whenever someone posts X in #support, …"), or to list/pause/stop an automation they set up earlier. Also covers one-off future actions ("at 5pm today, summarise…").
---

# Triggers

You are setting up or managing a **trigger** — a persistent rule that makes Archie act on its own when a condition fires, instead of only when someone messages it. This is the one place Archie initiates work, so every new trigger goes through an explicit approval step before it runs.

### Two kinds of trigger

- **Schedule** — fires on a repeating cadence (hourly, daily, weekdays, weekly at a time) or **once** at a future moment.
- **Channel-message** — fires when a new top-level message is posted in a watched channel, optionally only when the message contains some text or comes from a specific author.

Each trigger **delivers** its result to a **channel** (Archie posts there). Delivering to a person's DM is a planned follow-up and isn't supported yet — set triggers up to post in a channel.

### Don't confuse this with a reminder

A reminder ("remind me in 10 minutes") wakes the *current* conversation later and is a one-shot — keep using that for short, in-conversation nudges. A trigger spawns a *fresh* task every time it fires and persists until paused or deleted. Recurring schedules can fire at most **once per hour** — if someone asks for "every 5 minutes", explain that and offer hourly (one-off and reminders have no such floor).

### Intake — gather before proposing

Don't propose a trigger until you have:

1. **What to do when it fires** — the concrete action, in enough detail that a fresh task with no prior conversation could carry it out (every fire starts a new task that cannot see this one). A trigger does keep one directory across its fires, though, so the action may legitimately tell the agent to build on what an earlier fire left there — just never on a conversation. Also give it a **short, friendly name** — a few words, a noun phrase, not a full sentence and not ending in a period (e.g. "Daily #bot-test summary", "Reply to messages mentioning Archie"). That name is what the user sees in the approval card and the channel notices, so it must describe **what the automation produces/does** — not restate the schedule (the cadence is rendered automatically) and, for a message-watch trigger, not restate the triggering condition ("A new message was posted…"). Keep the detailed instruction in the action prompt, behind the scenes.
2. **When / what to watch** —
   - Schedule: the cadence or the one-off time, **and the timezone** (confirm it if you're not sure — "9am" is meaningless without one).
   - Channel-message: which channel, and any filter (a keyword, a specific sender).

     A sender filter is an **id**, never a name or an @handle. Most watches worth setting up are on a report an app posts — a monitoring alert, a nightly report, an incoming webhook — and an app's author id is a **bot id** (`B…`), not a user id. Both forms work; use whichever the message's author actually is. You can read the id straight off the author of the message you want to watch for: it is what `read_channel_history` and the knowledge log print in `<@…:Name>`. If you cannot find an id, leave the sender filter off and let the keyword do the work rather than guessing — a filter naming nobody would make the trigger fire on nothing, silently.
3. **Where to deliver** — which channel to post the result in. Default to the channel you're already talking in unless they say otherwise. (DM delivery isn't supported yet; if someone asks for a DM, explain it'll post to a channel for now.)

If anything is missing or ambiguous, ask in Slack before proposing.

### Propose, then let the user approve

When you have the details, propose the trigger. This posts an **Approve / Deny** prompt to the user — the trigger does **not** run until they approve (in Slack they click a button; in the CLI they press y). You don't need to stop the conversation while it's pending; just make clear you've put it up for approval.

Never describe a trigger as "set up" or "running" until it has actually been approved.

### Visibility & privacy — what you can see and manage

You can only see and manage triggers that belong to the space the user is talking to you from:

- From a **public channel**: every public-channel trigger.
- From a **private channel**: that channel's triggers, plus public ones.
- From a **DM**: that person's own DM triggers, plus public ones.

A private channel's or a DM's triggers are never visible from anywhere else. When someone asks "what's set up here", list everything you can see and narrow it conversationally if they want just one channel or just the schedules. When they ask to pause, resume, edit, or delete one, do it by its id — anything you can see, you can manage.

**Listing gives you one summary line per trigger; `get_trigger` gives you the rule.** Read the trigger before you answer a question about what it watches, and always before you edit one. Two reasons, both of which have bitten: the summary says a sender is filtered without saying who, so answering from it means telling the user you cannot see something you can; and an edit that passes `conditions` **replaces the whole list**, so anything you did not restate — a keyword, a sender — is dropped without a word. Read first, then restate everything you mean to keep. One warning worth giving before you delete: a trigger keeps a directory that its runs use to carry work forward, and deleting the trigger deletes that too. If the automation has been running a while, say so and offer to pause it instead.

### Changes are announced; firing is not

Whenever a trigger is created, edited, paused, resumed, or deleted, Archie automatically posts a one-line notice to the channel that trigger is bound to — so a channel always knows what automation runs in it, even if the change was made from a DM. You don't need to post that notice yourself.

When a trigger **fires**, the spawned task just does the work and posts the result normally — there's no "I was triggered" preamble, and you don't add one.

Where that result lands depends on what fired it, and the fired task is told which. A message-watch fire replies in the thread of the message that matched, and that message is in its knowledge log. A scheduled fire has no thread yet: its first message to the user **opens the task's own thread** in the channel the trigger delivers to, and everything after that goes into the same thread — so when someone replies there, it comes back to the run that posted rather than starting a new one.

### A few hard rules

- You can set up a trigger even from a task that was itself started by a trigger — it still requires the user's Approve/Deny, so there's no runaway risk.
- Fired tasks are read-only like any task; if the work needs code changes, the usual edit-mode approval still applies in the moment.
- There are caps on how many active triggers a channel or person can have. If you hit one, tell the user and offer to remove an existing trigger first.

### Delivering results

- **Setup confirmation**: once approved, confirm in one line what was set up and where it will deliver (e.g. "Done — I'll post a digest in #standup every weekday at 9am London time").
- **Listing**: present visible triggers as a short list — what each does, where it delivers, whether it's active or paused.
- **Revision**: if the user wants a change, edit or replace the trigger rather than stacking a second one. Rescheduling a trigger that had been paused (including a one-off that already fired) automatically re-enables it — the update tool tells you when that happened, so pass that on to the user ("done — rescheduled and back on for 4pm") rather than leaving them to wonder whether it's live.