Extend existing cron not duplicate

Skill Pdbjork/hermosskills-site/skills/extend-existing-cron-not-duplicate

When the user asks for a recurring review cadence (weekly portfolio review, daily digest, monthly check-in) on a project that already has a cron job, ALWAYS inspect existing cron jobs first via `cronjob action='list'` and extend the matching job's prompt with `cronjob action='update'`. Never schedule a parallel cron that does overlapping work — duplicates the same data collection, double-delivers to chat, and complicates delivery semantics.From its SKILL.md

Install

npx -y skills add Pdbjork/hermosskills-site --skill extend-existing-cron-not-duplicate

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.4 KB, 478 tokens by cl100k_base, as published. Nobody here has run it

Extend the existing cron — don't duplicate

When to apply

The user says any of:

"set a weekly review of the list"
"schedule a daily/weekly/monthly X check"
"remind me every Friday to ..."
"ping me periodically about ..."
"set up a recurring ..."

…and there is any existing cron in /root/HermesVault/, /root/scripts/, or referenced in session_search that touches the same subject matter.

Steps

cronjob action='list' — see what already exists.
Read the matching job's prompt and (if present) script path.
cronjob action='update job_id=... prompt='...' — extend the prompt rather than create a parallel job. Keep the existing data-collection step verbatim; append new analysis steps. Add skill attachments (skills=[...]) if useful.
Deliver explicit confirmation that this was an extension, not a new job, so the user knows firing cadence is unchanged.

Pitfalls

Don't change schedule or repeat unless the user explicitly asked. If the cadence was already right, leave it.
Delivery: if the original job delivers to 'local' or 'origin', mirror that — don't override.
no_agent: true jobs (script-only) cannot have their prompt meaningfully extended; instead either edit the script or schedule a new agent-driven cron with a clearly different deliverable (e.g. cron A scrapes → cron B interprets).
Trip wires in the prompt — when extending a generic data report into a tier-review type job, embed explicit "what would change my mind" rules from the user-facing notes, so the LLM has structured criteria instead of vibes.
enabled_toolsets — only set if you're narrowing the existing job's access; inheritance is usually fine.

Verification

cronjob action='list' again — confirm the count went down (or stayed) and the next_run_at is what you'd expect.
Mentally simulate: would both jobs have fired at the same minute? If yes, you scheduled a duplicate. Fix it.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.