メニュー
Patterns for creating, testing, debugging, and maintaining cron-driven automation in workspace-hub, including log strategy, failure analysis, and safe git-aware job design.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/vamseeachanta/workspace-hub --skill cron-job-managementコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Write outbound email and external messages in Vamsee Achanta's voice — a subtle offer to help, never bold or rash claims. Load before drafting ANY email, LinkedIn/Collide reply, proposal note, or outreach sent under his name.
Save/publish analysis or computation results from ANY ecosystem repo to Hugging Face as a queryable, viewer-renderable dataset. Use when the user wants to "save results to hugging face", "publish dataset to HF", "hugging face data saving", "save analysis results", "hf dataset", "make results queryable", or "render via datasets-server API". Reshapes nested results into flat parquet tables, writes a dataset card with a viewer `configs:` block and provenance, applies license/public-vs-private routing, enforces a domain data-quality gate (faithful-to-source != correct), publishes to `aceengineer/<repo>-<projection>`, and verifies via the datasets-server API.
Clone, create, fork, configure, and manage GitHub repositories. Manage remotes, secrets, releases, and workflows. Works with gh CLI or falls back to git + GitHub REST API via curl.
| name | cron-job-management |
| description | Patterns for creating, testing, debugging, and maintaining cron-driven automation in workspace-hub, including log strategy, failure analysis, and safe git-aware job design. |
| version | 1.0.0 |
| category | operations |
| type | skill |
| trigger | manual |
| auto_execute | false |
| capabilities | ["cron_design","cron_debugging","scheduled_automation","log_analysis","git_safe_automation"] |
| tools | ["Read","Write","Bash","Grep"] |
| related_skills | ["github-actions"] |
| requires | [] |
| tags | ["cron","automation","scheduled-tasks","operations","debugging"] |
Use this skill when working on:
config/scheduled-tasks/schedule-tasks.yamlscripts/cron/*Canonical schedule source:
config/scheduled-tasks/schedule-tasks.yamlTypical workflow:
scripts/cron/ when logic is non-trivialBefore creating a new scheduled workflow or a GitHub issue to add one, inspect the existing control-plane surfaces first:
config/scheduled-tasks/schedule-tasks.yamlscripts/cron/<task>.shdocs/ops/scheduled-tasks.mdtests/cron/Common real-world pattern:
Planning rule learned from weekly skills-maintenance work:
schedule-tasks.yaml, treat that as the upgrade targetInclude:
Good:
bash scripts/cron/my-job.sh
Avoid long inline command chains in YAML when the job:
If a cron task pulls/commits/pushes, use:
scripts/cron/lib/git-safe.shPrefer wrappers that call:
git_safe_initgit_safe_pullgit_safe_commitgit_safe_pushgit_safe_syncBefore cron installation:
bash scripts/cron/my-job.sh
bash -n scripts/cron/my-job.sh
For schedule rendering:
bash scripts/cron/setup-cron.sh --dry-run
For live installation on the current machine:
bash scripts/cron/setup-cron.sh --replace
crontab -l
Check in this order:
Useful checks:
crontab -l
rg -n "my-job" config/scheduled-tasks/schedule-tasks.yaml scripts/cron/
tail -n 100 logs/path/to/job.log
Every cron wrapper script MUST start with PATH injection. Cron's environment is minimal and does not include $HOME/.local/bin where uv, node, etc. live. A script that runs fine in your shell but breaks silently in cron is almost always a PATH issue.
#!/usr/bin/env bash
set -uo pipefail
# ── Ensure PATH for cron environment ────────────────────────────────────────
export PATH="$HOME/.local/bin:$HOME/.npm-global/bin:$PATH"
The cron-health-check script had uv: command not found for 5 consecutive days because of this exact issue. The schedule-tasks.yaml command lines include PATH overrides, but wrapper scripts called from those commands do not inherit them in subshells.
The cron-health-check reports STALE for weekly jobs (Sunday/Monday) when viewed on Tuesday. Day-of-week schedules (0 3 * * 0, 0 4 * * 1) naturally exceed the 25h default staleness threshold. When doing a health review:
Error scans must be bounded to recent log output, not the full append-only log. Use tail -n 100 (or another explicit recent window) before matching ERROR/Traceback, otherwise an old transient failure in logs/daily/cron.log can keep a healthy job red indefinitely.
Do not let cron-health self-poison: its own log legitimately contains [ERROR] rows when reporting other broken jobs. Either skip error-pattern scanning for the cron-health task itself or restrict self-checking to the current run's process exit/result artifact.
Make ERROR: matching case-sensitive and anchored, e.g. (^|[[:space:]])ERROR:, so warning prose such as 403 Client Error: Forbidden is not counted as an operational failure.
log: null in YAML means the health checker cannot monitor the task -- this produces a MISS on glob matching. Every task should have a log: field with a valid glob pattern.$WORKSPACE_HUB, so logs/quality/thing-*.log resolves to /mnt/local-analysis/workspace-hub/logs/quality/thing-*.log.Any script that creates issues with gh issue create --label "X" must pre-create the label:
gh label create "X" --description "..." --color "..." 2>/dev/null || true
Without this, gh issue create fails with could not add label: 'X' not found and the issue is silently not created.
The comprehensive-learning pipeline can be blocked by legal-sanity-scan when session JSONL logs contain client names that match deny-list patterns. Session logs are append-only operational data, not source code. Watch for this pattern:
RESULT: FAIL — N block violation(s) found in learning logsWARNING: learning artifact commit failed — changes remain localEither exclude the log directory from the legal scan, or use --diff-only for the learning pipeline's commit path.
To perform a comprehensive cron health review:
cron-health-check.sh manually -- this is your first passtail -10 logs/research/2026-04-*.log for research, etc.crontab -l vs config/scheduled-tasks/schedule-tasks.yamlbash scripts/cron/setup-cron.sh --dry-run -- this is the most reliable rendered view for the current host/today daily report at logs/daily/YYYY-MM-DD.md is freshFor full closeout of a "fix all cron jobs / daily report is current" request, collect the evidence bundle in references/cron-daily-report-closeout.md before reporting success.
When auditing cron drift in workspace-hub, treat these as canonical:
config/scheduled-tasks/schedule-tasks.yamlscripts/cron/setup-cron.shscripts/cron/validate-schedule.pyconfig/workstations/registry.yamlTreat these as legacy or drift-prone unless they are explicitly refreshed to match YAML:
scripts/coordination/context/setup_cron.shscripts/coordination/productivity/crontab.exampledocs/ops/scheduled-tasks.mddocs/WORKSPACE_HUB_CAPABILITIES_SUMMARY.mdscripts/cron/crontab-template.shIf live crontab and one of the legacy sources disagree, prefer YAML + setup-cron.sh --dry-run, not the legacy file.
Important operational lesson:
cron-health-check can report a low or even zero issue count while the installed crontab is still drifted from YAML.setup-cron.sh --replacecrontab -l and bash scripts/cron/setup-cron.sh --dry-runcron-health at 05:45 or daily-today at 06:00) producing a fresh log after reconciliation.crontab -l with setup-cron.sh --dry-runbash scripts/cron/setup-cron.sh --replaceWhen a weekly/daily task used to shell out to Claude/Codex/Gemini and you replace it with a deterministic script, update the scheduler metadata and test contract at the same time — not just the script body.
Required checks:
requires: in config/scheduled-tasks/schedule-tasks.yaml so it matches the new runtime (python3/uv/bash instead of claude, etc.)is_claude_task: (or equivalent task metadata) so the scheduler no longer advertises the job as provider-driven when it is now deterministicdescription: to remove mutating/agent-only behavior that is no longer trueid when the cadence/path should stay stable; replace the implementation behind it instead of creating a second overlapping task--dry-run / print-mode output reflects the new deterministic command lineCommon failure mode:
requires: [claude, ...] and is_claude_task: true, while tests/log paths still assume the old wrapper behavior. This creates governance drift and confusing operator docs even if the new script itself works.Recommended safe sequence:
cd /mnt/local-analysis/workspace-hub
export WORKSPACE_HUB=/mnt/local-analysis/workspace-hub
bash scripts/cron/setup-cron.sh --dry-run
mkdir -p "$WORKSPACE_HUB/.ops/cron-backups"
crontab -l > "$WORKSPACE_HUB/.ops/cron-backups/crontab.$(hostname -s).$(date +%Y%m%d-%H%M%S).bak"
bash scripts/cron/setup-cron.sh --replace
crontab -l
bash scripts/monitoring/cron-health-check.sh --workspace "$WORKSPACE_HUB"
Why --replace matters:
notification-purge cron line because append-mode dedupe did not recognize a non-script inline find ... -delete commandgit-safe wrapperslog: glob in YAMLconfig/scheduled-tasks/schedule-tasks.yamlscripts/cron/setup-cron.shscripts/cron/lib/git-safe.shscripts/cron/comprehensive-learning-nightly.shscripts/monitoring/cron-health-check.shThe % character in crontab date format strings must be escaped as \%. In schedule-tasks.yaml, the YAML >- block scalar strips trailing newlines but also adds an extra layer of backslash handling through the setup-cron.sh Python rendering pipeline. This creates a quadruple-escape trap:
$(date +\\\\%Y\\\\%m\\\\%d) (4 backslashes in YAML → \%Y\%m\%d in crontab → %Y%m%d for date)$(date +\\\\\\\\%Y\\\\\\\\%m\\\\\\\\%d) (too many escapes)$(date +\\\\%Y\\\\%m\\\\%d) with only 2 (becomes %Y%m%d with single backslash which also fails)If a cron log shows date format errors or the log file has literal backslash names, check the YAML escaping level. Use sed -n '/id: my-job/,/^[^ ]/p' config/scheduled-tasks/schedule-tasks.yaml to inspect.
Every task in schedule-tasks.yaml MUST have either a schedule: field or a schedule_by_machine: field. The cron-health entry (#1512) was declared in YAML without either, so setup-cron.sh silently skipped it -- the Python parser got an empty schedule string and continued. The cron-health-check.py could not find the crontab entry because it was never installed.
After adding or editing a task, always verify:
bash scripts/cron/setup-cron.sh --dry-run | grep task_id
bash scripts/cron/setup-cron.sh --replace
crontab -l | grep task_id
The requires: list in schedule-tasks.yaml is validated against the flattened capabilities in config/workstations/registry.yaml. The validator (scripts/cron/validate-schedule.py) merges all values from agent_clis, languages, and tools lists for the host machine.
Rule: Any tool name in requires: must appear in the machine's capabilities. Adding requires: [gh] or requires: [npm] will FAIL validation unless gh / npm are also added to the tools: list in registry.yaml for the target machine.
# WRONG — validation fails with "unknown capability 'gh'":
- id: my-new-job
requires: [python3, uv, gh]
# CORRECT — first add gh to registry.yaml:
# dev-primary capabilities:
# tools: [uv, git, gh] # ← add here
# Then in schedule-tasks.yaml:
- id: my-new-job
requires: [python3, uv, gh]
After adding new capabilities to registry.yaml, verify:
uv run --no-project python scripts/cron/validate-schedule.py
Hermes has its OWN cron scheduler inside the Gateway process (separate from system crontab). Jobs managed via the hermes cron CLI (gmail-daily-digest, memory-bridge-daily, etc.) require the Gateway to be running.
Starting the Gateway:
# Use the systemd service directly — the hermes CLI wrapper
# requires sudo which may not resolve hermes in root PATH
systemctl --hermes-gateway
# Equivalent: sudo systemctl start hermes-gateway
Diagnosing a dead Hermes cron job:
sudo systemctl status hermes-gateway # if not active, no Hermes cron fires
hermes cron list # check job next_run_at dates — stale dates mean gateway has been dead
Warning "No messaging platforms enabled" is non-fatal — the cron ticker still runs. 'local' delivery works fine. Only 'origin'/platform deliveries may be affected.
Scripts with # /// script\n# dependencies = ["pyyaml"]\n# /// blocks are PEP 723 inline-metadata scripts. uv treats them as self-contained scripts and auto-installs dependencies.
CRITICAL: Do NOT use python between uv run and the script path:
# WRONG — bypasses PEP 723 metadata, dependencies NOT installed:
uv run --no-project python scripts/ai/my-script.py
# RIGHT — uv recognizes the script's inline metadata block:
uv run --no-project scripts/ai/my-script.py
This bug caused agent-radar to fail for days with "Install PyYAML: uv add pyyaml" even though the script's metadata block declares pyyaml as a dependency.
When investigating alerts like "13 CVE references", "42 ERROR/FAIL", etc., always verify the raw count against unique root causes. Common traps:
grep -ci "CVE" counts "0 blocking CVEs" in daily summary lines — false alarmCron's minimal environment may not have $HOME set when PATH is expanded at parse time. Use hardcoded absolute paths rather than $HOME expansions in shell scripts:
# UNRELIABLE in cron:
export PATH="$HOME/.local/bin:$PATH"
# RELIABLE:
export PATH="/home/vamsee/.local/bin:$PATH"
# BEST: use absolute path for specific commands:
/home/vamsee/.local/bin/uv run --no-project ...
The daily productivity report is only healthy if you verify both the daily artifact and whether a weekly variant is actually scheduled.
Current canonical daily task pattern:
scripts/productivity/daily_today.shlogs/daily/YYYY-MM-DD.mdlogs/daily/cron.logImportant findings:
scripts/productivity/daily_today.sh already supports --week and writes logs/weekly/YYYY-Www.mdweekly-today task exists in config/scheduled-tasks/schedule-tasks.yamlscripts/coordination/productivity/crontab.example mentions it; that file may be stale or intentionally deprecateddaily-todayPreferred restoration pattern for weekly today:
- id: weekly-today
schedule: "5 6 * * 1"
machines: [dev-primary, ace-linux-1]
requires: [python3, bash, git]
command: >-
PATH=$HOME/.local/bin:$PATH;
cd $WORKSPACE_HUB &&
bash scripts/productivity/daily_today.sh --week
>> $WORKSPACE_HUB/logs/weekly/cron.log 2>&1
log: logs/weekly/cron.log
No script changes are needed for this pattern; only the YAML task and cron reinstall.
Documentation cleanup rule:
scripts/coordination/productivity/crontab.example still contains installable cron lines, consider converting it to deprecation-only guidance that points operators back to config/scheduled-tasks/schedule-tasks.yaml and scripts/cron/setup-cron.sh.If a cron task is important enough to debug twice, it is important enough to have: