BC cron-sentinel
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/.
As a process C 59/100 · Has gaps — weak spots: result and completion, inputs and preconditions, running it twice
How to improve
- Shorten the description to 1024 characters.
- A spec.yaml with trigger phrases and assertions — a behaviour contract for CI; `skilltest init` writes a template.
Guard findings · 1
✓ No critical or high findings
Medium and low: 1
-
low Dangerous commands
cmd-cron-mentioncron_sentinel.py:279Mentions editing / listing crontab (string literal in code, not executed; documentation of a security skill)print("# Paste into your crontab (crontab -e). Then have Sentinel watch them:")code literalsecurity skill
Files scanned: 5. Evidence is masked. Grey chips explain why severity was lowered.
Against the Agent Skills spec
- error
description-longdescription is 1070 chars, limit 1024
Process rating: all ten parameters 59/100
- 0Result and completion. Does not say what the result is
- 0Inputs and preconditions. Does not say what the process needs to start
- 0Progress reporting. Says nothing while it works
- 30Running it twice. 1 mutating operations with no state check
- 60Tools and files. Uses tools (bash, web, python) that frontmatter does not declare
- 70When it triggers. States when to use, but not when not to
- 100Steps. 17 steps
- 100Failures and branches. 5 branches, has a failure section
- 100Consistency. Name and required fields are in place
- 100Execution cost. Instruction body is 1668 tokens
- medium 2 test cases, all positive: not one "should refuse" or "should ask first"
Everything here is measured from the skill text rather than judged by a model, so the numbers are checkable. A parameter weighs more when it is a more common reason for the process to stall.
Quality signals
- +5Description has no quoted example phrases that should trigger the skill
- +4Description does not say when NOT to use the skill (false activations)
- +3Description length 1070: 120–800 characters recommended
- +3Output format is not stated: the model decides each time
- +1No license
- +2Single-language instructions
- +4Structure: 7 headings
- +3Step-by-step instructions: 17 items
- +4Has examples (1 code blocks)
Quality base 70; lint remarks subtract, signals add up to 100. Result: 56.