Cron Jobs: Skills-First Pattern

Fresh OpenClaw

Stop writing 50-line cron prompts. Use skills instead.

The reference guide to writing cron prompts that actually work: skills, timeout configuration, delivery modes, and validation.

---

The skill-first pattern makes your AI automations reliable, maintainable, and actually consistent. One skill file, unlimited crons, zero drift.

The two patterns

Same automation, two completely different approaches.

The common pattern (where it breaks):

1. Write the cron schedule. Pick the time, frequency, timezone. So far so good.
2. Dump the entire workflow into the prompt: every step, edge case, formatting rule, API call, and validation check. 50+ lines pasted directly into the cron prompt. This is where it breaks.
3. The agent reads the giant prompt and burns tokens on all that text, every single run, re-reading the same instructions from scratch.
4. You need to change the process, so now you have to find every cron that uses this workflow and update them all. Did you get all 5? Drift starts here.
5. Inconsistent results: cron #1 has the old instructions, cron #3 has the new ones, cron #5 has a mix. Outputs differ every time and you cannot figure out why.

The skill-first pattern (single source of truth):

1. Write the cron schedule. Same as before: time, frequency, timezone, model, session type.
2. Point to a skill file. First line: Read and follow: ~/skills/my-workflow/SKILL.md. Then add only context: project paths, service names, who to notify. Max 20 lines.
3. The agent reads the skill file: full workflow with steps, validation, edge cases, and output format, all in one versioned file, read fresh on every run.
4. You need to change the process, so you update ONE file: the SKILL.md. Every cron that references it automatically picks up the change. Zero cron edits.
5. Consistent results every run: same skill, same steps, same validation, same output, whether it is a daily cron, weekly cron, or manual trigger.

Separation of concerns

The cron prompt owns scheduling and context (when to run, what project to target):

• Schedule (frequency, timezone)
• Session type (isolated vs main)
• Model assignment
• Pointer to the skill file
• Project paths, ports, service names
• Who to report to

It must NOT contain workflow steps, business logic, or output formatting.

The SKILL.md owns workflow and logic (how to do the work):

• Step-by-step instructions
• Validation rules and checks
• Output format and templates
• Edge cases and error handling
• Prerequisites and dependencies
• Quality gates

It must NOT contain the schedule, environment-specific paths, or model selection.

Real example: a livestream metadata job

A job that should update YouTube descriptions and tags 24 hours after each stream. This is the failure mode that left Monday and Tuesday on placeholder copy.

Inline prompt (50+ lines):

LIVESTREAM POST-PUBLISH

## Pick a video
Process the oldest unprocessed livestream
Prefer streams at least 36-48 hours old
Do not process today's stream

## Run the command
Use Clearmud-OS /live-streams
Poll every 45 seconds
Generate description, tags, timestamps

## Push to YouTube
Run python3 ~/clawd/scripts/youtube-update.py
Mark processed after update

The problem: the cron ran at 8 PM, it included Sunday, it selected old backlog first, and it used system Python and system yt-dlp. Monday and Tuesday stayed on placeholder copy. The workflow was buried in the cron prompt; the real process changed, the prompt did not.

Skill-first (8 lines):

Read and follow: ~/clawd/skills/livestream-post-publish/SKILL.md

Context:
- Schedule: Tue-Sat noon PT
- Due window: previous Mon-Fri livestream, about 24 hours later
- API: http://localhost:8000/api/commands/live-streams
- Update: /home/clawdbot/clawd/projects/clearmud-os/.venv/bin/python /home/clawdbot/clawd/scripts/youtube-update.py
- Tracker: ~/clawd/projects/clearmud-os/agents/hype/data/processed_videos.json
- Rule: current-week due streams first, historical backlog second
- If captions are missing: stop blocked, do not mark processed

Why this matters

• Single source of truth - update the skill once, every cron picks up the change. No hunting for 5 cron prompts with slightly different instructions.
• Consistency across runs - the skill file is the contract, read fresh every time. No prompt drift.
• Fewer tokens, lower cost - a 50-line inline prompt burns tokens on every run. An 8-line pointer costs almost nothing. The skill is a file read, not prompt tokens.
• Reusable across triggers - the same skill referenced by a daily cron, a weekly cron, and a manual trigger. Different schedules, same workflow, zero duplication.

Real-world failure: what happens when you do not do this

The livestream cron kept stale inline instructions after the real schedule changed.

• Cron prompt said: "Process the oldest unprocessed eligible livestream"
• Skill file said: "Process the 24-hour due stream Tue-Sat at noon PT"

The cron prompt was a copy of an older version of the skill. The cadence changed to Mon-Fri livestreams plus next-day metadata, but the cron kept chewing through backlog first. Result: Monday and Tuesday streams still had placeholder descriptions.

The fix: keep timing and project context in the cron. Put selection rules, retries, and blockers in the skill. If captions are missing, stop blocked and retry later.

Get started: copy-paste starter templates

Cron prompt template:

Read and follow: ~/skills/[your-skill-name]/SKILL.md

Context:
- Project: ~/projects/[your-project]/
- Service: systemctl --user restart [service-name]
- Notify: [telegram-id or email]
- Data: ~/data/[relevant-file].json

SKILL.md template:

---
name: [skill-name]
description: [one-line what this does]
---

# [Skill Name]

[What this skill does and when it runs.]

## Prerequisites
- [What must exist before this runs]
- [Required files, services, APIs]

## Steps

### Step 1: [Gather / Check / Prepare]
[Detailed instructions]

### Step 2: [Execute / Build / Generate]
[The main work]

### Step 3: [Validate]
[Quality gates: what MUST be true before done]

### Step 4: [Deliver / Deploy / Notify]
[Where to send the output]

## Error Handling
- If [X] fails: [do Y]
- If [A] is missing: [do B]

Rules to live by: the skill-first checklist

1. Max 20 lines in a cron prompt. If it is longer, you are duplicating the skill.
2. First line: Read and follow: [skill path]. Always. No exceptions.
3. Update the SKILL.md, not the cron. Only touch the cron if the schedule changes.
4. Never paste skill steps into the cron. Reference the file. Always.
5. One skill per workflow. Multiple crons can reference the same skill.
6. Cron = scheduling plus context. Skill = workflow plus logic. Never mix them.
7. Always use isolated sessions. Never run crons in the main session.
8. If you change a process, change the skill first. The crons follow automatically.