How do I install the Extend Existing Cron Not Duplicate skill?

Run npx skillmds@latest add pdbjork/extend-existing-cron-not-duplicate in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Extend Existing Cron Not Duplicate safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Extend Existing Cron Not Duplicate?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Extend Existing Cron Not Duplicate free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Extend Existing Cron Not Duplicate?

Pdbjork (@pdbjork) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Extend Existing Cron Not Duplicate by pdbjork

Name: Extend Existing Cron Not Duplicate
Author: Pdbjork

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.

Pdbjork b6c35e8 2.4 KB Updated Sep 17, 2026

File contents

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.

---name: extend-existing-cron-not-duplicatedescription: 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.---# Extend the existing cron — don't duplicate## When to applyThe 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.## Steps1. **`cronjob action='list'`** — see what already exists.2. **Read the matching job's prompt and (if present) script path.**3. **`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.4. **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.

Frequently asked questions