{"id":"63d15cd3-deb4-4675-8a97-fc01e9e7d166","entityType":"agent","slug":"clawhub-chris-cron-sentinel","name":"cron-sentinel","canonicalUrl":"https://www.xpersona.co/agent/clawhub-chris-cron-sentinel","canonicalPath":"/agent/clawhub-chris-cron-sentinel","generatedAt":"2026-10-14T14:54:28.640Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T21:51:18.229Z","emptyReason":null},"description":"Monitor scheduled/cron jobs and get alerted when one fails OR silently never runs. Use this skill when the goal is reliability or failure-detection for a recurring task the user already runs or is setting up - e.g. 'how would I even know if my cron job silently stopped,' 'my backup didn't run and nothing warned me,' 'monitor my scheduled jobs,' 'alert me when a job fails,' 'add retries and a dead-man's switch to my cron,' or 'is my nightly task still actually running.' It wraps a scheduled command so each run is recorded (exit code, duration, redacted output tail) with optional retries and a timeout, then a watchdog flags both crashed jobs and overdue jobs that silently never ran. Do NOT trigger on plain scheduling requests with no monitoring need ('remind me at 5,' 'run this once tomorrow'), or on general cron-syntax questions ('what does * * * * * mean') - only when reliability or silent-failure detection is the actual ask. Runs a local, standard-library-only Python tool that executes the user's own command directly (no shell), keeps an owner-only state file under ~/.cron-sentinel/, and prints crontab lines for the user to add themselves. It never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges.","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 988 downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17f63svb641q2stekk1cmcdn183k4rq:cron-sentinel","sourceUrl":"https://clawhub.ai/chris/cron-sentinel","homepage":"https://clawhub.ai/chris/skills/cron-sentinel","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/chris/cron-sentinel","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/chris/skills/cron-sentinel","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"cron-sentinel 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-11T21:51:18.229Z","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-11T21:51:18.229Z","emptyReason":null},"stars":null,"forks":null,"downloads":988,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"1.2.0","tractionLabel":"988 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T21:51:18.168Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T21:51:18.229Z","lastCrawledAt":"2026-10-11T21:51:18.168Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T21:51:18.168Z","lastVerifiedAt":null,"highlights":[{"version":"1.2.0","createdAt":"2026-09-28T18:09:52.780Z","changelog":"v1.2.0 - Adds output redaction: output tails are now redacted for common secrets (passwords, tokens, API keys); use `--no-output-tail` to store no output at all. - Tightens security and privacy: commands are run without a shell, state file and directory are owner-only, and the tool never edits or creates scheduled tasks itself. - Updates documentation for precise behavior and new options (`wrap --no-output-tail`) and clarifies crontab setup. - Improves metadata: specifies dependencies, config locations, and environment variable usage. - Removes evals and skill-card files.","fileCount":6,"zipByteSize":14956},{"version":"1.1.0","createdAt":"2026-05-24T15:16:03.991Z","changelog":"Declare permissions in frontmatter, tighten triggers, add secrets warning + when-not-to-use guidance","fileCount":7,"zipByteSize":13478},{"version":"1.0.0","createdAt":"2026-05-23T16:01:38.715Z","changelog":"Initial release of cron-sentinel. - Monitors both crashed and silent (missed) scheduled jobs by wrapping commands to record every run. - Provides four core commands: `wrap` (wraps and tracks a job), `check` (watchdog for failures or missed runs), `status` (overview of tracked jobs), and `crontab` (generates wrapped crontab entries). - Detects silent failures using expected intervals (e.g., `--expect-every 1d`). - Supports job retries, per-attempt timeouts, and fine-tuned overdue detection with grace periods. - Designed to work alongside existing schedulers like cron or OpenClaw's scheduler by providing observability and alerts.","fileCount":6,"zipByteSize":10528}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17f63svb641q2stekk1cmcdn183k4rq:cron-sentinel","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s17f63svb641q2stekk1cmcdn183k4rq:cron-sentinel` 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/chris/cron-sentinel 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-chris-cron-sentinel/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/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-14T14:54:28.640Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-chris-cron-sentinel/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-11T21:51:18.229Z","emptyReason":null},"readme":"Skill: cron-sentinel\n\nOwner: chris\n\nSummary: Monitor scheduled/cron jobs and get alerted when one fails OR silently never runs. Use this skill when the goal is reliability or failure-detection for a recurring task the user already runs or is setting up - e.g. 'how would I even know if my cron job silently stopped,' 'my backup didn't run and nothing warned me,' 'monitor my scheduled jobs,' 'alert me when a job fails,' 'add retries and a dead-man's switch to my cron,' or 'is my nightly task still actually running.' It wraps a scheduled command so each run is recorded (exit code, duration, redacted output tail) with optional retries and a timeout, then a watchdog flags both crashed jobs and overdue jobs that silently never ran. Do NOT trigger on plain scheduling requests with no monitoring need ('remind me at 5,' 'run this once tomorrow'), or on general cron-syntax questions ('what does * * * * * mean') - only when reliability or silent-failure detection is the actual ask. Runs a local, standard-library-only Python tool that executes the user's own command directly (no shell), keeps an owner-only state file under ~/.cron-sentinel/, and prints crontab lines for the user to add themselves. It never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges.\n\nTags: latest:1.2.0\n\nVersion history:\n\nv1.2.0 | 2026-09-28T18:09:52.780Z | auto\n\nv1.2.0\n\n- Adds output redaction: output tails are now redacted for common secrets (passwords, tokens, API keys); use `--no-output-tail` to store no output at all.\n- Tightens security and privacy: commands are run without a shell, state file and directory are owner-only, and the tool never edits or creates scheduled tasks itself.\n- Updates documentation for precise behavior and new options (`wrap --no-output-tail`) and clarifies crontab setup.\n- Improves metadata: specifies dependencies, config locations, and environment variable usage.\n- Removes evals and skill-card files.\n\nv1.1.0 | 2026-05-24T15:16:03.991Z | user\n\nDeclare permissions in frontmatter, tighten triggers, add secrets warning + when-not-to-use guidance\n\nv1.0.0 | 2026-05-23T16:01:38.715Z | auto\n\nInitial release of cron-sentinel.\n\n- Monitors both crashed and silent (missed) scheduled jobs by wrapping commands to record every run.\n- Provides four core commands: `wrap` (wraps and tracks a job), `check` (watchdog for failures or missed runs), `status` (overview of tracked jobs), and `crontab` (generates wrapped crontab entries).\n- Detects silent failures using expected intervals (e.g., `--expect-every 1d`).\n- Supports job retries, per-attempt timeouts, and fine-tuned overdue detection with grace periods.\n- Designed to work alongside existing schedulers like cron or OpenClaw's scheduler by providing observability and alerts.\n\nArchive index:\n\nArchive v1.2.0: 6 files, 14956 bytes\n\nFiles: CHANGELOG.md (3931b), cron_sentinel.py (16741b), README.md (2720b), skill-card.md (1680b), SKILL.md (8986b), _meta.json (132b)\n\nFile v1.2.0:SKILL.md\n\n---\nname: cron-sentinel\nversion: 1.2.0\ndescription: \"Monitor scheduled/cron jobs and get alerted when one fails OR silently never runs. Use this skill when the goal is reliability or failure-detection for a recurring task the user already runs or is setting up - e.g. 'how would I even know if my cron job silently stopped,' 'my backup didn't run and nothing warned me,' 'monitor my scheduled jobs,' 'alert me when a job fails,' 'add retries and a dead-man's switch to my cron,' or 'is my nightly task still actually running.' It wraps a scheduled command so each run is recorded (exit code, duration, redacted output tail) with optional retries and a timeout, then a watchdog flags both crashed jobs and overdue jobs that silently never ran. Do NOT trigger on plain scheduling requests with no monitoring need ('remind me at 5,' 'run this once tomorrow'), or on general cron-syntax questions ('what does * * * * * mean') - only when reliability or silent-failure detection is the actual ask. Runs a local, standard-library-only Python tool that executes the user's own command directly (no shell), keeps an owner-only state file under ~/.cron-sentinel/, and prints crontab lines for the user to add themselves. It never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges.\"\nmetadata:\n  openclaw:\n    emoji: 🛡️\n    requires:\n      bins: [python3]\n      config: [\"~/.cron-sentinel/state.json\"]\n    envVars:\n      - name: CRON_SENTINEL_STATE\n        required: false\n        description: \"Optional path override for the state file. The only environment variable the tool reads.\"\n---\n\n# Cron Sentinel\n\nEveryone monitors the job that crashes. Almost nobody catches the job that just... stops. The machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded - the task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel is a dead-man's switch for your scheduled tasks: it records every run and alerts you both when a job fails loudly and when it goes silent.\n\nFour jobs:\n\n1. **wrap** - run your scheduled command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.\n2. **check** - the watchdog. Reports any job that crashed (non-zero exit) or is overdue (expected to have run by now but hasn't). Exits non-zero if anything is wrong, so it can drive an alert.\n3. **status** - a quick table of every tracked job: last run, health, when it's next expected.\n4. **crontab** - print a ready-to-paste crontab line that wraps a command, plus a watchdog line.\n\n## Permissions & data\n\nThis skill is not informational - it runs a local tool (`cron_sentinel.py`) that touches the system. Be transparent with the user about exactly what it does, and never run it on a command they didn't ask you to wrap. Its full reach:\n\n- **Command execution.** `wrap` runs the command placed after `--` as a direct subprocess with an argument list (`shell=False`), with optional retries and a per-attempt timeout. The command is never interpreted by a shell, and the tool never fetches, downloads, or evaluates anything else.\n- **Filesystem.** Reads and writes one state file, `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`). The folder is created owner-only and the file is written owner-only. Nothing else on disk is touched.\n- **Environment.** Reads `CRON_SENTINEL_STATE` only, to locate the state file.\n- **Network.** None. Pure Python standard library; nothing leaves the machine.\n- **Privileges.** Runs as the current user. It never requests elevated privileges; anything a job needs beyond that belongs in the user's own command and scheduler, not in Sentinel.\n- **Scheduling.** Sentinel never edits a crontab, creates scheduled tasks, or installs startup entries. `crontab` only prints lines for the user to review and add themselves.\n\n**Output and secrets:** so failures are diagnosable, `wrap` saves the last ~2000 characters of a job's output in the state file. Before saving, it masks common secret patterns (passwords, tokens, API keys, bearer headers, cloud and GitHub keys, private-key blocks, credentials in URLs). Redaction is best-effort, so for commands that handle credentials, add `--no-output-tail` to store no output at all. Mention this whenever you help wrap something that handles credentials.\n\n## When to use this\n\nUse this when the user cares about *whether a recurring job actually ran and succeeded* - reliability, alerting, or silent-failure detection. Signals: \"how would I even know if it failed,\" \"my backup didn't run and nothing warned me,\" \"monitor my jobs,\" \"alert me if it stops,\" \"add retries to my cron.\" If they're *creating* a schedule and reliability matters, set it up wrapped from the start. If they're *debugging* a schedule that misbehaved, `status` and `check` tell you what actually happened on the last run.\n\n**When NOT to use:** don't reach for this on a plain \"schedule this\" / \"run it every night\" request where the user just wants the job to run and hasn't expressed any concern about monitoring or failures - set that up with the normal scheduler instead. Likewise skip it for general cron-syntax help (\"what does `0 3 * * *` mean\") and for one-off, run-once-later reminders. Wrapping adds a tool, a state file, and a watchdog; only introduce that when failure-detection is genuinely the point. If you're unsure whether the user wants monitoring, ask before wrapping.\n\nThis is complementary to OpenClaw's own scheduler and to system cron - Sentinel doesn't replace what triggers the job, it makes whatever triggers it observable and self-reporting.\n\n## The tool\n\n```bash\n# Wrap a command (this is what cron actually runs):\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\npython cron_sentinel.py wrap --name sync --no-output-tail -- /path/sync-with-api.sh   # store no output\n\n# The watchdog (run this on its own short schedule):\npython cron_sentinel.py check          # exits 1 if any job failed or is overdue\npython cron_sentinel.py status         # human-readable table\n\n# Generate the crontab lines for the user:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh\n```\n\nThe command to run always goes after `--`. Job names may contain letters, digits, dot, underscore and hyphen. `--expect-every` accepts human durations (`30m`, `12h`, `1d`, `1w`) and is what makes silent-failure detection possible: it's how Sentinel knows a job *should* have run by now. State is stored in `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`); all timestamps are UTC so it stays correct across timezones and DST.\n\n## The pattern to set up\n\nThe whole design is two scheduled entries:\n\n1. **The wrapped job** - the real task, run through `wrap`, on its normal schedule.\n2. **The watchdog** - `check` on a short schedule (e.g. every 30 min) that pipes its output to wherever the user gets notified.\n\n`crontab` prints both lines. Show them to the user and let the user add them with `crontab -e`. Never run `crontab`, edit crontab files, or create scheduled tasks yourself. In OpenClaw, suggest the two scheduled tasks (the wrapped command, and a short-interval `check` whose output routes to their channel), show exactly what each would run, and create them only if the user explicitly confirms.\n\n## How to help\n\n1. **Setting up a new schedule:** ask for the command, how often it should run, and whether retries make sense (yes for anything network-dependent). Then produce the wrapped crontab line via `crontab`, and explain the watchdog line. Always set `--expect-every` - without it, silent failures can't be detected, which is the whole point.\n2. **\"Is my job still working?\"** run `status` and read back the last run time and health. If it shows `overdue`, that's your silent failure.\n3. **\"My job failed / isn't running\":** run `check`. A `💥 failed` means it ran and errored - show the captured output tail. A `🔇 overdue` means it never ran - the problem is upstream (the trigger, the machine, the path), not the command itself. That distinction saves a lot of wasted debugging.\n4. **Wiring up alerts:** the `check` exit code and output are designed to feed a notifier. In OpenClaw, schedule `check` and route its output to the user's channel so they only hear from it when something is actually wrong.\n\n## Honest interpretation\n\n- `overdue` uses a grace window (default 50% of the interval) so a job that's merely a little late doesn't cry wolf. Tune with `--grace` if a job's timing is naturally loose.\n- A `check` that reports all healthy is a real green light - say so plainly.\n- Retries help with *transient* failures (a flaky network call). They won't fix a broken command, and Sentinel still records the final failure - so don't let retries mask a job that's genuinely broken.\n\nFile v1.2.0:README.md\n\n# Cron Sentinel 🛡️\n\nA dead-man's switch for your scheduled tasks. Bulletproof scheduling that alerts you when a job **silently** fails.\n\nEveryone monitors the job that crashes. Almost nobody catches the job that just... stops — the machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded. The task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel catches both the loud failures and the silent ones.\n\n## What it does\n\n- **wrap** — run your command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.\n- **check** — the watchdog. Flags any job that crashed *or* is overdue (should have run by now but didn't). Exits non-zero so it can drive an alert.\n- **status** — a quick table of every tracked job: last run, health, next expected.\n- **crontab** — prints a ready-to-paste wrapped crontab line plus a watchdog line.\n\n## Quick start\n\n```bash\n# What cron actually runs:\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (its own short schedule):\npython cron_sentinel.py check       # exits 1 if anything failed or went silent\npython cron_sentinel.py status\n\n# Generate the crontab lines:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh\n```\n\nThe command always goes after `--`. `--expect-every` (`30m`, `12h`, `1d`, `1w`) is what makes silent-failure detection possible — it's how Sentinel knows a job *should* have run. State lives in `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`); all timestamps are UTC, so it's correct across timezones and DST.\n\n## The whole idea in two lines\n\n1. The **wrapped job** runs your real task on its normal schedule.\n2. The **watchdog** runs `check` every few minutes and pings you only when something's wrong.\n\nA `💥 failed` means it ran and errored (show the output tail). A `🔇 overdue` means it never ran — the problem is upstream, not the command. That distinction alone saves hours of debugging.\n\n## Safety and scope\n\n- Runs only the command you give it, directly, never through a shell\n- Never edits your crontab or creates scheduled tasks: `crontab` just prints lines for you to add\n- No network access and no dependencies; runs as your normal user\n- State is kept in one owner-only file (`~/.cron-sentinel/state.json`)\n- Secret-looking values in captured output are masked before saving; use `--no-output-tail` to save no output at all\n\n## Requirements\n\n- Python 3.8+ (standard library only). No API key, no external services.\n\nFile v1.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn77r9qjvh6fy4aja2km8bzgvd83khv9\",\n  \"slug\": \"cron-sentinel\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1790618992780\n}\n\nFile v1.2.0:CHANGELOG.md\n\n# Changelog\n\nAll notable changes to Cron Sentinel are documented here. Format follows [Keep a Changelog](https://keepachangelog.com/); this project adheres to semantic versioning.\n\n## [1.2.0] - 2026-09-28\n\nFixes from ClawHub's security audit. Existing commands and state files keep working.\n\n### Security\n- **State file is now owner-only.** The state folder is created with 0700 and `state.json` is written with 0600.\n- **Secrets are redacted before saving.** Captured output is scanned for common credential patterns (password/token/API-key assignments, bearer and basic auth headers, AWS, GitHub, Slack and `sk-` style keys, private-key blocks, credentials in URLs) and masked before it's written to the state file.\n- **New `--no-output-tail` flag** for `wrap` stores no command output at all.\n- **`crontab` output is validated and quoted.** `--name` must be a simple identifier, `--schedule` must be five cron fields or a macro like `@daily`, `--expect-every` must parse as a duration, the Python and script paths are quoted, and `%` is escaped so the printed line can't be broken or injected into.\n- `wrap` now passes `shell=False` explicitly and documents that commands are never run through a shell.\n\n### Changed\n- Replaced the frontmatter `permissions` block (not part of ClawHub's schema, so it wasn't being read) with `metadata.openclaw.requires` and `envVars` declarations.\n- SKILL.md and the description now state plainly that Sentinel never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges, and that the agent must not create scheduled tasks without the user's explicit confirmation.\n- Corrected the description, which previously said commands run \"via the shell.\"\n- `crontab` output now opens with a note that Sentinel doesn't install anything.\n\n### Added\n- `.clawhubignore` so development-only files (`evals/`) stay in the repository but aren't published to ClawHub.\n\n## [1.1.0] - 2026-05-24\n\nSecurity-review fixes. No behavior change to the tool itself.\n\n### Added\n- Explicit `permissions` block in the SKILL.md frontmatter (shell execution, state-file read/write under `~/.cron-sentinel/`, the `CRON_SENTINEL_STATE` env var, and no network) so the skill's real capabilities are visible to the permission model and to reviewers instead of being implicit in the code.\n- \"Permissions & data\" section documenting exactly what the skill touches, plus a secrets warning that `wrap` stores the last ~2000 chars of a job's output in `state.json` in plaintext (with mitigations).\n- \"When NOT to use\" guidance to keep the skill from activating on plain scheduling requests, cron-syntax questions, and one-off reminders.\n\n### Changed\n- Tightened the description and \"When to use this\" triggers to scope activation to reliability / silent-failure-detection intent rather than every mention of scheduling.\n\n## [1.0.0] - 2026-05-23\n\nInitial release.\n\n### Added\n- `wrap` command: runs a scheduled command and records each run (start, end, exit code, duration, output tail) to a state file, with configurable retries (exponential backoff) and a per-attempt timeout. Output is passed through transparently and the command's exit code is preserved.\n- `check` command: watchdog that flags both crashed jobs (non-zero exit) and overdue jobs (expected to have run by now but didn't), with a tunable grace window. Exits non-zero when any job is unhealthy so it can drive an alert.\n- `status` command: human-readable table of every tracked job — last run, health, and next expected time.\n- `crontab` command: prints a ready-to-paste wrapped crontab line plus a watchdog line, with correct shell quoting.\n- Human-duration parsing for cadence (`30m`, `12h`, `1d`, `1w`) powering silent-failure detection.\n- UTC-based timestamps and atomic state writes for correctness across timezones, DST, and concurrent runs.\n- Zero dependencies: pure Python standard library. No API key or external service.\n\nFile v1.2.0:skill-card.md\n\n## Description:\n\nMonitors recurring jobs for failures and missed runs, with optional retries and guidance for setting up alerts.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[chris](https://clawhub.ai/user/chris)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and operators use this skill to detect failed or overdue scheduled jobs and set up a watchdog that can trigger their chosen alerting channel.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated crontab lines may schedule commands or alerts differently than intended.\n\nMitigation: Review generated lines before adding them to the scheduler.\n\nRisk: Captured job output may contain credentials or other sensitive data despite best-effort redaction.\n\nMitigation: Use --no-output-tail for jobs that may print sensitive information.\n\n## Reference(s):\n\n- [Cron Sentinel on ClawHub](https://clawhub.ai/chris/skills/cron-sentinel)\n\n## Skill Output:\n\n**Output Type(s):** [Shell commands, Configuration instructions, Guidance]\n\n**Output Format:** [Markdown with shell snippets and human-readable job status]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Generated crontab entries require user review and installation; watchdog checks can exit non-zero to signal unhealthy jobs.]\n\n## Skill Version(s):\n\n1.2.0 (source: frontmatter, changelog, ClawHub release)\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.1.0: 7 files, 13478 bytes\n\nFiles: CHANGELOG.md (2187b), cron_sentinel.py (12751b), evals/evals.json (1965b), README.md (2277b), skill-card.md (2502b), SKILL.md (8381b), _meta.json (132b)\n\nFile v1.1.0:SKILL.md\n\n---\nname: cron-sentinel\nversion: \"1.1.0\"\ndescription: \"Monitor scheduled/cron jobs and get alerted when one fails OR silently never runs. Use this skill when the goal is reliability or failure-detection for a recurring task the user already runs or is setting up - e.g. 'how would I even know if my cron job silently stopped,' 'my backup didn't run and nothing warned me,' 'monitor my scheduled jobs,' 'alert me when a job fails,' 'add retries and a dead-man's switch to my cron,' or 'is my nightly task still actually running.' It wraps a scheduled command so each run is recorded (exit code, duration, output tail) with optional retries and a timeout, then a watchdog flags both crashed jobs and overdue jobs that silently never ran. Do NOT trigger on plain scheduling requests with no monitoring need ('remind me at 5,' 'run this once tomorrow'), or on general cron-syntax questions ('what does * * * * * mean') - only when reliability or silent-failure detection is the actual ask. Requires running a local Python tool that executes the wrapped command via the shell and reads/writes a state file under ~/.cron-sentinel/.\"\nmetadata:\n  openclaw:\n    emoji: 🛡️\n    # Declared so the skill's real reach is visible to the permission model and reviewers.\n    permissions:\n      shell: true                    # runs the command you pass after `--` (cron_sentinel.py wrap)\n      filesystem:\n        read: [\"~/.cron-sentinel/\"]   # loads run-state\n        write: [\"~/.cron-sentinel/\"]  # records each run (state.json), created if absent\n      env:\n        read: [\"CRON_SENTINEL_STATE\"] # optional override of the state-file path\n      network: false                 # no outbound network; pure stdlib\n---\n\n# Cron Sentinel\n\nEveryone monitors the job that crashes. Almost nobody catches the job that just... stops. The machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded - the task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel is a dead-man's switch for your scheduled tasks: it records every run and alerts you both when a job fails loudly and when it goes silent.\n\nFour jobs:\n\n1. **wrap** - run your scheduled command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.\n2. **check** - the watchdog. Reports any job that crashed (non-zero exit) or is overdue (expected to have run by now but hasn't). Exits non-zero if anything is wrong, so it can drive an alert.\n3. **status** - a quick table of every tracked job: last run, health, when it's next expected.\n4. **crontab** - print a ready-to-paste crontab line that wraps a command, plus a watchdog line.\n\n## Permissions & data\n\nThis skill is not informational - it runs a local tool (`cron_sentinel.py`) that touches the system. Be transparent with the user about exactly what it does, and never run it on a command they didn't ask you to wrap. Its full reach (also declared in the frontmatter `permissions` block):\n\n- **Shell execution.** `wrap` runs the command you place after `--` via a subprocess, with optional retries and a per-attempt timeout. It only ever runs the command the user explicitly provides - it does not fetch or execute anything else.\n- **Filesystem.** Reads and writes a single state file at `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`). The directory is created if missing. Nothing else on disk is touched.\n- **Environment.** Reads `CRON_SENTINEL_STATE` only, to locate the state file. No other env vars are read.\n- **Network.** None. Pure Python standard library; nothing leaves the machine.\n\n**Secrets warning:** `wrap` stores the last ~2000 characters of a job's combined stdout/stderr in `state.json` so failures are diagnosable. If a wrapped command prints a token, password, or other secret, that value lands in the state file in plaintext. For commands that emit secrets, either redirect that output away from Sentinel, restrict the state file (`chmod 600`), or point `--state` at a protected location. Mention this whenever you help wrap something that handles credentials.\n\n## When to use this\n\nUse this when the user cares about *whether a recurring job actually ran and succeeded* - reliability, alerting, or silent-failure detection. Signals: \"how would I even know if it failed,\" \"my backup didn't run and nothing warned me,\" \"monitor my jobs,\" \"alert me if it stops,\" \"add retries to my cron.\" If they're *creating* a schedule and reliability matters, set it up wrapped from the start. If they're *debugging* a schedule that misbehaved, `status` and `check` tell you what actually happened on the last run.\n\n**When NOT to use:** don't reach for this on a plain \"schedule this\" / \"run it every night\" request where the user just wants the job to run and hasn't expressed any concern about monitoring or failures - set that up with the normal scheduler instead. Likewise skip it for general cron-syntax help (\"what does `0 3 * * *` mean\") and for one-off, run-once-later reminders. Wrapping adds a tool, a state file, and a watchdog; only introduce that when failure-detection is genuinely the point. If you're unsure whether the user wants monitoring, ask before wrapping.\n\nThis is complementary to OpenClaw's own scheduler and to system cron - Sentinel doesn't replace what triggers the job, it makes whatever triggers it observable and self-reporting.\n\n## The tool\n\n```bash\n# Wrap a command (this is what cron actually runs):\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (run this on its own short schedule):\npython cron_sentinel.py check          # exits 1 if any job failed or is overdue\npython cron_sentinel.py status         # human-readable table\n\n# Generate the crontab lines for the user:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh\n```\n\nThe command to run always goes after `--`. `--expect-every` accepts human durations (`30m`, `12h`, `1d`, `1w`) and is what makes silent-failure detection possible: it's how Sentinel knows a job *should* have run by now. State is stored in `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`); all timestamps are UTC so it stays correct across timezones and DST.\n\n## The pattern to set up\n\nThe whole design is two scheduled entries:\n\n1. **The wrapped job** - the real task, run through `wrap`, on its normal schedule.\n2. **The watchdog** - `check` on a short schedule (e.g. every 30 min) that pipes its output to wherever the user gets notified.\n\n`crontab` prints both lines. Walk the user through pasting them, or, in OpenClaw, register the wrapped command as the scheduled task and a `check` as a second short-interval task whose output routes to their channel.\n\n## How to help\n\n1. **Setting up a new schedule:** ask for the command, how often it should run, and whether retries make sense (yes for anything network-dependent). Then produce the wrapped crontab line via `crontab`, and explain the watchdog line. Always set `--expect-every` - without it, silent failures can't be detected, which is the whole point.\n2. **\"Is my job still working?\"** run `status` and read back the last run time and health. If it shows `overdue`, that's your silent failure.\n3. **\"My job failed / isn't running\":** run `check`. A `💥 failed` means it ran and errored - show the captured output tail. A `🔇 overdue` means it never ran - the problem is upstream (the trigger, the machine, the path), not the command itself. That distinction saves a lot of wasted debugging.\n4. **Wiring up alerts:** the `check` exit code and output are designed to feed a notifier. In OpenClaw, schedule `check` and route its output to the user's channel so they only hear from it when something is actually wrong.\n\n## Honest interpretation\n\n- `overdue` uses a grace window (default 50% of the interval) so a job that's merely a little late doesn't cry wolf. Tune with `--grace` if a job's timing is naturally loose.\n- A `check` that reports all healthy is a real green light - say so plainly.\n- Retries help with *transient* failures (a flaky network call). They won't fix a broken command, and Sentinel still records the final failure - so don't let retries mask a job that's genuinely broken.\n\nFile v1.1.0:README.md\n\n# Cron Sentinel 🛡️\n\nA dead-man's switch for your scheduled tasks. Bulletproof scheduling that alerts you when a job **silently** fails.\n\nEveryone monitors the job that crashes. Almost nobody catches the job that just... stops — the machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded. The task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel catches both the loud failures and the silent ones.\n\n## What it does\n\n- **wrap** — run your command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.\n- **check** — the watchdog. Flags any job that crashed *or* is overdue (should have run by now but didn't). Exits non-zero so it can drive an alert.\n- **status** — a quick table of every tracked job: last run, health, next expected.\n- **crontab** — prints a ready-to-paste wrapped crontab line plus a watchdog line.\n\n## Quick start\n\n```bash\n# What cron actually runs:\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (its own short schedule):\npython cron_sentinel.py check       # exits 1 if anything failed or went silent\npython cron_sentinel.py status\n\n# Generate the crontab lines:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh\n```\n\nThe command always goes after `--`. `--expect-every` (`30m`, `12h`, `1d`, `1w`) is what makes silent-failure detection possible — it's how Sentinel knows a job *should* have run. State lives in `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`); all timestamps are UTC, so it's correct across timezones and DST.\n\n## The whole idea in two lines\n\n1. The **wrapped job** runs your real task on its normal schedule.\n2. The **watchdog** runs `check` every few minutes and pings you only when something's wrong.\n\nA `💥 failed` means it ran and errored (show the output tail). A `🔇 overdue` means it never ran — the problem is upstream, not the command. That distinction alone saves hours of debugging.\n\n## Requirements\n\n- Python 3.8+ (standard library only). No API key, no external services.\n\nFile v1.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn77r9qjvh6fy4aja2km8bzgvd83khv9\",\n  \"slug\": \"cron-sentinel\",\n  \"version\": \"1.1.0\",\n  \"publishedAt\": 1779635763991\n}\n\nFile v1.1.0:CHANGELOG.md\n\n# Changelog\n\nAll notable changes to Cron Sentinel are documented here. Format follows [Keep a Changelog](https://keepachangelog.com/); this project adheres to semantic versioning.\n\n## [1.1.0] - 2026-05-24\n\nSecurity-review fixes. No behavior change to the tool itself.\n\n### Added\n- Explicit `permissions` block in the SKILL.md frontmatter (shell execution, state-file read/write under `~/.cron-sentinel/`, the `CRON_SENTINEL_STATE` env var, and no network) so the skill's real capabilities are visible to the permission model and to reviewers instead of being implicit in the code.\n- \"Permissions & data\" section documenting exactly what the skill touches, plus a secrets warning that `wrap` stores the last ~2000 chars of a job's output in `state.json` in plaintext (with mitigations).\n- \"When NOT to use\" guidance to keep the skill from activating on plain scheduling requests, cron-syntax questions, and one-off reminders.\n\n### Changed\n- Tightened the description and \"When to use this\" triggers to scope activation to reliability / silent-failure-detection intent rather than every mention of scheduling.\n\n## [1.0.0] - 2026-05-23\n\nInitial release.\n\n### Added\n- `wrap` command: runs a scheduled command and records each run (start, end, exit code, duration, output tail) to a state file, with configurable retries (exponential backoff) and a per-attempt timeout. Output is passed through transparently and the command's exit code is preserved.\n- `check` command: watchdog that flags both crashed jobs (non-zero exit) and overdue jobs (expected to have run by now but didn't), with a tunable grace window. Exits non-zero when any job is unhealthy so it can drive an alert.\n- `status` command: human-readable table of every tracked job — last run, health, and next expected time.\n- `crontab` command: prints a ready-to-paste wrapped crontab line plus a watchdog line, with correct shell quoting.\n- Human-duration parsing for cadence (`30m`, `12h`, `1d`, `1w`) powering silent-failure detection.\n- UTC-based timestamps and atomic state writes for correctness across timezones, DST, and concurrent runs.\n- Zero dependencies: pure Python standard library. No API key or external service.\n\nFile v1.1.0:skill-card.md\n\n## Description:\n\nCron Sentinel helps monitor scheduled jobs by wrapping a recurring command, recording each run, and checking for both failed runs and overdue jobs that silently stopped running.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[chris](https://clawhub.ai/user/chris)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, operators, and technical users use this skill to add failure detection, retries, status checks, and watchdog alerts around recurring cron or scheduled jobs. It is most useful when a task must be observable if it crashes or silently stops running.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated crontab lines may persist unintended commands if untrusted job names, schedules, or command fields are used.\n\nMitigation: Use trusted inputs only and inspect every generated crontab line for extra commands, semicolons, command substitutions, and unexpected new lines before installing it.\n\nRisk: Wrapped jobs can store captured stdout and stderr in plaintext state, including secrets if the wrapped command prints them.\n\nMitigation: Avoid wrapping commands that print tokens or passwords, redirect sensitive output away from the wrapper, or store the state file in a private user-owned location with restrictive permissions.\n\nRisk: The skill executes the user-provided wrapped command through a local shell workflow.\n\nMitigation: Run it only for commands the user explicitly chose to monitor and explain the local shell and state-file effects before setup.\n\n## Reference(s):\n\n- [Cron Sentinel ClawHub page](https://clawhub.ai/chris/skills/cron-sentinel)\n- [chris publisher profile](https://clawhub.ai/user/chris)\n- [README.md](artifact/README.md)\n- [CHANGELOG.md](artifact/CHANGELOG.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown with inline shell commands and crontab examples]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May include watchdog status interpretation, ready-to-paste crontab lines, and local state-file handling guidance.]\n\n## Skill Version(s):\n\n1.1.0 (source: frontmatter and 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\nFile v1.1.0:evals/evals.json\n\n{\n  \"skill_name\": \"cron-sentinel\",\n  \"evals\": [\n    {\n      \"id\": 0,\n      \"name\": \"setup-reliable-schedule\",\n      \"prompt\": \"I want my backup script at /home/me/backup.sh to run every night at 3am, and I want to actually find out if it ever stops running. Walk me through setting that up so it's reliable.\",\n      \"expected_output\": \"Uses cron_sentinel.py to produce a crontab line that wraps the backup command (wrap --name ... --expect-every 1d), plus a separate watchdog line that runs `check` on a short interval to alert on failures or silence. Explains the two-line pattern and why --expect-every enables silent-failure detection.\",\n      \"files\": [],\n      \"assertions\": [\n        {\"text\": \"Produces a crontab line that runs the backup through cron_sentinel.py wrap\", \"kind\": \"qualitative\"},\n        {\"text\": \"Sets an expected cadence (--expect-every) so overdue/silent runs can be detected\", \"kind\": \"qualitative\"},\n        {\"text\": \"Includes a separate watchdog (check) on its own schedule for alerting\", \"kind\": \"qualitative\"}\n      ]\n    },\n    {\n      \"id\": 1,\n      \"name\": \"detect-silent-failure\",\n      \"prompt\": \"My nightly job hasn't produced output for two days but I never got an error message. Going forward, how do I detect when a scheduled job silently stops running, not just when it crashes?\",\n      \"expected_output\": \"Explains the dead-man's-switch pattern: wrap the job so each run is recorded with an expected cadence, then run `check`, which flags jobs that are overdue (never ran) distinctly from jobs that crashed. Ideally demonstrates with cron_sentinel.py.\",\n      \"files\": [],\n      \"assertions\": [\n        {\"text\": \"Explains detecting overdue / never-ran jobs, not just crashes\", \"kind\": \"qualitative\"},\n        {\"text\": \"Recommends wrapping the job and running check on a schedule\", \"kind\": \"qualitative\"},\n        {\"text\": \"Distinguishes a silent/overdue failure from a loud crash\", \"kind\": \"qualitative\"}\n      ]\n    }\n  ]\n}\n\nArchive v1.0.0: 6 files, 10528 bytes\n\nFiles: CHANGELOG.md (1259b), cron_sentinel.py (12751b), evals/evals.json (1965b), README.md (2277b), SKILL.md (5560b), _meta.json (132b)\n\nFile v1.0.0:SKILL.md\n\n---\nname: cron-sentinel\nversion: \"1.0.0\"\ndescription: \"Make scheduled jobs bulletproof and get alerted when one SILENTLY fails. Use this skill whenever the user is setting up, debugging, or worrying about recurring/scheduled tasks, including phrases like 'schedule this job,' 'set up a cron job,' 'run this every night,' 'my cron job isn't running,' 'how do I know if my scheduled task failed,' 'my backup didn't run and nobody told me,' 'add retries to my cron,' 'why did my job stop running,' 'monitor my scheduled jobs,' 'alert me when a job fails,' 'is my nightly task still working,' or 'make this schedule reliable.' Wraps any scheduled command so every run is recorded with retries and timeouts, then a watchdog catches BOTH crashed jobs and the more dangerous silent failures - jobs that simply never ran (machine asleep, cron misconfigured, command renamed) and produced no error for anyone to notice. The dead-man's switch for your cron.\"\nmetadata:\n  openclaw:\n    emoji: 🛡️\n---\n\n# Cron Sentinel\n\nEveryone monitors the job that crashes. Almost nobody catches the job that just... stops. The machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded - the task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel is a dead-man's switch for your scheduled tasks: it records every run and alerts you both when a job fails loudly and when it goes silent.\n\nFour jobs:\n\n1. **wrap** - run your scheduled command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.\n2. **check** - the watchdog. Reports any job that crashed (non-zero exit) or is overdue (expected to have run by now but hasn't). Exits non-zero if anything is wrong, so it can drive an alert.\n3. **status** - a quick table of every tracked job: last run, health, when it's next expected.\n4. **crontab** - print a ready-to-paste crontab line that wraps a command, plus a watchdog line.\n\n## When to use this\n\nWhenever recurring tasks come up: \"schedule this,\" \"run it every night,\" \"my cron job isn't running,\" \"how would I even know if it failed,\" \"add retries,\" \"my backup didn't run and nothing warned me,\" \"monitor my jobs.\" If the user is *creating* a schedule, set it up wrapped from the start. If they're *debugging* a schedule that misbehaved, `status` and `check` tell you what actually happened on the last run.\n\nThis is complementary to OpenClaw's own scheduler and to system cron - Sentinel doesn't replace what triggers the job, it makes whatever triggers it observable and self-reporting.\n\n## The tool\n\n```bash\n# Wrap a command (this is what cron actually runs):\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (run this on its own short schedule):\npython cron_sentinel.py check          # exits 1 if any job failed or is overdue\npython cron_sentinel.py status         # human-readable table\n\n# Generate the crontab lines for the user:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh\n```\n\nThe command to run always goes after `--`. `--expect-every` accepts human durations (`30m`, `12h`, `1d`, `1w`) and is what makes silent-failure detection possible: it's how Sentinel knows a job *should* have run by now. State is stored in `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`); all timestamps are UTC so it stays correct across timezones and DST.\n\n## The pattern to set up\n\nThe whole design is two scheduled entries:\n\n1. **The wrapped job** - the real task, run through `wrap`, on its normal schedule.\n2. **The watchdog** - `check` on a short schedule (e.g. every 30 min) that pipes its output to wherever the user gets notified.\n\n`crontab` prints both lines. Walk the user through pasting them, or, in OpenClaw, register the wrapped command as the scheduled task and a `check` as a second short-interval task whose output routes to their channel.\n\n## How to help\n\n1. **Setting up a new schedule:** ask for the command, how often it should run, and whether retries make sense (yes for anything network-dependent). Then produce the wrapped crontab line via `crontab`, and explain the watchdog line. Always set `--expect-every` - without it, silent failures can't be detected, which is the whole point.\n2. **\"Is my job still working?\"** run `status` and read back the last run time and health. If it shows `overdue`, that's your silent failure.\n3. **\"My job failed / isn't running\":** run `check`. A `💥 failed` means it ran and errored - show the captured output tail. A `🔇 overdue` means it never ran - the problem is upstream (the trigger, the machine, the path), not the command itself. That distinction saves a lot of wasted debugging.\n4. **Wiring up alerts:** the `check` exit code and output are designed to feed a notifier. In OpenClaw, schedule `check` and route its output to the user's channel so they only hear from it when something is actually wrong.\n\n## Honest interpretation\n\n- `overdue` uses a grace window (default 50% of the interval) so a job that's merely a little late doesn't cry wolf. Tune with `--grace` if a job's timing is naturally loose.\n- A `check` that reports all healthy is a real green light - say so plainly.\n- Retries help with *transient* failures (a flaky network call). They won't fix a broken command, and Sentinel still records the final failure - so don't let retries mask a job that's genuinely broken.\n\nFile v1.0.0:README.md\n\n# Cron Sentinel 🛡️\n\nA dead-man's switch for your scheduled tasks. Bulletproof scheduling that alerts you when a job **silently** fails.\n\nEveryone monitors the job that crashes. Almost nobody catches the job that just... stops — the machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded. The task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel catches both the loud failures and the silent ones.\n\n## What it does\n\n- **wrap** — run your command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.\n- **check** — the watchdog. Flags any job that crashed *or* is overdue (should have run by now but didn't). Exits non-zero so it can drive an alert.\n- **status** — a quick table of every tracked job: last run, health, next expected.\n- **crontab** — prints a ready-to-paste wrapped crontab line plus a watchdog line.\n\n## Quick start\n\n```bash\n# What cron actually runs:\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (its own short schedule):\npython cron_sentinel.py check       # exits 1 if anything failed or went silent\npython cron_sentinel.py status\n\n# Generate the crontab lines:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh\n```\n\nThe command always goes after `--`. `--expect-every` (`30m`, `12h`, `1d`, `1w`) is what makes silent-failure detection possible — it's how Sentinel knows a job *should* have run. State lives in `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`); all timestamps are UTC, so it's correct across timezones and DST.\n\n## The whole idea in two lines\n\n1. The **wrapped job** runs your real task on its normal schedule.\n2. The **watchdog** runs `check` every few minutes and pings you only when something's wrong.\n\nA `💥 failed` means it ran and errored (show the output tail). A `🔇 overdue` means it never ran — the problem is upstream, not the command. That distinction alone saves hours of debugging.\n\n## Requirements\n\n- Python 3.8+ (standard library only). No API key, no external services.\n\nFile v1.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn77r9qjvh6fy4aja2km8bzgvd83khv9\",\n  \"slug\": \"cron-sentinel\",\n  \"version\": \"1.0.0\",\n  \"publishedAt\": 1779552098715\n}\n\nFile v1.0.0:CHANGELOG.md\n\n# Changelog\n\nAll notable changes to Cron Sentinel are documented here. Format follows [Keep a Changelog](https://keepachangelog.com/); this project adheres to semantic versioning.\n\n## [1.0.0] - 2026-05-23\n\nInitial release.\n\n### Added\n- `wrap` command: runs a scheduled command and records each run (start, end, exit code, duration, output tail) to a state file, with configurable retries (exponential backoff) and a per-attempt timeout. Output is passed through transparently and the command's exit code is preserved.\n- `check` command: watchdog that flags both crashed jobs (non-zero exit) and overdue jobs (expected to have run by now but didn't), with a tunable grace window. Exits non-zero when any job is unhealthy so it can drive an alert.\n- `status` command: human-readable table of every tracked job — last run, health, and next expected time.\n- `crontab` command: prints a ready-to-paste wrapped crontab line plus a watchdog line, with correct shell quoting.\n- Human-duration parsing for cadence (`30m`, `12h`, `1d`, `1w`) powering silent-failure detection.\n- UTC-based timestamps and atomic state writes for correctness across timezones, DST, and concurrent runs.\n- Zero dependencies: pure Python standard library. No API key or external service.\n\nFile v1.0.0:evals/evals.json\n\n{\n  \"skill_name\": \"cron-sentinel\",\n  \"evals\": [\n    {\n      \"id\": 0,\n      \"name\": \"setup-reliable-schedule\",\n      \"prompt\": \"I want my backup script at /home/me/backup.sh to run every night at 3am, and I want to actually find out if it ever stops running. Walk me through setting that up so it's reliable.\",\n      \"expected_output\": \"Uses cron_sentinel.py to produce a crontab line that wraps the backup command (wrap --name ... --expect-every 1d), plus a separate watchdog line that runs `check` on a short interval to alert on failures or silence. Explains the two-line pattern and why --expect-every enables silent-failure detection.\",\n      \"files\": [],\n      \"assertions\": [\n        {\"text\": \"Produces a crontab line that runs the backup through cron_sentinel.py wrap\", \"kind\": \"qualitative\"},\n        {\"text\": \"Sets an expected cadence (--expect-every) so overdue/silent runs can be detected\", \"kind\": \"qualitative\"},\n        {\"text\": \"Includes a separate watchdog (check) on its own schedule for alerting\", \"kind\": \"qualitative\"}\n      ]\n    },\n    {\n      \"id\": 1,\n      \"name\": \"detect-silent-failure\",\n      \"prompt\": \"My nightly job hasn't produced output for two days but I never got an error message. Going forward, how do I detect when a scheduled job silently stops running, not just when it crashes?\",\n      \"expected_output\": \"Explains the dead-man's-switch pattern: wrap the job so each run is recorded with an expected cadence, then run `check`, which flags jobs that are overdue (never ran) distinctly from jobs that crashed. Ideally demonstrates with cron_sentinel.py.\",\n      \"files\": [],\n      \"assertions\": [\n        {\"text\": \"Explains detecting overdue / never-ran jobs, not just crashes\", \"kind\": \"qualitative\"},\n        {\"text\": \"Recommends wrapping the job and running check on a schedule\", \"kind\": \"qualitative\"},\n        {\"text\": \"Distinguishes a silent/overdue failure from a loud crash\", \"kind\": \"qualitative\"}\n      ]\n    }\n  ]\n}","readmeExcerpt":"Skill: cron-sentinel Owner: chris Summary: Monitor scheduled/cron jobs and get alerted when one fails OR silently never runs. Use this skill when the goal is reliability or failure-detection for a recurring task the user already runs or is setting up - e.g. 'how would I even know if my cron job silently stopped,' 'my backup didn't run and nothing warned me,' 'monitor my scheduled jobs,' 'alert me when a job fails,' '","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"# Wrap a command (this is what cron actually runs):\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\npython cron_sentinel.py wrap --name sync --no-output-tail -- /path/sync-with-api.sh   # store no output\n\n# The watchdog (run this on its own short schedule):\npython cron_sentinel.py check          # exits 1 if any job failed or is overdue\npython cron_sentinel.py status         # human-readable table\n\n# Generate the crontab lines for the user:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh"},{"language":"bash","snippet":"# What cron actually runs:\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (its own short schedule):\npython cron_sentinel.py check       # exits 1 if anything failed or went silent\npython cron_sentinel.py status\n\n# Generate the crontab lines:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh"},{"language":"bash","snippet":"# Wrap a command (this is what cron actually runs):\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (run this on its own short schedule):\npython cron_sentinel.py check          # exits 1 if any job failed or is overdue\npython cron_sentinel.py status         # human-readable table\n\n# Generate the crontab lines for the user:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh"},{"language":"bash","snippet":"# What cron actually runs:\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (its own short schedule):\npython cron_sentinel.py check       # exits 1 if anything failed or went silent\npython cron_sentinel.py status\n\n# Generate the crontab lines:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh"},{"language":"bash","snippet":"# Wrap a command (this is what cron actually runs):\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (run this on its own short schedule):\npython cron_sentinel.py check          # exits 1 if any job failed or is overdue\npython cron_sentinel.py status         # human-readable table\n\n# Generate the crontab lines for the user:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh"},{"language":"bash","snippet":"# What cron actually runs:\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (its own short schedule):\npython cron_sentinel.py check       # exits 1 if anything failed or went silent\npython cron_sentinel.py status\n\n# Generate the crontab lines:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: cron-sentinel\nversion: 1.2.0\ndescription: \"Monitor scheduled/cron jobs and get alerted when one fails OR silently never runs. Use this skill when the goal is reliability or failure-detection for a recurring task the user already runs or is setting up - e.g. 'how would I even know if my cron job silently stopped,' 'my backup didn't run and nothing warned me,' 'monitor my scheduled jobs,' 'alert me when a job fails,' 'add retries and a dead-man's switch to my cron,' or 'is my nightly task still actually running.' It wraps a scheduled command so each run is recorded (exit code, duration, redacted output tail) with optional retries and a timeout, then a watchdog flags both crashed jobs and overdue jobs that silently never ran. Do NOT trigger on plain scheduling requests with no monitoring need ('remind me at 5,' 'run this once tomorrow'), or on general cron-syntax questions ('what does * * * * * mean') - only when reliability or silent-failure detection is the actual ask. Runs a local, standard-library-only Python tool that executes the user's own command directly (no shell), keeps an owner-only state file under ~/.cron-sentinel/, and prints crontab lines for the user to add themselves. It never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges.\"\nmetadata:\n  openclaw:\n    emoji: 🛡️\n    requires:\n      bins: [python3]\n      config: [\"~/.cron-sentinel/state.json\"]\n    envVars:\n      - name: CRON_SENTINEL_STATE\n        required: false\n        description: \"Optional path override for the state file. The only environment variable the tool reads.\"\n---\n\n# Cron Sentinel\n\nEveryone monitors the job that crashes. Almost nobody catches the job that just... stops. The machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded - the task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel is a dead-man's switch for your scheduled tasks: it records every run and alerts you both when a job fails loudly and when it goes silent.\n\nFour jobs:\n\n1. **wrap** - run your scheduled command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.\n2. **check** - the watchdog. Reports any job that crashed (non-zero exit) or is overdue (expected to have run by now but hasn't). Exits non-zero if anything is wrong, so it can drive an alert.\n3. **status** - a quick table of every tracked job: last run, health, when it's next expected.\n4. **crontab** - print a ready-to-paste crontab line that wraps a command, plus a watchdog line.\n\n## Permissions & data\n\nThis skill is not informational - it runs a local tool (`cron_sentinel.py`) that touches the system. Be transparent with the user about exactly what it does, and never run it on a command they didn't ask you to wrap. Its full reach:\n\n- **Command execution.** `wrap` runs the command placed after `--` as a direct sub"},{"path":"README.md","content":"# Cron Sentinel 🛡️\n\nA dead-man's switch for your scheduled tasks. Bulletproof scheduling that alerts you when a job **silently** fails.\n\nEveryone monitors the job that crashes. Almost nobody catches the job that just... stops — the machine was asleep at 3am, someone renamed the script, the cron daemon wasn't reloaded. The task never ran, threw no error, and the first you hear of it is when the backup you needed isn't there. Cron Sentinel catches both the loud failures and the silent ones.\n\n## What it does\n\n- **wrap** — run your command through Sentinel so each run is recorded (start, end, exit code, duration, output tail), with optional retries and a per-attempt timeout.\n- **check** — the watchdog. Flags any job that crashed *or* is overdue (should have run by now but didn't). Exits non-zero so it can drive an alert.\n- **status** — a quick table of every tracked job: last run, health, next expected.\n- **crontab** — prints a ready-to-paste wrapped crontab line plus a watchdog line.\n\n## Quick start\n\n```bash\n# What cron actually runs:\npython cron_sentinel.py wrap --name backup --expect-every 1d --retries 2 -- /path/backup.sh\n\n# The watchdog (its own short schedule):\npython cron_sentinel.py check       # exits 1 if anything failed or went silent\npython cron_sentinel.py status\n\n# Generate the crontab lines:\npython cron_sentinel.py crontab --name backup --schedule \"0 3 * * *\" --expect-every 1d -- /path/backup.sh\n```\n\nThe command always goes after `--`. `--expect-every` (`30m`, `12h`, `1d`, `1w`) is what makes silent-failure detection possible — it's how Sentinel knows a job *should* have run. State lives in `~/.cron-sentinel/state.json` (override with `--state` or `$CRON_SENTINEL_STATE`); all timestamps are UTC, so it's correct across timezones and DST.\n\n## The whole idea in two lines\n\n1. The **wrapped job** runs your real task on its normal schedule.\n2. The **watchdog** runs `check` every few minutes and pings you only when something's wrong.\n\nA `💥 failed` means it ran and errored (show the output tail). A `🔇 overdue` means it never ran — the problem is upstream, not the command. That distinction alone saves hours of debugging.\n\n## Safety and scope\n\n- Runs only the command you give it, directly, never through a shell\n- Never edits your crontab or creates scheduled tasks: `crontab` just prints lines for you to add\n- No network access and no dependencies; runs as your normal user\n- State is kept in one owner-only file (`~/.cron-sentinel/state.json`)\n- Secret-looking values in captured output are masked before saving; use `--no-output-tail` to save no output at all\n\n## Requirements\n\n- Python 3.8+ (standard library only). No API key, no external services."},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn77r9qjvh6fy4aja2km8bzgvd83khv9\",\n  \"slug\": \"cron-sentinel\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1790618992780\n}"},{"path":"CHANGELOG.md","content":"# Changelog\n\nAll notable changes to Cron Sentinel are documented here. Format follows [Keep a Changelog](https://keepachangelog.com/); this project adheres to semantic versioning.\n\n## [1.2.0] - 2026-09-28\n\nFixes from ClawHub's security audit. Existing commands and state files keep working.\n\n### Security\n- **State file is now owner-only.** The state folder is created with 0700 and `state.json` is written with 0600.\n- **Secrets are redacted before saving.** Captured output is scanned for common credential patterns (password/token/API-key assignments, bearer and basic auth headers, AWS, GitHub, Slack and `sk-` style keys, private-key blocks, credentials in URLs) and masked before it's written to the state file.\n- **New `--no-output-tail` flag** for `wrap` stores no command output at all.\n- **`crontab` output is validated and quoted.** `--name` must be a simple identifier, `--schedule` must be five cron fields or a macro like `@daily`, `--expect-every` must parse as a duration, the Python and script paths are quoted, and `%` is escaped so the printed line can't be broken or injected into.\n- `wrap` now passes `shell=False` explicitly and documents that commands are never run through a shell.\n\n### Changed\n- Replaced the frontmatter `permissions` block (not part of ClawHub's schema, so it wasn't being read) with `metadata.openclaw.requires` and `envVars` declarations.\n- SKILL.md and the description now state plainly that Sentinel never edits a crontab, creates scheduled tasks, uses the network, or requires elevated privileges, and that the agent must not create scheduled tasks without the user's explicit confirmation.\n- Corrected the description, which previously said commands run \"via the shell.\"\n- `crontab` output now opens with a note that Sentinel doesn't install anything.\n\n### Added\n- `.clawhubignore` so development-only files (`evals/`) stay in the repository but aren't published to ClawHub.\n\n## [1.1.0] - 2026-05-24\n\nSecurity-review fixes. No behavior change to the tool itself.\n\n### Added\n- Explicit `permissions` block in the SKILL.md frontmatter (shell execution, state-file read/write under `~/.cron-sentinel/`, the `CRON_SENTINEL_STATE` env var, and no network) so the skill's real capabilities are visible to the permission model and to reviewers instead of being implicit in the code.\n- \"Permissions & data\" section documenting exactly what the skill touches, plus a secrets warning that `wrap` stores the last ~2000 chars of a job's output in `state.json` in plaintext (with mitigations).\n- \"When NOT to use\" guidance to keep the skill from activating on plain scheduling requests, cron-syntax questions, and one-off reminders.\n\n### Changed\n- Tightened the description and \"When to use this\" triggers to scope activation to reliability / silent-failure-detection intent rather than every mention of scheduling.\n\n## [1.0.0] - 2026-05-23\n\nInitial release.\n\n### Added\n- `wrap` command: runs a scheduled command and records each run (start, end, exit code, durati"},{"path":"skill-card.md","content":"## Description:\n\nMonitors recurring jobs for failures and missed runs, with optional retries and guidance for setting up alerts.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[chris](https://clawhub.ai/user/chris)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and operators use this skill to detect failed or overdue scheduled jobs and set up a watchdog that can trigger their chosen alerting channel.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated crontab lines may schedule commands or alerts differently than intended.\n\nMitigation: Review generated lines before adding them to the scheduler.\n\nRisk: Captured job output may contain credentials or other sensitive data despite best-effort redaction.\n\nMitigation: Use --no-output-tail for jobs that may print sensitive information.\n\n## Reference(s):\n\n- [Cron Sentinel on ClawHub](https://clawhub.ai/chris/skills/cron-sentinel)\n\n## Skill Output:\n\n**Output Type(s):** [Shell commands, Configuration instructions, Guidance]\n\n**Output Format:** [Markdown with shell snippets and human-readable job status]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Generated crontab entries require user review and installation; watchdog checks can exit non-zero to signal unhealthy jobs.]\n\n## Skill Version(s):\n\n1.2.0 (source: frontmatter, changelog, ClawHub release)\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."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2223,"uniquenessScore":36,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T21:51:18.229Z","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-11T21:51:18.229Z","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-14T14:54:28.640Z","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"}]}}}