delay

name	delay
description	Schedule instructions to run ONCE at a later time in the current session, via a one-shot in-session cron job (CronCreate with recurring: false). Use when: (1) User invokes /delay, (2) User says 'in N hours/minutes do X', 'schedule X for later', 'do this at 16:30', 'remind me in an hour to X', or any other one-shot delayed-execution request. NOT for recurring intervals (use /loop) and NOT for schedules that must survive closing the terminal (use a cloud Routine — the Claude Code Remote `create_trigger` / `send_later` MCP tools, which persist server-side). This skill only schedules — it never executes the instructions immediately.
argument-hint	<time spec>, <instructions>

Delay

Schedule the given instructions to fire exactly once at a future time in this session. Scheduling is the entire task of this turn — do NOT start executing the instructions now, even partially. That is the failure mode this skill exists to prevent: the task running immediately AND again at fire time.

Arguments: $ARGUMENTS

Steps

1. Parse arguments. Split at the first comma: everything before it is the time spec ("1 hour later", "in 30 min", "at 16:30", "tomorrow 9am"), everything after is the instructions to run later (pass through verbatim — including slash commands like /x-wt-teams foo bar). If either part is missing or the time spec is ambiguous, ask instead of guessing.

2. Compute the fire time. Run date '+%Y-%m-%d %H:%M' for the current local time, then compute the target:

• Relative spec → add the delta to now.
• Absolute spec already past today → assume the next occurrence (tomorrow).
• Handle rollover: adding hours may cross midnight or month boundaries — the pinned day/month must match the actual target date.

3. Create exactly one job with the CronCreate tool:

• cron: fully pinned "M H DOM MON *" for the target time. Use the exact computed minute — don't round to :00/:30 (the harness fires those up to 90s early, and round marks cause fleet-wide load spikes).

• recurring: false. This makes the job auto-delete after firing. A recurring job (the default) stays alive and can fire again — the double-invoke bug.

• prompt: prefix the instructions so the future turn knows it is a scheduled firing, not a fresh request to schedule:

  [One-shot task scheduled earlier via /delay, firing now as planned. Do not reschedule or delay again — execute directly:]
  <instructions verbatim>
  

4. Confirm to the user (and stop — no other tool calls after this):

• The exact fire time and job ID (cancelable via CronDelete by ID).
• The session must stay open — the job is in-memory and dies silently if Claude Code exits.
• The job fires only while the session is idle, so it may start a bit late if work is in progress at the target time.

Guardrails

• Exactly one CronCreate call per /delay invocation. Don't add wakeups, loops, or Monitor tasks alongside it.
• Never run any part of the instructions in the scheduling turn — not even "harmless prep" like a git pull.
• If the user actually wants a recurring cadence, hand off to /loop; if they need it to survive terminal close, hand it off to a cloud Routine (the Claude Code Remote create_trigger / send_later MCP tools), which persists server-side instead of dying with the session.