schedule-recurring-check · git:20260615.82ecab1 · 2026-06-15 · sha256 2bb96f8fa08a32a2
schedule-recurring-check git:20260615.82ecab1A
Immutable. This exact content is served forever at /api/v1/blob/2bb96f8fa08a32a2.
---
name: schedule-recurring-check
description: Set up a recurring check that only does work (and spends tokens) when there's something new — e.g. "every hour, check BuildBetter for new calls".
---
The user wants a recurring check. Design it as a CHEAP probe that only acts on a delta — never a blind poll that burns tokens on an empty result.
1. Pin down three things:
- WHAT to check (which tool/source — e.g. a BuildBetter search, a Linear query, an MCP tool via `run_mcp_tool`).
- HOW OFTEN (a fixed interval, or a daily time).
- What "new" means here — the cursor that separates old from new (a since-last-run timestamp, an id you haven't seen, a count that changed).
2. Create it with `schedule_message`:
- `prompt`: a SELF-CONTAINED instruction that, when it fires, will:
(a) fetch only items newer than the last check (use the cursor),
(b) if there is NOTHING new → reply with a single short line like "nothing new" and STOP (don't elaborate, don't call more tools),
(c) only if there IS something new → summarize it and/or take the action the user asked for.
- `intervalSeconds` (recurring every N seconds) OR `dailyAt` "HH:MM".
- Leave `channel`/`target` default so the result returns on the user's channel.
3. Confirm back: what you scheduled, how often, and how to stop it (`list_cron_jobs` to find the id, then `cancel_cron_job`).
Principle: react to deltas, not to the clock. The fired prompt must short-circuit cheaply when nothing changed — that's what keeps an idle agent at ~$0.
User asked: {{input}}