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. 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. 1. Plain reminder

• - Example: INLINECODE1
• Default: INLINECODE2
• Use for lightweight reminders and nudges.

1. 2. Recurring reminder

• - Example: INLINECODE3
• Usually still INLINECODE4
• Set timezone explicitly if wall-clock time matters.

1. 3. Internal worker

• - Example: INLINECODE5
• Default: INLINECODE6
• Use for background chores, scans, maintenance, and noisy internal jobs.

1. 4. Scheduled visible delivery

• - Example: INLINECODE7
• Default: INLINECODE8
• Do not rely on implicit last in multi-channel setups.

1. 5. Session/thread push or prompt injection

• - Example: INLINECODE10
• Preserve current-session / current-thread intent explicitly.
• Do not silently convert this into generic visible delivery.

1. 6. Diagnose / repair existing cron

• - Example: Why did this job not deliver? / INLINECODE12
• Inspect first. Do not recreate blindly.

Safe defaults

Use these defaults unless the user clearly wants something else:

• - reminder → INLINECODE13
• background worker → INLINECODE14
• visible scheduled post → INLINECODE15
• recurring job → explicit INLINECODE16
• non-trivial task → INLINECODE17

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. 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. 1. INLINECODE20
2. INLINECODE21
3. if safe, INLINECODE22
4. confirm:

• - correct INLINECODE23
• correct payload kind
• correct timezone
• explicit delivery target, or explicit INLINECODE24
• plausible timeout

Repair workflow

When repairing an existing job:

1. 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
• INLINECODE27 — safe default patterns
• INLINECODE28 — common failure modes and anti-patterns
• INLINECODE29 — prompt-first examples for real user requests

Deeper references

• - references/integration-modes.md — natural-language vs normalized-intent vs spec-first integration paths
• INLINECODE31 — structured triage and repair flow
• INLINECODE32 — natural-language parser examples
• INLINECODE33 — normalized intent → cron spec examples
• INLINECODE34 — cron spec JSON examples
• INLINECODE35 — 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

• - INLINECODE36
• INLINECODE37

Validate / render / create

• - INLINECODE38
• INLINECODE39
• INLINECODE40

Inspect / doctor / repair

• - INLINECODE41
• INLINECODE42
• INLINECODE43

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.