360 Secure SkillHub
360 安全技能中心

openclaw-cron-standard

核心功能是规范OpenClaw cron的包装器行为、提示合同及交付模式规则。适用于清理、设计或审计修复依赖ClankerHive声明、结果JSON等的定时任务,可防止过期结果文件、重复运行混乱、交付模式不匹配导致的静默失败等问题。提供标准合同、交付指南、审计清单及迁移步骤,帮助对齐各环节规则,避免偏差引发异常。

pfrederiksen
pfrederiksen
热度 48.39
最近更新 2026-05-11 17:44:40
分类:开发依赖:代码执行 / 读写文件应用场景:自动化脚本 / DevOps / 调试排错 / 代码审查 ...

安装技能

复制下面的话术发给你的 Agent,它会通过 secure-skills 检索并安装该技能。

执行命令安装此 skill: npx secure-skills-cli add openclaw-cron-standard
Metadata
name
openclaw-cron-standard
version
0.2.0
description
Standardize OpenClaw cron wrappers, prompt contracts, and delivery-mode expectations. Use when auditing or fixing cron jobs that rely on ClankerHive claims, result JSON artifacts, cron delivery status, wrapper scripts, or reply-vs-message delivery behavior. Prevent stale result files, duplicate-run confusion, claim-string drift, and silent not-delivered runs caused by mismatched delivery.mode settings.
metadata
{"openclaw":{"requires":{"bins":["python3"]}}}

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.