# Openclaw Cron Guardrails > Create, review, repair, or route OpenClaw cron jobs and other scheduled agent actions with safe defaults and explicit delivery/session routing. Use when the user asks in natural language for reminders, alarms, recurring nudges, periodic scans, daily/nightly jobs, repeated prompt injection into the current session/thread, or any `openclaw cron add/edit/run` workflow. Especially use this in multi-channel setups (for example Discord + Feishu) or when delivery routing, `channel=last`, `sessionTarget`, `timeoutSeconds`, thread targeting, or natural-language schedule parsing could go wrong. - Skill: `dvcrn/openclaw-cron-guardrails` (Agent Skill, multi-file: 19 files) - Install (CLI): `npx skillmds@latest add dvcrn/openclaw-cron-guardrails` - Raw SKILL.md: https://api.skillmd.com/api/skills/dvcrn/openclaw-cron-guardrails/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: dvcrn (https://skillmd.com/u/dvcrn) - Updated: 2026-09-08 - Page: https://skillmd.com/skills/dvcrn/openclaw-cron-guardrails --- # OpenClaw Cron Guardrails Use this skill when the user wants a scheduled or repeated action, even if they never say `cron`. ## What this skill is for This skill is a guardrails layer for scheduled agent actions. Treat OpenClaw cron as: - scheduler - agent runtime - delivery router The timer is usually not the hard part. The hard part is choosing the right task type, session target, and delivery target. ## Use this workflow 1. Classify the request. 2. Choose the safest job pattern. 3. Explain what will happen. 4. Create, inspect, or modify the job. 5. Verify after creation/edit. ## First classify the request Choose one bucket first: 1. **Plain reminder** - Example: `Remind me in 20 minutes to reply` - Default: `main + systemEvent` - Use for lightweight reminders and nudges. 2. **Recurring reminder** - Example: `Remind me every morning to check my calendar` - Usually still `main + systemEvent` - Set timezone explicitly if wall-clock time matters. 3. **Internal worker** - Example: `Run a nightly scan and keep the results local` - Default: `isolated + delivery.mode:none` - Use for background chores, scans, maintenance, and noisy internal jobs. 4. **Scheduled visible delivery** - Example: `Post the daily summary to Discord at 9am` - Default: `isolated + explicit delivery.channel + explicit delivery.to` - Do not rely on implicit `last` in multi-channel setups. 5. **Session/thread push or prompt injection** - Example: `Push the current thread every 10 minutes` - Preserve current-session / current-thread intent explicitly. - Do not silently convert this into generic visible delivery. 6. **Diagnose / repair existing cron** - Example: `Why did this job not deliver?` / `Fix this cron` - Inspect first. Do not recreate blindly. ## Safe defaults Use these defaults unless the user clearly wants something else: - reminder → `main + systemEvent` - background worker → `isolated + no-deliver` - visible scheduled post → `isolated + explicit channel + explicit to` - recurring job → explicit `tz` - non-trivial task → `timeoutSeconds >= 180` ## When to ask instead of guessing Ask a focused clarification if any of these are unclear: - reminder vs worker vs visible scheduled post - current thread/current session vs explicit external target - concrete `channel` given but `to` missing - research-task semantics are mixed into an otherwise normal reminder request - wall-clock schedule matters but timezone is not clear Do not hide ambiguity with clever defaults when the job could post to the wrong place. ## Output contract When helping with a cron request, prefer this response order: 1. detected task type 2. chosen safe pattern 3. exact command or exact JSON/tool payload 4. why this pattern is safe 5. verification step Keep the top-level explanation short and predictable. ## Verification after create/edit Always verify after creating or editing a job: 1. `openclaw cron list` 2. `openclaw cron runs --id --limit 5` 3. if safe, `openclaw cron run ` 4. confirm: - correct `sessionTarget` - correct payload kind - correct timezone - explicit delivery target, or explicit `none` - plausible timeout ## Repair workflow When repairing an existing job: 1. read the existing job 2. inspect recent runs 3. classify the failure 4. fix the root cause, not just the symptom Common failure buckets: - delivery-target ambiguity - auth/permission/channel issue - timeout too short - schedule/timezone issue - prompt/content issue For a fuller triage flow, read `references/diagnostics.md`. ## What to read Read only what you need. ### Beta-essential references - `references/intent-routing.md` — intent buckets and normalization schema - `references/patterns.md` — safe default patterns - `references/pitfalls.md` — common failure modes and anti-patterns - `references/public-examples.md` — prompt-first examples for real user requests ### Deeper references - `references/integration-modes.md` — natural-language vs normalized-intent vs spec-first integration paths - `references/diagnostics.md` — structured triage and repair flow - `references/nl-parser-examples.md` — natural-language parser examples - `references/intent-to-spec-examples.md` — normalized intent → cron spec examples - `references/spec-examples.md` — cron spec JSON examples - `references/target-helpers.md` — explicit target string guidance ## Scope boundary Do not turn this skill into a universal prompt-understanding layer. Its job is to: - provide easy-start patterns - enforce safe routing/session/delivery defaults - support deterministic validate/render/create flows Upstream products or base models may do richer prompt understanding than this skill does. That is fine. Prefer stable interfaces over trying to cover every possible natural-language corner case here. ## Scripts Use scripts when the user wants a deterministic, reusable cron definition instead of ad-hoc flag assembly. ### Parse / normalize - `scripts/parse_nl_intent.py` - `scripts/intent_to_cron_spec.py` ### Validate / render / create - `scripts/validate_cron_spec.py` - `scripts/render_cron_command.py` - `scripts/create_cron.py` ### Inspect / doctor / repair - `scripts/lint_existing_crons.py` - `scripts/cron_fix.py` - `scripts/cron_doctor.py` ## Non-goals This skill is not: - a full replacement for OpenClaw cron docs - a guarantee against every runtime/provider failure - a license to guess external delivery targets when intent is ambiguous Prefer explicit, boring, reproducible cron definitions over clever shorthand.