Schedule recurring work

Scheduled jobs are how you keep working while the owner is not talking to you: the Monday report, the daily check of a supplier portal, the reminder before a deadline. Each run starts fresh, with no memory of the chat that created it, so the job has to carry everything it needs. The standard: every job has a clear name, the right time in the owner's time zone, a prompt that would make sense to a stranger, output only when there is something worth reading, and the owner knows it exists and how to stop it.

When to use

• "Send me a sales summary every Monday at 8."
• "Remind me to renew the domain two weeks before it expires."
• "Check the supplier portal every morning and tell me if an invoice is overdue."
• "On the first of each month, download the statements and file them."
• "Keep an eye on this page and tell me when the price changes."

What you need

• What the job does and what a useful result looks like.
• When: time, days, frequency, start and end, and the owner's time zone (check memory; ask if unknown). Schedules follow the time zone configured for the OS, so confirm the two agree.
• Where results go: this chat (the default), saved only, or the owner's connected channels.
• What counts as nothing to report, so the job can stay quiet.
• Permissions: a scheduled job runs unattended. It may read, check, draft, file and report. It must not send, post, pay, submit, delete or accept anything unless the owner gave an explicit standing OK for exactly that action, in their words, which you save with memory and quote in the job prompt.

Method

1. Check what already exists. cronjob with action: "list", and scope: "team" to see teammates' jobs. Update an existing job instead of creating a near-duplicate; never guess a job id, take it from the list.

2. Choose the schedule.

   Owner says	schedule
   every 30 minutes	30m
   every 2 hours	every 2h
   weekdays at 9:00	0 9 * * 1-5
   Mondays at 8:30	30 8 * * 1
   1st of the month at 9:00	0 9 1 * *
   every 15 min in working hours	*/15 9-17 * * 1-5
   once, on a date	2026-11-01T09:00:00 (one-shot)
   Cron fields are minute, hour, day of month, month, day of week (0 or 7 is Sunday). "Last day of the month" has no cron form: run daily at the time on days 28 to 31 and have the prompt exit quietly unless tomorrow is the 1st. Avoid exact hours that everyone uses (pick 8:07 rather than 8:00) and the 01:00 to 03:00 window on daylight-saving change nights. Use repeat to stop after a number of runs.

3. Write the job prompt so a stranger could run it. Include:

   • Who you are and the goal: "You are Ada, the owner's operations assistant. Goal: ..."
   • Exact inputs: file paths, which connected app or signed-in site, which skills to load (skills).
   • Steps in order, with the checks.
   • The output format, short, starting with the answer.
   • The quiet rule: "If nothing is overdue, reply exactly: No overdue invoices." (or use monitor so the job only wakes on change).
   • The limits: what it must never do (send, pay, delete) and what to do instead (draft, report).
   • It cannot ask questions: "If something is unclear or access fails, report the problem in one line and stop." Examples in references/job-prompts.md.

4. Pick the options.

   • monitor: an http(s) URL checked each tick at no model cost; the job only runs when the page output changes. Good for "tell me when this page changes". The output must be stable (no timestamps), or every tick looks like a change.
   • continuity: true: each run sees the previous run's output, so digests do not repeat items.
   • context_from: chain jobs (one collects, the next reports).
   • deliver: omit for this chat; local to save without posting; all for every connected home channel.
   • skills: the skills the run should load, for example ["clean-and-analyse-data"].
   • script and no_agent run a script from the OS's scripts folder (named in the tool's description), not from your own computer. Prefer a prompt job unless the owner has set up such a script.

5. Create, then test once. action: "create" with name, schedule, prompt and the options. Then action: "run" with the job id to fire it now; the result comes back by itself, so carry on with other work rather than polling. Read the output as the owner would and adjust the prompt with action: "update".

6. Tell the owner and record it. One line per job: name, when in plain words with time zone, what they will receive, how to stop it ("say 'stop the Monday sales job'"). Save the job id and purpose with memory.

7. Look after the jobs. Pause (pause) jobs the owner is away from; remove (remove) temporary ones when done; once a month, list jobs and ask whether each is still read. A job nobody reads costs money and buries real alerts.

Output

Scheduled: [name] (id [job id])
When: [plain words, e.g. every weekday at 8:07, London time]; first run [date and time]
Does: [one line]
You'll get: [what and where; "nothing" when there is nothing to report]
Never does: [send / pay / delete], it drafts and reports instead
Stop it: tell me "[stop phrase]"

Checks before you finish

• No duplicate of an existing job (yours or a teammate's).
• Schedule tested against the owner's words and time zone; one-shot dates in the future.
• The prompt names every path, account and skill it needs, and has a quiet rule and a no-irreversible-actions rule.
• A test run produced the output you expected.
• The owner has been told what will run, when, and how to stop it; job id saved in memory.

Pitfalls

• Prompts that rely on the chat ("do the usual report"). The run has no chat history; spell it out.
• Time zone slips. A job set for 9:00 server time can land at 4:00 for the owner. Confirm the zone and state it.
• Too frequent. Every 5 minutes is rarely needed; every run costs. Match frequency to how fast the owner would act.
• Noisy jobs. Daily "nothing new" messages train the owner to ignore you. Use the quiet rule or monitor.
• Unattended irreversible actions. No standing OK, no sending, paying, posting or deleting from a job.
• Silent breakage. Sign-ins expire and pages change. Make the prompt report access failures plainly, and check the job after its first few runs.

See also: status-updates-and-handoffs (what a weekly update should say), get-tasks-done-in-browser (scheduled portal checks), meeting-notes-and-actions (action reminders).