Reminders & watchers
Ask in plain language — “remind me at 9”, “tell me when the deploy finishes”, “watch this folder” — and Briglia builds the right kind of reminder. This page explains the three kinds and the rules behind them.
1 · Time reminders — “remind me AT”
A one-shot local date-time, or recurring: daily, weekly, monthly, weekdays, weekends, every_X_minutes, every_X_hours, or specific days of the week. When it fires, Briglia wakes up with your instruction and acts — a message, a check, a task.
2 · Scripted watchers — “tell me WHEN”
Briglia writes a small shell script that checks a condition, and runs it on a schedule (at least every 5 minutes). The contract keeps them cheap and quiet:
- The script prints only new events and nothing when there is no news — empty output means silent reschedule, no message, no model cost.
- It gets a private state file (
$WATCHER_STATE) to remember what it has already reported; the first run records a baseline and stays silent. - 60-second timeout per run; a non-zero exit or timeout counts as a failure, and three consecutive failures pause the watcher (ask Briglia to resume it once fixed).
- Before registering, Briglia runs the script twice against the real state file and rejects it if the second run isn't clean.
- The stored script is hash-verified before every run — editing the
.shin place stops the watcher with a tamper error; delete and recreate instead. - Watchers can only be created in turns you started, and Briglia announces every new one.
3 · External triggers — “when this program says so”
A watcher with no schedule and no script: it fires when any local process runs
briglia trigger <watcher-id> [payload]Briglia gives you the exact command when it creates the watcher. Use it from cron, a CI job, a git hook, a smart-home script — anything. Events survive daemon restarts and can be posted while Briglia isn't running; up to 500 queue per watcher. An event after 5 quiet minutes fires immediately; a burst within 5 minutes is delivered as one batched fire. Payloads are capped at 2,000 characters and treated as untrusted data.
Who gets woken up: triage
By default every fire wakes the main Briglia (notify: main). For noisy sources, route to a triage subagent instead: subagent (a dedicated one) or subagent:<name> (a shared session — give related watchers the same name, e.g. infra, so one agent correlates across them). The triage agent has read-only tools (read, grep, list — no shell, no writes, no sending), follows your triage instructions, and answers SKIP or NOTIFY; only NOTIFY reaches you. Failures and pauses always reach the main agent regardless of routing.
Pick the triage model per watcher: inherit (your main model), cheap-vision or cheap-text — lanes you configure once with /subagentmodels. A shared group runs one lane for all its members.
Scripted watchers restored from a Mind backup arrive paused and quarantined — a backup can contain shell programs. Only you can re-arm them, by typing /resumewatcher; Briglia cannot.
Managing
Just ask: “list my reminders”, “delete the deploy watcher”, “route the log watchers to a shared triage session called infra”. Briglia uses its manage_reminders tool (set / list / delete / resume / update_triage). Everything lives in ~/.local/share/briglia/reminders.json and reminder-scripts/.