Scheduled Task Ops

Design, operate, audit, and clean up Claude Code scheduled work. Use this skill for /loop, session-scoped cron wakeups, CronCreate, CronList, CronDelete, ScheduleWakeup, Desktop scheduled tasks, cloud/Routines scheduling, and deciding when another control surface is safer. [DOC]

Treat current Claude Code documentation and the local claude --version output as runtime authority. If a tool schema, command flag, surface, or installed version cannot be verified, state coverage_gap rather than guessing. [DOC][INFERENCIA]

Use these supporting resources as needed:

• references/scheduled-task-model.md - Session cron model, /loop, ScheduleWakeup, CronCreate, listing/deletion, and prompt/interval combinations. [DOC]
• references/decision-guide.md - When to use scheduled tasks versus Routines, Desktop tasks, GitHub Actions, channels, hooks, /goal, headless claude -p, or background agents. [DOC][INFERENCIA]
• references/safety-cleanup.md - Safety rules, cleanup workflow, idempotency, destructive-action boundaries, and stale task handling. [CONFIG]
• assets/scheduled-task-runbook.md - Operator checklist for creating, inspecting, and closing scheduled tasks. [CONFIG]
• assets/schedule-option-matrix.json - Machine-readable option matrix for examples and audits. [CONFIG]
• assets/cleanup-checklist.md - Focused cleanup checklist before deleting or leaving scheduled tasks behind. [CONFIG]
• assets/source-map.md - Official documentation anchors used by this skill. [DOC]
• scripts/check.sh - Deterministic package check for required files, fixtures, eval coverage, and required scheduling terms. [CONFIG]

Inputs Expected

• Goal: create, list, delete, explain, audit, migrate, troubleshoot, or compare scheduled Claude Code work.
• Runtime surface: current CLI session, Desktop app, cloud/Routines, GitHub Actions, channel trigger, hook, /goal, or headless claude -p.
• Schedule shape: one-shot wakeup, fixed interval, cron expression, polling loop, external event, or condition-driven continuation.
• Prompt payload: autonomous instruction, success criteria, allowed actions, reporting destination, failure behavior, cleanup rule, and escalation boundary.
• Local evidence when available: claude --version, active directory, task IDs, CronList output, hook session_crons, /loop prompt, or Desktop/Routines configuration.

Outputs Expected

• A schedule plan, command/tool plan, cleanup report, or decision recommendation with evidence tags.
• Explicit choice of surface: /loop, ScheduleWakeup, CronCreate, Desktop scheduled task, Routines, GitHub Actions, channel, hook, /goal, or headless run.
• Prompt and interval pairing with expected result handling and failure behavior.
• Safety and cleanup steps, including CronList before CronDelete when the tool surface is available.
• Residual risks and coverage_gap items for unverified version, unavailable task IDs, inaccessible Desktop/Routines state, or missing official docs.

Core Rules

Use /loop for quick polling inside the current CLI session. Keep the prompt small, idempotent, and explicit about when to stop. Treat /loop as session-bound: it is not a durable cloud automation surface, and it is the wrong choice when the task must keep running after the session is abandoned. [DOC]

Use ScheduleWakeup for a one-shot session wakeup when the desired behavior is "resume this session later and run this prompt once," but only after probing that the tool exists in the live session; otherwise treat it as coverage_gap and use a one-shot CronCreate (recurring: false) instead. Pair it with a concrete timestamp or delay, a result destination, and cleanup expectation. [DOC][INFERENCIA]

Use CronCreate for recurring session-scoped prompts when the current tool surface exposes it. Pair every recurrence with a prompt that can run without clarifying questions, a schedule expression or interval, a bounded objective, and a cleanup plan. Use CronList to inspect existing tasks and CronDelete to remove stale or superseded tasks when those tools are available. [DOC][INFERENCIA]

Session crons default to in-memory only (gone when Claude exits). If your CronCreate schema exposes a durability flag, a session cron need not be strictly ephemeral; the concrete flag name and any on-disk path are runtime-specific [SUPUESTO: el flag de durabilidad y la ruta .claude/scheduled_tasks.json no se verifican desde el filesystem del paquete → probar en la sesión viva o declarar coverage_gap]. Local persistence is still not a cloud/Routines surface: it does not run while the machine is off and does not survive uninstalling the project. Persist a session cron only when the user asks the task to outlive the session; prefer Routines/Desktop when the durability requirement is cloud-grade. [INFERENCIA]

Interpret session_crons in Stop-hook input as evidence that the session may be paused for a scheduled wakeup rather than completely finished. Stop hooks can receive cron entries sourced from CronCreate, ScheduleWakeup, and /loop. Do not block a Stop hook indefinitely; respect existing loop-protection behavior and prefer explicit status output. [DOC]

Write autonomous prompts. Include success criteria, files or services to inspect, allowed mutations, reporting channel, retry behavior, and what to do when prerequisites are missing. Scheduled tasks cannot ask a clarifying question at fire time, so missing required context should produce a report or coverage_gap, not invention. [DOC][INFERENCIA]

Choose the hosting surface by durability and access; do not use a scheduled task where a different surface is the right primitive. Cron re-runs a prompt at fixed wall-clock intervals — for "notify me the moment X changes" (log line, file, process, command output) prefer an event-driven monitor that streams events as they happen instead of polling on a schedule, when one is exposed in your runtime [SUPUESTO: la fila Monitor es solo prosa; no figura en assets/schedule-option-matrix.json → confirma la tool en la sesión viva o declara coverage_gap]. The 8 non-Monitor rows below, plus ScheduleWakeup and CronCreate, are machine-readable in assets/schedule-option-matrix.json (10 entries); the Monitor row is prose-only. [CÓDIGO]

Procedure

1. Locate Authority

Identify the active Claude Code surface and version. Prefer official docs, local tool help, claude --version, and actual CronList or hook input over memory. CronCreate/CronList/CronDelete se exponen como tools cuando la sesión los probe (verificado en esta sesión). ScheduleWakeup NO está verificado: trátalo como coverage_gap hasta probarlo en la sesión viva — no afirmes disponibilidad sin probe. Si un tool no está en tu versión, cae a Desktop scheduled tasks, Routines o /loop. State coverage_gap for unknown tool availability, unknown task IDs, inaccessible Desktop/Routines configuration, or unverified cloud state. [CÓDIGO][DOC]

2. Classify The Schedule

Classify the request as one-shot wakeup, recurring cron, short polling loop, durable cloud routine, Desktop local task, CI cron, external event, condition loop, or headless run. Reject ambiguous "schedule this" requests by selecting a conservative default only when the run location and durability are clear. [INFERENCIA]

3. Pair Prompt And Interval

For each scheduled unit, define prompt, cadence, scope, success, failure, reporting, and cleanup. Keep short intervals read-only or low impact. Require stronger guardrails for write-capable or production-impacting intervals. Avoid schedules that can create duplicate PRs, repeated destructive edits, or noisy notifications. [INFERENCIA]

4. Create Or Inspect

Before creating a recurring task, inspect existing tasks with CronList when available or read current Desktop/Routines configuration when that is the selected surface. When creating, capture the task ID, schedule, prompt summary, expected owner, and cleanup condition. [CONFIG]

5. Clean Up

Delete stale or superseded session crons with CronDelete only after confirming the target ID. For /loop, stop or replace the active loop explicitly. For Desktop/Routines/GitHub Actions, close in the owning UI or repository workflow, not by assuming session cleanup removed it. Record retained tasks and why they remain active. [CONFIG]

6. Validate

Apply assets/scheduled-task-runbook.md and assets/cleanup-checklist.md. For package maintenance, run the skill-local, script-relative scripts/check.sh; it works from an installed plugin as well as from a Git checkout. [CONFIG]

Quality Criteria

• The output names the selected scheduling surface and why it fits durability and access needs.
• The output distinguishes /loop, ScheduleWakeup, CronCreate, Desktop scheduled tasks, Routines, GitHub Actions, channels, hooks, /goal, and headless claude -p.
• The output states session-scoped behavior and does not imply /loop or session crons are durable cloud jobs.
• Every scheduled prompt includes success criteria, failure behavior, reporting, and cleanup.
• Existing scheduled tasks are inspected before creating duplicates when inspection is available.
• Cleanup identifies exact task IDs or owning configuration surfaces before deletion.
• Destructive or write-capable recurrence includes explicit confirmation, idempotency, and rollback boundaries.
• coverage_gap is visible when docs, version, IDs, permissions, or owning surface cannot be verified.

Usage

• /scheduled-task-ops
• set up /loop to poll CI every five minutes
• create a Claude Code cron with CronCreate and a cleanup rule
• list and delete stale Cron tasks
• should this be a Routine, Desktop scheduled task, hook, /goal, channel, or headless claude -p job?

Contract

• Aceptación: tarea con condición de parada explícita y cadencia justificada por lo que cambia. [EXPLICIT]
• Límites: programa/operación; no reemplaza un workflow resumible. [EXPLICIT]
• Casos borde: sleep corto mantiene el prompt-cache; sleep largo paga cache-miss [SUPUESTO: el TTL exacto del prompt-cache no es verificable desde el filesystem] — elegir la ventana por comportamiento de cache, no por minutos redondos. Auto-expiry: si tu runtime caduca las recurrentes de CronCreate tras una vida máxima, eso acota sesión y durabilidad [SUPUESTO: ningún horizonte de expiración —p. ej. "7 días"— se verifica desde el paquete → probar en la sesión viva o declarar coverage_gap]; trátalo como coverage_gap y avisa al usuario antes de confiar en una recurrente de larga vida. Jitter del scheduler: no prometas precisión de cadencia al segundo —las recurrentes pueden dispararse algo tarde y solo con el REPL idle, y las one-shot pueden adelantarse cerca de marcas de minuto comunes [SUPUESTO: magnitudes concretas del jitter/skew no verificables desde el filesystem → coverage_gap]; elige un minuto poco común para no colisionar con otras tareas. Cleanup parcial: si CronList está pero CronDelete no, registra el ID huérfano y ciérralo en su surface, no asumas borrado. session_cron huérfano sin task_id recuperable → re-listar con CronList o declarar coverage_gap. [INFERENCIA]
• Supuestos: CronCreate/List/Delete verificados como tools en la sesión viva [CÓDIGO]; ScheduleWakeup, flag de durabilidad, ruta on-disk, horizonte de expiración y magnitud de jitter NO verificados → coverage_gap hasta probe. [SUPUESTO]
• Trade-off: polling frecuente quema cache; fallback largo sobrevive cuelgues. [EXPLICIT]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output · scripts/ automatización local · assets/ recursos estáticos.