[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6F536JYPYZEBPHFFBBFTDFT":3,"skill-same:01M6F536JYPYZEBPHFFBBFTDFT":85},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":41,"linkOnly":42,"markdownContent":43,"markdownBody":44,"frontMatter":45,"refName":25,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M6F536JYPYZEBPHFFBBFTDFT","cron-doctor",null,"Diagnose and validate cron expressions before they ship. Catches the five silent death-traps: impossible dates that never fire, OR-semantics that fire too often, midnight spikes, uneven step drift, and leap-year February 29.","boisenoise\u002Fskills-collections","boisenoise","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F193180?v=4","01M6CDBDQK6BDN55ZMA6B6PKBM","01M6CDBDVSJ3JPTBYN26FZ7TZK",12,"MIT","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-cron-doctor\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40],"cron doctor","doctor","cron","ship","2026","dates","drift","main","community","scheduling","opencode","never","devops","cursor","safe","https","license","debugging","diagnose","codex","kubernetes","github","gemini","2026-11-10 10:12:30",false,"---\nname: cron-doctor\ndescription: \"Diagnose and validate cron expressions before they ship. Catches the five silent death-traps: impossible dates that never fire, OR-semantics that fire too often, midnight spikes, uneven step drift, and leap-year February 29.\"\ncategory: devops\nrisk: safe\nsource: community\nsource_repo: takeaseatventure\u002Fdevops-skills\nsource_type: community\ndate_added: \"2026-06-26\"\nauthor: takeaseat\ntags: [cron, crontab, scheduling, devops, debugging, kubernetes, validation]\ntools: [claude, cursor, codex, gemini, opencode]\nlicense: \"MIT\"\nlicense_source: \"https:\u002F\u002Fgithub.com\u002Ftakeaseatventure\u002Fdevops-skills\u002Fblob\u002Fmain\u002FLICENSE\"\n---\n\n# cron-doctor\n\n## Overview\n\nCron is deceptively error-prone. The failure mode is **silent** — a syntactically\nvalid expression that simply never fires, or fires far more often than intended.\n`0 0 30 2 *` parses cleanly and then sits dead forever (February has no 30th).\n`0 0 1,15 * 1` looks like \"1st and 15th if Monday\" but actually means \"1st, 15th,\n**OR** every Monday\" — ~6 fires\u002Fmonth instead of ~2.\n\nThis skill teaches an agent to catch those before they reach production. It comes\nwith a zero-dependency validation engine (`scripts\u002Fcron-engine.js`, no install\nneeded) that parses, describes, deep-validates, and computes next fire times.\n\n## When to Use This Skill\n\n- Use when a user writes, edits, reviews, or deploys a cron expression — in a\n  crontab, a Kubernetes `CronJob`, a GitHub Actions `schedule`, an Airflow DAG,\n  a Celery beat schedule, a systemd timer, or any scheduled task.\n- Use when debugging a job that \"didn't fire\" or \"fired at the wrong time.\"\n- Use when a user asks \"what does this cron expression mean?\" or \"when will this\n  run next?\" or \"how often does this run per year?\"\n- Use when reviewing a CI\u002FCD pipeline or infrastructure config that contains a\n  `schedule` field.\n- Use when a user pastes a 5-field cron expression and asks for a sanity check.\n\n## Scheduler and calculation limits\n\nIdentify the scheduler\u002Fdialect and timezone first. systemd OnCalendar is not a five-field cron expression; Quartz and library day semantics differ. This engine uses the Node process local timezone, not CRON_TZ\u002Fspec.timeZone, and scans at most 600,000 minutes (~416 days): fewer than requested results are partial, not proof a schedule never fires. It does not model platform delays, DST policy, missed-job recovery or overlap control. Confirm next runs in the actual scheduler. No scripts were runtime-tested during this content review.\n\n## How It Works\n\n### Step 1: Parse the expression\n\nSplit on whitespace into 5 fields: minute, hour, day-of-month, month, day-of-week.\nConfirm valid ranges:\n\n| Field | Position | Range | Notes |\n|-------|----------|-------|-------|\n| minute | 1 | 0–59 | |\n| hour | 2 | 0–23 | |\n| day-of-month | 3 | 1–31 | |\n| month | 4 | 1–12 | names (JAN–DEC) accepted |\n| day-of-week | 5 | 0–7 | 0 and 7 both = Sunday; names (SUN–SAT) accepted |\n\n### Step 2: Describe it in plain English\n\nState what the user *thinks* it does vs. what it *actually* does. Be explicit\nabout OR-vs-AND semantics for day-of-month + day-of-week (see death-trap #2).\n\n### Step 3: Run the trap checklist\n\nCheck the five death-traps below and flag any that apply.\n\n### Step 4: Calculate next runs and annual fire count\n\nCompute the next 5 fire times as concrete dates so the user can verify the\nschedule behaves as expected. Estimate annual fire count — a schedule that fires\n365×\u002Fyear vs. 12×\u002Fyear is a ~30× cost and load difference.\n\n## The Five Cron Death-Traps\n\nThese are the bugs that pass `crontab -l` validation but break in production.\n\n### 1. Impossible dates — the \"never fires\" bug\n\n```\n0 0 30 2 *\n```\n\n**Valid syntax. Never fires.** February has no 30th. This schedule is a dead job\nthat silently sits forever. The same applies to day 31 in any 30-day month:\n`0 0 31 4 *`, `0 0 31 6 *`, `0 0 31 9 *`, `0 0 31 11 *`.\n\n**Fix:** use `0 0 28-31 * *` and check for end-of-month in the script, or use `L`\n(last day) syntax if your scheduler supports it.\n\n### 2. OR-semantics — the \"fires too often\" bug\n\n```\n0 0 1,15 * 1\n```\n\n**Does NOT mean** \"midnight on the 1st and 15th if it's Monday.\"\n**Does mean** \"midnight on the 1st, the 15th, **OR** every Monday.\" That's ~6\nfires\u002Fmonth instead of ~2.\n\nThis is the single most misunderstood cron rule. When **both** day-of-month AND\nday-of-week are restricted (neither is `*`), cron uses OR logic, not AND.\n\n**Fix:** if you need \"1st and 15th only if Monday,\" run daily and check in the\nscript:\n\n```bash\n0 0 * * 1 [ \"$(date +\\%d)\" = \"01\" -o \"$(date +\\%d)\" = \"15\" ] && your-command\n```\n\n### 3. Midnight spike — the \"everything at once\" bug\n\n```\n0 0 * * *\n```\n\nEvery job scheduled at `0 0` competes for resources at exactly 00:00. Database\nbackups, log rotations, cert renewals, report generation — all fire simultaneously.\nThis causes load spikes, connection-pool exhaustion, and cascading timeouts.\n\n**Fix:** stagger jobs across the hour. Use `17 2 * * *` or `43 3 * * *` instead of\n`0 0`. Jitter is your friend.\n\n### 4. Uneven steps — the \"drift\" bug\n\n```\n*\u002F7 * * * *\n```\n\n**Does NOT mean** \"every 7 minutes evenly.\" It means \"every 7 minutes starting at\n0, then resets at 60.\" So: 0, 7, 14, 21, 28, 35, 42, 49, 56 — then 0 again\n(a 4-minute gap). The intervals drift: 7,7,7,7,7,7,7,7,**4**.\n\n**Fix:** 60 is not divisible by 7. Use step values that divide 60 evenly: `*\u002F5`,\n`*\u002F10`, `*\u002F15`, `*\u002F20`, `*\u002F30`. If you truly need every-7-minutes, use a supervised monotonic\u002Finterval scheduler; a sleep loop adds task duration and needs restart\u002Foverlap handling.\n\n### 5. Leap-year February 29 — the \"annual surprise\"\n\n```\n0 0 29 2 *\n```\n\nFires only on leap years — February 29, 2024 \u002F 2028 \u002F 2032… If someone writes this\nexpecting \"end of February,\" they'll be confused for 3 out of every 4 years.\n\n**Fix:** for last day of February, run on 28 and 29 and use an explicit next-day-is-March guard; running only on the 28th cannot select the 29th.\n\n## Using the validation script\n\nThis skill ships a zero-dependency engine at `scripts\u002Fcron-engine.js` (Node.js, no\n`npm install` needed). You can use it programmatically or from the CLI:\n\n```javascript\n\u002F\u002F Programmatic — Node.js, zero dependencies\nconst { describe, validate, nextRuns, formatNextRuns } = require('.\u002Fscripts\u002Fcron-engine.js');\n\n\u002F\u002F Parse + describe -> returns { text, error, parsed }\nconst d = describe('0 0 30 2 *');\nconsole.log(d.text);   \u002F\u002F \"At 00:00, on day-of-month 30 in in FEB\"\n\n\u002F\u002F Deep validation -> catches the traps\nconst result = validate('0 0 30 2 *');\nconsole.log(result.valid);              \u002F\u002F true (syntax is valid)\nconsole.log(result.observations);       \u002F\u002F includes the \"never fires\" insight\nconsole.log(result.suggestions);        \u002F\u002F e.g. \"Midnight is a common spike...\"\n\n\u002F\u002F Next 5 fire times -> returns Date[]\nconst runs = nextRuns('0 9 * * 1-5', new Date(), 5);\nconsole.log(formatNextRuns(runs, new Date())); \u002F\u002F [{ date, relative, formatted }, ...]\n```\n\n```bash\n# CLI (via the bundled wrapper)\nnode scripts\u002Fcli.js describe \"*\u002F5 * * * *\"\nnode scripts\u002Fcli.js validate \"0 0 30 2 *\"\nnode scripts\u002Fcli.js next \"0 9 * * 1-5\" 5\n```\n\n## Common cron presets\n\n| Expression | Description | Use case |\n|-----------|-------------|----------|\n| `*\u002F5 * * * *` | Every 5 minutes | Health checks, polling |\n| `0 * * * *` | Every hour | Hourly aggregation |\n| `0 *\u002F2 * * *` | Every 2 hours | Semi-frequent sync |\n| `0 9 * * 1-5` | 9am Mon–Fri | Business-hours task |\n| `0 2 * * *` | 2am daily | Off-peak batch (avoid midnight) |\n| `0 0 * * 0` | Midnight Sunday | Weekly maintenance |\n| `0 0 1 * *` | Midnight 1st of month | Monthly report |\n| `0 0 1 1 *` | Midnight Jan 1st | Annual task |\n\n## Best Practices\n\n- ✅ Always provide the plain-English description AND run the trap checklist.\n- ✅ Stagger midnight jobs to avoid the spike.\n- ✅ Prefer step values that divide 60 evenly (`*\u002F5`, `*\u002F15`, `*\u002F30`).\n- ✅ Add a comment above every crontab line explaining intent.\n- ✅ Set an explicit timezone (`CRON_TZ`) on schedulers that support it.\n- ❌ Don't trust `crontab -l` validation — it lists the installed crontab; it is not a syntax or semantic validator.\n- ❌ Don't restrict both day-of-month and day-of-week without confirming OR-logic.\n- ❌ Don't schedule everything at `0 0`.\n\n## Common Pitfalls\n\n- **Problem:** \"My cron job isn't running.\"\n  **Solution:** Check for an impossible date (trap #1) and confirm the daemon is\n  running (`service cron status` \u002F `systemctl status crond`). Verify the file\n  ends with a newline and has correct ownership.\n\n- **Problem:** \"My job runs far more often than expected.\"\n  **Solution:** You hit OR-semantics (trap #2). If both day-of-month and\n  day-of-week are set, cron ORs them. Move one to `*` or guard in-script.\n\n- **Problem:** \"Intervals are uneven — sometimes 7 min, sometimes 4.\"\n  **Solution:** Step value doesn't divide 60 evenly (trap #4). Use a divisor of 60.\n\n- **Problem:** \"My job works locally but not in the cluster.\"\n  **Solution:** Timezone mismatch. Kubernetes uses the controller local timezone unless `spec.timeZone` is set; use `spec.timeZone: Etc\u002FUTC` deliberately. Do not embed TZ\u002FCRON_TZ in its schedule string. Check the exact GitHub Actions schedule support and execution delays.\n\n## Limitations\n\n- This skill targets standard 5-field cron as implemented by Vixie-style cron and Kubernetes `CronJob`, GitHub Actions `schedule`, and most libraries. It\n  does **not** validate Quartz 6\u002F7-field expressions with seconds\u002Fyears, nor\n  non-standard `@reboot` \u002F `L` \u002F `#` extensions without a note.\n- Estimated annual fire counts assume a non-leap reference year; February 29\n  schedules (trap #5) are flagged explicitly.\n- This skill does not replace environment-specific validation, testing, or expert\n  review. Stop and ask for clarification if required inputs, permissions, or\n  safety boundaries are missing.\n\n## Related Skills\n\n- `docker-expert` — when the cron job runs inside a container and the issue is the\n  container\u002Fentrypoint rather than the schedule.\n- `kubernetes-deployment` — when validating a `CronJob` manifest's `spec.schedule`\n  field alongside the broader resource config.\n\n## Security & Safety Notes\n\nThis skill is read-only and `risk: safe`. The validation script performs no file\nwrites, network calls, or mutations — it only parses and computes. It accepts data only, but inputs\u002Fcounts must be bounded and execution should use reviewed local files. Parsing cannot guarantee a job will execute.\n","# cron-doctor\n\n## Overview\n\nCron is deceptively error-prone. The failure mode is **silent** — a syntactically\nvalid expression that simply never fires, or fires far more often than intended.\n`0 0 30 2 *` parses cleanly and then sits dead forever (February has no 30th).\n`0 0 1,15 * 1` looks like \"1st and 15th if Monday\" but actually means \"1st, 15th,\n**OR** every Monday\" — ~6 fires\u002Fmonth instead of ~2.\n\nThis skill teaches an agent to catch those before they reach production. It comes\nwith a zero-dependency validation engine (`scripts\u002Fcron-engine.js`, no install\nneeded) that parses, describes, deep-validates, and computes next fire times.\n\n## When to Use This Skill\n\n- Use when a user writes, edits, reviews, or deploys a cron expression — in a\n  crontab, a Kubernetes `CronJob`, a GitHub Actions `schedule`, an Airflow DAG,\n  a Celery beat schedule, a systemd timer, or any scheduled task.\n- Use when debugging a job that \"didn't fire\" or \"fired at the wrong time.\"\n- Use when a user asks \"what does this cron expression mean?\" or \"when will this\n  run next?\" or \"how often does this run per year?\"\n- Use when reviewing a CI\u002FCD pipeline or infrastructure config that contains a\n  `schedule` field.\n- Use when a user pastes a 5-field cron expression and asks for a sanity check.\n\n## Scheduler and calculation limits\n\nIdentify the scheduler\u002Fdialect and timezone first. systemd OnCalendar is not a five-field cron expression; Quartz and library day semantics differ. This engine uses the Node process local timezone, not CRON_TZ\u002Fspec.timeZone, and scans at most 600,000 minutes (~416 days): fewer than requested results are partial, not proof a schedule never fires. It does not model platform delays, DST policy, missed-job recovery or overlap control. Confirm next runs in the actual scheduler. No scripts were runtime-tested during this content review.\n\n## How It Works\n\n### Step 1: Parse the expression\n\nSplit on whitespace into 5 fields: minute, hour, day-of-month, month, day-of-week.\nConfirm valid ranges:\n\n| Field | Position | Range | Notes |\n|-------|----------|-------|-------|\n| minute | 1 | 0–59 | |\n| hour | 2 | 0–23 | |\n| day-of-month | 3 | 1–31 | |\n| month | 4 | 1–12 | names (JAN–DEC) accepted |\n| day-of-week | 5 | 0–7 | 0 and 7 both = Sunday; names (SUN–SAT) accepted |\n\n### Step 2: Describe it in plain English\n\nState what the user *thinks* it does vs. what it *actually* does. Be explicit\nabout OR-vs-AND semantics for day-of-month + day-of-week (see death-trap #2).\n\n### Step 3: Run the trap checklist\n\nCheck the five death-traps below and flag any that apply.\n\n### Step 4: Calculate next runs and annual fire count\n\nCompute the next 5 fire times as concrete dates so the user can verify the\nschedule behaves as expected. Estimate annual fire count — a schedule that fires\n365×\u002Fyear vs. 12×\u002Fyear is a ~30× cost and load difference.\n\n## The Five Cron Death-Traps\n\nThese are the bugs that pass `crontab -l` validation but break in production.\n\n### 1. Impossible dates — the \"never fires\" bug\n\n```\n0 0 30 2 *\n```\n\n**Valid syntax. Never fires.** February has no 30th. This schedule is a dead job\nthat silently sits forever. The same applies to day 31 in any 30-day month:\n`0 0 31 4 *`, `0 0 31 6 *`, `0 0 31 9 *`, `0 0 31 11 *`.\n\n**Fix:** use `0 0 28-31 * *` and check for end-of-month in the script, or use `L`\n(last day) syntax if your scheduler supports it.\n\n### 2. OR-semantics — the \"fires too often\" bug\n\n```\n0 0 1,15 * 1\n```\n\n**Does NOT mean** \"midnight on the 1st and 15th if it's Monday.\"\n**Does mean** \"midnight on the 1st, the 15th, **OR** every Monday.\" That's ~6\nfires\u002Fmonth instead of ~2.\n\nThis is the single most misunderstood cron rule. When **both** day-of-month AND\nday-of-week are restricted (neither is `*`), cron uses OR logic, not AND.\n\n**Fix:** if you need \"1st and 15th only if Monday,\" run daily and check in the\nscript:\n\n```bash\n0 0 * * 1 [ \"$(date +\\%d)\" = \"01\" -o \"$(date +\\%d)\" = \"15\" ] && your-command\n```\n\n### 3. Midnight spike — the \"everything at once\" bug\n\n```\n0 0 * * *\n```\n\nEvery job scheduled at `0 0` competes for resources at exactly 00:00. Database\nbackups, log rotations, cert renewals, report generation — all fire simultaneously.\nThis causes load spikes, connection-pool exhaustion, and cascading timeouts.\n\n**Fix:** stagger jobs across the hour. Use `17 2 * * *` or `43 3 * * *` instead of\n`0 0`. Jitter is your friend.\n\n### 4. Uneven steps — the \"drift\" bug\n\n```\n*\u002F7 * * * *\n```\n\n**Does NOT mean** \"every 7 minutes evenly.\" It means \"every 7 minutes starting at\n0, then resets at 60.\" So: 0, 7, 14, 21, 28, 35, 42, 49, 56 — then 0 again\n(a 4-minute gap). The intervals drift: 7,7,7,7,7,7,7,7,**4**.\n\n**Fix:** 60 is not divisible by 7. Use step values that divide 60 evenly: `*\u002F5`,\n`*\u002F10`, `*\u002F15`, `*\u002F20`, `*\u002F30`. If you truly need every-7-minutes, use a supervised monotonic\u002Finterval scheduler; a sleep loop adds task duration and needs restart\u002Foverlap handling.\n\n### 5. Leap-year February 29 — the \"annual surprise\"\n\n```\n0 0 29 2 *\n```\n\nFires only on leap years — February 29, 2024 \u002F 2028 \u002F 2032… If someone writes this\nexpecting \"end of February,\" they'll be confused for 3 out of every 4 years.\n\n**Fix:** for last day of February, run on 28 and 29 and use an explicit next-day-is-March guard; running only on the 28th cannot select the 29th.\n\n## Using the validation script\n\nThis skill ships a zero-dependency engine at `scripts\u002Fcron-engine.js` (Node.js, no\n`npm install` needed). You can use it programmatically or from the CLI:\n\n```javascript\n\u002F\u002F Programmatic — Node.js, zero dependencies\nconst { describe, validate, nextRuns, formatNextRuns } = require('.\u002Fscripts\u002Fcron-engine.js');\n\n\u002F\u002F Parse + describe -> returns { text, error, parsed }\nconst d = describe('0 0 30 2 *');\nconsole.log(d.text);   \u002F\u002F \"At 00:00, on day-of-month 30 in in FEB\"\n\n\u002F\u002F Deep validation -> catches the traps\nconst result = validate('0 0 30 2 *');\nconsole.log(result.valid);              \u002F\u002F true (syntax is valid)\nconsole.log(result.observations);       \u002F\u002F includes the \"never fires\" insight\nconsole.log(result.suggestions);        \u002F\u002F e.g. \"Midnight is a common spike...\"\n\n\u002F\u002F Next 5 fire times -> returns Date[]\nconst runs = nextRuns('0 9 * * 1-5', new Date(), 5);\nconsole.log(formatNextRuns(runs, new Date())); \u002F\u002F [{ date, relative, formatted }, ...]\n```\n\n```bash\n# CLI (via the bundled wrapper)\nnode scripts\u002Fcli.js describe \"*\u002F5 * * * *\"\nnode scripts\u002Fcli.js validate \"0 0 30 2 *\"\nnode scripts\u002Fcli.js next \"0 9 * * 1-5\" 5\n```\n\n## Common cron presets\n\n| Expression | Description | Use case |\n|-----------|-------------|----------|\n| `*\u002F5 * * * *` | Every 5 minutes | Health checks, polling |\n| `0 * * * *` | Every hour | Hourly aggregation |\n| `0 *\u002F2 * * *` | Every 2 hours | Semi-frequent sync |\n| `0 9 * * 1-5` | 9am Mon–Fri | Business-hours task |\n| `0 2 * * *` | 2am daily | Off-peak batch (avoid midnight) |\n| `0 0 * * 0` | Midnight Sunday | Weekly maintenance |\n| `0 0 1 * *` | Midnight 1st of month | Monthly report |\n| `0 0 1 1 *` | Midnight Jan 1st | Annual task |\n\n## Best Practices\n\n- ✅ Always provide the plain-English description AND run the trap checklist.\n- ✅ Stagger midnight jobs to avoid the spike.\n- ✅ Prefer step values that divide 60 evenly (`*\u002F5`, `*\u002F15`, `*\u002F30`).\n- ✅ Add a comment above every crontab line explaining intent.\n- ✅ Set an explicit timezone (`CRON_TZ`) on schedulers that support it.\n- ❌ Don't trust `crontab -l` validation — it lists the installed crontab; it is not a syntax or semantic validator.\n- ❌ Don't restrict both day-of-month and day-of-week without confirming OR-logic.\n- ❌ Don't schedule everything at `0 0`.\n\n## Common Pitfalls\n\n- **Problem:** \"My cron job isn't running.\"\n  **Solution:** Check for an impossible date (trap #1) and confirm the daemon is\n  running (`service cron status` \u002F `systemctl status crond`). Verify the file\n  ends with a newline and has correct ownership.\n\n- **Problem:** \"My job runs far more often than expected.\"\n  **Solution:** You hit OR-semantics (trap #2). If both day-of-month and\n  day-of-week are set, cron ORs them. Move one to `*` or guard in-script.\n\n- **Problem:** \"Intervals are uneven — sometimes 7 min, sometimes 4.\"\n  **Solution:** Step value doesn't divide 60 evenly (trap #4). Use a divisor of 60.\n\n- **Problem:** \"My job works locally but not in the cluster.\"\n  **Solution:** Timezone mismatch. Kubernetes uses the controller local timezone unless `spec.timeZone` is set; use `spec.timeZone: Etc\u002FUTC` deliberately. Do not embed TZ\u002FCRON_TZ in its schedule string. Check the exact GitHub Actions schedule support and execution delays.\n\n## Limitations\n\n- This skill targets standard 5-field cron as implemented by Vixie-style cron and Kubernetes `CronJob`, GitHub Actions `schedule`, and most libraries. It\n  does **not** validate Quartz 6\u002F7-field expressions with seconds\u002Fyears, nor\n  non-standard `@reboot` \u002F `L` \u002F `#` extensions without a note.\n- Estimated annual fire counts assume a non-leap reference year; February 29\n  schedules (trap #5) are flagged explicitly.\n- This skill does not replace environment-specific validation, testing, or expert\n  review. Stop and ask for clarification if required inputs, permissions, or\n  safety boundaries are missing.\n\n## Related Skills\n\n- `docker-expert` — when the cron job runs inside a container and the issue is the\n  container\u002Fentrypoint rather than the schedule.\n- `kubernetes-deployment` — when validating a `CronJob` manifest's `spec.schedule`\n  field alongside the broader resource config.\n\n## Security & Safety Notes\n\nThis skill is read-only and `risk: safe`. The validation script performs no file\nwrites, network calls, or mutations — it only parses and computes. It accepts data only, but inputs\u002Fcounts must be bounded and execution should use reviewed local files. Parsing cannot guarantee a job will execute.\n",{"name":5,"risk":32,"tags":46,"tools":49,"author":51,"source":26,"license":14,"category":30,"date_added":52,"description":7,"source_repo":53,"source_type":26,"license_source":54},[20,47,27,30,35,38,48],"crontab","validation",[50,31,37,40,28],"claude","takeaseat","2026-06-26","takeaseatventure\u002Fdevops-skills","https:\u002F\u002Fgithub.com\u002Ftakeaseatventure\u002Fdevops-skills\u002Fblob\u002Fmain\u002FLICENSE","7bf2279c8a65758319526a721d5c4b75683aec9c","skills\u002Fantigravity-cron-doctor",3,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections","https:\u002F\u002Fgithub.com\u002Fboisenoise","2026-11-11 14:20:43",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add boisenoise\u002Fskills-collections --skill cron-doctor",{"tool":67,"command":68},"bunx","bunx skills add boisenoise\u002Fskills-collections --skill cron-doctor",{"tool":70,"command":71},"pnpm","pnpm dlx skills add boisenoise\u002Fskills-collections --skill cron-doctor","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-cron-doctor\u002FSKILL.md",true,[75,81],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"scripts\u002Fcli.js","SCRIPT","脚本",2438,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-cron-doctor\u002Fscripts\u002Fcli.js",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"scripts\u002Fcron-engine.js",23279,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-cron-doctor\u002Fscripts\u002Fcron-engine.js",[86,115,141,166,185,208],{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":91,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":41},"01M6WNH92BHVFXHGPDZCPJ0AG0","web-access","Use Treg for public web or platform data only when existing search, browser and connected tools cannot cover the task, with explicit cost and data boundaries.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-web-access\u002FSKILL.md",[],[95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,22],"web","access","web access","official","development","browser","search","data","Tools","read","fetch","only","youtube","free tools","platform","critical","free","cover","normal","when",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":119,"sourceHtmlUrl":120,"categories":121,"keywords":127,"publishedAt":41},"01M6WNF9XAYAB2CZDDJBAKNM93","treg","Use the Treg CLI or MCP catalog to discover, price and call authorized external tools with team-scoped credentials and a user-approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-treg\u002FSKILL.md",[122],{"categoryNo":123,"categoryName":124,"taxonomyType":125,"taxonomyTypeDesc":126},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[117,128,129,39,98,99,34,103,130,131,132,133,134,135,136,110,137,138,139,140,22],"MCP","cli","Budget","credentials","team","catalog","use","call","discover","external tools","with","scoped","blob",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":145,"sourceHtmlUrl":146,"categories":147,"keywords":153,"publishedAt":41},"01M6WN93MEAZ4E41DYAHJRPHQT","recruit","Turn a job description into an evidence-linked candidate shortlist through Treg, with job-related ranking and optional authorized business contact enrichment.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-recruit\u002FSKILL.md",[148],{"categoryNo":149,"categoryName":150,"taxonomyType":151,"taxonomyTypeDesc":152},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[143,39,98,34,33,154,155,156,157,158,110,159,160,161,138,162,163,164,165,140,117,22],"email","enrichment","business","evidence","phone","ranking","post","job description","for","person","candidate","reason",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":170,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":41},"01M6WN8R5RXSMHM9B4D9FAFX42","rea-growth","Analyze a company’s public growth and content through Treg, distinguish observations from hypotheses, and produce an evidence-linked playbook within an approved budget.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-rea-growth\u002FSKILL.md",[],[174,175,176,39,98,34,177,178,33,179,130,180,181,182,157,110,183,184,140,117,22],"growth","rea","rea growth","produce","content","playbook","marketing","analyze","public","observations","company",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":189,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":41},"01M6WN2EVE3RQRGWAKBT4S7YT2","make-ugc","Create original AI UGC-style product videos through Treg: research hooks, approve a licensed presenter and voice, generate clips, add captions and report costs.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-make-ugc\u002FSKILL.md",[],[193,194,39,195,98,196,34,197,198,199,200,201,110,202,203,204,205,206,207,140],"make","make ugc","research","create","Video","Captions","ads","short","hooks","head","style","niche","trending","talking-head","approve",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":90,"licenseFileUrl":212,"sourceHtmlUrl":213,"categories":214,"keywords":215,"publishedAt":41},"01M6WN10ARAA63Y8K1YNGXJ2RM","lead-signals","Find and qualify public buying signals through Treg, rank fitting business accounts and optionally enrich authorized business contact information.","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FLICENSE","https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-lead-signals\u002FSKILL.md",[],[216,217,218,39,98,34,219,220,156,221,222,110,223,224,225,226,227,228,229,140],"signals","lead","lead signals","how","find","ready","as","how to","qualify","people","information","enrich","changes","funding"]