| name | local-schedule |
| description | In-session scheduling via CronCreate. For "at <time>", "in <duration>", "remind me", "tomorrow". Defer to /schedule for remote. |
local-schedule
Route time-anchored task requests to CronCreate instead of the remote /schedule skill.
When to use this vs /schedule
| Task needs… | Tool |
|---|
| Files / processes / cwd / state from THIS session | CronCreate (this skill) |
| To survive Claude restart | CronCreate with durable: true |
| To run as a remote agent independent of this session | /schedule |
| "Every Nm run /slash-cmd" — bare slash-command on an interval | /loop (tighter match for that exact pattern) |
| Pure prompt with no local dependency, user didn't specify | CronCreate (default — cheaper, faster, no remote spin-up) |
If unsure, prefer CronCreate. Local scheduling can do everything /schedule can do for an idle session; the reverse is not true. The exception is /loop — it's purpose-built for repeatedly invoking a slash command, so when the user's phrasing is essentially every <interval> /<command>, defer.
How to schedule
Call CronCreate directly. The tool's own description has the cron syntax and runtime details — read it before composing the call. The pieces that matter most:
- 5-field cron in local time. No timezone math.
0 9 * * * is 9am wherever the user is.
- One-shots use
recurring: false with minute/hour/day-of-month/month all pinned. For "at 22:00 today": resolve today's date, build MM HH DOM MON *, set recurring: false. The job auto-deletes after firing.
- Recurring uses
recurring: true (the default) and auto-expires after 7 days. Tell the user about the 7-day cap when they ask for an open-ended recurring job.
- Off-minute discipline. When the user's time is approximate ("around 9", "hourly", "in an hour"), pick a minute that is NOT
0 or 30. Every model defaults to :00 and the fleet collides. Use 57 8 * * * or 3 9 * * * for "around 9am", 7 * * * * for "hourly". Only honor :00/:30 when the user names that exact time.
durable: true only when the user explicitly asks the task to survive a session restart. Default in-memory mode is correct for "tonight" / "tomorrow morning" / "every 5 min for a while".
Resolving relative times
The user's prompt-submit hook injects the current wall clock as Message time: YYYY-MM-DD HH:MM:SS Weekday. Use that as the anchor — do not guess.
- "in 30 minutes" → add 30 min to message time, pin the resulting minute/hour/dom/month,
recurring: false.
- "tonight at 10" → today's dom/month,
0 22 ... (user named :00 exactly, so :00 is fine).
- "tomorrow morning" → tomorrow's dom/month, pick
57 8 or 3 9, recurring: false.
- "every weekday at market open" →
28 9 * * 1-5 (off-minute; user can correct if they meant 9:30 sharp).
If the message-time hook is absent, ask the user for the current time rather than guessing — cron mistakes are silent until the fire moment.
What to put in the prompt field
The prompt fires as a fresh user turn in this session at fire time. Write it as if the user just typed it: enough context that the model can act without re-reading scrollback. Example:
- User says: "at 22:00 run the regression test on the branch I just pushed"
- Prompt:
Run the regression test on branch <name> that we pushed at <time>. Logs go to <path>. Report pass/fail and any new failures vs main.
Don't write "do the thing we discussed" — fire-time context is just this session's history; the model can read it but a self-contained prompt is more reliable.
After scheduling
Tell the user, in one line: what was scheduled, the resolved fire time in their local clock, and the cron expression you used. They need to see the cron string to catch a misread time. Save the returned job ID if you might need to cancel it later (CronDelete).
When to defer to /schedule instead
Hand off to /schedule only when the user explicitly indicates one of:
- The task must run after this Claude session ends and
durable: true isn't enough (e.g., they want it on a true cron schedule for weeks/months).
- The task should run in a clean remote environment — fresh checkout, no local mutations, no in-flight session state.
- They literally say "schedule it remotely" or "use /schedule".
In those cases, mention you're switching to /schedule and why, so the user can correct you if the locality assumption was wrong.
