A recurring-task prompt is a saved instruction that runs again when a scheduler invokes it. Specify the user decision it serves, its cadence, the permitted data scope, the output artifact, and a stopping condition. 'Keep an eye on shipments' is not an executable contract: the task could check once, monitor every minute, or send a message after every unchanged run. Separate the schedule from the task body. The scheduler decides when to invoke; the prompt decides what to inspect and how to report a result. Confirm that the named dataset and destination will still be available on later runs.
Recurring prompts: define the trigger and stop condition
Operational case
A fictional depot manager wants a morning review of held parcels for North Pier. The run compares the current held set with the prior confirmed snapshot and flags new holds, released holds, and records whose status cannot be verified. It stops after the 30-day pilot or when the manager cancels it. The prompt names the North Pier depot and limits itself to read-only shipment data. It does not infer permission to rebook shipments or contact customers from the word 'review'.
Task: review North Pier held parcels at each scheduled run.
Window: current snapshot against last confirmed run.
Output: changed records, unresolved records, run time, and evidence IDs.
Stop: end of 30-day pilot or manager cancellation.
Allowed: read shipment status. Forbidden: rebook or notify customers.Performance and operating cost
A run over N shipment records costs O(N) for a full comparison, or O(C) when a trustworthy change feed exposes C changed records. Retaining a small prior snapshot has O(N) storage cost; this must be weighed against missing changes when the feed is incomplete. A vague schedule can create unbounded model calls and duplicate notifications. Bound both run frequency and the period for which the task remains active.
Common Mistakes
- Do not convert 'check tomorrow' into an indefinite daily task.
- Do not treat a reporting instruction as permission to change shipments.
- Do not omit the end condition for a pilot workflow.
Connected lessons
- Prompt engineering applications
- Prompt Engineering
- Prompt engineering: define a task that can be checked
- Clarification gates: ask only when a missing fact changes the outcome
- Tool calls: validate intent and arguments before an external effect
- Recurring prompts: bind local time and data windows
- Recurring prompts: validate fresh inputs and empty states
- Recurring prompts: survive retries without duplicate effects
- Recurring prompts: notify only on actionable changes
- Recurring prompts: renew authority for sensitive actions
- Recurring prompts: make every run replayable and auditable
- Project: build a North Pier recurring review
- Recurring prompt workflow decisions
Continue with: Calendar prompts: scope recurrence changes to the right instances.
