{"id":"2b3f3084-3e98-46a8-849b-cd7f6728ee02","entityType":"agent","slug":"clawhub-daniel-refahi-ikara-dr-schedule-manager","name":"DR Schedule Manager","canonicalUrl":"https://www.xpersona.co/agent/clawhub-daniel-refahi-ikara-dr-schedule-manager","canonicalPath":"/agent/clawhub-daniel-refahi-ikara-dr-schedule-manager","generatedAt":"2026-10-11T07:40:12.703Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:15:01.395Z","emptyReason":null},"description":"Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect imme...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s177xe2n6zt5z29v51zpxrnx9183wyda:dr-schedule-manager","sourceUrl":"https://clawhub.ai/daniel-refahi-ikara/dr-schedule-manager","homepage":"https://clawhub.ai/daniel-refahi-ikara/skills/dr-schedule-manager","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/daniel-refahi-ikara/dr-schedule-manager","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/daniel-refahi-ikara/skills/dr-schedule-manager","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"DR Schedule Manager technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:15:01.395Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:15:01.395Z","emptyReason":null},"stars":null,"forks":null,"downloads":1149,"packageName":null,"latestVersion":"1.1.0","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:15:01.336Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T05:15:01.395Z","lastCrawledAt":"2026-10-11T05:15:01.336Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T05:15:01.336Z","lastVerifiedAt":null,"highlights":[{"version":"1.1.0","createdAt":"2026-06-29T05:05:57.772Z","changelog":"Add execution substrate gate, non-agent vs agent runner patterns, high-frequency LLM guardrail, and scheduler payload validation","fileCount":8,"zipByteSize":14777},{"version":"1.0.4","createdAt":"2026-06-28T08:46:16.872Z","changelog":"Correct packaged metadata for the neutral model example release.","fileCount":8,"zipByteSize":12113},{"version":"1.0.3","createdAt":"2026-06-28T08:42:19.800Z","changelog":"Replace stale concrete model examples with neutral placeholders.","fileCount":8,"zipByteSize":12158},{"version":"1.0.2","createdAt":"2026-06-26T00:18:05.237Z","changelog":"Add checkpointed rollout safety for scheduled jobs: dry-run/shadow validation, separate generation/delivery/scheduler tests, and approval gates before live side effects.","fileCount":8,"zipByteSize":12143},{"version":"1.0.1","createdAt":"2026-05-01T04:20:29.080Z","changelog":"Clarify that the skill is architecture guidance; align manifest templates with the live job format; normalize display name to dr-schedule-manager.","fileCount":8,"zipByteSize":11530},{"version":"1.0.0","createdAt":"2026-04-20T02:04:41.708Z","changelog":"Initial release: thin-trigger scheduling pattern for OpenClaw, local manifest resolution, cron snapshot caveats, and reliability review guidance.","fileCount":7,"zipByteSize":9583}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s177xe2n6zt5z29v51zpxrnx9183wyda:dr-schedule-manager","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s177xe2n6zt5z29v51zpxrnx9183wyda:dr-schedule-manager` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/daniel-refahi-ikara/dr-schedule-manager before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T07:40:12.696Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:15:01.395Z","emptyReason":null},"readme":"Skill: DR Schedule Manager\n\nOwner: daniel-refahi-ikara\n\nSummary: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect imme...\n\nTags: latest:1.1.0\n\nVersion history:\n\nv1.1.0 | 2026-06-29T05:05:57.772Z | user\n\nAdd execution substrate gate, non-agent vs agent runner patterns, high-frequency LLM guardrail, and scheduler payload validation\n\nv1.0.4 | 2026-06-28T08:46:16.872Z | user\n\nCorrect packaged metadata for the neutral model example release.\n\nv1.0.3 | 2026-06-28T08:42:19.800Z | user\n\nReplace stale concrete model examples with neutral placeholders.\n\nv1.0.2 | 2026-06-26T00:18:05.237Z | user\n\nAdd checkpointed rollout safety for scheduled jobs: dry-run/shadow validation, separate generation/delivery/scheduler tests, and approval gates before live side effects.\n\nv1.0.1 | 2026-05-01T04:20:29.080Z | user\n\nClarify that the skill is architecture guidance; align manifest templates with the live job format; normalize display name to dr-schedule-manager.\n\nv1.0.0 | 2026-04-20T02:04:41.708Z | user\n\nInitial release: thin-trigger scheduling pattern for OpenClaw, local manifest resolution, cron snapshot caveats, and reliability review guidance.\n\nArchive index:\n\nArchive v1.1.0: 8 files, 14777 bytes\n\nFiles: _meta.json (138b), references/architecture-patterns.md (3249b), references/example-migration-daily-briefing.md (2878b), references/job-manifest-template.json (1273b), references/migration-checklist.md (1933b), references/reliability-review.md (2290b), skill-card.md (2836b), SKILL.md (19690b)\n\nFile v1.1.0:SKILL.md\n\n---\nname: dr-schedule-manager\ndescription: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. Use when cron jobs, daily briefings, reminders, digests, or background agents keep using stale models, stale prompts, stale session state, or detached execution contexts. Also use when standardizing automation architecture across multiple agents or converting brittle time-triggered workflows into reusable config-driven jobs.\n---\n\n# dr-schedule-manager\n\nBuild scheduled automations so each run reflects current configuration immediately.\n\n## Core outcome\n\nThis skill is a scheduling **architecture and migration playbook**, not a one-command scheduler installer.\n\nAfter installation or migration, scheduled jobs should:\n- pick up current prompt changes on the next run\n- pick up current policy changes on the next run\n- pick up current delivery changes on the next run\n- pick up current default model changes on the next run, unless intentionally pinned\n- avoid stale session residue from prior runs\n- use an execution substrate appropriate to the job, instead of defaulting every scheduled reference into an LLM-backed agent run\n\nIf a design does not guarantee those properties, do not recommend it as the default.\n\n## Current OpenClaw constraint\n\nTreat current OpenClaw cron as **snapshot-based unless proven otherwise**.\n\nIn practice, cron jobs may embed:\n- prompt text\n- model override\n- delivery route\n- other runtime details\n\nThat means editing local files alone may **not** change the behavior of the already-registered job.\n\nBecause of this, the preferred practical pattern is not \"fat job config in cron\". It is:\n- thin scheduler reference\n- local file resolution at runtime\n- explicit final delivery through the correct outbound path when delivery is needed\n\nThe scheduler reference may point to an agent runner or a non-agent runner. Choose that substrate deliberately.\n\n## Default architecture\n\nPrefer a **thin-reference, fresh-run, config-driven job architecture**.\n\n### Rule 1, scheduler is only a trigger/reference carrier\n\nThe scheduler should only:\n- wake the job\n- identify the job slug or manifest\n- pass a small stable trigger message or command reference\n\nDo not embed business logic, formatting rules, prompt text, delivery rules, or model decisions in the scheduler unless you intentionally accept snapshot behavior.\n\n### Rule 2, manifest is the operational contract\n\nEach scheduled job should have a manifest file that defines:\n- slug\n- name\n- agent id when an agent runner is required\n- execution substrate\n- schedule\n- runtime mode\n- trigger mode\n- prompt file path when generation/reasoning is required\n- policy file paths\n- delivery contract\n- model policy when an LLM is used\n- verification rules\n- live scheduler id if your local tooling tracks one\n\n### Rule 3, runtime assembly happens at execution time\n\nOn every run, load current files before generating output or executing deterministic work.\n\nAlways assemble from:\n- current manifest\n- current prompt file when applicable\n- current policy files\n- current delivery rules\n- current model policy when applicable\n- current deterministic script/CLI configuration when applicable\n\nDo not trust previous session state for these.\n\n### Rule 4, delivery is explicit and provider-aware\n\nStore delivery in a clear adapter contract.\n\nDo not assume session metadata is valid for outbound sends if the provider requires a different target format.\n\n### Rule 5, persistent sessions are not the source of truth\n\nIf you keep a persistent automation agent, use it only as a dispatcher or coordinator.\n\nDo not let a persistent scheduled session be the authoritative source for:\n- prompt wording\n- model selection\n- formatting rules\n- delivery routing\n- deterministic script configuration\n\n## Execution substrate gate\n\nBefore choosing an approved pattern, decide whether the scheduled task needs an agent/LLM at run time.\n\nThin trigger means **thin stable reference**, not automatically **OpenClaw agentTurn**.\n\n### Deterministic non-LLM jobs\n\nIf the scheduled task is a deterministic script, CLI, ETL, monitor, report generator, reconciliation job, artifact builder, or health check that does not need natural-language reasoning at run time, default to a non-agent runner.\n\nAppropriate non-agent substrates include:\n- systemd timer\n- OS cron\n- platform scheduler\n- queue worker\n- direct command runner available in the environment\n- another deterministic execution substrate already approved for that host\n\nRules:\n- The scheduler entry should point to a stable runner, wrapper, or manifest path.\n- The scheduler entry must not embed the job definition.\n- OpenClaw, Codex, or another LLM must not be in the hot path for high-frequency deterministic jobs.\n- The deterministic runner should still load current manifest/config files at run time.\n\n### Agent/LLM jobs\n\nUse OpenClaw `agentTurn` or another LLM-backed agent path only when the scheduled run genuinely needs one or more of:\n- agent reasoning\n- natural-language generation\n- tool orchestration with judgment\n- conversational context\n- adaptive summarization or decision-making\n\nEven then, the payload must stay thin:\n- pass only a job slug, manifest path, and small trigger message\n- make the agent load current manifest, prompt, policy, delivery, and model files at runtime\n- avoid embedding the full prompt, model, policy, or delivery details into the scheduler payload\n\n### High-frequency guardrail\n\nFor frequent jobs, especially every 5-15 minutes or less, require an explicit written justification before using an LLM-backed scheduler path.\n\nThe justification should explain why deterministic execution is insufficient.\n\nIf no justification exists, choose a non-agent execution substrate.\n\n### Substrate decision checklist\n\nAsk:\n- Does the job require natural-language generation or reasoning on every run?\n- Does it require tool orchestration where judgment changes run-to-run?\n- Is the output deterministic from API/file inputs?\n- Is the frequency high enough that token cost or model latency matters?\n- Can a script/CLI produce the artifact and only alert on exceptions?\n- Does delivery require an agent, or can delivery be handled by a provider adapter or direct command?\n\nDefault answer:\n- deterministic job -> Pattern B1\n- agent/LLM job -> Pattern B2\n- mixed job -> deterministic runner first; call an agent only for the genuinely reasoning-dependent step\n\n## Approved patterns\n\n### Pattern A, wake-only trigger into fresh main execution\n\nUse when you want the latest main assistant behavior to apply automatically and the job genuinely needs an agent/LLM.\n\nBest for:\n- personal briefings\n- reminders with natural-language rendering\n- evolving assistant workflows\n\nStrengths:\n- changes propagate immediately\n- minimal drift risk\n- simple to reason about\n\nWeaknesses:\n- less isolated\n- changes to main behavior affect the job immediately\n- inappropriate for deterministic high-frequency jobs\n\n### Pattern B1, thin trigger to non-agent runner plus local manifest resolution\n\nUse as the default for deterministic scheduled jobs.\n\nBest for:\n- health checks\n- ETL/sync jobs\n- deterministic report generation\n- monitors that poll APIs or local state\n- high-frequency jobs\n- jobs where the output is produced by a script or CLI without natural-language reasoning\n\nHow it works:\n- scheduler stores only a small stable reference to a runner, wrapper, command, or manifest\n- the non-agent runner reads local job files at runtime\n- script/config/policy/delivery are resolved from the workspace or approved config path\n- output artifacts, ledgers, and exit status are written for validation\n- final delivery uses a deterministic delivery adapter when needed\n\nStrengths:\n- avoids LLM token spend for deterministic work\n- avoids model latency and model availability risk\n- avoids stale embedded prompt/model drift\n- changes are effective on the next run because runtime inputs are file-based\n- easy to validate with unit/integration checks and scheduler logs\n\nWeaknesses:\n- cannot perform open-ended reasoning or natural-language synthesis unless another step is added\n- requires local execution tooling, scripts, and observability\n\n### Pattern B2, thin trigger to agent runner plus local manifest resolution\n\nUse as the default only for jobs that actually need an agent/LLM.\n\nBest for:\n- natural-language briefings and digests\n- judgment-heavy summaries\n- workflows that need adaptive tool orchestration\n- jobs that rely on conversational context\n\nHow it works:\n- scheduler stores only a small stable trigger\n- the triggered agent reads local job files at runtime\n- prompt, policy, model policy, and delivery are resolved from the workspace\n- final delivery uses the normal outbound path, not cron announce, when announce is unreliable\n\nStrengths:\n- avoids stale embedded prompt and model drift\n- avoids stale model pins in cron payloads\n- makes file edits effective on the next run\n- appropriate when the actual task needs an agent\n\nWeaknesses:\n- consumes LLM tokens\n- introduces model latency and model availability risk\n- requires stronger justification for high-frequency jobs\n- still depends on reliable final outbound delivery\n\n### Pattern C, persistent dispatcher plus fresh worker run\n\nUse for more advanced orchestration.\n\nBest for:\n- retry queues\n- fan-out workflows\n- multi-step automation pipelines\n- mixed deterministic and agent work\n\nStrengths:\n- scalable\n- strong separation between orchestration and generation\n- can route deterministic work to non-agent runners and reasoning work to agents\n\nWeaknesses:\n- more moving parts\n- requires careful observability and ownership boundaries\n\n## Default recommendation\n\nFor most current scheduled jobs, use **Pattern B1** when the job is deterministic and **Pattern B2** only when the job genuinely needs an agent/LLM.\n\nReason:\n- both preserve the thin-reference, file-based scheduling contract\n- B1 prevents high-frequency deterministic jobs from accidentally consuming LLM tokens\n- B2 keeps agent-backed jobs fresh without embedding stale prompt/model/delivery payloads\n- both avoid stale embedded scheduler payload drift when implemented correctly\n\n## Checkpointed rollout safety\n\nWhen implementing or changing real scheduled behavior, use `dr-checkpoint-implementation`.\n\nThis applies to:\n- cron jobs\n- reminders\n- briefings\n- digests\n- alerting or monitoring jobs\n- delivery flows\n- background agents that write, notify, or mutate production state\n\nWork in checkpoints:\n1. Discover current scheduler, manifest, prompt, policy, model, session, substrate, delivery state, and registered scheduler payload.\n2. Decide the execution substrate using the substrate gate.\n3. Design or update the manifest and file-based runtime contract.\n4. Dry-run deterministic execution or generation from current files without live delivery.\n5. Test outbound delivery separately from scheduler announce behavior.\n6. Test the scheduler trigger separately from content generation or deterministic work.\n7. Validate the actual registered scheduler payload/substrate.\n8. Calibrate timing, cooldowns, suppression, and failure behavior where alerts or notifications are involved.\n9. Enable live cron delivery or production mutations only after user approval.\n\nSelf-approve routine checkpoints only when validation passes and no new live side effect is introduced.\n\nStop for user approval before:\n- enabling or changing live cron delivery\n- sending notifications, emails, or public posts\n- writing or mutating production data\n- changing a customer-facing schedule\n- changing alert thresholds, cooldowns, or suppression behavior\n- accepting weak, missing, or contradictory validation\n- using an LLM-backed path for a high-frequency deterministic job without explicit justification\n\n## Model policy rules\n\nModel behavior must be explicit when an LLM-backed path is used.\n\n### Preferred\n\nUse inherit-default when upgrades should propagate automatically.\n\nExample:\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\n### Use only when intentionally pinned\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}\n```\n\nIf pinning is used, document why.\n\n### Shared-policy option\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same rule.\n\nFor deterministic non-LLM jobs, model policy should be absent or explicitly marked not applicable.\n\n## Verification rules\n\nVerification should catch broken assembly and wrong execution substrates, not freeze intended upgrades.\n\nGood checks:\n- prompt path exists when prompt is required\n- policy paths exist\n- delivery route matches current job contract\n- schedule matches manifest\n- pinned model matches manifest, if pinning is intentional\n- registered scheduler payload is a thin reference, not an embedded full job definition\n- registered scheduler payload points to the intended substrate\n- deterministic jobs do not start `agentTurn` or another agent/LLM session unless explicitly justified\n- LLM-backed jobs pass only slug/manifest path and a small trigger message\n- artifacts, ledgers, or logs prove the selected runner loaded current files\n\nFor systemd timers, verify:\n- unit file exists and points to the intended wrapper/runner\n- timer file exists\n- timer is active/enabled when live operation is approved\n- next run is visible\n- last run exit status is available\n- logs or ledger/artifact output prove what ran\n\nKeep separate validation for:\n- delivery\n- schedule\n- manifest loading\n- actual registered scheduler payload/substrate\n- live side effects\n\nAvoid exact verification for settings that are supposed to inherit current defaults.\n\nIf the job should follow current default model changes, do **not** require an exact old model string.\n\nDo not claim OpenClaw cron can directly execute shell commands unless the runtime actually supports that. If shell execution is required, choose an OS/platform scheduler or another direct command runner.\n\n## Anti-patterns\n\nReject these by default.\n\n### Embedded full-payload cron jobs for dynamic automations\n\nA cron job stores the full prompt, model, and delivery configuration even though the automation is expected to evolve via local files.\n\n### Treating thin trigger as automatically agent-backed\n\nA design says \"thin trigger\" but always starts OpenClaw `agentTurn`, even when the job is deterministic and could run as a script or CLI.\n\n### High-frequency deterministic LLM polling\n\nA deterministic monitor, health check, ETL, or report generator runs through Codex/OpenClaw every few minutes even though no run-time reasoning is needed.\n\n### Stale exact model pinning\n\nA manifest or cron payload hardcodes an old model and exact verification preserves it forever.\n\n### Chat-only preference changes\n\nA user requests a format change in chat, but the job still reads an older prompt source.\n\n### Session-derived outbound routing\n\nOutbound delivery copies stale or misleading session metadata rather than a provider-valid target.\n\n### Persistent scheduled generation context\n\nA long-lived automation session accumulates outdated assumptions and keeps using them.\n\n### Assuming scheduler reliability equals delivery reliability\n\nA job can resolve current local files correctly and still fail because the scheduler's announce/delivery adapter is broken.\n\n## Anti-regression example\n\n### Integration Platform Health Monitor, every 5 minutes\n\nA health monitor runs every 5 minutes and executes a Python CLI that checks deterministic API and platform status.\n\nCorrect design:\n- Pattern B1\n- systemd timer, OS cron, platform scheduler, or approved direct command runner\n- scheduler points to a wrapper or manifest-backed CLI command\n- CLI loads current manifest/config files at runtime\n- CLI writes a ledger/artifact with checked targets, timestamp, result, and exit status\n- delivery is deterministic and separate from scheduler behavior\n\nIncorrect design:\n- OpenClaw `agentTurn` every 5 minutes\n- agent starts even when the Python CLI itself contains all deterministic logic\n- Codex tokens are consumed on every poll without a reasoning requirement\n\nEscalation design:\n- deterministic CLI runs every 5 minutes\n- agent/LLM is invoked only for exception analysis, incident summary generation, or operator-facing natural-language report when needed\n\n## Migration workflow\n\nWhen fixing an existing job:\n\n1. Inspect current manifest and scheduler behavior.\n2. Inspect the registered scheduler payload, not just local files.\n3. Identify stale sources:\n   - model\n   - prompt\n   - policy\n   - delivery\n   - session mode\n   - substrate\n   - embedded cron payloads\n4. Decide whether the job is deterministic, agent/LLM-backed, or mixed.\n5. Move all durable rules into files.\n6. Replace fat cron payloads with thin references.\n7. Choose execution substrate:\n   - B1 for deterministic jobs\n   - B2 for agent/LLM jobs\n   - C for mixed orchestration\n8. Choose model policy only when an LLM is used.\n9. Make delivery explicit.\n10. Reduce over-strict verification that blocks intended inheritance.\n11. Dry-run deterministic execution or generation from current files without live delivery.\n12. Test final delivery separately.\n13. Test scheduler trigger behavior separately from delivery.\n14. Get user approval before enabling live delivery or production mutations.\n15. Record provider-specific quirks and substrate validation details.\n\n## Required output when using this skill\n\nProvide:\n- recommended runtime pattern\n- execution substrate recommendation and justification\n- manifest structure\n- model policy recommendation, or why model policy is not applicable\n- delivery contract recommendation\n- what must move out of session state or scheduler payload\n- migration steps\n- verification plan, including registered scheduler payload/substrate checks\n- checkpoint plan and approval gates for rollout\n- reliability risks and tradeoffs\n- whether additional local execution tooling is still required\n\n## Reliability review checklist\n\nBefore declaring the architecture good, confirm:\n- the execution substrate matches the job need\n- deterministic jobs use non-agent runners unless explicitly justified\n- high-frequency deterministic jobs do not consume LLM tokens in the hot path\n- the registered scheduler payload is inspected and matches the intended substrate\n- a prompt edit affects the next run when prompts are part of the job\n- a policy edit affects the next run\n- a delivery target edit affects the next run\n- a default-model change affects the next run when inherit-default is used\n- the scheduler stores only a thin trigger/reference for dynamic jobs, or re-registration is explicitly part of the workflow\n- no persistent session is required for content correctness\n- provider-specific outbound routing is documented where needed\n- final delivery works independently of cron announce delivery\n- dry-run or shadow output was reviewed before live delivery\n- live delivery, notifications, writes, or production mutations were explicitly approved\n\n## References\n\nRead `references/architecture-patterns.md` when designing the execution model.\nRead `references/migration-checklist.md` when converting an existing stale scheduled job.\nRead `references/reliability-review.md` before finalizing a job architecture or publishing this pattern for wider reuse.\nRead `references/job-manifest-template.json` for the recommended manifest shape.\nRead `references/example-migration-daily-briefing.md` for a concrete migration from a stale scheduled digest to a fresh-runtime job.\n\nFile v1.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn75qhdfr3qnbx390tbrjgz48981y6e4\",\n  \"slug\": \"dr-schedule-manager\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1782709557772\n}\n\nFile v1.1.0:references/architecture-patterns.md\n\n# Architecture patterns for reliable scheduled jobs\n\n## Design goal\n\nA scheduled job should reflect current configuration on the very next run.\n\nThat means changes to:\n- prompt\n- policy\n- delivery route\n- default model\n\nmust be loaded at execution time, not remembered from stale session state.\n\n## Recommended default\n\nUse a thin-trigger, file-resolved execution path.\n\nThe scheduler should carry only a small stable trigger. The runtime then assembles the job from local files.\n\n## Current OpenClaw reality\n\nCurrent OpenClaw cron jobs may embed prompt text, model choice, and delivery details directly in the registered job.\n\nThat means cron can behave as a snapshot system unless you deliberately design around it.\n\nFor dynamic automations, do not treat the cron registration as the canonical source of truth.\nTreat it as a trigger carrier.\n\n## Pattern A, wake-only trigger into fresh main execution\n\nUse when:\n- you want the latest main assistant behavior automatically\n- isolation is less important than immediate propagation\n\nPros:\n- very low drift\n- changes apply immediately\n\nCons:\n- less isolated\n- changes in main behavior can affect the job unexpectedly\n\n## Pattern B, fresh isolated run from manifest\n\nUse when:\n- you want reusable architecture across many agents\n- each run should start clean\n- immediate application of file changes matters\n\nPros:\n- predictable\n- portable\n- avoids stale session memory\n\nCons:\n- requires disciplined manifests and policy files\n\n## Pattern C, dispatcher plus fresh worker\n\nUse when:\n- orchestration complexity exists\n- retries or queues matter\n- multi-step automations are needed\n\nPros:\n- scalable\n- separates orchestration from generation\n\nCons:\n- more moving parts\n\n## Manifest recommendations\n\nA manifest should explicitly define:\n- slug\n- name\n- agentId\n- schedule\n- runtimeMode\n- triggerMode\n- promptFile\n- policyFiles\n- delivery\n- modelPolicy\n- verify\n- live scheduler id when your local tooling keeps one\n\n## Model policy recommendations\n\n### Best default\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\nUse when the job should follow system model upgrades.\n\n### Intentional pinning\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}\n```\n\nOnly use if output stability outweighs automatic upgrades.\n\n### Shared policy file\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same resolution behavior.\n\n## Verification recommendations\n\nVerification should ensure assembly correctness.\n\nGood checks:\n- manifest exists\n- prompt file exists\n- policy files exist\n- delivery target matches policy\n- schedule matches manifest\n- pinned model matches manifest if pinning is intentional\n\nBad checks:\n- exact model verification when model inheritance is intended\n- exact prompt text verification when prompt changes should be allowed through file edits\n\n## Delivery recommendations\n\nDelivery must be explicit and provider-aware.\n\nExample:\n\n```json\n{\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\"\n  }\n}\n```\n\nDo not trust session metadata blindly for outbound sends.\n\nFile v1.1.0:references/example-migration-daily-briefing.md\n\n# Example migration: Daily briefing job\n\n## Symptoms\n\nA daily briefing keeps using old settings even after the system changed.\n\nTypical signs:\n- old model still in use\n- old formatting still in use\n- requested changes take multiple attempts to stick\n- delivery route behaves differently from current runtime expectations\n\n## Root causes to check\n\n- manifest pins an outdated model\n- session mode is isolated but still behaves like a stale long-lived context\n- prompt changes live partly in chat history instead of files\n- outbound delivery route uses misleading session metadata\n- verification rules freeze old configuration\n\n## Before\n\nExample brittle pattern:\n\n```json\n{\n  \"model\": \"old-hardcoded-model-example\",\n  \"session\": \"isolated\",\n  \"wake\": \"now\",\n  \"to\": \"channel:1476754066481877155\",\n  \"verify\": {\n    \"requirePromptExact\": true,\n    \"requireModelExact\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true\n  }\n}\n```\n\nProblems:\n- old model pin\n- exact model verification locks drift in place\n- outbound target may not be the provider-valid DM form\n- prompt exactness can hide where the true source of truth lives\n\n## After\n\nRecommended fresh-runtime pattern:\n\n```json\n{\n  \"slug\": \"daily-ai-briefing\",\n  \"cronId\": \"replace-with-live-cron-id-if-tracked-locally\",\n  \"name\": \"daily-ai-briefing\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/daily-ai-briefing/prompt.md\",\n  \"policyFiles\": [\n    \"automation/jobs/daily-ai-briefing/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  }\n}\n```\n\nIf you're using a local automation manager, keeping `slug` and `cronId` in the manifest makes reconciliation and verification deterministic.\n\n## Why this fixes drift\n\n- prompt is loaded from file every run\n- policy is loaded from file every run\n- delivery target is explicit and provider-valid\n- model follows current default unless intentionally pinned\n- exact model verification no longer preserves an outdated pin\n\n## Validation checklist\n\nAfter migration, confirm:\n- editing the prompt changes the next run\n- editing the policy changes the next run\n- changing the default model affects the next run\n- delivery still works after a live send test\n- attachments work if the job needs them\n\n## Provider-specific reminder\n\nFor Discord DMs, outbound sends may require `user:<discord_user_id>` even if session metadata suggests a `channel:<id>` route.\n\nFile v1.1.0:references/job-manifest-template.json\n\n{\n  \"slug\": \"example-scheduled-job\",\n  \"cronId\": \"replace-with-live-cron-id-if-your-tooling-tracks-it\",\n  \"name\": \"Example scheduled job\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/example-scheduled-job/prompt.md\",\n  \"policyFiles\": [\n    \"automation/policies/default-runtime.json\",\n    \"automation/jobs/example-scheduled-job/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  },\n  \"notes\": [\n    \"Set requireModelExact=true only when modelPolicy.mode is pin.\",\n    \"Do not rely on session metadata for outbound delivery if the provider requires a different target format.\",\n    \"Every run should load promptFile and policyFiles fresh.\",\n    \"If your local automation manager tracks live scheduler ids, keep cronId in sync after create/edit operations.\"\n  ]\n}\n\nFile v1.1.0:references/migration-checklist.md\n\n# Migration checklist for stale scheduled jobs\n\n## Goal\n\nConvert a brittle scheduled job into a design where changes are effective on the next run.\n\n## Checklist\n\n### 1. Inspect the current job\n\nCheck:\n- model field\n- session mode\n- prompt source\n- policy source\n- delivery route\n- verification rules\n\n### 2. Identify drift sources\n\nCommon causes:\n- old pinned model\n- isolated stale session behavior\n- prompt rules only stored in chat history\n- delivery target copied from misleading session metadata\n- exact verification preventing intended inheritance\n- cron registration embedding old prompt, model, or delivery values\n\n### 3. Move behavior into files\n\nCreate or update:\n- manifest\n- prompt file\n- policy file\n- local registry or scheduler-id mapping if your tooling reconciles live jobs\n\n### 4. Fix model policy\n\nChoose one:\n- inherit-default\n- pin\n- policy-file\n\nDefault: inherit-default.\n\n### 5. Replace fat cron payloads with thin triggers\n\nMake the cron payload a small stable instruction that tells the agent to load local files.\n\n### 6. Make delivery explicit\n\nWrite the exact provider-valid outbound target in the manifest.\n\n### 7. Relax harmful verification\n\nKeep checks that validate assembly.\nRemove checks that freeze old desired behavior.\n\n### 8. Test one live run for content freshness\n\nConfirm:\n- current prompt is used\n- current policy is used\n- current model policy behaves as intended\n\n### 9. Test final delivery separately\n\nConfirm:\n- the final outbound route works\n- attachments work if relevant\n- cron announce is not silently masking a delivery bug\n\n### 10. Record discovered quirks\n\nDocument provider-specific routing or runtime behavior for future reuse.\n\n### 11. Record ownership boundaries\n\nWrite down whether the design is:\n- architecture-only guidance\n- a manifest convention\n- or a complete installable execution path\n\nDo not imply a one-command rollout if local execution tooling is still required.\n\nFile v1.1.0:references/reliability-review.md\n\n# Reliability review for scheduled job architecture\n\nUse this before publishing or rolling out a scheduling pattern.\n\n## A design is reliable only if all are true\n\n- Prompt changes take effect on the next run.\n- Policy changes take effect on the next run.\n- Delivery changes take effect on the next run.\n- Default model changes take effect on the next run when inheritance is intended.\n- Pinned model behavior is explicit and documented when inheritance is not intended.\n- Dynamic jobs do not depend on fat embedded cron payloads unless re-registration is explicitly part of the process.\n- No persistent session is required for correctness of content generation.\n- Provider-specific outbound routing is documented where needed.\n- Verification checks assembly correctness without blocking intended updates.\n- Final delivery has been tested independently from scheduler announce behavior.\n\n## Review questions\n\n### Runtime freshness\n\n- Does every run read current files?\n- Can a stale session override current files?\n- Is generation happening in a clean runtime?\n\n### Model freshness\n\n- Is the model intentionally inherited or intentionally pinned?\n- Could an old manifest silently keep using an outdated model?\n- Does verification accidentally lock an old model in place?\n\n### Prompt and policy freshness\n\n- Are formatting and content rules stored in files?\n- Would a file edit affect the next run without extra manual steps?\n\n### Delivery correctness\n\n- Is outbound delivery defined explicitly?\n- Is the target format valid for the provider?\n- Have attachments been tested if relevant?\n- Is normal outbound delivery working even if cron announce delivery is not?\n\n### Operational resilience\n\n- Can the job fail safely?\n- Can it be re-run cleanly?\n- Can another agent reuse the pattern without hidden assumptions?\n\n## Red flags\n\n- exact old model pinned without a clear reason\n- persistent automation session used as content source of truth\n- prompt requirements only captured in conversation history\n- delivery route inferred from stale session metadata\n- verification that prevents intended updates from taking effect\n- cron registration storing the full job content for a supposedly dynamic automation\n- relying on cron announce delivery without separately testing the real outbound path\n\nFile v1.1.0:skill-card.md\n\n## Description:\n\nDesigns and migrates scheduled or event-triggered automations so prompt, policy, delivery, and model changes take effect on the next run.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[daniel-refahi-ikara](https://clawhub.ai/user/daniel-refahi-ikara)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and automation engineers use this skill to design or migrate scheduled jobs, briefings, reminders, digests, and background agent workflows so runtime behavior is assembled from current files. It helps teams replace stale scheduler payloads and persistent session assumptions with thin triggers, manifests, explicit delivery contracts, and focused verification.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Copied manifest examples may send scheduled output to an unintended Discord recipient if placeholder targets are reused.\n\nMitigation: Replace the Discord target with the intended recipient, set the deployment timezone, and validate delivery with a dry run before enabling live sends.\n\nRisk: Live scheduled jobs can create notifications, public posts, or production mutations before the operator has confirmed the updated behavior.\n\nMitigation: Require explicit confirmation after dry-run validation before enabling live delivery, notifications, public posts, or production mutations.\n\nRisk: Scheduler payloads or persistent sessions can keep using stale prompts, policies, delivery routes, or model settings.\n\nMitigation: Use thin scheduler references, resolve manifests and policy files at runtime, and verify the registered scheduler payload and execution substrate.\n\n## Reference(s):\n\n- [Architecture patterns for reliable scheduled jobs](references/architecture-patterns.md)\n- [Example migration: Daily briefing job](references/example-migration-daily-briefing.md)\n- [Job manifest template](references/job-manifest-template.json)\n- [Migration checklist for stale scheduled jobs](references/migration-checklist.md)\n- [Reliability review for scheduled job architecture](references/reliability-review.md)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown, Code, Shell commands, Configuration]\n\n**Output Format:** [Markdown guidance with JSON manifest examples and inline command recommendations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include runtime pattern recommendations, migration steps, verification plans, delivery contracts, and rollout approval gates.]\n\n## Skill Version(s):\n\n1.1.0 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.0.4: 8 files, 12113 bytes\n\nFiles: _meta.json (138b), references/architecture-patterns.md (3249b), references/example-migration-daily-briefing.md (2878b), references/job-manifest-template.json (1273b), references/migration-checklist.md (1933b), references/reliability-review.md (2290b), skill-card.md (2823b), SKILL.md (10978b)\n\nFile v1.0.4:SKILL.md\n\n---\nname: dr-schedule-manager\ndescription: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. Use when cron jobs, daily briefings, reminders, digests, or background agents keep using stale models, stale prompts, stale session state, or detached execution contexts. Also use when standardizing automation architecture across multiple agents or converting brittle time-triggered workflows into reusable config-driven jobs.\n---\n\n# dr-schedule-manager\n\nBuild scheduled automations so each run reflects current configuration immediately.\n\n## Core outcome\n\nThis skill is a scheduling **architecture and migration playbook**, not a one-command scheduler installer.\n\nAfter installation or migration, scheduled jobs should:\n- pick up current prompt changes on the next run\n- pick up current policy changes on the next run\n- pick up current delivery changes on the next run\n- pick up current default model changes on the next run, unless intentionally pinned\n- avoid stale session residue from prior runs\n\nIf a design does not guarantee those properties, do not recommend it as the default.\n\n## Current OpenClaw constraint\n\nTreat current OpenClaw cron as **snapshot-based unless proven otherwise**.\n\nIn practice, cron jobs may embed:\n- prompt text\n- model override\n- delivery route\n- other runtime details\n\nThat means editing local files alone may **not** change the behavior of the already-registered job.\n\nBecause of this, the preferred practical pattern for current OpenClaw is not \"fat job config in cron\". It is:\n- thin trigger in cron\n- local file resolution at runtime\n- explicit final delivery through the normal outbound path\n\n## Default architecture\n\nPrefer a **thin-trigger, fresh-run, config-driven job architecture**.\n\n### Rule 1, scheduler is only a trigger carrier\n\nThe scheduler should only:\n- wake the job\n- identify the job slug or manifest\n- pass a small stable trigger message\n\nDo not embed business logic, formatting rules, or model decisions in the scheduler unless you intentionally accept snapshot behavior.\n\n### Rule 2, manifest is the operational contract\n\nEach scheduled job should have a manifest file that defines:\n- slug\n- name\n- agent id\n- schedule\n- runtime mode\n- trigger mode\n- prompt file path\n- policy file paths\n- delivery contract\n- model policy\n- verification rules\n- live scheduler id if your local tooling tracks one\n\n### Rule 3, runtime assembly happens at execution time\n\nOn every run, load current files before generating output.\n\nAlways assemble from:\n- current manifest\n- current prompt file\n- current policy files\n- current delivery rules\n- current model policy\n\nDo not trust previous session state for these.\n\n### Rule 4, delivery is explicit and provider-aware\n\nStore delivery in a clear adapter contract.\n\nDo not assume session metadata is valid for outbound sends if the provider requires a different target format.\n\n### Rule 5, persistent sessions are not the source of truth\n\nIf you keep a persistent automation agent, use it only as a dispatcher or coordinator.\n\nDo not let a persistent scheduled session be the authoritative source for:\n- prompt wording\n- model selection\n- formatting rules\n- delivery routing\n\n## Approved patterns\n\n### Pattern A, wake-only trigger into fresh main execution\n\nUse when you want the latest main assistant behavior to apply automatically.\n\nBest for:\n- personal briefings\n- reminders\n- evolving assistant workflows\n\nStrengths:\n- changes propagate immediately\n- minimal drift risk\n- simple to reason about\n\nWeaknesses:\n- less isolated\n- changes to main behavior affect the job immediately\n\n### Pattern B, thin trigger plus local manifest resolution\n\nUse as the default reusable pattern across agents for current OpenClaw.\n\nBest for:\n- reusable automation frameworks\n- reports and digests\n- jobs that need clean state on every run\n- setups where cron otherwise snapshots prompt, model, or delivery\n\nHow it works:\n- cron stores only a small stable trigger\n- the triggered agent reads local job files at runtime\n- prompt, policy, model policy, and delivery are resolved from the workspace\n- final delivery uses the normal outbound path, not cron announce, when announce is unreliable\n\nStrengths:\n- avoids stale embedded prompt drift\n- avoids stale model pins in cron payloads\n- makes file edits effective on the next run\n- easy to migrate across agents\n\nWeaknesses:\n- requires the agent to actually honor the trigger by reading the local files\n- still depends on reliable final outbound delivery\n\n### Pattern C, persistent dispatcher plus fresh worker run\n\nUse for more advanced orchestration.\n\nBest for:\n- retry queues\n- fan-out workflows\n- multi-step automation pipelines\n\nStrengths:\n- scalable\n- strong separation between orchestration and generation\n\nWeaknesses:\n- more moving parts\n\n## Default recommendation\n\nFor most current OpenClaw scheduled jobs, use **Pattern B, thin trigger plus local manifest resolution**.\n\nReason:\n- it works around snapshot-based cron behavior\n- it is reusable across many agents\n- it avoids stale embedded prompt and model drift\n- changes are effective on the next run because runtime inputs are file-based\n- it scales better than manual re-registration for every content tweak\n\n## Checkpointed rollout safety\n\nWhen implementing or changing real scheduled behavior, use `dr-checkpoint-implementation`.\n\nThis applies to:\n- cron jobs\n- reminders\n- briefings\n- digests\n- alerting or monitoring jobs\n- delivery flows\n- background agents that write, notify, or mutate production state\n\nWork in checkpoints:\n1. Discover current scheduler, manifest, prompt, policy, model, session, and delivery state.\n2. Design or update the manifest and file-based runtime contract.\n3. Dry-run generation from current files without live delivery.\n4. Test outbound delivery separately from scheduler announce behavior.\n5. Test the scheduler trigger separately from content generation.\n6. Calibrate timing, cooldowns, suppression, and failure behavior where alerts or notifications are involved.\n7. Enable live cron delivery or production mutations only after user approval.\n\nSelf-approve routine checkpoints only when validation passes and no new live side effect is introduced.\n\nStop for user approval before:\n- enabling or changing live cron delivery\n- sending notifications, emails, or public posts\n- writing or mutating production data\n- changing a customer-facing schedule\n- changing alert thresholds, cooldowns, or suppression behavior\n- accepting weak, missing, or contradictory validation\n\n## Model policy rules\n\nModel behavior must be explicit.\n\n### Preferred\n\nUse inherit-default when upgrades should propagate automatically.\n\nExample:\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\n### Use only when intentionally pinned\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}\n```\n\nIf pinning is used, document why.\n\n### Shared-policy option\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same rule.\n\n## Verification rules\n\nVerification should catch broken assembly, not freeze intended upgrades.\n\nGood checks:\n- prompt path exists\n- policy paths exist\n- delivery route matches current job contract\n- schedule matches manifest\n- pinned model matches manifest, if pinning is intentional\n\nAvoid exact verification for settings that are supposed to inherit current defaults.\n\nIf the job should follow current default model changes, do **not** require an exact old model string.\n\n## Anti-patterns\n\nReject these by default.\n\n### Embedded full-payload cron jobs for dynamic automations\n\nA cron job stores the full prompt, model, and delivery configuration even though the automation is expected to evolve via local files.\n\n### Stale exact model pinning\n\nA manifest or cron payload hardcodes an old model and exact verification preserves it forever.\n\n### Chat-only preference changes\n\nA user requests a format change in chat, but the job still reads an older prompt source.\n\n### Session-derived outbound routing\n\nOutbound delivery copies stale or misleading session metadata rather than a provider-valid target.\n\n### Persistent scheduled generation context\n\nA long-lived automation session accumulates outdated assumptions and keeps using them.\n\n### Assuming scheduler reliability equals delivery reliability\n\nA job can resolve current local files correctly and still fail because the scheduler's announce/delivery adapter is broken.\n\n## Migration workflow\n\nWhen fixing an existing job:\n\n1. Inspect current manifest and scheduler behavior\n2. Identify stale sources\n   - model\n   - prompt\n   - policy\n   - delivery\n   - session mode\n   - embedded cron payloads\n3. Move all durable rules into files\n4. Replace fat cron payloads with a thin stable trigger\n5. Choose model policy\n6. Make delivery explicit\n7. Reduce over-strict verification that blocks intended inheritance\n8. Dry-run generation from current files without live delivery\n9. Test final delivery separately\n10. Test scheduler trigger behavior separately from delivery\n11. Get user approval before enabling live delivery or production mutations\n12. Record provider-specific quirks\n\n## Required output when using this skill\n\nProvide:\n- recommended runtime pattern\n- manifest structure\n- model policy recommendation\n- delivery contract recommendation\n- what must move out of session state\n- migration steps\n- verification plan\n- checkpoint plan and approval gates for rollout\n- reliability risks and tradeoffs\n- whether additional local execution tooling is still required\n\n## Reliability review checklist\n\nBefore declaring the architecture good, confirm:\n- a prompt edit affects the next run\n- a policy edit affects the next run\n- a delivery target edit affects the next run\n- a default-model change affects the next run when inherit-default is used\n- the scheduler stores only a thin trigger for dynamic jobs, or re-registration is explicitly part of the workflow\n- no persistent session is required for content correctness\n- provider-specific outbound routing is documented where needed\n- final delivery works independently of cron announce delivery\n- dry-run or shadow output was reviewed before live delivery\n- live delivery, notifications, writes, or production mutations were explicitly approved\n\n## References\n\nRead `references/architecture-patterns.md` when designing the execution model.\nRead `references/migration-checklist.md` when converting an existing stale scheduled job.\nRead `references/reliability-review.md` before finalizing a job architecture or publishing this pattern for wider reuse.\nRead `references/job-manifest-template.json` for the recommended manifest shape.\nRead `references/example-migration-daily-briefing.md` for a concrete migration from a stale scheduled digest to a fresh-runtime job.\n\nFile v1.0.4:_meta.json\n\n{\n  \"ownerId\": \"kn75qhdfr3qnbx390tbrjgz48981y6e4\",\n  \"slug\": \"dr-schedule-manager\",\n  \"version\": \"1.0.4\",\n  \"publishedAt\": 1782636376872\n}\n\nFile v1.0.4:references/architecture-patterns.md\n\n# Architecture patterns for reliable scheduled jobs\n\n## Design goal\n\nA scheduled job should reflect current configuration on the very next run.\n\nThat means changes to:\n- prompt\n- policy\n- delivery route\n- default model\n\nmust be loaded at execution time, not remembered from stale session state.\n\n## Recommended default\n\nUse a thin-trigger, file-resolved execution path.\n\nThe scheduler should carry only a small stable trigger. The runtime then assembles the job from local files.\n\n## Current OpenClaw reality\n\nCurrent OpenClaw cron jobs may embed prompt text, model choice, and delivery details directly in the registered job.\n\nThat means cron can behave as a snapshot system unless you deliberately design around it.\n\nFor dynamic automations, do not treat the cron registration as the canonical source of truth.\nTreat it as a trigger carrier.\n\n## Pattern A, wake-only trigger into fresh main execution\n\nUse when:\n- you want the latest main assistant behavior automatically\n- isolation is less important than immediate propagation\n\nPros:\n- very low drift\n- changes apply immediately\n\nCons:\n- less isolated\n- changes in main behavior can affect the job unexpectedly\n\n## Pattern B, fresh isolated run from manifest\n\nUse when:\n- you want reusable architecture across many agents\n- each run should start clean\n- immediate application of file changes matters\n\nPros:\n- predictable\n- portable\n- avoids stale session memory\n\nCons:\n- requires disciplined manifests and policy files\n\n## Pattern C, dispatcher plus fresh worker\n\nUse when:\n- orchestration complexity exists\n- retries or queues matter\n- multi-step automations are needed\n\nPros:\n- scalable\n- separates orchestration from generation\n\nCons:\n- more moving parts\n\n## Manifest recommendations\n\nA manifest should explicitly define:\n- slug\n- name\n- agentId\n- schedule\n- runtimeMode\n- triggerMode\n- promptFile\n- policyFiles\n- delivery\n- modelPolicy\n- verify\n- live scheduler id when your local tooling keeps one\n\n## Model policy recommendations\n\n### Best default\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\nUse when the job should follow system model upgrades.\n\n### Intentional pinning\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}\n```\n\nOnly use if output stability outweighs automatic upgrades.\n\n### Shared policy file\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same resolution behavior.\n\n## Verification recommendations\n\nVerification should ensure assembly correctness.\n\nGood checks:\n- manifest exists\n- prompt file exists\n- policy files exist\n- delivery target matches policy\n- schedule matches manifest\n- pinned model matches manifest if pinning is intentional\n\nBad checks:\n- exact model verification when model inheritance is intended\n- exact prompt text verification when prompt changes should be allowed through file edits\n\n## Delivery recommendations\n\nDelivery must be explicit and provider-aware.\n\nExample:\n\n```json\n{\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\"\n  }\n}\n```\n\nDo not trust session metadata blindly for outbound sends.\n\nFile v1.0.4:references/example-migration-daily-briefing.md\n\n# Example migration: Daily briefing job\n\n## Symptoms\n\nA daily briefing keeps using old settings even after the system changed.\n\nTypical signs:\n- old model still in use\n- old formatting still in use\n- requested changes take multiple attempts to stick\n- delivery route behaves differently from current runtime expectations\n\n## Root causes to check\n\n- manifest pins an outdated model\n- session mode is isolated but still behaves like a stale long-lived context\n- prompt changes live partly in chat history instead of files\n- outbound delivery route uses misleading session metadata\n- verification rules freeze old configuration\n\n## Before\n\nExample brittle pattern:\n\n```json\n{\n  \"model\": \"old-hardcoded-model-example\",\n  \"session\": \"isolated\",\n  \"wake\": \"now\",\n  \"to\": \"channel:1476754066481877155\",\n  \"verify\": {\n    \"requirePromptExact\": true,\n    \"requireModelExact\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true\n  }\n}\n```\n\nProblems:\n- old model pin\n- exact model verification locks drift in place\n- outbound target may not be the provider-valid DM form\n- prompt exactness can hide where the true source of truth lives\n\n## After\n\nRecommended fresh-runtime pattern:\n\n```json\n{\n  \"slug\": \"daily-ai-briefing\",\n  \"cronId\": \"replace-with-live-cron-id-if-tracked-locally\",\n  \"name\": \"daily-ai-briefing\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/daily-ai-briefing/prompt.md\",\n  \"policyFiles\": [\n    \"automation/jobs/daily-ai-briefing/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  }\n}\n```\n\nIf you're using a local automation manager, keeping `slug` and `cronId` in the manifest makes reconciliation and verification deterministic.\n\n## Why this fixes drift\n\n- prompt is loaded from file every run\n- policy is loaded from file every run\n- delivery target is explicit and provider-valid\n- model follows current default unless intentionally pinned\n- exact model verification no longer preserves an outdated pin\n\n## Validation checklist\n\nAfter migration, confirm:\n- editing the prompt changes the next run\n- editing the policy changes the next run\n- changing the default model affects the next run\n- delivery still works after a live send test\n- attachments work if the job needs them\n\n## Provider-specific reminder\n\nFor Discord DMs, outbound sends may require `user:<discord_user_id>` even if session metadata suggests a `channel:<id>` route.\n\nFile v1.0.4:references/job-manifest-template.json\n\n{\n  \"slug\": \"example-scheduled-job\",\n  \"cronId\": \"replace-with-live-cron-id-if-your-tooling-tracks-it\",\n  \"name\": \"Example scheduled job\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/example-scheduled-job/prompt.md\",\n  \"policyFiles\": [\n    \"automation/policies/default-runtime.json\",\n    \"automation/jobs/example-scheduled-job/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  },\n  \"notes\": [\n    \"Set requireModelExact=true only when modelPolicy.mode is pin.\",\n    \"Do not rely on session metadata for outbound delivery if the provider requires a different target format.\",\n    \"Every run should load promptFile and policyFiles fresh.\",\n    \"If your local automation manager tracks live scheduler ids, keep cronId in sync after create/edit operations.\"\n  ]\n}\n\nFile v1.0.4:references/migration-checklist.md\n\n# Migration checklist for stale scheduled jobs\n\n## Goal\n\nConvert a brittle scheduled job into a design where changes are effective on the next run.\n\n## Checklist\n\n### 1. Inspect the current job\n\nCheck:\n- model field\n- session mode\n- prompt source\n- policy source\n- delivery route\n- verification rules\n\n### 2. Identify drift sources\n\nCommon causes:\n- old pinned model\n- isolated stale session behavior\n- prompt rules only stored in chat history\n- delivery target copied from misleading session metadata\n- exact verification preventing intended inheritance\n- cron registration embedding old prompt, model, or delivery values\n\n### 3. Move behavior into files\n\nCreate or update:\n- manifest\n- prompt file\n- policy file\n- local registry or scheduler-id mapping if your tooling reconciles live jobs\n\n### 4. Fix model policy\n\nChoose one:\n- inherit-default\n- pin\n- policy-file\n\nDefault: inherit-default.\n\n### 5. Replace fat cron payloads with thin triggers\n\nMake the cron payload a small stable instruction that tells the agent to load local files.\n\n### 6. Make delivery explicit\n\nWrite the exact provider-valid outbound target in the manifest.\n\n### 7. Relax harmful verification\n\nKeep checks that validate assembly.\nRemove checks that freeze old desired behavior.\n\n### 8. Test one live run for content freshness\n\nConfirm:\n- current prompt is used\n- current policy is used\n- current model policy behaves as intended\n\n### 9. Test final delivery separately\n\nConfirm:\n- the final outbound route works\n- attachments work if relevant\n- cron announce is not silently masking a delivery bug\n\n### 10. Record discovered quirks\n\nDocument provider-specific routing or runtime behavior for future reuse.\n\n### 11. Record ownership boundaries\n\nWrite down whether the design is:\n- architecture-only guidance\n- a manifest convention\n- or a complete installable execution path\n\nDo not imply a one-command rollout if local execution tooling is still required.\n\nFile v1.0.4:references/reliability-review.md\n\n# Reliability review for scheduled job architecture\n\nUse this before publishing or rolling out a scheduling pattern.\n\n## A design is reliable only if all are true\n\n- Prompt changes take effect on the next run.\n- Policy changes take effect on the next run.\n- Delivery changes take effect on the next run.\n- Default model changes take effect on the next run when inheritance is intended.\n- Pinned model behavior is explicit and documented when inheritance is not intended.\n- Dynamic jobs do not depend on fat embedded cron payloads unless re-registration is explicitly part of the process.\n- No persistent session is required for correctness of content generation.\n- Provider-specific outbound routing is documented where needed.\n- Verification checks assembly correctness without blocking intended updates.\n- Final delivery has been tested independently from scheduler announce behavior.\n\n## Review questions\n\n### Runtime freshness\n\n- Does every run read current files?\n- Can a stale session override current files?\n- Is generation happening in a clean runtime?\n\n### Model freshness\n\n- Is the model intentionally inherited or intentionally pinned?\n- Could an old manifest silently keep using an outdated model?\n- Does verification accidentally lock an old model in place?\n\n### Prompt and policy freshness\n\n- Are formatting and content rules stored in files?\n- Would a file edit affect the next run without extra manual steps?\n\n### Delivery correctness\n\n- Is outbound delivery defined explicitly?\n- Is the target format valid for the provider?\n- Have attachments been tested if relevant?\n- Is normal outbound delivery working even if cron announce delivery is not?\n\n### Operational resilience\n\n- Can the job fail safely?\n- Can it be re-run cleanly?\n- Can another agent reuse the pattern without hidden assumptions?\n\n## Red flags\n\n- exact old model pinned without a clear reason\n- persistent automation session used as content source of truth\n- prompt requirements only captured in conversation history\n- delivery route inferred from stale session metadata\n- verification that prevents intended updates from taking effect\n- cron registration storing the full job content for a supposedly dynamic automation\n- relying on cron announce delivery without separately testing the real outbound path\n\nFile v1.0.4:skill-card.md\n\n## Description: <br>\nDesign and implement reliable scheduled or event-triggered OpenClaw automations that load current model, prompt, delivery, and policy configuration on each run. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[daniel-refahi-ikara](https://clawhub.ai/user/daniel-refahi-ikara) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineers use this skill to design, migrate, and review scheduled OpenClaw jobs such as daily briefings, reminders, digests, alerts, and background automations so each run uses current files and explicit delivery rules. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Users may treat the playbook as a ready-made scheduler and enable live notifications, public posts, or production changes before validating behavior. <br>\nMitigation: Keep dry-runs enabled during setup and require explicit approval before live delivery or production mutations. <br>\nRisk: Scheduled jobs can keep using stale prompts, policies, delivery routes, or model settings if cron payloads or persistent sessions remain the source of truth. <br>\nMitigation: Use a thin trigger and load the manifest, prompt files, policy files, delivery contract, and model policy at runtime. <br>\nRisk: Delivery can fail or route incorrectly when session metadata is reused instead of a provider-valid outbound target. <br>\nMitigation: Define delivery explicitly in the manifest and test final outbound delivery separately from scheduler trigger behavior. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/daniel-refahi-ikara/skills/dr-schedule-manager) <br>\n- [Architecture patterns](references/architecture-patterns.md) <br>\n- [Migration checklist](references/migration-checklist.md) <br>\n- [Reliability review](references/reliability-review.md) <br>\n- [Job manifest template](references/job-manifest-template.json) <br>\n- [Example migration: Daily briefing job](references/example-migration-daily-briefing.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, configuration, guidance] <br>\n**Output Format:** [Markdown guidance with JSON manifest examples] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include migration steps, verification plans, checkpoint approval gates, reliability tradeoffs, and notes about required local execution tooling.] <br>\n\n## Skill Version(s): <br>\n1.0.4 (source: server release metadata and _meta.json) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.3: 8 files, 12158 bytes\n\nFiles: _meta.json (138b), references/architecture-patterns.md (3249b), references/example-migration-daily-briefing.md (2878b), references/job-manifest-template.json (1273b), references/migration-checklist.md (1933b), references/reliability-review.md (2290b), skill-card.md (2974b), SKILL.md (10978b)\n\nFile v1.0.3:SKILL.md\n\n---\nname: dr-schedule-manager\ndescription: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. Use when cron jobs, daily briefings, reminders, digests, or background agents keep using stale models, stale prompts, stale session state, or detached execution contexts. Also use when standardizing automation architecture across multiple agents or converting brittle time-triggered workflows into reusable config-driven jobs.\n---\n\n# dr-schedule-manager\n\nBuild scheduled automations so each run reflects current configuration immediately.\n\n## Core outcome\n\nThis skill is a scheduling **architecture and migration playbook**, not a one-command scheduler installer.\n\nAfter installation or migration, scheduled jobs should:\n- pick up current prompt changes on the next run\n- pick up current policy changes on the next run\n- pick up current delivery changes on the next run\n- pick up current default model changes on the next run, unless intentionally pinned\n- avoid stale session residue from prior runs\n\nIf a design does not guarantee those properties, do not recommend it as the default.\n\n## Current OpenClaw constraint\n\nTreat current OpenClaw cron as **snapshot-based unless proven otherwise**.\n\nIn practice, cron jobs may embed:\n- prompt text\n- model override\n- delivery route\n- other runtime details\n\nThat means editing local files alone may **not** change the behavior of the already-registered job.\n\nBecause of this, the preferred practical pattern for current OpenClaw is not \"fat job config in cron\". It is:\n- thin trigger in cron\n- local file resolution at runtime\n- explicit final delivery through the normal outbound path\n\n## Default architecture\n\nPrefer a **thin-trigger, fresh-run, config-driven job architecture**.\n\n### Rule 1, scheduler is only a trigger carrier\n\nThe scheduler should only:\n- wake the job\n- identify the job slug or manifest\n- pass a small stable trigger message\n\nDo not embed business logic, formatting rules, or model decisions in the scheduler unless you intentionally accept snapshot behavior.\n\n### Rule 2, manifest is the operational contract\n\nEach scheduled job should have a manifest file that defines:\n- slug\n- name\n- agent id\n- schedule\n- runtime mode\n- trigger mode\n- prompt file path\n- policy file paths\n- delivery contract\n- model policy\n- verification rules\n- live scheduler id if your local tooling tracks one\n\n### Rule 3, runtime assembly happens at execution time\n\nOn every run, load current files before generating output.\n\nAlways assemble from:\n- current manifest\n- current prompt file\n- current policy files\n- current delivery rules\n- current model policy\n\nDo not trust previous session state for these.\n\n### Rule 4, delivery is explicit and provider-aware\n\nStore delivery in a clear adapter contract.\n\nDo not assume session metadata is valid for outbound sends if the provider requires a different target format.\n\n### Rule 5, persistent sessions are not the source of truth\n\nIf you keep a persistent automation agent, use it only as a dispatcher or coordinator.\n\nDo not let a persistent scheduled session be the authoritative source for:\n- prompt wording\n- model selection\n- formatting rules\n- delivery routing\n\n## Approved patterns\n\n### Pattern A, wake-only trigger into fresh main execution\n\nUse when you want the latest main assistant behavior to apply automatically.\n\nBest for:\n- personal briefings\n- reminders\n- evolving assistant workflows\n\nStrengths:\n- changes propagate immediately\n- minimal drift risk\n- simple to reason about\n\nWeaknesses:\n- less isolated\n- changes to main behavior affect the job immediately\n\n### Pattern B, thin trigger plus local manifest resolution\n\nUse as the default reusable pattern across agents for current OpenClaw.\n\nBest for:\n- reusable automation frameworks\n- reports and digests\n- jobs that need clean state on every run\n- setups where cron otherwise snapshots prompt, model, or delivery\n\nHow it works:\n- cron stores only a small stable trigger\n- the triggered agent reads local job files at runtime\n- prompt, policy, model policy, and delivery are resolved from the workspace\n- final delivery uses the normal outbound path, not cron announce, when announce is unreliable\n\nStrengths:\n- avoids stale embedded prompt drift\n- avoids stale model pins in cron payloads\n- makes file edits effective on the next run\n- easy to migrate across agents\n\nWeaknesses:\n- requires the agent to actually honor the trigger by reading the local files\n- still depends on reliable final outbound delivery\n\n### Pattern C, persistent dispatcher plus fresh worker run\n\nUse for more advanced orchestration.\n\nBest for:\n- retry queues\n- fan-out workflows\n- multi-step automation pipelines\n\nStrengths:\n- scalable\n- strong separation between orchestration and generation\n\nWeaknesses:\n- more moving parts\n\n## Default recommendation\n\nFor most current OpenClaw scheduled jobs, use **Pattern B, thin trigger plus local manifest resolution**.\n\nReason:\n- it works around snapshot-based cron behavior\n- it is reusable across many agents\n- it avoids stale embedded prompt and model drift\n- changes are effective on the next run because runtime inputs are file-based\n- it scales better than manual re-registration for every content tweak\n\n## Checkpointed rollout safety\n\nWhen implementing or changing real scheduled behavior, use `dr-checkpoint-implementation`.\n\nThis applies to:\n- cron jobs\n- reminders\n- briefings\n- digests\n- alerting or monitoring jobs\n- delivery flows\n- background agents that write, notify, or mutate production state\n\nWork in checkpoints:\n1. Discover current scheduler, manifest, prompt, policy, model, session, and delivery state.\n2. Design or update the manifest and file-based runtime contract.\n3. Dry-run generation from current files without live delivery.\n4. Test outbound delivery separately from scheduler announce behavior.\n5. Test the scheduler trigger separately from content generation.\n6. Calibrate timing, cooldowns, suppression, and failure behavior where alerts or notifications are involved.\n7. Enable live cron delivery or production mutations only after user approval.\n\nSelf-approve routine checkpoints only when validation passes and no new live side effect is introduced.\n\nStop for user approval before:\n- enabling or changing live cron delivery\n- sending notifications, emails, or public posts\n- writing or mutating production data\n- changing a customer-facing schedule\n- changing alert thresholds, cooldowns, or suppression behavior\n- accepting weak, missing, or contradictory validation\n\n## Model policy rules\n\nModel behavior must be explicit.\n\n### Preferred\n\nUse inherit-default when upgrades should propagate automatically.\n\nExample:\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\n### Use only when intentionally pinned\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}\n```\n\nIf pinning is used, document why.\n\n### Shared-policy option\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same rule.\n\n## Verification rules\n\nVerification should catch broken assembly, not freeze intended upgrades.\n\nGood checks:\n- prompt path exists\n- policy paths exist\n- delivery route matches current job contract\n- schedule matches manifest\n- pinned model matches manifest, if pinning is intentional\n\nAvoid exact verification for settings that are supposed to inherit current defaults.\n\nIf the job should follow current default model changes, do **not** require an exact old model string.\n\n## Anti-patterns\n\nReject these by default.\n\n### Embedded full-payload cron jobs for dynamic automations\n\nA cron job stores the full prompt, model, and delivery configuration even though the automation is expected to evolve via local files.\n\n### Stale exact model pinning\n\nA manifest or cron payload hardcodes an old model and exact verification preserves it forever.\n\n### Chat-only preference changes\n\nA user requests a format change in chat, but the job still reads an older prompt source.\n\n### Session-derived outbound routing\n\nOutbound delivery copies stale or misleading session metadata rather than a provider-valid target.\n\n### Persistent scheduled generation context\n\nA long-lived automation session accumulates outdated assumptions and keeps using them.\n\n### Assuming scheduler reliability equals delivery reliability\n\nA job can resolve current local files correctly and still fail because the scheduler's announce/delivery adapter is broken.\n\n## Migration workflow\n\nWhen fixing an existing job:\n\n1. Inspect current manifest and scheduler behavior\n2. Identify stale sources\n   - model\n   - prompt\n   - policy\n   - delivery\n   - session mode\n   - embedded cron payloads\n3. Move all durable rules into files\n4. Replace fat cron payloads with a thin stable trigger\n5. Choose model policy\n6. Make delivery explicit\n7. Reduce over-strict verification that blocks intended inheritance\n8. Dry-run generation from current files without live delivery\n9. Test final delivery separately\n10. Test scheduler trigger behavior separately from delivery\n11. Get user approval before enabling live delivery or production mutations\n12. Record provider-specific quirks\n\n## Required output when using this skill\n\nProvide:\n- recommended runtime pattern\n- manifest structure\n- model policy recommendation\n- delivery contract recommendation\n- what must move out of session state\n- migration steps\n- verification plan\n- checkpoint plan and approval gates for rollout\n- reliability risks and tradeoffs\n- whether additional local execution tooling is still required\n\n## Reliability review checklist\n\nBefore declaring the architecture good, confirm:\n- a prompt edit affects the next run\n- a policy edit affects the next run\n- a delivery target edit affects the next run\n- a default-model change affects the next run when inherit-default is used\n- the scheduler stores only a thin trigger for dynamic jobs, or re-registration is explicitly part of the workflow\n- no persistent session is required for content correctness\n- provider-specific outbound routing is documented where needed\n- final delivery works independently of cron announce delivery\n- dry-run or shadow output was reviewed before live delivery\n- live delivery, notifications, writes, or production mutations were explicitly approved\n\n## References\n\nRead `references/architecture-patterns.md` when designing the execution model.\nRead `references/migration-checklist.md` when converting an existing stale scheduled job.\nRead `references/reliability-review.md` before finalizing a job architecture or publishing this pattern for wider reuse.\nRead `references/job-manifest-template.json` for the recommended manifest shape.\nRead `references/example-migration-daily-briefing.md` for a concrete migration from a stale scheduled digest to a fresh-runtime job.\n\nFile v1.0.3:_meta.json\n\n{\n  \"ownerId\": \"kn75qhdfr3qnbx390tbrjgz48981y6e4\",\n  \"slug\": \"dr-schedule-manager\",\n  \"version\": \"1.0.3\",\n  \"publishedAt\": 1782636139800\n}\n\nFile v1.0.3:references/architecture-patterns.md\n\n# Architecture patterns for reliable scheduled jobs\n\n## Design goal\n\nA scheduled job should reflect current configuration on the very next run.\n\nThat means changes to:\n- prompt\n- policy\n- delivery route\n- default model\n\nmust be loaded at execution time, not remembered from stale session state.\n\n## Recommended default\n\nUse a thin-trigger, file-resolved execution path.\n\nThe scheduler should carry only a small stable trigger. The runtime then assembles the job from local files.\n\n## Current OpenClaw reality\n\nCurrent OpenClaw cron jobs may embed prompt text, model choice, and delivery details directly in the registered job.\n\nThat means cron can behave as a snapshot system unless you deliberately design around it.\n\nFor dynamic automations, do not treat the cron registration as the canonical source of truth.\nTreat it as a trigger carrier.\n\n## Pattern A, wake-only trigger into fresh main execution\n\nUse when:\n- you want the latest main assistant behavior automatically\n- isolation is less important than immediate propagation\n\nPros:\n- very low drift\n- changes apply immediately\n\nCons:\n- less isolated\n- changes in main behavior can affect the job unexpectedly\n\n## Pattern B, fresh isolated run from manifest\n\nUse when:\n- you want reusable architecture across many agents\n- each run should start clean\n- immediate application of file changes matters\n\nPros:\n- predictable\n- portable\n- avoids stale session memory\n\nCons:\n- requires disciplined manifests and policy files\n\n## Pattern C, dispatcher plus fresh worker\n\nUse when:\n- orchestration complexity exists\n- retries or queues matter\n- multi-step automations are needed\n\nPros:\n- scalable\n- separates orchestration from generation\n\nCons:\n- more moving parts\n\n## Manifest recommendations\n\nA manifest should explicitly define:\n- slug\n- name\n- agentId\n- schedule\n- runtimeMode\n- triggerMode\n- promptFile\n- policyFiles\n- delivery\n- modelPolicy\n- verify\n- live scheduler id when your local tooling keeps one\n\n## Model policy recommendations\n\n### Best default\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\nUse when the job should follow system model upgrades.\n\n### Intentional pinning\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}\n```\n\nOnly use if output stability outweighs automatic upgrades.\n\n### Shared policy file\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same resolution behavior.\n\n## Verification recommendations\n\nVerification should ensure assembly correctness.\n\nGood checks:\n- manifest exists\n- prompt file exists\n- policy files exist\n- delivery target matches policy\n- schedule matches manifest\n- pinned model matches manifest if pinning is intentional\n\nBad checks:\n- exact model verification when model inheritance is intended\n- exact prompt text verification when prompt changes should be allowed through file edits\n\n## Delivery recommendations\n\nDelivery must be explicit and provider-aware.\n\nExample:\n\n```json\n{\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\"\n  }\n}\n```\n\nDo not trust session metadata blindly for outbound sends.\n\nFile v1.0.3:references/example-migration-daily-briefing.md\n\n# Example migration: Daily briefing job\n\n## Symptoms\n\nA daily briefing keeps using old settings even after the system changed.\n\nTypical signs:\n- old model still in use\n- old formatting still in use\n- requested changes take multiple attempts to stick\n- delivery route behaves differently from current runtime expectations\n\n## Root causes to check\n\n- manifest pins an outdated model\n- session mode is isolated but still behaves like a stale long-lived context\n- prompt changes live partly in chat history instead of files\n- outbound delivery route uses misleading session metadata\n- verification rules freeze old configuration\n\n## Before\n\nExample brittle pattern:\n\n```json\n{\n  \"model\": \"old-hardcoded-model-example\",\n  \"session\": \"isolated\",\n  \"wake\": \"now\",\n  \"to\": \"channel:1476754066481877155\",\n  \"verify\": {\n    \"requirePromptExact\": true,\n    \"requireModelExact\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true\n  }\n}\n```\n\nProblems:\n- old model pin\n- exact model verification locks drift in place\n- outbound target may not be the provider-valid DM form\n- prompt exactness can hide where the true source of truth lives\n\n## After\n\nRecommended fresh-runtime pattern:\n\n```json\n{\n  \"slug\": \"daily-ai-briefing\",\n  \"cronId\": \"replace-with-live-cron-id-if-tracked-locally\",\n  \"name\": \"daily-ai-briefing\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/daily-ai-briefing/prompt.md\",\n  \"policyFiles\": [\n    \"automation/jobs/daily-ai-briefing/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  }\n}\n```\n\nIf you're using a local automation manager, keeping `slug` and `cronId` in the manifest makes reconciliation and verification deterministic.\n\n## Why this fixes drift\n\n- prompt is loaded from file every run\n- policy is loaded from file every run\n- delivery target is explicit and provider-valid\n- model follows current default unless intentionally pinned\n- exact model verification no longer preserves an outdated pin\n\n## Validation checklist\n\nAfter migration, confirm:\n- editing the prompt changes the next run\n- editing the policy changes the next run\n- changing the default model affects the next run\n- delivery still works after a live send test\n- attachments work if the job needs them\n\n## Provider-specific reminder\n\nFor Discord DMs, outbound sends may require `user:<discord_user_id>` even if session metadata suggests a `channel:<id>` route.\n\nFile v1.0.3:references/job-manifest-template.json\n\n{\n  \"slug\": \"example-scheduled-job\",\n  \"cronId\": \"replace-with-live-cron-id-if-your-tooling-tracks-it\",\n  \"name\": \"Example scheduled job\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/example-scheduled-job/prompt.md\",\n  \"policyFiles\": [\n    \"automation/policies/default-runtime.json\",\n    \"automation/jobs/example-scheduled-job/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  },\n  \"notes\": [\n    \"Set requireModelExact=true only when modelPolicy.mode is pin.\",\n    \"Do not rely on session metadata for outbound delivery if the provider requires a different target format.\",\n    \"Every run should load promptFile and policyFiles fresh.\",\n    \"If your local automation manager tracks live scheduler ids, keep cronId in sync after create/edit operations.\"\n  ]\n}\n\nFile v1.0.3:references/migration-checklist.md\n\n# Migration checklist for stale scheduled jobs\n\n## Goal\n\nConvert a brittle scheduled job into a design where changes are effective on the next run.\n\n## Checklist\n\n### 1. Inspect the current job\n\nCheck:\n- model field\n- session mode\n- prompt source\n- policy source\n- delivery route\n- verification rules\n\n### 2. Identify drift sources\n\nCommon causes:\n- old pinned model\n- isolated stale session behavior\n- prompt rules only stored in chat history\n- delivery target copied from misleading session metadata\n- exact verification preventing intended inheritance\n- cron registration embedding old prompt, model, or delivery values\n\n### 3. Move behavior into files\n\nCreate or update:\n- manifest\n- prompt file\n- policy file\n- local registry or scheduler-id mapping if your tooling reconciles live jobs\n\n### 4. Fix model policy\n\nChoose one:\n- inherit-default\n- pin\n- policy-file\n\nDefault: inherit-default.\n\n### 5. Replace fat cron payloads with thin triggers\n\nMake the cron payload a small stable instruction that tells the agent to load local files.\n\n### 6. Make delivery explicit\n\nWrite the exact provider-valid outbound target in the manifest.\n\n### 7. Relax harmful verification\n\nKeep checks that validate assembly.\nRemove checks that freeze old desired behavior.\n\n### 8. Test one live run for content freshness\n\nConfirm:\n- current prompt is used\n- current policy is used\n- current model policy behaves as intended\n\n### 9. Test final delivery separately\n\nConfirm:\n- the final outbound route works\n- attachments work if relevant\n- cron announce is not silently masking a delivery bug\n\n### 10. Record discovered quirks\n\nDocument provider-specific routing or runtime behavior for future reuse.\n\n### 11. Record ownership boundaries\n\nWrite down whether the design is:\n- architecture-only guidance\n- a manifest convention\n- or a complete installable execution path\n\nDo not imply a one-command rollout if local execution tooling is still required.\n\nFile v1.0.3:references/reliability-review.md\n\n# Reliability review for scheduled job architecture\n\nUse this before publishing or rolling out a scheduling pattern.\n\n## A design is reliable only if all are true\n\n- Prompt changes take effect on the next run.\n- Policy changes take effect on the next run.\n- Delivery changes take effect on the next run.\n- Default model changes take effect on the next run when inheritance is intended.\n- Pinned model behavior is explicit and documented when inheritance is not intended.\n- Dynamic jobs do not depend on fat embedded cron payloads unless re-registration is explicitly part of the process.\n- No persistent session is required for correctness of content generation.\n- Provider-specific outbound routing is documented where needed.\n- Verification checks assembly correctness without blocking intended updates.\n- Final delivery has been tested independently from scheduler announce behavior.\n\n## Review questions\n\n### Runtime freshness\n\n- Does every run read current files?\n- Can a stale session override current files?\n- Is generation happening in a clean runtime?\n\n### Model freshness\n\n- Is the model intentionally inherited or intentionally pinned?\n- Could an old manifest silently keep using an outdated model?\n- Does verification accidentally lock an old model in place?\n\n### Prompt and policy freshness\n\n- Are formatting and content rules stored in files?\n- Would a file edit affect the next run without extra manual steps?\n\n### Delivery correctness\n\n- Is outbound delivery defined explicitly?\n- Is the target format valid for the provider?\n- Have attachments been tested if relevant?\n- Is normal outbound delivery working even if cron announce delivery is not?\n\n### Operational resilience\n\n- Can the job fail safely?\n- Can it be re-run cleanly?\n- Can another agent reuse the pattern without hidden assumptions?\n\n## Red flags\n\n- exact old model pinned without a clear reason\n- persistent automation session used as content source of truth\n- prompt requirements only captured in conversation history\n- delivery route inferred from stale session metadata\n- verification that prevents intended updates from taking effect\n- cron registration storing the full job content for a supposedly dynamic automation\n- relying on cron announce delivery without separately testing the real outbound path\n\nFile v1.0.3:skill-card.md\n\n## Description: <br>\nDesign and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[daniel-refahi-ikara](https://clawhub.ai/user/daniel-refahi-ikara) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineers use this skill to design, migrate, and review scheduled or event-triggered OpenClaw automations so each run loads current prompts, policies, delivery rules, and model policy instead of stale scheduler or session state. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill can produce scheduling manifests or migration plans that affect live sends, notifications, schedule changes, or production writes. <br>\nMitigation: Require explicit approval before enabling live delivery, changing customer-facing schedules, sending notifications, or mutating production data. <br>\nRisk: Generated manifest paths, cron IDs, model policy, or delivery targets may be incorrect for the user's local environment. <br>\nMitigation: Confirm paths, scheduler identifiers, model policy, and provider-valid delivery targets before use, then dry-run generation and test delivery separately. <br>\nRisk: Users may treat the skill as a scheduler installer even though it is a planning and migration playbook. <br>\nMitigation: Present outputs as architecture and migration guidance, and call out any additional local execution tooling required before rollout. <br>\n\n\n## Reference(s): <br>\n- [Architecture Patterns](references/architecture-patterns.md) <br>\n- [Example Migration: Daily Briefing Job](references/example-migration-daily-briefing.md) <br>\n- [Job Manifest Template](references/job-manifest-template.json) <br>\n- [Migration Checklist](references/migration-checklist.md) <br>\n- [Reliability Review](references/reliability-review.md) <br>\n- [ClawHub Skill Page](https://clawhub.ai/daniel-refahi-ikara/skills/dr-schedule-manager) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, configuration, code, shell commands, markdown] <br>\n**Output Format:** [Markdown guidance with JSON manifest examples and optional command or code snippets] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Outputs should include runtime pattern recommendations, manifest structure, model policy, delivery contract, migration steps, verification plan, approval gates, reliability risks, and tooling requirements.] <br>\n\n## Skill Version(s): <br>\n1.0.3 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.2: 8 files, 12143 bytes\n\nFiles: references/architecture-patterns.md (3239b), references/example-migration-daily-briefing.md (2865b), references/job-manifest-template.json (1273b), references/migration-checklist.md (1933b), references/reliability-review.md (2290b), skill-card.md (2901b), SKILL.md (10968b), _meta.json (138b)\n\nFile v1.0.2:SKILL.md\n\n---\nname: dr-schedule-manager\ndescription: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. Use when cron jobs, daily briefings, reminders, digests, or background agents keep using stale models, stale prompts, stale session state, or detached execution contexts. Also use when standardizing automation architecture across multiple agents or converting brittle time-triggered workflows into reusable config-driven jobs.\n---\n\n# dr-schedule-manager\n\nBuild scheduled automations so each run reflects current configuration immediately.\n\n## Core outcome\n\nThis skill is a scheduling **architecture and migration playbook**, not a one-command scheduler installer.\n\nAfter installation or migration, scheduled jobs should:\n- pick up current prompt changes on the next run\n- pick up current policy changes on the next run\n- pick up current delivery changes on the next run\n- pick up current default model changes on the next run, unless intentionally pinned\n- avoid stale session residue from prior runs\n\nIf a design does not guarantee those properties, do not recommend it as the default.\n\n## Current OpenClaw constraint\n\nTreat current OpenClaw cron as **snapshot-based unless proven otherwise**.\n\nIn practice, cron jobs may embed:\n- prompt text\n- model override\n- delivery route\n- other runtime details\n\nThat means editing local files alone may **not** change the behavior of the already-registered job.\n\nBecause of this, the preferred practical pattern for current OpenClaw is not \"fat job config in cron\". It is:\n- thin trigger in cron\n- local file resolution at runtime\n- explicit final delivery through the normal outbound path\n\n## Default architecture\n\nPrefer a **thin-trigger, fresh-run, config-driven job architecture**.\n\n### Rule 1, scheduler is only a trigger carrier\n\nThe scheduler should only:\n- wake the job\n- identify the job slug or manifest\n- pass a small stable trigger message\n\nDo not embed business logic, formatting rules, or model decisions in the scheduler unless you intentionally accept snapshot behavior.\n\n### Rule 2, manifest is the operational contract\n\nEach scheduled job should have a manifest file that defines:\n- slug\n- name\n- agent id\n- schedule\n- runtime mode\n- trigger mode\n- prompt file path\n- policy file paths\n- delivery contract\n- model policy\n- verification rules\n- live scheduler id if your local tooling tracks one\n\n### Rule 3, runtime assembly happens at execution time\n\nOn every run, load current files before generating output.\n\nAlways assemble from:\n- current manifest\n- current prompt file\n- current policy files\n- current delivery rules\n- current model policy\n\nDo not trust previous session state for these.\n\n### Rule 4, delivery is explicit and provider-aware\n\nStore delivery in a clear adapter contract.\n\nDo not assume session metadata is valid for outbound sends if the provider requires a different target format.\n\n### Rule 5, persistent sessions are not the source of truth\n\nIf you keep a persistent automation agent, use it only as a dispatcher or coordinator.\n\nDo not let a persistent scheduled session be the authoritative source for:\n- prompt wording\n- model selection\n- formatting rules\n- delivery routing\n\n## Approved patterns\n\n### Pattern A, wake-only trigger into fresh main execution\n\nUse when you want the latest main assistant behavior to apply automatically.\n\nBest for:\n- personal briefings\n- reminders\n- evolving assistant workflows\n\nStrengths:\n- changes propagate immediately\n- minimal drift risk\n- simple to reason about\n\nWeaknesses:\n- less isolated\n- changes to main behavior affect the job immediately\n\n### Pattern B, thin trigger plus local manifest resolution\n\nUse as the default reusable pattern across agents for current OpenClaw.\n\nBest for:\n- reusable automation frameworks\n- reports and digests\n- jobs that need clean state on every run\n- setups where cron otherwise snapshots prompt, model, or delivery\n\nHow it works:\n- cron stores only a small stable trigger\n- the triggered agent reads local job files at runtime\n- prompt, policy, model policy, and delivery are resolved from the workspace\n- final delivery uses the normal outbound path, not cron announce, when announce is unreliable\n\nStrengths:\n- avoids stale embedded prompt drift\n- avoids stale model pins in cron payloads\n- makes file edits effective on the next run\n- easy to migrate across agents\n\nWeaknesses:\n- requires the agent to actually honor the trigger by reading the local files\n- still depends on reliable final outbound delivery\n\n### Pattern C, persistent dispatcher plus fresh worker run\n\nUse for more advanced orchestration.\n\nBest for:\n- retry queues\n- fan-out workflows\n- multi-step automation pipelines\n\nStrengths:\n- scalable\n- strong separation between orchestration and generation\n\nWeaknesses:\n- more moving parts\n\n## Default recommendation\n\nFor most current OpenClaw scheduled jobs, use **Pattern B, thin trigger plus local manifest resolution**.\n\nReason:\n- it works around snapshot-based cron behavior\n- it is reusable across many agents\n- it avoids stale embedded prompt and model drift\n- changes are effective on the next run because runtime inputs are file-based\n- it scales better than manual re-registration for every content tweak\n\n## Checkpointed rollout safety\n\nWhen implementing or changing real scheduled behavior, use `dr-checkpoint-implementation`.\n\nThis applies to:\n- cron jobs\n- reminders\n- briefings\n- digests\n- alerting or monitoring jobs\n- delivery flows\n- background agents that write, notify, or mutate production state\n\nWork in checkpoints:\n1. Discover current scheduler, manifest, prompt, policy, model, session, and delivery state.\n2. Design or update the manifest and file-based runtime contract.\n3. Dry-run generation from current files without live delivery.\n4. Test outbound delivery separately from scheduler announce behavior.\n5. Test the scheduler trigger separately from content generation.\n6. Calibrate timing, cooldowns, suppression, and failure behavior where alerts or notifications are involved.\n7. Enable live cron delivery or production mutations only after user approval.\n\nSelf-approve routine checkpoints only when validation passes and no new live side effect is introduced.\n\nStop for user approval before:\n- enabling or changing live cron delivery\n- sending notifications, emails, or public posts\n- writing or mutating production data\n- changing a customer-facing schedule\n- changing alert thresholds, cooldowns, or suppression behavior\n- accepting weak, missing, or contradictory validation\n\n## Model policy rules\n\nModel behavior must be explicit.\n\n### Preferred\n\nUse inherit-default when upgrades should propagate automatically.\n\nExample:\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\n### Use only when intentionally pinned\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"openai-codex/gpt-5.4\"\n  }\n}\n```\n\nIf pinning is used, document why.\n\n### Shared-policy option\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same rule.\n\n## Verification rules\n\nVerification should catch broken assembly, not freeze intended upgrades.\n\nGood checks:\n- prompt path exists\n- policy paths exist\n- delivery route matches current job contract\n- schedule matches manifest\n- pinned model matches manifest, if pinning is intentional\n\nAvoid exact verification for settings that are supposed to inherit current defaults.\n\nIf the job should follow current default model changes, do **not** require an exact old model string.\n\n## Anti-patterns\n\nReject these by default.\n\n### Embedded full-payload cron jobs for dynamic automations\n\nA cron job stores the full prompt, model, and delivery configuration even though the automation is expected to evolve via local files.\n\n### Stale exact model pinning\n\nA manifest or cron payload hardcodes an old model and exact verification preserves it forever.\n\n### Chat-only preference changes\n\nA user requests a format change in chat, but the job still reads an older prompt source.\n\n### Session-derived outbound routing\n\nOutbound delivery copies stale or misleading session metadata rather than a provider-valid target.\n\n### Persistent scheduled generation context\n\nA long-lived automation session accumulates outdated assumptions and keeps using them.\n\n### Assuming scheduler reliability equals delivery reliability\n\nA job can resolve current local files correctly and still fail because the scheduler's announce/delivery adapter is broken.\n\n## Migration workflow\n\nWhen fixing an existing job:\n\n1. Inspect current manifest and scheduler behavior\n2. Identify stale sources\n   - model\n   - prompt\n   - policy\n   - delivery\n   - session mode\n   - embedded cron payloads\n3. Move all durable rules into files\n4. Replace fat cron payloads with a thin stable trigger\n5. Choose model policy\n6. Make delivery explicit\n7. Reduce over-strict verification that blocks intended inheritance\n8. Dry-run generation from current files without live delivery\n9. Test final delivery separately\n10. Test scheduler trigger behavior separately from delivery\n11. Get user approval before enabling live delivery or production mutations\n12. Record provider-specific quirks\n\n## Required output when using this skill\n\nProvide:\n- recommended runtime pattern\n- manifest structure\n- model policy recommendation\n- delivery contract recommendation\n- what must move out of session state\n- migration steps\n- verification plan\n- checkpoint plan and approval gates for rollout\n- reliability risks and tradeoffs\n- whether additional local execution tooling is still required\n\n## Reliability review checklist\n\nBefore declaring the architecture good, confirm:\n- a prompt edit affects the next run\n- a policy edit affects the next run\n- a delivery target edit affects the next run\n- a default-model change affects the next run when inherit-default is used\n- the scheduler stores only a thin trigger for dynamic jobs, or re-registration is explicitly part of the workflow\n- no persistent session is required for content correctness\n- provider-specific outbound routing is documented where needed\n- final delivery works independently of cron announce delivery\n- dry-run or shadow output was reviewed before live delivery\n- live delivery, notifications, writes, or production mutations were explicitly approved\n\n## References\n\nRead `references/architecture-patterns.md` when designing the execution model.\nRead `references/migration-checklist.md` when converting an existing stale scheduled job.\nRead `references/reliability-review.md` before finalizing a job architecture or publishing this pattern for wider reuse.\nRead `references/job-manifest-template.json` for the recommended manifest shape.\nRead `references/example-migration-daily-briefing.md` for a concrete migration from a stale scheduled digest to a fresh-runtime job.\n\nFile v1.0.2:_meta.json\n\n{\n  \"ownerId\": \"kn75qhdfr3qnbx390tbrjgz48981y6e4\",\n  \"slug\": \"dr-schedule-manager\",\n  \"version\": \"1.0.2\",\n  \"publishedAt\": 1782433085237\n}\n\nFile v1.0.2:references/architecture-patterns.md\n\n# Architecture patterns for reliable scheduled jobs\n\n## Design goal\n\nA scheduled job should reflect current configuration on the very next run.\n\nThat means changes to:\n- prompt\n- policy\n- delivery route\n- default model\n\nmust be loaded at execution time, not remembered from stale session state.\n\n## Recommended default\n\nUse a thin-trigger, file-resolved execution path.\n\nThe scheduler should carry only a small stable trigger. The runtime then assembles the job from local files.\n\n## Current OpenClaw reality\n\nCurrent OpenClaw cron jobs may embed prompt text, model choice, and delivery details directly in the registered job.\n\nThat means cron can behave as a snapshot system unless you deliberately design around it.\n\nFor dynamic automations, do not treat the cron registration as the canonical source of truth.\nTreat it as a trigger carrier.\n\n## Pattern A, wake-only trigger into fresh main execution\n\nUse when:\n- you want the latest main assistant behavior automatically\n- isolation is less important than immediate propagation\n\nPros:\n- very low drift\n- changes apply immediately\n\nCons:\n- less isolated\n- changes in main behavior can affect the job unexpectedly\n\n## Pattern B, fresh isolated run from manifest\n\nUse when:\n- you want reusable architecture across many agents\n- each run should start clean\n- immediate application of file changes matters\n\nPros:\n- predictable\n- portable\n- avoids stale session memory\n\nCons:\n- requires disciplined manifests and policy files\n\n## Pattern C, dispatcher plus fresh worker\n\nUse when:\n- orchestration complexity exists\n- retries or queues matter\n- multi-step automations are needed\n\nPros:\n- scalable\n- separates orchestration from generation\n\nCons:\n- more moving parts\n\n## Manifest recommendations\n\nA manifest should explicitly define:\n- slug\n- name\n- agentId\n- schedule\n- runtimeMode\n- triggerMode\n- promptFile\n- policyFiles\n- delivery\n- modelPolicy\n- verify\n- live scheduler id when your local tooling keeps one\n\n## Model policy recommendations\n\n### Best default\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\nUse when the job should follow system model upgrades.\n\n### Intentional pinning\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"openai-codex/gpt-5.4\"\n  }\n}\n```\n\nOnly use if output stability outweighs automatic upgrades.\n\n### Shared policy file\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same resolution behavior.\n\n## Verification recommendations\n\nVerification should ensure assembly correctness.\n\nGood checks:\n- manifest exists\n- prompt file exists\n- policy files exist\n- delivery target matches policy\n- schedule matches manifest\n- pinned model matches manifest if pinning is intentional\n\nBad checks:\n- exact model verification when model inheritance is intended\n- exact prompt text verification when prompt changes should be allowed through file edits\n\n## Delivery recommendations\n\nDelivery must be explicit and provider-aware.\n\nExample:\n\n```json\n{\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\"\n  }\n}\n```\n\nDo not trust session metadata blindly for outbound sends.\n\nFile v1.0.2:references/example-migration-daily-briefing.md\n\n# Example migration: Daily briefing job\n\n## Symptoms\n\nA daily briefing keeps using old settings even after the system changed.\n\nTypical signs:\n- old model still in use\n- old formatting still in use\n- requested changes take multiple attempts to stick\n- delivery route behaves differently from current runtime expectations\n\n## Root causes to check\n\n- manifest pins an outdated model\n- session mode is isolated but still behaves like a stale long-lived context\n- prompt changes live partly in chat history instead of files\n- outbound delivery route uses misleading session metadata\n- verification rules freeze old configuration\n\n## Before\n\nExample brittle pattern:\n\n```json\n{\n  \"model\": \"openai/gpt-5.2\",\n  \"session\": \"isolated\",\n  \"wake\": \"now\",\n  \"to\": \"channel:1476754066481877155\",\n  \"verify\": {\n    \"requirePromptExact\": true,\n    \"requireModelExact\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true\n  }\n}\n```\n\nProblems:\n- old model pin\n- exact model verification locks drift in place\n- outbound target may not be the provider-valid DM form\n- prompt exactness can hide where the true source of truth lives\n\n## After\n\nRecommended fresh-runtime pattern:\n\n```json\n{\n  \"slug\": \"daily-ai-briefing\",\n  \"cronId\": \"replace-with-live-cron-id-if-tracked-locally\",\n  \"name\": \"daily-ai-briefing\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/daily-ai-briefing/prompt.md\",\n  \"policyFiles\": [\n    \"automation/jobs/daily-ai-briefing/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  }\n}\n```\n\nIf you're using a local automation manager, keeping `slug` and `cronId` in the manifest makes reconciliation and verification deterministic.\n\n## Why this fixes drift\n\n- prompt is loaded from file every run\n- policy is loaded from file every run\n- delivery target is explicit and provider-valid\n- model follows current default unless intentionally pinned\n- exact model verification no longer preserves an outdated pin\n\n## Validation checklist\n\nAfter migration, confirm:\n- editing the prompt changes the next run\n- editing the policy changes the next run\n- changing the default model affects the next run\n- delivery still works after a live send test\n- attachments work if the job needs them\n\n## Provider-specific reminder\n\nFor Discord DMs, outbound sends may require `user:<discord_user_id>` even if session metadata suggests a `channel:<id>` route.\n\nFile v1.0.2:references/job-manifest-template.json\n\n{\n  \"slug\": \"example-scheduled-job\",\n  \"cronId\": \"replace-with-live-cron-id-if-your-tooling-tracks-it\",\n  \"name\": \"Example scheduled job\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/example-scheduled-job/prompt.md\",\n  \"policyFiles\": [\n    \"automation/policies/default-runtime.json\",\n    \"automation/jobs/example-scheduled-job/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  },\n  \"notes\": [\n    \"Set requireModelExact=true only when modelPolicy.mode is pin.\",\n    \"Do not rely on session metadata for outbound delivery if the provider requires a different target format.\",\n    \"Every run should load promptFile and policyFiles fresh.\",\n    \"If your local automation manager tracks live scheduler ids, keep cronId in sync after create/edit operations.\"\n  ]\n}\n\nFile v1.0.2:references/migration-checklist.md\n\n# Migration checklist for stale scheduled jobs\n\n## Goal\n\nConvert a brittle scheduled job into a design where changes are effective on the next run.\n\n## Checklist\n\n### 1. Inspect the current job\n\nCheck:\n- model field\n- session mode\n- prompt source\n- policy source\n- delivery route\n- verification rules\n\n### 2. Identify drift sources\n\nCommon causes:\n- old pinned model\n- isolated stale session behavior\n- prompt rules only stored in chat history\n- delivery target copied from misleading session metadata\n- exact verification preventing intended inheritance\n- cron registration embedding old prompt, model, or delivery values\n\n### 3. Move behavior into files\n\nCreate or update:\n- manifest\n- prompt file\n- policy file\n- local registry or scheduler-id mapping if your tooling reconciles live jobs\n\n### 4. Fix model policy\n\nChoose one:\n- inherit-default\n- pin\n- policy-file\n\nDefault: inherit-default.\n\n### 5. Replace fat cron payloads with thin triggers\n\nMake the cron payload a small stable instruction that tells the agent to load local files.\n\n### 6. Make delivery explicit\n\nWrite the exact provider-valid outbound target in the manifest.\n\n### 7. Relax harmful verification\n\nKeep checks that validate assembly.\nRemove checks that freeze old desired behavior.\n\n### 8. Test one live run for content freshness\n\nConfirm:\n- current prompt is used\n- current policy is used\n- current model policy behaves as intended\n\n### 9. Test final delivery separately\n\nConfirm:\n- the final outbound route works\n- attachments work if relevant\n- cron announce is not silently masking a delivery bug\n\n### 10. Record discovered quirks\n\nDocument provider-specific routing or runtime behavior for future reuse.\n\n### 11. Record ownership boundaries\n\nWrite down whether the design is:\n- architecture-only guidance\n- a manifest convention\n- or a complete installable execution path\n\nDo not imply a one-command rollout if local execution tooling is still required.\n\nFile v1.0.2:references/reliability-review.md\n\n# Reliability review for scheduled job architecture\n\nUse this before publishing or rolling out a scheduling pattern.\n\n## A design is reliable only if all are true\n\n- Prompt changes take effect on the next run.\n- Policy changes take effect on the next run.\n- Delivery changes take effect on the next run.\n- Default model changes take effect on the next run when inheritance is intended.\n- Pinned model behavior is explicit and documented when inheritance is not intended.\n- Dynamic jobs do not depend on fat embedded cron payloads unless re-registration is explicitly part of the process.\n- No persistent session is required for correctness of content generation.\n- Provider-specific outbound routing is documented where needed.\n- Verification checks assembly correctness without blocking intended updates.\n- Final delivery has been tested independently from scheduler announce behavior.\n\n## Review questions\n\n### Runtime freshness\n\n- Does every run read current files?\n- Can a stale session override current files?\n- Is generation happening in a clean runtime?\n\n### Model freshness\n\n- Is the model intentionally inherited or intentionally pinned?\n- Could an old manifest silently keep using an outdated model?\n- Does verification accidentally lock an old model in place?\n\n### Prompt and policy freshness\n\n- Are formatting and content rules stored in files?\n- Would a file edit affect the next run without extra manual steps?\n\n### Delivery correctness\n\n- Is outbound delivery defined explicitly?\n- Is the target format valid for the provider?\n- Have attachments been tested if relevant?\n- Is normal outbound delivery working even if cron announce delivery is not?\n\n### Operational resilience\n\n- Can the job fail safely?\n- Can it be re-run cleanly?\n- Can another agent reuse the pattern without hidden assumptions?\n\n## Red flags\n\n- exact old model pinned without a clear reason\n- persistent automation session used as content source of truth\n- prompt requirements only captured in conversation history\n- delivery route inferred from stale session metadata\n- verification that prevents intended updates from taking effect\n- cron registration storing the full job content for a supposedly dynamic automation\n- relying on cron announce delivery without separately testing the real outbound path\n\nFile v1.0.2:skill-card.md\n\n## Description: <br>\nDesign and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[daniel-refahi-ikara](https://clawhub.ai/user/daniel-refahi-ikara) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and automation engineers use this skill to design or migrate scheduled OpenClaw jobs so each run loads current prompts, policies, model rules, and delivery settings. It is intended for cron jobs, reminders, digests, briefings, background agents, and reusable automation standards. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Applying schedule or delivery changes directly can trigger live notifications, public posts, or production mutations before the behavior is validated. <br>\nMitigation: Use dry-run generation, separate delivery and scheduler tests, and require explicit approval before enabling live sends or production mutations. <br>\nRisk: Cron registrations or persistent sessions may preserve stale prompt, model, policy, or delivery details. <br>\nMitigation: Keep the scheduler as a thin trigger and load the manifest, prompt, policy files, model policy, and delivery contract at runtime. <br>\nRisk: Outbound delivery can fail or route incorrectly when session metadata does not match the provider-required target format. <br>\nMitigation: Define provider-aware delivery contracts and test final outbound delivery independently from scheduler announce behavior. <br>\n\n\n## Reference(s): <br>\n- [Architecture patterns for reliable scheduled jobs](references/architecture-patterns.md) <br>\n- [Migration checklist for stale scheduled jobs](references/migration-checklist.md) <br>\n- [Reliability review for scheduled job architecture](references/reliability-review.md) <br>\n- [Job manifest template](references/job-manifest-template.json) <br>\n- [Example migration: Daily briefing job](references/example-migration-daily-briefing.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, code, configuration, guidance] <br>\n**Output Format:** [Markdown guidance with JSON manifest examples and checklist-style recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [May include proposed architecture patterns, manifest structure, verification plans, checkpoint gates, and rollout recommendations.] <br>\n\n## Skill Version(s): <br>\n1.0.2 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.1: 8 files, 11530 bytes\n\nFiles: references/architecture-patterns.md (3239b), references/example-migration-daily-briefing.md (2865b), references/job-manifest-template.json (1273b), references/migration-checklist.md (1933b), references/reliability-review.md (2290b), skill-card.md (2869b), SKILL.md (9316b), _meta.json (138b)\n\nFile v1.0.1:SKILL.md\n\n---\nname: dr-schedule-manager\ndescription: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. Use when cron jobs, daily briefings, reminders, digests, or background agents keep using stale models, stale prompts, stale session state, or detached execution contexts. Also use when standardizing automation architecture across multiple agents or converting brittle time-triggered workflows into reusable config-driven jobs.\n---\n\n# dr-schedule-manager\n\nBuild scheduled automations so each run reflects current configuration immediately.\n\n## Core outcome\n\nThis skill is a scheduling **architecture and migration playbook**, not a one-command scheduler installer.\n\nAfter installation or migration, scheduled jobs should:\n- pick up current prompt changes on the next run\n- pick up current policy changes on the next run\n- pick up current delivery changes on the next run\n- pick up current default model changes on the next run, unless intentionally pinned\n- avoid stale session residue from prior runs\n\nIf a design does not guarantee those properties, do not recommend it as the default.\n\n## Current OpenClaw constraint\n\nTreat current OpenClaw cron as **snapshot-based unless proven otherwise**.\n\nIn practice, cron jobs may embed:\n- prompt text\n- model override\n- delivery route\n- other runtime details\n\nThat means editing local files alone may **not** change the behavior of the already-registered job.\n\nBecause of this, the preferred practical pattern for current OpenClaw is not \"fat job config in cron\". It is:\n- thin trigger in cron\n- local file resolution at runtime\n- explicit final delivery through the normal outbound path\n\n## Default architecture\n\nPrefer a **thin-trigger, fresh-run, config-driven job architecture**.\n\n### Rule 1, scheduler is only a trigger carrier\n\nThe scheduler should only:\n- wake the job\n- identify the job slug or manifest\n- pass a small stable trigger message\n\nDo not embed business logic, formatting rules, or model decisions in the scheduler unless you intentionally accept snapshot behavior.\n\n### Rule 2, manifest is the operational contract\n\nEach scheduled job should have a manifest file that defines:\n- slug\n- name\n- agent id\n- schedule\n- runtime mode\n- trigger mode\n- prompt file path\n- policy file paths\n- delivery contract\n- model policy\n- verification rules\n- live scheduler id if your local tooling tracks one\n\n### Rule 3, runtime assembly happens at execution time\n\nOn every run, load current files before generating output.\n\nAlways assemble from:\n- current manifest\n- current prompt file\n- current policy files\n- current delivery rules\n- current model policy\n\nDo not trust previous session state for these.\n\n### Rule 4, delivery is explicit and provider-aware\n\nStore delivery in a clear adapter contract.\n\nDo not assume session metadata is valid for outbound sends if the provider requires a different target format.\n\n### Rule 5, persistent sessions are not the source of truth\n\nIf you keep a persistent automation agent, use it only as a dispatcher or coordinator.\n\nDo not let a persistent scheduled session be the authoritative source for:\n- prompt wording\n- model selection\n- formatting rules\n- delivery routing\n\n## Approved patterns\n\n### Pattern A, wake-only trigger into fresh main execution\n\nUse when you want the latest main assistant behavior to apply automatically.\n\nBest for:\n- personal briefings\n- reminders\n- evolving assistant workflows\n\nStrengths:\n- changes propagate immediately\n- minimal drift risk\n- simple to reason about\n\nWeaknesses:\n- less isolated\n- changes to main behavior affect the job immediately\n\n### Pattern B, thin trigger plus local manifest resolution\n\nUse as the default reusable pattern across agents for current OpenClaw.\n\nBest for:\n- reusable automation frameworks\n- reports and digests\n- jobs that need clean state on every run\n- setups where cron otherwise snapshots prompt, model, or delivery\n\nHow it works:\n- cron stores only a small stable trigger\n- the triggered agent reads local job files at runtime\n- prompt, policy, model policy, and delivery are resolved from the workspace\n- final delivery uses the normal outbound path, not cron announce, when announce is unreliable\n\nStrengths:\n- avoids stale embedded prompt drift\n- avoids stale model pins in cron payloads\n- makes file edits effective on the next run\n- easy to migrate across agents\n\nWeaknesses:\n- requires the agent to actually honor the trigger by reading the local files\n- still depends on reliable final outbound delivery\n\n### Pattern C, persistent dispatcher plus fresh worker run\n\nUse for more advanced orchestration.\n\nBest for:\n- retry queues\n- fan-out workflows\n- multi-step automation pipelines\n\nStrengths:\n- scalable\n- strong separation between orchestration and generation\n\nWeaknesses:\n- more moving parts\n\n## Default recommendation\n\nFor most current OpenClaw scheduled jobs, use **Pattern B, thin trigger plus local manifest resolution**.\n\nReason:\n- it works around snapshot-based cron behavior\n- it is reusable across many agents\n- it avoids stale embedded prompt and model drift\n- changes are effective on the next run because runtime inputs are file-based\n- it scales better than manual re-registration for every content tweak\n\n## Model policy rules\n\nModel behavior must be explicit.\n\n### Preferred\n\nUse inherit-default when upgrades should propagate automatically.\n\nExample:\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\n### Use only when intentionally pinned\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"openai-codex/gpt-5.4\"\n  }\n}\n```\n\nIf pinning is used, document why.\n\n### Shared-policy option\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same rule.\n\n## Verification rules\n\nVerification should catch broken assembly, not freeze intended upgrades.\n\nGood checks:\n- prompt path exists\n- policy paths exist\n- delivery route matches current job contract\n- schedule matches manifest\n- pinned model matches manifest, if pinning is intentional\n\nAvoid exact verification for settings that are supposed to inherit current defaults.\n\nIf the job should follow current default model changes, do **not** require an exact old model string.\n\n## Anti-patterns\n\nReject these by default.\n\n### Embedded full-payload cron jobs for dynamic automations\n\nA cron job stores the full prompt, model, and delivery configuration even though the automation is expected to evolve via local files.\n\n### Stale exact model pinning\n\nA manifest or cron payload hardcodes an old model and exact verification preserves it forever.\n\n### Chat-only preference changes\n\nA user requests a format change in chat, but the job still reads an older prompt source.\n\n### Session-derived outbound routing\n\nOutbound delivery copies stale or misleading session metadata rather than a provider-valid target.\n\n### Persistent scheduled generation context\n\nA long-lived automation session accumulates outdated assumptions and keeps using them.\n\n### Assuming scheduler reliability equals delivery reliability\n\nA job can resolve current local files correctly and still fail because the scheduler's announce/delivery adapter is broken.\n\n## Migration workflow\n\nWhen fixing an existing job:\n\n1. Inspect current manifest and scheduler behavior\n2. Identify stale sources\n   - model\n   - prompt\n   - policy\n   - delivery\n   - session mode\n   - embedded cron payloads\n3. Move all durable rules into files\n4. Replace fat cron payloads with a thin stable trigger\n5. Choose model policy\n6. Make delivery explicit\n7. Reduce over-strict verification that blocks intended inheritance\n8. Test one live run for content freshness\n9. Test final delivery separately\n10. Record provider-specific quirks\n\n## Required output when using this skill\n\nProvide:\n- recommended runtime pattern\n- manifest structure\n- model policy recommendation\n- delivery contract recommendation\n- what must move out of session state\n- migration steps\n- verification plan\n- reliability risks and tradeoffs\n- whether additional local execution tooling is still required\n\n## Reliability review checklist\n\nBefore declaring the architecture good, confirm:\n- a prompt edit affects the next run\n- a policy edit affects the next run\n- a delivery target edit affects the next run\n- a default-model change affects the next run when inherit-default is used\n- the scheduler stores only a thin trigger for dynamic jobs, or re-registration is explicitly part of the workflow\n- no persistent session is required for content correctness\n- provider-specific outbound routing is documented where needed\n- final delivery works independently of cron announce delivery\n\n## References\n\nRead `references/architecture-patterns.md` when designing the execution model.\nRead `references/migration-checklist.md` when converting an existing stale scheduled job.\nRead `references/reliability-review.md` before finalizing a job architecture or publishing this pattern for wider reuse.\nRead `references/job-manifest-template.json` for the recommended manifest shape.\nRead `references/example-migration-daily-briefing.md` for a concrete migration from a stale scheduled digest to a fresh-runtime job.\n\nFile v1.0.1:_meta.json\n\n{\n  \"ownerId\": \"kn75qhdfr3qnbx390tbrjgz48981y6e4\",\n  \"slug\": \"dr-schedule-manager\",\n  \"version\": \"1.0.1\",\n  \"publishedAt\": 1777609229080\n}\n\nFile v1.0.1:references/architecture-patterns.md\n\n# Architecture patterns for reliable scheduled jobs\n\n## Design goal\n\nA scheduled job should reflect current configuration on the very next run.\n\nThat means changes to:\n- prompt\n- policy\n- delivery route\n- default model\n\nmust be loaded at execution time, not remembered from stale session state.\n\n## Recommended default\n\nUse a thin-trigger, file-resolved execution path.\n\nThe scheduler should carry only a small stable trigger. The runtime then assembles the job from local files.\n\n## Current OpenClaw reality\n\nCurrent OpenClaw cron jobs may embed prompt text, model choice, and delivery details directly in the registered job.\n\nThat means cron can behave as a snapshot system unless you deliberately design around it.\n\nFor dynamic automations, do not treat the cron registration as the canonical source of truth.\nTreat it as a trigger carrier.\n\n## Pattern A, wake-only trigger into fresh main execution\n\nUse when:\n- you want the latest main assistant behavior automatically\n- isolation is less important than immediate propagation\n\nPros:\n- very low drift\n- changes apply immediately\n\nCons:\n- less isolated\n- changes in main behavior can affect the job unexpectedly\n\n## Pattern B, fresh isolated run from manifest\n\nUse when:\n- you want reusable architecture across many agents\n- each run should start clean\n- immediate application of file changes matters\n\nPros:\n- predictable\n- portable\n- avoids stale session memory\n\nCons:\n- requires disciplined manifests and policy files\n\n## Pattern C, dispatcher plus fresh worker\n\nUse when:\n- orchestration complexity exists\n- retries or queues matter\n- multi-step automations are needed\n\nPros:\n- scalable\n- separates orchestration from generation\n\nCons:\n- more moving parts\n\n## Manifest recommendations\n\nA manifest should explicitly define:\n- slug\n- name\n- agentId\n- schedule\n- runtimeMode\n- triggerMode\n- promptFile\n- policyFiles\n- delivery\n- modelPolicy\n- verify\n- live scheduler id when your local tooling keeps one\n\n## Model policy recommendations\n\n### Best default\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\nUse when the job should follow system model upgrades.\n\n### Intentional pinning\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"openai-codex/gpt-5.4\"\n  }\n}\n```\n\nOnly use if output stability outweighs automatic upgrades.\n\n### Shared policy file\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same resolution behavior.\n\n## Verification recommendations\n\nVerification should ensure assembly correctness.\n\nGood checks:\n- manifest exists\n- prompt file exists\n- policy files exist\n- delivery target matches policy\n- schedule matches manifest\n- pinned model matches manifest if pinning is intentional\n\nBad checks:\n- exact model verification when model inheritance is intended\n- exact prompt text verification when prompt changes should be allowed through file edits\n\n## Delivery recommendations\n\nDelivery must be explicit and provider-aware.\n\nExample:\n\n```json\n{\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\"\n  }\n}\n```\n\nDo not trust session metadata blindly for outbound sends.\n\nFile v1.0.1:references/example-migration-daily-briefing.md\n\n# Example migration: Daily briefing job\n\n## Symptoms\n\nA daily briefing keeps using old settings even after the system changed.\n\nTypical signs:\n- old model still in use\n- old formatting still in use\n- requested changes take multiple attempts to stick\n- delivery route behaves differently from current runtime expectations\n\n## Root causes to check\n\n- manifest pins an outdated model\n- session mode is isolated but still behaves like a stale long-lived context\n- prompt changes live partly in chat history instead of files\n- outbound delivery route uses misleading session metadata\n- verification rules freeze old configuration\n\n## Before\n\nExample brittle pattern:\n\n```json\n{\n  \"model\": \"openai/gpt-5.2\",\n  \"session\": \"isolated\",\n  \"wake\": \"now\",\n  \"to\": \"channel:1476754066481877155\",\n  \"verify\": {\n    \"requirePromptExact\": true,\n    \"requireModelExact\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true\n  }\n}\n```\n\nProblems:\n- old model pin\n- exact model verification locks drift in place\n- outbound target may not be the provider-valid DM form\n- prompt exactness can hide where the true source of truth lives\n\n## After\n\nRecommended fresh-runtime pattern:\n\n```json\n{\n  \"slug\": \"daily-ai-briefing\",\n  \"cronId\": \"replace-with-live-cron-id-if-tracked-locally\",\n  \"name\": \"daily-ai-briefing\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/daily-ai-briefing/prompt.md\",\n  \"policyFiles\": [\n    \"automation/jobs/daily-ai-briefing/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  }\n}\n```\n\nIf you're using a local automation manager, keeping `slug` and `cronId` in the manifest makes reconciliation and verification deterministic.\n\n## Why this fixes drift\n\n- prompt is loaded from file every run\n- policy is loaded from file every run\n- delivery target is explicit and provider-valid\n- model follows current default unless intentionally pinned\n- exact model verification no longer preserves an outdated pin\n\n## Validation checklist\n\nAfter migration, confirm:\n- editing the prompt changes the next run\n- editing the policy changes the next run\n- changing the default model affects the next run\n- delivery still works after a live send test\n- attachments work if the job needs them\n\n## Provider-specific reminder\n\nFor Discord DMs, outbound sends may require `user:<discord_user_id>` even if session metadata suggests a `channel:<id>` route.\n\nFile v1.0.1:references/job-manifest-template.json\n\n{\n  \"slug\": \"example-scheduled-job\",\n  \"cronId\": \"replace-with-live-cron-id-if-your-tooling-tracks-it\",\n  \"name\": \"Example scheduled job\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/example-scheduled-job/prompt.md\",\n  \"policyFiles\": [\n    \"automation/policies/default-runtime.json\",\n    \"automation/jobs/example-scheduled-job/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  },\n  \"notes\": [\n    \"Set requireModelExact=true only when modelPolicy.mode is pin.\",\n    \"Do not rely on session metadata for outbound delivery if the provider requires a different target format.\",\n    \"Every run should load promptFile and policyFiles fresh.\",\n    \"If your local automation manager tracks live scheduler ids, keep cronId in sync after create/edit operations.\"\n  ]\n}\n\nFile v1.0.1:references/migration-checklist.md\n\n# Migration checklist for stale scheduled jobs\n\n## Goal\n\nConvert a brittle scheduled job into a design where changes are effective on the next run.\n\n## Checklist\n\n### 1. Inspect the current job\n\nCheck:\n- model field\n- session mode\n- prompt source\n- policy source\n- delivery route\n- verification rules\n\n### 2. Identify drift sources\n\nCommon causes:\n- old pinned model\n- isolated stale session behavior\n- prompt rules only stored in chat history\n- delivery target copied from misleading session metadata\n- exact verification preventing intended inheritance\n- cron registration embedding old prompt, model, or delivery values\n\n### 3. Move behavior into files\n\nCreate or update:\n- manifest\n- prompt file\n- policy file\n- local registry or scheduler-id mapping if your tooling reconciles live jobs\n\n### 4. Fix model policy\n\nChoose one:\n- inherit-default\n- pin\n- policy-file\n\nDefault: inherit-default.\n\n### 5. Replace fat cron payloads with thin triggers\n\nMake the cron payload a small stable instruction that tells the agent to load local files.\n\n### 6. Make delivery explicit\n\nWrite the exact provider-valid outbound target in the manifest.\n\n### 7. Relax harmful verification\n\nKeep checks that validate assembly.\nRemove checks that freeze old desired behavior.\n\n### 8. Test one live run for content freshness\n\nConfirm:\n- current prompt is used\n- current policy is used\n- current model policy behaves as intended\n\n### 9. Test final delivery separately\n\nConfirm:\n- the final outbound route works\n- attachments work if relevant\n- cron announce is not silently masking a delivery bug\n\n### 10. Record discovered quirks\n\nDocument provider-specific routing or runtime behavior for future reuse.\n\n### 11. Record ownership boundaries\n\nWrite down whether the design is:\n- architecture-only guidance\n- a manifest convention\n- or a complete installable execution path\n\nDo not imply a one-command rollout if local execution tooling is still required.\n\nFile v1.0.1:references/reliability-review.md\n\n# Reliability review for scheduled job architecture\n\nUse this before publishing or rolling out a scheduling pattern.\n\n## A design is reliable only if all are true\n\n- Prompt changes take effect on the next run.\n- Policy changes take effect on the next run.\n- Delivery changes take effect on the next run.\n- Default model changes take effect on the next run when inheritance is intended.\n- Pinned model behavior is explicit and documented when inheritance is not intended.\n- Dynamic jobs do not depend on fat embedded cron payloads unless re-registration is explicitly part of the process.\n- No persistent session is required for correctness of content generation.\n- Provider-specific outbound routing is documented where needed.\n- Verification checks assembly correctness without blocking intended updates.\n- Final delivery has been tested independently from scheduler announce behavior.\n\n## Review questions\n\n### Runtime freshness\n\n- Does every run read current files?\n- Can a stale session override current files?\n- Is generation happening in a clean runtime?\n\n### Model freshness\n\n- Is the model intentionally inherited or intentionally pinned?\n- Could an old manifest silently keep using an outdated model?\n- Does verification accidentally lock an old model in place?\n\n### Prompt and policy freshness\n\n- Are formatting and content rules stored in files?\n- Would a file edit affect the next run without extra manual steps?\n\n### Delivery correctness\n\n- Is outbound delivery defined explicitly?\n- Is the target format valid for the provider?\n- Have attachments been tested if relevant?\n- Is normal outbound delivery working even if cron announce delivery is not?\n\n### Operational resilience\n\n- Can the job fail safely?\n- Can it be re-run cleanly?\n- Can another agent reuse the pattern without hidden assumptions?\n\n## Red flags\n\n- exact old model pinned without a clear reason\n- persistent automation session used as content source of truth\n- prompt requirements only captured in conversation history\n- delivery route inferred from stale session metadata\n- verification that prevents intended updates from taking effect\n- cron registration storing the full job content for a supposedly dynamic automation\n- relying on cron announce delivery without separately testing the real outbound path\n\nFile v1.0.1:skill-card.md\n\n## Description: <br>\nDesign and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[daniel-refahi-ikara](https://clawhub.ai/user/daniel-refahi-ikara) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and engineers use this skill to design, review, or migrate scheduled OpenClaw jobs so each run loads current prompt, policy, model, and delivery configuration instead of relying on stale cron payloads or session state. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: Jobs created from this guidance may become persistent automations that keep running after configuration, prompt, policy, or delivery assumptions change. <br>\nMitigation: Replace example targets, restrict who can edit manifest and policy files, test one live run, and maintain a clear disable or rollback process. <br>\nRisk: A scheduler can store stale prompt, model, or delivery data if it is treated as the source of truth. <br>\nMitigation: Use a thin trigger and load the manifest, prompt file, policy files, model policy, and delivery contract fresh at execution time. <br>\nRisk: Outbound delivery can fail or route incorrectly when session metadata is reused for provider-specific targets. <br>\nMitigation: Store provider-valid delivery targets in the manifest and test final delivery separately from scheduler announce behavior. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/daniel-refahi-ikara/dr-schedule-manager) <br>\n- [Architecture patterns for reliable scheduled jobs](references/architecture-patterns.md) <br>\n- [Example migration: Daily briefing job](references/example-migration-daily-briefing.md) <br>\n- [Job manifest template](references/job-manifest-template.json) <br>\n- [Migration checklist for stale scheduled jobs](references/migration-checklist.md) <br>\n- [Reliability review for scheduled job architecture](references/reliability-review.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, configuration, markdown, code] <br>\n**Output Format:** [Markdown guidance with JSON manifest examples] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Produces architecture recommendations, migration steps, verification plans, and reliability tradeoffs for scheduled automations.] <br>\n\n## Skill Version(s): <br>\n1.0.1 (source: server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.0.0: 7 files, 9583 bytes\n\nFiles: references/architecture-patterns.md (3164b), references/example-migration-daily-briefing.md (2604b), references/job-manifest-template.json (1006b), references/migration-checklist.md (1605b), references/reliability-review.md (2290b), SKILL.md (9071b), _meta.json (138b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: dr-schedule-manager\ndescription: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. Use when cron jobs, daily briefings, reminders, digests, or background agents keep using stale models, stale prompts, stale session state, or detached execution contexts. Also use when standardizing automation architecture across multiple agents or converting brittle time-triggered workflows into reusable config-driven jobs.\n---\n\n# DR. Schedule Manager\n\nBuild scheduled automations so each run reflects current configuration immediately.\n\n## Core outcome\n\nAfter installation or migration, scheduled jobs should:\n- pick up current prompt changes on the next run\n- pick up current policy changes on the next run\n- pick up current delivery changes on the next run\n- pick up current default model changes on the next run, unless intentionally pinned\n- avoid stale session residue from prior runs\n\nIf a design does not guarantee those properties, do not recommend it as the default.\n\n## Current OpenClaw constraint\n\nTreat current OpenClaw cron as **snapshot-based unless proven otherwise**.\n\nIn practice, cron jobs may embed:\n- prompt text\n- model override\n- delivery route\n- other runtime details\n\nThat means editing local files alone may **not** change the behavior of the already-registered job.\n\nBecause of this, the preferred practical pattern for current OpenClaw is not \"fat job config in cron\". It is:\n- thin trigger in cron\n- local file resolution at runtime\n- explicit final delivery through the normal outbound path\n\n## Default architecture\n\nPrefer a **thin-trigger, fresh-run, config-driven job architecture**.\n\n### Rule 1, scheduler is only a trigger carrier\n\nThe scheduler should only:\n- wake the job\n- identify the job slug or manifest\n- pass a small stable trigger message\n\nDo not embed business logic, formatting rules, or model decisions in the scheduler unless you intentionally accept snapshot behavior.\n\n### Rule 2, manifest is the operational contract\n\nEach scheduled job should have a manifest file that defines:\n- name\n- agent id\n- schedule\n- runtime mode\n- prompt file path\n- policy file paths\n- delivery contract\n- model policy\n- verification rules\n\n### Rule 3, runtime assembly happens at execution time\n\nOn every run, load current files before generating output.\n\nAlways assemble from:\n- current manifest\n- current prompt file\n- current policy files\n- current delivery rules\n- current model policy\n\nDo not trust previous session state for these.\n\n### Rule 4, delivery is explicit and provider-aware\n\nStore delivery in a clear adapter contract.\n\nDo not assume session metadata is valid for outbound sends if the provider requires a different target format.\n\n### Rule 5, persistent sessions are not the source of truth\n\nIf you keep a persistent automation agent, use it only as a dispatcher or coordinator.\n\nDo not let a persistent scheduled session be the authoritative source for:\n- prompt wording\n- model selection\n- formatting rules\n- delivery routing\n\n## Approved patterns\n\n### Pattern A, wake-only trigger into fresh main execution\n\nUse when you want the latest main assistant behavior to apply automatically.\n\nBest for:\n- personal briefings\n- reminders\n- evolving assistant workflows\n\nStrengths:\n- changes propagate immediately\n- minimal drift risk\n- simple to reason about\n\nWeaknesses:\n- less isolated\n- changes to main behavior affect the job immediately\n\n### Pattern B, thin trigger plus local manifest resolution\n\nUse as the default reusable pattern across agents for current OpenClaw.\n\nBest for:\n- reusable automation frameworks\n- reports and digests\n- jobs that need clean state on every run\n- setups where cron otherwise snapshots prompt, model, or delivery\n\nHow it works:\n- cron stores only a small stable trigger\n- the triggered agent reads local job files at runtime\n- prompt, policy, model policy, and delivery are resolved from the workspace\n- final delivery uses the normal outbound path, not cron announce, when announce is unreliable\n\nStrengths:\n- avoids stale embedded prompt drift\n- avoids stale model pins in cron payloads\n- makes file edits effective on the next run\n- easy to migrate across agents\n\nWeaknesses:\n- requires the agent to actually honor the trigger by reading the local files\n- still depends on reliable final outbound delivery\n\n### Pattern C, persistent dispatcher plus fresh worker run\n\nUse for more advanced orchestration.\n\nBest for:\n- retry queues\n- fan-out workflows\n- multi-step automation pipelines\n\nStrengths:\n- scalable\n- strong separation between orchestration and generation\n\nWeaknesses:\n- more moving parts\n\n## Default recommendation\n\nFor most current OpenClaw scheduled jobs, use **Pattern B, thin trigger plus local manifest resolution**.\n\nReason:\n- it works around snapshot-based cron behavior\n- it is reusable across many agents\n- it avoid","readmeExcerpt":"Skill: DR Schedule Manager Owner: daniel-refahi-ikara Summary: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect imme... Tags: latest:1.1.0 Version history: v1.1.0 | 2026-06-29T05:05:57.772Z | user Add execution substrate gate, non-agent vs agent runner patterns, high-frequency LLM guardrail, and scheduler payload v","codeSnippets":[],"executableExamples":[{"language":"json","snippet":"{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}"},{"language":"json","snippet":"{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}"},{"language":"json","snippet":"{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}"},{"language":"json","snippet":"{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}"},{"language":"json","snippet":"{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}"},{"language":"json","snippet":"{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: dr-schedule-manager\ndescription: Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect immediately on the next run. Use when cron jobs, daily briefings, reminders, digests, or background agents keep using stale models, stale prompts, stale session state, or detached execution contexts. Also use when standardizing automation architecture across multiple agents or converting brittle time-triggered workflows into reusable config-driven jobs.\n---\n\n# dr-schedule-manager\n\nBuild scheduled automations so each run reflects current configuration immediately.\n\n## Core outcome\n\nThis skill is a scheduling **architecture and migration playbook**, not a one-command scheduler installer.\n\nAfter installation or migration, scheduled jobs should:\n- pick up current prompt changes on the next run\n- pick up current policy changes on the next run\n- pick up current delivery changes on the next run\n- pick up current default model changes on the next run, unless intentionally pinned\n- avoid stale session residue from prior runs\n- use an execution substrate appropriate to the job, instead of defaulting every scheduled reference into an LLM-backed agent run\n\nIf a design does not guarantee those properties, do not recommend it as the default.\n\n## Current OpenClaw constraint\n\nTreat current OpenClaw cron as **snapshot-based unless proven otherwise**.\n\nIn practice, cron jobs may embed:\n- prompt text\n- model override\n- delivery route\n- other runtime details\n\nThat means editing local files alone may **not** change the behavior of the already-registered job.\n\nBecause of this, the preferred practical pattern is not \"fat job config in cron\". It is:\n- thin scheduler reference\n- local file resolution at runtime\n- explicit final delivery through the correct outbound path when delivery is needed\n\nThe scheduler reference may point to an agent runner or a non-agent runner. Choose that substrate deliberately.\n\n## Default architecture\n\nPrefer a **thin-reference, fresh-run, config-driven job architecture**.\n\n### Rule 1, scheduler is only a trigger/reference carrier\n\nThe scheduler should only:\n- wake the job\n- identify the job slug or manifest\n- pass a small stable trigger message or command reference\n\nDo not embed business logic, formatting rules, prompt text, delivery rules, or model decisions in the scheduler unless you intentionally accept snapshot behavior.\n\n### Rule 2, manifest is the operational contract\n\nEach scheduled job should have a manifest file that defines:\n- slug\n- name\n- agent id when an agent runner is required\n- execution substrate\n- schedule\n- runtime mode\n- trigger mode\n- prompt file path when generation/reasoning is required\n- policy file paths\n- delivery contract\n- model policy when an LLM is used\n- verification rules\n- live scheduler id if your local tooling tracks one\n\n### Rule 3, runtime assembly happens at execution time\n\nOn every run, load current files befor"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn75qhdfr3qnbx390tbrjgz48981y6e4\",\n  \"slug\": \"dr-schedule-manager\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1782709557772\n}"},{"path":"references/architecture-patterns.md","content":"# Architecture patterns for reliable scheduled jobs\n\n## Design goal\n\nA scheduled job should reflect current configuration on the very next run.\n\nThat means changes to:\n- prompt\n- policy\n- delivery route\n- default model\n\nmust be loaded at execution time, not remembered from stale session state.\n\n## Recommended default\n\nUse a thin-trigger, file-resolved execution path.\n\nThe scheduler should carry only a small stable trigger. The runtime then assembles the job from local files.\n\n## Current OpenClaw reality\n\nCurrent OpenClaw cron jobs may embed prompt text, model choice, and delivery details directly in the registered job.\n\nThat means cron can behave as a snapshot system unless you deliberately design around it.\n\nFor dynamic automations, do not treat the cron registration as the canonical source of truth.\nTreat it as a trigger carrier.\n\n## Pattern A, wake-only trigger into fresh main execution\n\nUse when:\n- you want the latest main assistant behavior automatically\n- isolation is less important than immediate propagation\n\nPros:\n- very low drift\n- changes apply immediately\n\nCons:\n- less isolated\n- changes in main behavior can affect the job unexpectedly\n\n## Pattern B, fresh isolated run from manifest\n\nUse when:\n- you want reusable architecture across many agents\n- each run should start clean\n- immediate application of file changes matters\n\nPros:\n- predictable\n- portable\n- avoids stale session memory\n\nCons:\n- requires disciplined manifests and policy files\n\n## Pattern C, dispatcher plus fresh worker\n\nUse when:\n- orchestration complexity exists\n- retries or queues matter\n- multi-step automations are needed\n\nPros:\n- scalable\n- separates orchestration from generation\n\nCons:\n- more moving parts\n\n## Manifest recommendations\n\nA manifest should explicitly define:\n- slug\n- name\n- agentId\n- schedule\n- runtimeMode\n- triggerMode\n- promptFile\n- policyFiles\n- delivery\n- modelPolicy\n- verify\n- live scheduler id when your local tooling keeps one\n\n## Model policy recommendations\n\n### Best default\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  }\n}\n```\n\nUse when the job should follow system model upgrades.\n\n### Intentional pinning\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"pin\",\n    \"model\": \"replace-with-intentional-model\"\n  }\n}\n```\n\nOnly use if output stability outweighs automatic upgrades.\n\n### Shared policy file\n\n```json\n{\n  \"modelPolicy\": {\n    \"mode\": \"policy-file\",\n    \"path\": \"automation/policies/default-runtime.json\"\n  }\n}\n```\n\nUse when many jobs should share the same resolution behavior.\n\n## Verification recommendations\n\nVerification should ensure assembly correctness.\n\nGood checks:\n- manifest exists\n- prompt file exists\n- policy files exist\n- delivery target matches policy\n- schedule matches manifest\n- pinned model matches manifest if pinning is intentional\n\nBad checks:\n- exact model verification when model inheritance is intended\n- exact prompt text verification when prompt changes should be allowed through file edits\n\n## Delivery recommendation"},{"path":"references/example-migration-daily-briefing.md","content":"# Example migration: Daily briefing job\n\n## Symptoms\n\nA daily briefing keeps using old settings even after the system changed.\n\nTypical signs:\n- old model still in use\n- old formatting still in use\n- requested changes take multiple attempts to stick\n- delivery route behaves differently from current runtime expectations\n\n## Root causes to check\n\n- manifest pins an outdated model\n- session mode is isolated but still behaves like a stale long-lived context\n- prompt changes live partly in chat history instead of files\n- outbound delivery route uses misleading session metadata\n- verification rules freeze old configuration\n\n## Before\n\nExample brittle pattern:\n\n```json\n{\n  \"model\": \"old-hardcoded-model-example\",\n  \"session\": \"isolated\",\n  \"wake\": \"now\",\n  \"to\": \"channel:1476754066481877155\",\n  \"verify\": {\n    \"requirePromptExact\": true,\n    \"requireModelExact\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true\n  }\n}\n```\n\nProblems:\n- old model pin\n- exact model verification locks drift in place\n- outbound target may not be the provider-valid DM form\n- prompt exactness can hide where the true source of truth lives\n\n## After\n\nRecommended fresh-runtime pattern:\n\n```json\n{\n  \"slug\": \"daily-ai-briefing\",\n  \"cronId\": \"replace-with-live-cron-id-if-tracked-locally\",\n  \"name\": \"daily-ai-briefing\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/daily-ai-briefing/prompt.md\",\n  \"policyFiles\": [\n    \"automation/jobs/daily-ai-briefing/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  }\n}\n```\n\nIf you're using a local automation manager, keeping `slug` and `cronId` in the manifest makes reconciliation and verification deterministic.\n\n## Why this fixes drift\n\n- prompt is loaded from file every run\n- policy is loaded from file every run\n- delivery target is explicit and provider-valid\n- model follows current default unless intentionally pinned\n- exact model verification no longer preserves an outdated pin\n\n## Validation checklist\n\nAfter migration, confirm:\n- editing the prompt changes the next run\n- editing the policy changes the next run\n- changing the default model affects the next run\n- delivery still works after a live send test\n- attachments work if the job needs them\n\n## Provider-specific reminder\n\nFor Discord DMs, outbound sends may require `user:<discord_user_id>` even if session metadata suggests a `channel:<id>` route."},{"path":"references/job-manifest-template.json","content":"{\n  \"slug\": \"example-scheduled-job\",\n  \"cronId\": \"replace-with-live-cron-id-if-your-tooling-tracks-it\",\n  \"name\": \"Example scheduled job\",\n  \"agentId\": \"main\",\n  \"schedule\": {\n    \"kind\": \"cron\",\n    \"expr\": \"0 8 * * *\",\n    \"tz\": \"Australia/Brisbane\"\n  },\n  \"runtimeMode\": \"fresh-isolated\",\n  \"triggerMode\": \"wake-only\",\n  \"promptFile\": \"automation/jobs/example-scheduled-job/prompt.md\",\n  \"policyFiles\": [\n    \"automation/policies/default-runtime.json\",\n    \"automation/jobs/example-scheduled-job/policy.md\"\n  ],\n  \"delivery\": {\n    \"channel\": \"discord\",\n    \"target\": \"user:270548320366100480\",\n    \"accountId\": \"default\",\n    \"mode\": \"runtime-send\"\n  },\n  \"modelPolicy\": {\n    \"mode\": \"inherit-default\"\n  },\n  \"verify\": {\n    \"requirePromptPath\": true,\n    \"requirePolicyPaths\": true,\n    \"requireDeliveryExact\": true,\n    \"requireScheduleExact\": true,\n    \"requireModelExact\": false\n  },\n  \"notes\": [\n    \"Set requireModelExact=true only when modelPolicy.mode is pin.\",\n    \"Do not rely on session metadata for outbound delivery if the provider requires a different target format.\",\n    \"Every run should load promptFile and policyFiles fresh.\",\n    \"If your local automation manager tracks live scheduler ids, keep cronId in sync after create/edit operations.\"\n  ]\n}"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1680,"uniquenessScore":42,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T05:15:01.395Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T05:15:01.395Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T07:40:12.703Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}