ClawHub

openclaw-cron-standard

v0.2.0

Standardize OpenClaw cron wrappers, prompt contracts, and delivery-mode expectations. Use when auditing or fixing cron jobs that rely on ClankerHive claims,...

⭐ 0· 162·0 current·0 all-time
byPaul Frederiksen@pfrederiksen

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for pfrederiksen/openclaw-cron-standard.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "openclaw-cron-standard" (pfrederiksen/openclaw-cron-standard) from ClawHub.
Skill page: https://clawhub.ai/pfrederiksen/openclaw-cron-standard
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Required binaries: python3
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install openclaw-cron-standard

ClawHub CLI

Package manager switcher

npx clawhub@latest install openclaw-cron-standard
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
✓
Purpose & Capability
The name/description (cron wrapper/contract standardization) matches the content: checklist-style guidance for claim/result lifecycle and delivery.mode. The only runtime requirement is python3, which is plausible for helpers; nothing requested is unrelated to the stated purpose.
✓
Instruction Scope
SKILL.md contains policy and checklist guidance rather than executable instructions that read arbitrary files or exfiltrate data. It references result JSON artifacts and claim helpers (expected for cron wrappers) but does not direct the agent to access credentials, system-wide configs, or external endpoints.
✓
Install Mechanism
No install spec or code files are present; the skill is instruction-only (text files), so nothing is downloaded or written to disk by the skill itself.
✓
Credentials
The skill declares no environment variables, credentials, or config paths. References to ClankerHive claims are contextual guidance and do not trigger any unexpected credential requests.
✓
Persistence & Privilege
always is false and autonomous invocation is allowed by default; the skill does not request persistent or elevated system presence and does not modify other skills' configs.
Assessment
This skill is low-risk: it's pure documentation / conventions for cron wrappers and does not include code, installers, or credential requests. Before adopting: (1) review and test any wrapper/helper code you write to implement these contracts in a staging environment, (2) ensure any integration with ClankerHive or other systems supplies credentials only to the actual implementation (not the skill text), and (3) when changing delivery.mode or claim behavior, validate end-to-end notification behavior so jobs do not become silently non-delivering.

Like a lobster shell, security has layers — review code before you run it.

Runtime requirements

Binspython3
latestvk971g6vt5rzbaqttjwb94yxk2d85b567
162downloads
0stars
2versions
Updated 5d ago
v0.2.0
MIT-0
Paul Frederiksen@pfrederiksen
latest
Download

openclaw-cron-standard

Use this skill when cleaning up or designing OpenClaw cron jobs.

Standard contract

For cron wrappers:

  1. Clear the old result artifact before a new run.
  2. Claim through one shared helper.
  3. If the claim reports ALREADY_CLAIMED, print that sentinel, exit 0, and do not write a result artifact.
  4. Only write a result JSON for a real execution or a real failure.
  5. Keep result artifacts as the source of truth for real runs, not duplicate-run guards.

For cron prompts:

  1. Run the wrapper first.
  2. If it prints ALREADY_CLAIMED, reply only with NO_REPLY.
  3. Only then read the result JSON.
  4. Never read a stale artifact after a duplicate-claim guard path.
  5. Match the prompt's delivery contract to the cron job's delivery.mode.

Delivery-mode contract

This is the easy place to break a healthy cron job.

Use delivery.mode: announce when:

  • the job returns user-visible text as its final assistant reply
  • the prompt says things like return summary_text exactly, return the alert text, or return the formatted message
  • the job explicitly says Do not use the message tool

Use delivery.mode: none when:

  • the job is intentionally silent on success
  • the job sends alerts explicitly via the message tool
  • the job is maintenance-only and should never rely on reply-text fallback delivery

Common failure mode

If you set delivery.mode: none on a cron that still relies on reply-text delivery, the job can:

  • run successfully
  • generate valid summary text
  • update freshness facts
  • still never notify the user

That is not a wrapper failure. It is a delivery-contract mismatch.

Why this matters

The fragile failure mode is usually contract drift across three places:

  • wrapper behavior
  • prompt behavior
  • claim string expectations such as already claimed vs already-claimed

That drift can turn a healthy duplicate-run guard into a fake failure or a silent not-delivered run. Delivery-mode drift can do the same thing even when the wrapper itself is fine.

Preferred implementation shape

Use a small shared helper module for:

  • prepare_result_path(...)
  • claim_or_exit(...)
  • run(...)

Keep wrapper-specific business logic outside the shared helper.

Audit checklist

  • no result artifact written on ALREADY_CLAIMED
  • stale result file is removed before each run
  • prompts check the sentinel before reading the artifact
  • delivery.mode matches the actual delivery contract (announce for reply delivery, none for explicit message-tool or silent jobs)
  • validator passes after edits
  • dead scratch wrappers and tmp scripts are removed if unreferenced

Good migration order

  1. Patch the wrapper contract first.
  2. Patch the live cron prompt second.
  3. Patch delivery.mode to match the prompt's real delivery behavior.
  4. Validate with the cron validator and any runtime snapshot tools.
  5. Remove dead one-off scripts after reference checks.

Scope guidance

This skill is for cron wrapper standardization, not for changing the business logic of a cron job unless that logic is required to fit the contract.

Comments

Loading comments...