@wonsukchoi/crondex 0.6.0 → 0.7.0

package/jobs/construction/inspection-deadline-reminder.yaml

@@ -0,0 +1,31 @@
+id: inspection-deadline-reminder
+version: 1
+name: Inspection Deadline Reminder
+description: >
+  Warns you before a scheduled inspection date, so the site is actually
+  ready. Use this if an inspector has ever shown up to a site that wasn't
+  prepped because the date snuck up on the crew.
+category: construction
+tags: [construction, inspection, scheduling]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F, -v today="$today" -v warn={{warn_days}} '
+    NR>1 {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline insp_ts; close(cmd);
+      days_left = int((insp_ts - today) / 86400);
+      if (days_left <= warn && days_left >= 0) print "WARNING: " $1 " inspection in " days_left " days (" $2 ")";
+    }
+  ' {{inspections_csv}}
+variables:
+  inspections_csv:
+    default: "inspections.csv"
+    description: "CSV with header row, columns: site_name,inspection_date(YYYY-MM-DD)."
+  warn_days:
+    default: 3
+    description: Days before the inspection to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Keep inspections.csv updated as inspections get scheduled with the local authority.

package/jobs/construction/permit-expiry-check.yaml

@@ -0,0 +1,31 @@
+id: permit-expiry-check
+version: 1
+name: Building Permit Expiry Check
+description: >
+  Warns you before a building permit expires so work doesn't get caught
+  without valid coverage. Use this if a permit has ever lapsed mid-project
+  and forced a costly re-inspection or re-application.
+category: construction
+tags: [construction, permits, compliance]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F, -v today="$today" -v warn={{warn_days}} '
+    NR>1 {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline exp_ts; close(cmd);
+      days_left = int((exp_ts - today) / 86400);
+      if (days_left <= warn) print "WARNING: permit \"" $1 "\" expires in " days_left " days (" $2 ")";
+    }
+  ' {{permits_csv}}
+variables:
+  permits_csv:
+    default: "permits.csv"
+    description: "CSV with header row, columns: permit_name,expiry_date(YYYY-MM-DD)."
+  warn_days:
+    default: 30
+    description: Days before expiry to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Keep permits.csv updated per project/site — one row per active permit.

package/jobs/content/hreflang-audit.yaml

@@ -0,0 +1,25 @@
+id: hreflang-audit
+version: 1
+name: Hreflang Audit
+description: >
+  Checks a page's hreflang tags for missing reciprocal links or obviously
+  wrong language/region codes. Use this if a hreflang mistake has ever
+  quietly sent the wrong country's visitors to the wrong language version.
+category: content
+tags: [seo, hreflang, international]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  tags=$(curl -s {{page_url}} | grep -o '<link[^>]*rel=["'"'"']alternate["'"'"'][^>]*hreflang=["'"'"'][^"'"'"']*["'"'"'][^>]*>');
+  if [ -z "$tags" ]; then echo "WARNING: no hreflang tags found on {{page_url}}"; exit 1; fi;
+  echo "$tags" | grep -o 'hreflang=["'"'"'][^"'"'"']*' | sed 's/hreflang=["'"'"']//' | while read -r code; do
+    echo "$code" | grep -qE '^[a-z]{2}(-[A-Z]{2})?$|^x-default$' || echo "WARNING: suspicious hreflang code \"$code\" on {{page_url}}";
+  done;
+  echo "OK: found $(echo "$tags" | wc -l | tr -d ' ') hreflang tag(s) — verify reciprocal links manually"
+variables:
+  page_url:
+    default: "https://example.com"
+    description: URL of the page to check.
+compatible_agents: [generic, claude, codex]
+notes: Flags malformed language/region codes and missing tags on this page only — checking reciprocal hreflang links across the whole site needs crawling every listed URL, which this job doesn't do.

package/jobs/content/image-alt-text-audit.yaml

@@ -0,0 +1,21 @@
+id: image-alt-text-audit
+version: 1
+name: Image Alt Text Audit
+description: >
+  Checks a page for images missing alt text. Use this if images have ever
+  shipped without alt text because nobody double-checked before merging.
+category: content
+tags: [seo, accessibility, images]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  count=$(curl -s {{page_url}} | grep -o '<img[^>]*>' | grep -cv 'alt=');
+  if [ "$count" -gt 0 ]; then echo "WARNING: $count image(s) missing alt text on {{page_url}}"; exit 1;
+  else echo "OK: all images on {{page_url}} have alt text"; fi
+variables:
+  page_url:
+    default: "https://example.com"
+    description: URL of the page to check.
+compatible_agents: [generic, claude, codex]
+notes: Flags images with no alt attribute at all — doesn't judge whether existing alt text is actually descriptive.

package/jobs/content/page-speed-regression-watch.yaml

@@ -0,0 +1,26 @@
+id: page-speed-regression-watch
+version: 1
+name: Page Speed Regression Watch
+description: >
+  Checks a page's load time against a baseline and flags a real
+  regression. Use this if a page has ever gotten slowly, silently slower
+  release after release until it was a real problem.
+category: content
+tags: [performance, seo, monitoring]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  time_total=$(curl -s -o /dev/null -w '%{time_total}' {{page_url}});
+  if awk "BEGIN{exit !($time_total > {{threshold_seconds}})}"; then
+    echo "WARNING: {{page_url}} took ${time_total}s to load (threshold {{threshold_seconds}}s)"; exit 1;
+  else echo "OK: {{page_url}} loaded in ${time_total}s"; fi
+variables:
+  page_url:
+    default: "https://example.com"
+    description: URL of the page to check.
+  threshold_seconds:
+    default: 3
+    description: Load time in seconds beyond which to warn.
+compatible_agents: [generic, claude, codex]
+notes: Measures raw TTFB-through-download time via curl, not real browser rendering — use a synthetic monitoring tool for full Core Web Vitals.

package/jobs/creator/content-calendar-gap-check.yaml

@@ -0,0 +1,31 @@
+id: content-calendar-gap-check
+version: 1
+name: Content Calendar Gap Check
+description: >
+  Checks that you have something scheduled to post in the next few days.
+  Use this if your publishing cadence has ever quietly broken because
+  nothing was queued and nobody noticed until the gap already showed.
+category: creator
+tags: [content, calendar, publishing]
+schedule: "0 9 * * 1,4"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  cutoff=$(( today + {{lookahead_days}} * 86400 ));
+  next_ts=$(awk -F, 'NR>1 {
+      cmd="date -d \"" $1 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $1 "\" +%s";
+      cmd | getline ts; close(cmd);
+      if (ts >= "'"$today"'") { print ts; exit }
+    }' {{schedule_csv}});
+  if [ -z "$next_ts" ] || [ "$next_ts" -gt "$cutoff" ]; then echo "WARNING: no post scheduled in the next {{lookahead_days}} days"; exit 1;
+  else echo "OK: next post is scheduled within {{lookahead_days}} days"; fi
+variables:
+  schedule_csv:
+    default: "content-calendar.csv"
+    description: "CSV with header row, columns: publish_date(YYYY-MM-DD),title,platform."
+  lookahead_days:
+    default: 3
+    description: Days ahead that must have at least one scheduled post.
+compatible_agents: [generic, claude, codex]
+notes: Reads a plain CSV export of your content calendar — point schedule_csv at wherever your planning tool exports to.

package/jobs/creator/engagement-drop-watch.yaml

@@ -0,0 +1,36 @@
+id: engagement-drop-watch
+version: 1
+name: Engagement Drop Watch
+description: >
+  Compares recent post engagement to your baseline and flags a real drop.
+  Use this if you've ever kept posting into a falling algorithm curve for
+  weeks before noticing the numbers were down.
+category: creator
+tags: [content, engagement, social]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check engagement (likes, comments, shares, views — whatever the
+  platform reports) for posts on {{platform_hint}} over the last
+  {{recent_days}} days.
+  1. Compare average engagement rate to the prior {{baseline_days}}-day
+     baseline.
+  2. Flag a drop of {{drop_threshold_pct}}% or more.
+  3. If flagged, note anything that changed around the drop (posting time,
+     format, frequency) if it's visible from the data.
+variables:
+  platform_hint:
+    default: "your primary platform (YouTube, Instagram, TikTok, etc.)"
+    description: Which platform's analytics to check.
+  recent_days:
+    default: 7
+    description: Recent window to evaluate.
+  baseline_days:
+    default: 30
+    description: Prior window used as the baseline for comparison.
+  drop_threshold_pct:
+    default: 25
+    description: Percent drop in engagement rate that counts as a real decline.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — platform analytics APIs vary widely and most need OAuth the agent may not have configured.

package/jobs/devops/cdn-cache-purge-reminder.yaml

@@ -0,0 +1,27 @@
+id: cdn-cache-purge-reminder
+version: 1
+name: CDN Cache Purge Reminder
+description: >
+  Reminds you to purge the CDN cache after a deploy, and can trigger it
+  directly if you give it credentials. Use this if you've ever shipped a
+  fix and then spent an hour confused why users still saw the old version.
+category: devops
+tags: [cdn, cache, deploy]
+schedule: "*/30 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  if [ -z "{{deploy_marker_file}}" ] || [ ! -f "{{deploy_marker_file}}" ]; then echo "OK: no pending deploy marker found"; exit 0; fi;
+  echo "REMINDER: deploy marker found at {{deploy_marker_file}} — purge CDN cache for {{cdn_zone}} if not already done, then remove the marker.";
+variables:
+  deploy_marker_file:
+    default: ".deploy-pending"
+    description: Path to a marker file your deploy script touches; job reminds until it's removed.
+  cdn_zone:
+    default: "your CDN zone/distribution"
+    description: Name of the CDN zone, for the reminder text.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Deliberately doesn't call any CDN API directly since providers differ
+  widely (Cloudflare, Fastly, CloudFront) — have your deploy script touch
+  the marker file, and remove it once cache is purged.

package/jobs/devops/ci-build-time-regression-watch.yaml

@@ -0,0 +1,35 @@
+id: ci-build-time-regression-watch
+version: 1
+name: CI Build Time Regression Watch
+description: >
+  Compares recent CI build durations to a baseline and flags a real
+  slowdown. Use this if build times have ever crept up gradually until a
+  30-second CI run became a 15-minute one.
+category: devops
+tags: [ci, performance, build-time]
+schedule: "0 9 * * 1-5"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check recent CI run durations for {{repo_hint}} over the last
+  {{recent_runs}} runs on the main branch.
+  1. Compute the average duration and compare to the average of the prior
+     {{baseline_runs}} runs.
+  2. Flag a regression of {{threshold_pct}}% or more.
+  3. If flagged, note which stage/job grew the most, if that breakdown is
+     available.
+variables:
+  repo_hint:
+    default: "this repo's CI (GitHub Actions, CircleCI, etc.)"
+    description: Which repo and CI provider to check.
+  recent_runs:
+    default: 10
+    description: Number of recent runs to average for the current period.
+  baseline_runs:
+    default: 30
+    description: Number of prior runs to use as the baseline.
+  threshold_pct:
+    default: 30
+    description: Percent increase in average duration that counts as a regression.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — CI provider APIs vary, and per-stage timing breakdowns need provider-specific parsing.

package/jobs/devops/k8s-pod-restart-watch.yaml

@@ -0,0 +1,26 @@
+id: k8s-pod-restart-watch
+version: 1
+name: Kubernetes Pod Restart Watch
+description: >
+  Checks for pods with a high restart count and flags them. Use this if a
+  crash-looping pod has ever burned through hours before anyone noticed
+  it wasn't actually staying up.
+category: devops
+tags: [kubernetes, pods, monitoring]
+schedule: "*/15 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  command -v kubectl >/dev/null 2>&1 || { echo "ERROR: kubectl not installed"; exit 1; };
+  kubectl get pods -n {{namespace}} --no-headers 2>/dev/null | awk -v threshold={{threshold}} '
+    { restarts=$4+0; if (restarts >= threshold) print "WARNING: pod " $1 " has " restarts " restarts" }
+  '
+variables:
+  namespace:
+    default: "default"
+    description: Kubernetes namespace to check.
+  threshold:
+    default: 5
+    description: Restart count that triggers a warning.
+compatible_agents: [generic, claude, codex]
+notes: Requires kubectl configured with a context pointing at the cluster; emits nothing if no pod is over threshold.

package/jobs/devops/log-forwarding-health-check.yaml

@@ -0,0 +1,32 @@
+id: log-forwarding-health-check
+version: 1
+name: Log Forwarding Health Check
+description: >
+  Checks that logs are still actually arriving at your log aggregator.
+  Use this if a log shipper has ever silently died and nobody found out
+  until they needed logs that were never collected.
+category: devops
+tags: [logging, monitoring, observability]
+schedule: "*/30 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  last_ts=$(curl -s -H "Authorization: Bearer {{log_api_token}}" "{{log_query_api_url}}" | grep -o '"timestamp":"[^"]*"' | sort -r | head -n1 | cut -d'"' -f4);
+  if [ -z "$last_ts" ]; then echo "WARNING: no recent log entries found via {{log_query_api_url}}"; exit 1; fi;
+  last_epoch=$(date -d "$last_ts" +%s 2>/dev/null);
+  now_epoch=$(date +%s);
+  minutes_since=$(( (now_epoch - last_epoch) / 60 ));
+  if [ "$minutes_since" -ge "{{max_gap_minutes}}" ]; then echo "WARNING: no new logs in $minutes_since minutes (last at $last_ts)"; exit 1;
+  else echo "OK: most recent log entry $minutes_since minutes ago"; fi
+variables:
+  log_query_api_url:
+    default: "https://api.example-logs.com/query?limit=1&sort=desc"
+    description: Log aggregator API endpoint returning at least the most recent entry's timestamp.
+  log_api_token:
+    default: "your-api-token"
+    description: API token for the log aggregator.
+  max_gap_minutes:
+    default: 15
+    description: Minutes without a new log entry before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Generic REST pattern — point log_query_api_url at your aggregator's (Datadog, Splunk, ELK) most-recent-entry query; adjust field names to match its response shape.

package/jobs/devops/staging-prod-config-diff.yaml

@@ -0,0 +1,32 @@
+id: staging-prod-config-diff
+version: 1
+name: Staging vs Production Config Diff
+description: >
+  Diffs environment variable keys between staging and production and
+  flags mismatches. Use this if staging and prod have ever quietly
+  drifted apart until a deploy broke only in one of them.
+category: devops
+tags: [config, environments, drift]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  staging_keys=$(cut -d= -f1 {{staging_env_file}} | grep -v '^#' | sort);
+  prod_keys=$(cut -d= -f1 {{prod_env_file}} | grep -v '^#' | sort);
+  only_staging=$(comm -23 <(echo "$staging_keys") <(echo "$prod_keys"));
+  only_prod=$(comm -13 <(echo "$staging_keys") <(echo "$prod_keys"));
+  if [ -n "$only_staging" ] || [ -n "$only_prod" ]; then
+    echo "DRIFT DETECTED:";
+    [ -n "$only_staging" ] && echo "only in staging: $only_staging";
+    [ -n "$only_prod" ] && echo "only in prod: $only_prod";
+    exit 1;
+  else echo "OK: staging and prod env keys match"; fi
+variables:
+  staging_env_file:
+    default: ".env.staging"
+    description: Path to the staging environment file (keys only compared, not values).
+  prod_env_file:
+    default: ".env.production"
+    description: Path to the production environment file.
+compatible_agents: [generic, claude, codex]
+notes: Compares key names only, never values, so secrets are never read or logged.

package/jobs/education/assignment-grading-backlog-check.yaml

@@ -0,0 +1,23 @@
+id: assignment-grading-backlog-check
+version: 1
+name: Assignment Grading Backlog Check
+description: >
+  Checks how many submitted assignments are still ungraded and flags it if
+  the backlog is growing. Use this if grading has ever piled up for weeks
+  until students started asking where their grades were.
+category: education
+tags: [education, grading, backlog]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select course, count(*) from submissions where graded_at is null and submitted_at < now() - interval '{{stale_days}} days' group by course;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the LMS/gradebook database.
+  stale_days:
+    default: 3
+    description: Days a submission can sit ungraded before it's counted in the backlog.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a `submissions` table with `graded_at` and `submitted_at` — adjust the query for your LMS's schema or export.

package/jobs/education/attendance-anomaly-check.yaml

@@ -0,0 +1,33 @@
+id: attendance-anomaly-check
+version: 1
+name: Attendance Anomaly Check
+description: >
+  Flags students whose attendance has dropped sharply, before it becomes a
+  pattern nobody caught early. Use this if a student's attendance has ever
+  quietly fallen off and only got noticed at report-card time.
+category: education
+tags: [education, attendance, students]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review attendance records from {{sis_hint}} for the last
+  {{recent_weeks}} weeks.
+  1. Compare each student's recent attendance rate to their prior
+     baseline for the term.
+  2. Flag students with a drop of {{drop_threshold_pct}} percentage
+     points or more.
+  3. Report flagged students with their recent and baseline rates, so
+     follow-up (counselor, parent contact) can be prioritized.
+variables:
+  sis_hint:
+    default: "your student information system"
+    description: Where attendance data lives.
+  recent_weeks:
+    default: 2
+    description: Recent window to evaluate.
+  drop_threshold_pct:
+    default: 20
+    description: Percentage-point drop in attendance rate that counts as an anomaly.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — SIS platforms vary widely and most need OAuth or export access the agent may not have configured.

package/jobs/events/rsvp-followup-reminder.yaml

@@ -0,0 +1,30 @@
+id: rsvp-followup-reminder
+version: 1
+name: RSVP Follow-up Reminder
+description: >
+  Flags invitees who haven't RSVP'd as the event date gets close. Use this
+  if you've ever had to guess headcount because half the guest list never
+  replied and nobody chased them.
+category: events
+tags: [events, rsvp, planning]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  event_ts=$(date -d "{{event_date}}" +%s 2>/dev/null || date -jf "%Y-%m-%d" "{{event_date}}" +%s);
+  days_left=$(( (event_ts - today) / 86400 ));
+  if [ "$days_left" -gt "{{warn_days}}" ]; then echo "OK: event is $days_left days out, no follow-up needed yet"; exit 0; fi;
+  awk -F, 'NR>1 && $2 == "pending" {print "PENDING RSVP: " $1}' {{guest_list_csv}}
+variables:
+  event_date:
+    default: "2026-12-01"
+    description: Date of the event (YYYY-MM-DD).
+  warn_days:
+    default: 14
+    description: Days before the event to start flagging pending RSVPs.
+  guest_list_csv:
+    default: "guest-list.csv"
+    description: "CSV with header row, columns: name,rsvp_status(pending/yes/no)."
+compatible_agents: [generic, claude, codex]
+notes: Keep guest-list.csv updated as RSVPs come in, or export it from your invite tool before each run.

package/jobs/events/vendor-payment-deadline-reminder.yaml

@@ -0,0 +1,31 @@
+id: vendor-payment-deadline-reminder
+version: 1
+name: Event Vendor Payment Deadline Reminder
+description: >
+  Warns you before a vendor deposit or balance payment for an event is
+  due. Use this if a vendor has ever threatened to cancel because a
+  payment deadline slipped past unnoticed.
+category: events
+tags: [events, vendors, payments]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F, -v today="$today" -v warn={{warn_days}} '
+    NR>1 {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline due_ts; close(cmd);
+      days_left = int((due_ts - today) / 86400);
+      if (days_left <= warn && days_left >= 0) print "WARNING: payment to \"" $1 "\" (" $3 ") due in " days_left " days (" $2 ")";
+    }
+  ' {{vendor_payments_csv}}
+variables:
+  vendor_payments_csv:
+    default: "vendor-payments.csv"
+    description: "CSV with header row, columns: vendor_name,due_date(YYYY-MM-DD),amount."
+  warn_days:
+    default: 7
+    description: Days before due date to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Keep vendor-payments.csv updated as contracts are signed — one row per deposit/balance milestone.

package/jobs/finance/payroll-run-reminder.yaml

@@ -0,0 +1,27 @@
+id: payroll-run-reminder
+version: 1
+name: Payroll Run Reminder
+description: >
+  Warns you before the payroll submission deadline so employees actually
+  get paid on time. Use this if payroll has ever run late because the
+  submission cutoff snuck up during a busy week.
+category: finance
+tags: [finance, payroll, deadlines]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  cutoff_ts=$(date -d "{{next_cutoff_date}}" +%s 2>/dev/null || date -jf "%Y-%m-%d" "{{next_cutoff_date}}" +%s);
+  days_left=$(( (cutoff_ts - today) / 86400 ));
+  if [ "$days_left" -le "{{warn_days}}" ] && [ "$days_left" -ge 0 ]; then echo "WARNING: payroll submission cutoff in $days_left days ({{next_cutoff_date}})"; exit 1;
+  else echo "OK: payroll submission cutoff in $days_left days"; fi
+variables:
+  next_cutoff_date:
+    default: "2026-08-01"
+    description: Next payroll submission cutoff date (YYYY-MM-DD).
+  warn_days:
+    default: 2
+    description: Days before the cutoff to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Manual next_cutoff_date input — update it each pay cycle, or generate a recurring schedule externally if your payroll provider uses a fixed cadence.

package/jobs/finance/recurring-payment-failure-check.yaml

@@ -0,0 +1,23 @@
+id: recurring-payment-failure-check
+version: 1
+name: Recurring Payment Failure Check
+description: >
+  Flags subscription charges that failed and haven't successfully retried
+  yet. Use this if a failed card has ever silently churned a customer
+  because nobody noticed the retry never succeeded.
+category: finance
+tags: [finance, billing, payments]
+schedule: "0 */6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select customer_email, amount, failed_at, retry_count from subscription_charges where status = 'failed' and retry_count >= {{max_retries}};"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the billing database.
+  max_retries:
+    default: 2
+    description: Retry count at or above which a failed charge is flagged for manual follow-up.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a `subscription_charges` table with `status`, `retry_count`, and `failed_at` columns — adjust the query to your billing provider's schema or webhook log.

package/jobs/fleet/fuel-card-anomaly-check.yaml

@@ -0,0 +1,37 @@
+id: fuel-card-anomaly-check
+version: 1
+name: Fuel Card Anomaly Check
+description: >
+  Flags fuel card transactions that look unusual (too large, too frequent,
+  or outside normal hours/locations). Use this if fuel card misuse has
+  ever gone unnoticed until the monthly statement showed up.
+category: fleet
+tags: [fleet, fuel-card, fraud]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review fuel card transactions from {{fuel_card_provider_hint}} for the
+  last 24 hours.
+  1. Flag transactions over {{max_transaction_usd}} USD.
+  2. Flag more than {{max_daily_transactions}} transactions on the same
+     card in one day.
+  3. Flag transactions outside typical operating hours ({{operating_hours}})
+     if timestamps are available.
+  4. Report flagged transactions with card holder, amount, time, and
+     location.
+variables:
+  fuel_card_provider_hint:
+    default: "your fuel card provider (WEX, Fuelman, etc.)"
+    description: Name of the fuel card provider/portal.
+  max_transaction_usd:
+    default: 150
+    description: Single-transaction amount that triggers a flag.
+  max_daily_transactions:
+    default: 2
+    description: Transactions per card per day that triggers a flag.
+  operating_hours:
+    default: "06:00-19:00"
+    description: Normal operating hours; transactions outside this window are flagged.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — fuel card provider APIs/exports vary and flagging patterns benefits from judgment, not just fixed rules.

package/jobs/fleet/vehicle-maintenance-due-check.yaml

@@ -0,0 +1,36 @@
+id: vehicle-maintenance-due-check
+version: 1
+name: Fleet Vehicle Maintenance Due Check
+description: >
+  Flags fleet vehicles due for scheduled maintenance by date or mileage.
+  Use this if a fleet vehicle has ever broken down on a job because its
+  service interval quietly passed.
+category: fleet
+tags: [fleet, vehicles, maintenance]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F, -v today="$today" -v warn_days={{warn_days}} -v warn_miles={{warn_miles}} '
+    NR>1 {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline due_ts; close(cmd);
+      days_left = int((due_ts - today) / 86400);
+      miles_left = $4 - $3;
+      if (days_left <= warn_days || miles_left <= warn_miles)
+        print "WARNING: vehicle " $1 " due in " days_left " days or " miles_left " miles (service due " $2 " / " $4 " mi)";
+    }
+  ' {{fleet_csv}}
+variables:
+  fleet_csv:
+    default: "fleet-maintenance.csv"
+    description: "CSV with header row, columns: vehicle_id,next_service_date(YYYY-MM-DD),current_mileage,next_service_mileage."
+  warn_days:
+    default: 14
+    description: Days before the service date to start warning.
+  warn_miles:
+    default: 500
+    description: Miles remaining before the service mileage to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Keep fleet-maintenance.csv updated from odometer readings/telematics exports before each run.

package/jobs/hiring/candidate-followup-nudge.yaml

@@ -0,0 +1,23 @@
+id: candidate-followup-nudge
+version: 1
+name: Candidate Follow-up Nudge
+description: >
+  Flags interviewed candidates who haven't heard back in a while. Use this
+  if candidates have ever gone quiet after a final interview simply
+  because nobody circled back with a decision.
+category: hiring
+tags: [hiring, recruiting, candidates]
+schedule: "0 9 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select name, stage, last_interview_at from candidates where stage not in ('hired','rejected') and last_interview_at < now() - interval '{{stale_days}} days';"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the candidates/ATS database.
+  stale_days:
+    default: 7
+    description: Days since last interview before a candidate is flagged for follow-up.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a `candidates` table with `stage` and `last_interview_at` columns — adjust the query to your ATS's schema or export.