What makes DR Schedule Manager notable?

1.1K downloads. Trust evidence available

How should DR Schedule Manager be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

DR Schedule Manager

Design and implement reliable scheduled or event-triggered automations for OpenClaw agents so changes to model, prompt, delivery, and policy take effect imme...

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

1.1.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.1.0release · observed Jun 29, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s177xe2n6zt5z29v51zpxrnx9183wyda:dr-schedule-manager

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: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-daniel-refahi-ikara-dr-schedule-manager/snapshot"

Documentation

CLAWHUB

145,001 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: dr-schedule-manager
description: 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.
---

# dr-schedule-manager

Build scheduled automations so each run reflects current configuration immediately.

## Core outcome

This skill is a scheduling **architecture and migration playbook**, not a one-command scheduler installer.

After installation or migration, scheduled jobs should:
- pick up current prompt changes on the next run
- pick up current policy changes on the next run
- pick up current delivery changes on the next run
- pick up current default model changes on the next run, unless intentionally pinned
- avoid stale session residue from prior runs
- use an execution substrate appropriate to the job, instead of defaulting every scheduled reference into an LLM-backed agent run

If a design does not guarantee those properties, do not recommend it as the default.

## Current OpenClaw constraint

Treat current OpenClaw cron as **snapshot-based unless proven otherwise**.

In practice, cron jobs may embed:
- prompt text
- model override
- delivery route
- other runtime details

That means editing local files alone may **not** change the behavior of the already-registered job.

Because of this, the preferred practical pattern is not "fat job config in cron". It is:
- thin scheduler reference
- local file resolution at runtime
- explicit final delivery through the correct outbound path when delivery is needed

The scheduler reference may point to an agent runner or a non-agent runner. Choose that substrate deliberately.

## Default architecture

Prefer a **thin-reference, fresh-run, config-driven job architecture**.

### Rule 1, scheduler is only a trigger/reference carrier

The scheduler should only:
- wake the job
- identify the job slug or manifest
- pass a small stable trigger message or command reference

Do not embed business logic, formatting rules, prompt text, delivery rules, or model decisions in the scheduler unless you intentionally accept snapshot behavior.

### Rule 2, manifest is the operational contract

Each scheduled job should have a manifest file that defines:
- slug
- name
- agent id when an agent runner is required
- execution substrate
- schedule
- runtime mode
- trigger mode
- prompt file path when generation/reasoning is required
- policy file paths
- delivery contract
- model policy when an LLM is used
- verification rules
- live scheduler id if your local tooling tracks one

### Rule 3, runtime assembly happens at execution time

On every run, load current files befor

_meta.json

{
  "ownerId": "kn75qhdfr3qnbx390tbrjgz48981y6e4",
  "slug": "dr-schedule-manager",
  "version": "1.1.0",
  "publishedAt": 1782709557772
}

references/architecture-patterns.md

# Architecture patterns for reliable scheduled jobs

## Design goal

A scheduled job should reflect current configuration on the very next run.

That means changes to:
- prompt
- policy
- delivery route
- default model

must be loaded at execution time, not remembered from stale session state.

## Recommended default

Use a thin-trigger, file-resolved execution path.

The scheduler should carry only a small stable trigger. The runtime then assembles the job from local files.

## Current OpenClaw reality

Current OpenClaw cron jobs may embed prompt text, model choice, and delivery details directly in the registered job.

That means cron can behave as a snapshot system unless you deliberately design around it.

For dynamic automations, do not treat the cron registration as the canonical source of truth.
Treat it as a trigger carrier.

## Pattern A, wake-only trigger into fresh main execution

Use when:
- you want the latest main assistant behavior automatically
- isolation is less important than immediate propagation

Pros:
- very low drift
- changes apply immediately

Cons:
- less isolated
- changes in main behavior can affect the job unexpectedly

## Pattern B, fresh isolated run from manifest

Use when:
- you want reusable architecture across many agents
- each run should start clean
- immediate application of file changes matters

Pros:
- predictable
- portable
- avoids stale session memory

Cons:
- requires disciplined manifests and policy files

## Pattern C, dispatcher plus fresh worker

Use when:
- orchestration complexity exists
- retries or queues matter
- multi-step automations are needed

Pros:
- scalable
- separates orchestration from generation

Cons:
- more moving parts

## Manifest recommendations

A manifest should explicitly define:
- slug
- name
- agentId
- schedule
- runtimeMode
- triggerMode
- promptFile
- policyFiles
- delivery
- modelPolicy
- verify
- live scheduler id when your local tooling keeps one

## Model policy recommendations

### Best default

```json
{
  "modelPolicy": {
    "mode": "inherit-default"
  }
}
```

Use when the job should follow system model upgrades.

### Intentional pinning

```json
{
  "modelPolicy": {
    "mode": "pin",
    "model": "replace-with-intentional-model"
  }
}
```

Only use if output stability outweighs automatic upgrades.

### Shared policy file

```json
{
  "modelPolicy": {
    "mode": "policy-file",
    "path": "automation/policies/default-runtime.json"
  }
}
```

Use when many jobs should share the same resolution behavior.

## Verification recommendations

Verification should ensure assembly correctness.

Good checks:
- manifest exists
- prompt file exists
- policy files exist
- delivery target matches policy
- schedule matches manifest
- pinned model matches manifest if pinning is intentional

Bad checks:
- exact model verification when model inheritance is intended
- exact prompt text verification when prompt changes should be allowed through file edits

## Delivery recommendation

references/example-migration-daily-briefing.md

# Example migration: Daily briefing job

## Symptoms

A daily briefing keeps using old settings even after the system changed.

Typical signs:
- old model still in use
- old formatting still in use
- requested changes take multiple attempts to stick
- delivery route behaves differently from current runtime expectations

## Root causes to check

- manifest pins an outdated model
- session mode is isolated but still behaves like a stale long-lived context
- prompt changes live partly in chat history instead of files
- outbound delivery route uses misleading session metadata
- verification rules freeze old configuration

## Before

Example brittle pattern:

```json
{
  "model": "old-hardcoded-model-example",
  "session": "isolated",
  "wake": "now",
  "to": "channel:1476754066481877155",
  "verify": {
    "requirePromptExact": true,
    "requireModelExact": true,
    "requireDeliveryExact": true,
    "requireScheduleExact": true
  }
}
```

Problems:
- old model pin
- exact model verification locks drift in place
- outbound target may not be the provider-valid DM form
- prompt exactness can hide where the true source of truth lives

## After

Recommended fresh-runtime pattern:

```json
{
  "slug": "daily-ai-briefing",
  "cronId": "replace-with-live-cron-id-if-tracked-locally",
  "name": "daily-ai-briefing",
  "agentId": "main",
  "schedule": {
    "kind": "cron",
    "expr": "0 8 * * *",
    "tz": "Australia/Brisbane"
  },
  "runtimeMode": "fresh-isolated",
  "triggerMode": "wake-only",
  "promptFile": "automation/jobs/daily-ai-briefing/prompt.md",
  "policyFiles": [
    "automation/jobs/daily-ai-briefing/policy.md"
  ],
  "delivery": {
    "channel": "discord",
    "target": "user:270548320366100480",
    "accountId": "default",
    "mode": "runtime-send"
  },
  "modelPolicy": {
    "mode": "inherit-default"
  },
  "verify": {
    "requirePromptPath": true,
    "requirePolicyPaths": true,
    "requireDeliveryExact": true,
    "requireScheduleExact": true,
    "requireModelExact": false
  }
}
```

If you're using a local automation manager, keeping `slug` and `cronId` in the manifest makes reconciliation and verification deterministic.

## Why this fixes drift

- prompt is loaded from file every run
- policy is loaded from file every run
- delivery target is explicit and provider-valid
- model follows current default unless intentionally pinned
- exact model verification no longer preserves an outdated pin

## Validation checklist

After migration, confirm:
- editing the prompt changes the next run
- editing the policy changes the next run
- changing the default model affects the next run
- delivery still works after a live send test
- attachments work if the job needs them

## Provider-specific reminder

For Discord DMs, outbound sends may require `user:<discord_user_id>` even if session metadata suggests a `channel:<id>` route.

references/job-manifest-template.json

{
  "slug": "example-scheduled-job",
  "cronId": "replace-with-live-cron-id-if-your-tooling-tracks-it",
  "name": "Example scheduled job",
  "agentId": "main",
  "schedule": {
    "kind": "cron",
    "expr": "0 8 * * *",
    "tz": "Australia/Brisbane"
  },
  "runtimeMode": "fresh-isolated",
  "triggerMode": "wake-only",
  "promptFile": "automation/jobs/example-scheduled-job/prompt.md",
  "policyFiles": [
    "automation/policies/default-runtime.json",
    "automation/jobs/example-scheduled-job/policy.md"
  ],
  "delivery": {
    "channel": "discord",
    "target": "user:270548320366100480",
    "accountId": "default",
    "mode": "runtime-send"
  },
  "modelPolicy": {
    "mode": "inherit-default"
  },
  "verify": {
    "requirePromptPath": true,
    "requirePolicyPaths": true,
    "requireDeliveryExact": true,
    "requireScheduleExact": true,
    "requireModelExact": false
  },
  "notes": [
    "Set requireModelExact=true only when modelPolicy.mode is pin.",
    "Do not rely on session metadata for outbound delivery if the provider requires a different target format.",
    "Every run should load promptFile and policyFiles fresh.",
    "If your local automation manager tracks live scheduler ids, keep cronId in sync after create/edit operations."
  ]
}

Github ReposUpdated 1d agoRank 70

AionUi

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!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

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

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.