@wonsukchoi/crondex 0.19.0 → 0.20.0

package/jobs/hr/probation-period-review-reminder.yaml

@@ -0,0 +1,36 @@
+id: probation-period-review-reminder
+version: 1
+name: Probation Period Review Reminder
+description: >
+  Warns you before a new hire's probation period ends so a manager can
+  complete the required review before it lapses automatically. Use this
+  if a probation deadline has ever passed with no review on file and
+  nobody caught it until it became a compliance headache.
+category: hr
+tags: [hr, probation, new-hire, compliance]
+schedule: "0 8 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    $3 != "" {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline end_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (end_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "REVIEW DUE: %s — probation ends %s (%d days), no review on file\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{probation_tracking_csv_path}}"
+variables:
+  probation_tracking_csv_path:
+    default: "./probation-tracking.csv"
+    description: "Path to a CSV with columns: employee_name,probation_end_date (YYYY-MM-DD),review_completed_date (blank if not yet done)."
+  warn_days_before:
+    default: 14
+    description: How many days before probation ends to start warning if no review is on file.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a maintained CSV export from your HRIS tracking probation end dates and review completion; distinct from performance-review-cycle-reminder, which covers ongoing cyclical reviews rather than one-time new-hire probation.

package/jobs/insurance/endorsement-request-followup-check.yaml

@@ -0,0 +1,37 @@
+id: endorsement-request-followup-check
+version: 1
+name: Policy Endorsement Request Follow-up Check
+description: >
+  Checks requested policy endorsements or amendments (e.g. adding a
+  driver, changing coverage limits) that haven't been confirmed processed
+  within a set window and flags them for follow-up. Use this if you've
+  ever submitted a change request to a carrier and only found out months
+  later it was never actually applied.
+category: insurance
+tags: [insurance, endorsement, policy-changes, follow-up]
+schedule: "0 9 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v days="{{overdue_days}}" '
+    NR==1 {next}
+    $4 != "" {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline requested_epoch; close(cmd);
+      pending_days = (today - requested_epoch) / 86400;
+      if (pending_days >= days) {
+        printf "OVERDUE: %s — %s requested %s (%d days, not confirmed processed)\n", $1, $2, $3, pending_days;
+      }
+    }
+  ' "{{endorsements_csv_path}}"
+variables:
+  endorsements_csv_path:
+    default: "./endorsement-requests.csv"
+    description: "Path to a CSV with columns: policy_name,requested_change,requested_date (YYYY-MM-DD),confirmed_date (blank if not yet confirmed by the carrier)."
+  overdue_days:
+    default: 10
+    description: Days since an endorsement was requested, with no carrier confirmation, before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Maintain the CSV manually or export it from your broker/agency management system; distinct from claim-status-check, which tracks claims rather than policy change requests.

package/jobs/inventory/purchase-order-receiving-delay-check.yaml

@@ -0,0 +1,33 @@
+id: purchase-order-receiving-delay-check
+version: 1
+name: Purchase Order Receiving Delay Check
+description: >
+  Checks open purchase orders against their expected delivery date and
+  flags any that are overdue and not yet marked received. Use this if
+  stock has ever run out because a purchase order was quietly late and
+  nobody chased the supplier until shelves were already empty.
+category: inventory
+tags: [inventory, purchase-orders, receiving, suppliers]
+schedule: "0 7 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    $5 != "" {next}
+    {
+      cmd = "date -d \"" $4 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $4 "\" +%s 2>/dev/null";
+      cmd | getline expected_epoch; close(cmd);
+      overdue_days = (today - expected_epoch) / 86400;
+      if (overdue_days > 0) {
+        printf "OVERDUE: PO %s from %s expected %s (%d days late, not received)\n", $1, $2, $4, overdue_days;
+      }
+    }
+  ' "{{purchase_orders_csv_path}}"
+variables:
+  purchase_orders_csv_path:
+    default: "./purchase-orders.csv"
+    description: "Path to a CSV with columns: po_number,supplier_name,order_date (YYYY-MM-DD),expected_delivery_date (YYYY-MM-DD),received_date (blank if not yet received)."
+compatible_agents: [generic, claude, codex]
+notes: Assumes a maintained CSV export from your procurement/inventory system; distinct from supplier-lead-time-drift-check, which tracks aggregate lead-time trends rather than individual overdue POs.

package/jobs/investing/dca-contribution-reminder.yaml

@@ -0,0 +1,33 @@
+id: dca-contribution-reminder
+version: 1
+name: DCA Contribution Reminder
+description: >
+  Checks your dollar-cost-averaging log and warns if it's been longer than
+  your planned interval since the last logged contribution. Use this if
+  you've ever meant to invest a fixed amount on a schedule and let a month
+  slip by without actually placing the order.
+category: investing
+tags: [investing, dca, dollar-cost-averaging, contributions]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  last_line=$(tail -n 1 "{{contribution_log_csv}}" 2>/dev/null);
+  if [ -z "$last_line" ]; then echo "WARNING: no contributions logged yet in {{contribution_log_csv}}"; exit 1; fi;
+  last_date=$(echo "$last_line" | cut -d',' -f1);
+  last_ts=$(date -d "$last_date" +%s 2>/dev/null || date -jf "%Y-%m-%d" "$last_date" +%s 2>/dev/null);
+  today_ts=$(date +%s);
+  days_since=$(( (today_ts - last_ts) / 86400 ));
+  if [ "$days_since" -ge "{{interval_days}}" ]; then
+    echo "WARNING: last DCA contribution was $days_since days ago (on $last_date) — due for another (${{interval_days}}-day interval)";
+    exit 1;
+  else echo "OK: last DCA contribution was $days_since days ago (on $last_date), within the ${{interval_days}}-day interval"; fi
+variables:
+  contribution_log_csv:
+    default: "dca-contributions.csv"
+    description: "CSV with header row, columns: date(YYYY-MM-DD),amount,ticker — append a row each time you invest."
+  interval_days:
+    default: 30
+    description: Expected number of days between contributions before this flags as overdue.
+compatible_agents: [generic, claude, codex]
+notes: Append a row to dca-contributions.csv yourself (or via your brokerage export) each time you make a scheduled contribution.

package/jobs/learning/webinar-attendance-reminder.yaml

@@ -0,0 +1,32 @@
+id: webinar-attendance-reminder
+version: 1
+name: Webinar Attendance Reminder
+description: >
+  Checks a list of webinars/workshops you've registered for and flags any
+  happening soon so you can block the time and prep. Use this if you've
+  ever signed up for a webinar and completely forgotten about it by the
+  time it started.
+category: learning
+tags: [learning, webinars, events, reminders]
+schedule: "0 8 * * *"
+timezone: "America/Los_Angeles"
+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 event_ts; close(cmd);
+      days_left = int((event_ts - today) / 86400);
+      if (days_left >= 0 && days_left <= warn) print "UPCOMING: \"" $1 "\" on " $2 " (in " days_left " day(s))";
+    }
+  ' "{{registrations_csv}}"
+variables:
+  registrations_csv:
+    default: "webinar-registrations.csv"
+    description: "CSV with header row, columns: title,date(YYYY-MM-DD)."
+  warn_days:
+    default: 3
+    description: Days ahead of a webinar to start flagging it as upcoming.
+compatible_agents: [generic, claude, codex]
+notes: Add a row to webinar-registrations.csv whenever you sign up for a webinar or workshop — this job only reads it, it doesn't register you anywhere.

package/jobs/legal/patent-maintenance-fee-reminder.yaml

@@ -0,0 +1,35 @@
+id: patent-maintenance-fee-reminder
+version: 1
+name: Patent Maintenance Fee Reminder
+description: >
+  Warns you before a patent maintenance (annuity) fee comes due so the
+  patent doesn't lapse. Use this if a patent has ever gone abandoned
+  because a maintenance fee deadline was missed.
+category: legal
+tags: [legal, patents, ip, maintenance-fees]
+schedule: "0 9 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 due_ts; close(cmd);
+      days_left = int((due_ts - today) / 86400);
+      if (days_left <= warn) print "WARNING: patent \"" $1 "\" maintenance fee due in " days_left " days (" $2 ")";
+    }
+  ' "{{patents_csv}}"
+variables:
+  patents_csv:
+    default: "patent-maintenance-fees.csv"
+    description: "CSV with header row, columns: patent_name_or_number,fee_due_date(YYYY-MM-DD)."
+  warn_days:
+    default: 60
+    description: Days before a maintenance fee due date to start warning — most jurisdictions allow a grace period but with a surcharge, so warn early.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Keep patent-maintenance-fees.csv updated with each patent's next fee due
+  date (from your IP counsel or the relevant patent office schedule) —
+  fee intervals and amounts vary by jurisdiction, so this job only tracks
+  dates you supply.

package/jobs/logistics/driver-hos-compliance-check.yaml

@@ -0,0 +1,38 @@
+id: driver-hos-compliance-check
+version: 1
+name: Driver Hours-of-Service Compliance Check
+description: >
+  Checks logged driving hours against the daily hours-of-service limit and
+  flags any driver close to or over it. Use this if a driver has ever run
+  over their legal on-duty hours because nobody was tallying it in real
+  time.
+category: logistics
+tags: [logistics, drivers, hos, compliance, safety]
+schedule: "0 */4 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v limit={{daily_hours_limit}} -v warn={{warn_hours_remaining}} '
+    NR>1 {
+      driver = $1; hours_today = $2;
+      remaining = limit - hours_today;
+      if (hours_today >= limit) print "OVER LIMIT: " driver " has logged " hours_today "h, exceeds the " limit "h daily limit";
+      else if (remaining <= warn) print "WARNING: " driver " has logged " hours_today "h, only " remaining "h remaining before the " limit "h daily limit";
+    }
+  ' "{{driver_hours_csv}}"
+variables:
+  driver_hours_csv:
+    default: "driver-hours-today.csv"
+    description: "CSV with header row, columns: driver_name,hours_logged_today — update from your ELD (electronic logging device) export."
+  daily_hours_limit:
+    default: 11
+    description: Maximum on-duty driving hours allowed per day under your governing HOS rules.
+  warn_hours_remaining:
+    default: 1
+    description: Hours remaining before the limit at which to start warning a driver is close.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Defaults reflect the US FMCSA 11-hour driving limit — adjust
+  daily_hours_limit for your jurisdiction's rules. This is a schedule-side
+  check against a CSV you export from your ELD/telematics system, not a
+  replacement for that system's own compliance logging.

package/jobs/manufacturing/energy-consumption-spike-check.yaml

@@ -0,0 +1,37 @@
+id: energy-consumption-spike-check
+version: 1
+name: Energy Consumption Spike Check
+description: >
+  Compares today's logged energy usage against a rolling baseline and
+  flags an unusual spike. Use this if a jump in electricity use has ever
+  gone unnoticed until the utility bill arrived, when it could have
+  pointed to a failing motor, a stuck compressor, or equipment left
+  running.
+category: manufacturing
+tags: [manufacturing, energy, utilities, anomaly]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v threshold={{spike_pct_threshold}} '
+    NR>1 { sum += $2; count++; readings[count] = $2 }
+    END {
+      if (count < 2) { print "OK: not enough readings yet to establish a baseline"; exit 0 }
+      latest = readings[count];
+      baseline_sum = sum - latest;
+      baseline_avg = baseline_sum / (count - 1);
+      if (baseline_avg == 0) { print "OK: baseline average is zero, skipping comparison"; exit 0 }
+      pct_over = ((latest - baseline_avg) / baseline_avg) * 100;
+      if (pct_over >= threshold) printf "SPIKE: latest reading %.1f kWh is %.1f%% above the %.1f kWh rolling baseline\n", latest, pct_over, baseline_avg;
+      else printf "OK: latest reading %.1f kWh is within %.1f%% of the %.1f kWh rolling baseline\n", latest, threshold, baseline_avg;
+    }
+  ' "{{energy_readings_csv}}"
+variables:
+  energy_readings_csv:
+    default: "energy-readings.csv"
+    description: "CSV with header row, columns: date,kwh — one row per day, most recent row last."
+  spike_pct_threshold:
+    default: 25
+    description: Percent above the rolling baseline average that counts as a spike worth flagging.
+compatible_agents: [generic, claude, codex]
+notes: Append a row to energy-readings.csv daily (from a smart meter export or utility portal) — the baseline is just the average of all prior rows, so accuracy improves as history builds up.

package/jobs/marketing/broken-campaign-link-check.yaml

@@ -0,0 +1,31 @@
+id: broken-campaign-link-check
+version: 1
+name: Broken Campaign Link Check
+description: >
+  Requests each active campaign's landing page URL and flags any that
+  return an error instead of loading. Use this if paid traffic has ever
+  kept flowing to a campaign whose landing page was quietly down or
+  redirecting to a 404.
+category: marketing
+tags: [marketing, campaigns, links, uptime]
+schedule: "0 */2 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  while IFS=',' read -r name url; do
+    [ "$name" = "campaign_name" ] && continue;
+    [ -z "$url" ] && continue;
+    code=$(curl -s -o /dev/null -w "%{http_code}" --max-time {{timeout_seconds}} "$url");
+    if [ "$code" -ge 400 ] || [ "$code" = "000" ]; then
+      echo "BROKEN: \"$name\" -> $url returned HTTP $code";
+    fi;
+  done < "{{campaign_urls_csv}}"
+variables:
+  campaign_urls_csv:
+    default: "campaign-urls.csv"
+    description: "CSV with header row, columns: campaign_name,landing_page_url — one row per active campaign."
+  timeout_seconds:
+    default: 10
+    description: Seconds to wait for each landing page before treating it as unreachable.
+compatible_agents: [generic, claude, codex]
+notes: Keep campaign-urls.csv in sync with whatever's currently live in your ad platform — a URL left in the file after a campaign ends will keep getting checked (and may false-flag if the page is intentionally retired).

package/jobs/nonprofit/donation-acknowledgment-lag-check.yaml

@@ -0,0 +1,32 @@
+id: donation-acknowledgment-lag-check
+version: 1
+name: Donation Acknowledgment Lag Check
+description: >
+  Flags donations that haven't been thanked yet and are approaching or
+  past your acknowledgment window. Use this if a donor has ever given and
+  waited weeks for a thank-you, or if a gift needing a timely
+  tax-receipt letter almost slipped past the deadline.
+category: nonprofit
+tags: [nonprofit, donors, acknowledgments, stewardship]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn={{warn_days}} '
+    NR>1 && $3 == "no" {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline gift_ts; close(cmd);
+      days_since = int((today - gift_ts) / 86400);
+      if (days_since >= warn) print "UNACKNOWLEDGED: " $1 " gave on " $2 " (" days_since " days ago, not yet thanked)";
+    }
+  ' "{{donations_csv}}"
+variables:
+  donations_csv:
+    default: "donations.csv"
+    description: "CSV with header row, columns: donor_name,gift_date(YYYY-MM-DD),acknowledged(yes/no)."
+  warn_days:
+    default: 7
+    description: Days since the gift date before an unacknowledged donation gets flagged.
+compatible_agents: [generic, claude, codex]
+notes: Mark a donation's acknowledged column "yes" once a thank-you/receipt goes out — export donations.csv from your CRM or update it manually.

package/jobs/podcast/rss-feed-health-check.yaml

@@ -0,0 +1,25 @@
+id: rss-feed-health-check
+version: 1
+name: Podcast RSS Feed Health Check
+description: >
+  Checks that your podcast's RSS feed is reachable and still valid XML with
+  the required podcast tags. Use this if a feed has ever silently broken
+  (bad edit, hosting hiccup, malformed enclosure) and stopped new episodes
+  from reaching Apple Podcasts or Spotify for days before anyone noticed.
+category: podcast
+tags: [podcast, rss, feed, distribution]
+schedule: "0 */6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  http_code=$(curl -s -o /tmp/rss-feed-check.xml -w "%{http_code}" "{{feed_url}}");
+  if [ "$http_code" != "200" ]; then echo "FAIL: feed_url returned HTTP $http_code"; exit 1; fi;
+  if ! grep -q "<rss" /tmp/rss-feed-check.xml; then echo "FAIL: response is not RSS XML"; exit 1; fi;
+  if ! grep -q "<enclosure" /tmp/rss-feed-check.xml; then echo "WARNING: no <enclosure> tag found — feed may have no episodes"; exit 1; fi;
+  echo "OK: feed reachable and looks valid"
+variables:
+  feed_url:
+    default: "https://example.com/podcast/feed.xml"
+    description: Public URL of your podcast's RSS feed.
+compatible_agents: [generic, claude, codex]
+notes: A passing check confirms the feed is reachable and structurally sane — it doesn't validate against the full RSS/iTunes spec, so still run a dedicated feed validator before a big launch.

package/jobs/realestate/insurance-policy-renewal-reminder.yaml

@@ -0,0 +1,31 @@
+id: insurance-policy-renewal-reminder
+version: 1
+name: Property Insurance Policy Renewal Reminder
+description: >
+  Flags property insurance policies that are coming up for renewal within a
+  set window. Use this if a policy has ever lapsed because the renewal
+  notice got buried in an inbox and nobody caught it in time.
+category: realestate
+tags: [realestate, insurance, renewals, 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 \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline exp_ts; close(cmd);
+      days_left = int((exp_ts - today) / 86400);
+      if (days_left <= warn) print "RENEWAL DUE: " $1 " policy " $2 " expires in " days_left " days (" $3 ")";
+    }
+  ' {{policies_csv}}
+variables:
+  policies_csv:
+    default: "property-insurance-policies.csv"
+    description: "CSV with header row, columns: property_name,policy_number,expiration_date(YYYY-MM-DD)."
+  warn_days:
+    default: 30
+    description: Days before expiration to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Keep property-insurance-policies.csv updated whenever a policy is bound, renewed, or switched carriers.

package/jobs/restaurant/walk-in-cooler-temp-log-check.yaml

@@ -0,0 +1,31 @@
+id: walk-in-cooler-temp-log-check
+version: 1
+name: Walk-In Cooler Temperature Log Check
+description: >
+  Scans today's logged cooler/freezer temperature readings and flags any
+  that fall outside the safe range. Use this if an out-of-range reading has
+  ever sat unnoticed in a paper log until a health inspector found it.
+category: restaurant
+tags: [restaurant, food-safety, temperature, compliance]
+schedule: "0 11,17,23 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min="{{min_safe_f}}" -v max="{{max_safe_f}}" '
+    NR==1 {next}
+    {
+      if ($3 < min || $3 > max) printf "OUT OF RANGE: %s %s reading %.1fF at %s\n", $1, $2, $3, $4;
+    }
+  ' "{{temp_log_csv}}"
+variables:
+  temp_log_csv:
+    default: "./cooler-temp-log.csv"
+    description: "CSV with header row, columns: unit_name,unit_type,temp_f,logged_at — one row per temperature check."
+  min_safe_f:
+    default: 33
+    description: Minimum safe temperature in Fahrenheit for a walk-in cooler/freezer reading.
+  max_safe_f:
+    default: 40
+    description: Maximum safe temperature in Fahrenheit for a walk-in cooler/freezer reading.
+compatible_agents: [generic, claude, codex]
+notes: Freezer units need a separate, much lower range — run this job once per unit_type with min_safe_f/max_safe_f set accordingly, or pre-filter the CSV.

package/jobs/retail/loyalty-points-expiry-reminder.yaml

@@ -0,0 +1,31 @@
+id: loyalty-points-expiry-reminder
+version: 1
+name: Loyalty Points Expiry Reminder
+description: >
+  Finds customers whose loyalty/reward points are about to expire unused.
+  Use this if points have ever quietly expired on customers who would have
+  redeemed them if someone had just reminded them in time.
+category: retail
+tags: [retail, loyalty, customers, rewards]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F, -v today="$today" -v warn={{warn_days}} '
+    NR>1 {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline exp_ts; close(cmd);
+      days_left = int((exp_ts - today) / 86400);
+      if (days_left <= warn && days_left >= 0 && $2 > 0) print "EXPIRING: " $1 " has " $2 " points expiring in " days_left " days (" $3 ")";
+    }
+  ' {{loyalty_csv}}
+variables:
+  loyalty_csv:
+    default: "loyalty-points.csv"
+    description: "CSV with header row, columns: customer_name,points_balance,expiration_date(YYYY-MM-DD)."
+  warn_days:
+    default: 14
+    description: Days before expiration to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Export loyalty-points.csv from your loyalty/POS platform on a schedule that matches how it tracks per-point expiration.

package/jobs/sales/quote-expiry-reminder.yaml

@@ -0,0 +1,24 @@
+id: quote-expiry-reminder
+version: 1
+name: Sales Quote Expiry Reminder
+description: >
+  Flags outstanding price quotes that are about to expire before the
+  customer has accepted them. Use this if a quote has ever lapsed and
+  forced a re-negotiation because nobody followed up before the locked-in
+  pricing ran out.
+category: sales
+tags: [sales, quotes, pricing, followup]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select customer_name, owner, quote_number, expires_at from quotes where status = 'sent' and expires_at < now() + interval '{{warn_days}} days';"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the quotes/CPQ database.
+  warn_days:
+    default: 5
+    description: Days before expires_at to start flagging a quote.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a `quotes` table with `status`, `expires_at`, and `owner` columns — adjust the query to your CPQ or CRM's schema.

package/jobs/support/knowledge-base-article-staleness-check.yaml

@@ -0,0 +1,39 @@
+id: knowledge-base-article-staleness-check
+version: 1
+name: Knowledge Base Article Staleness Check
+description: >
+  Flags published help center articles that haven't been reviewed or
+  updated in a long time. Use this if a stale article has ever kept giving
+  customers outdated instructions because nobody was tracking when it was
+  last touched.
+category: support
+tags: [support, knowledge-base, content, self-service]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  curl -s -H "Authorization: Bearer {{api_token}}" "{{kb_api_url}}" | grep -o '"title":"[^"]*","updated_at":"[^"]*"' | while IFS= read -r line; do
+    title=$(echo "$line" | sed -E 's/.*"title":"([^"]*)".*/\1/');
+    updated=$(echo "$line" | sed -E 's/.*"updated_at":"([^"]*)".*/\1/');
+    upd_ts=$(date -d "$updated" +%s 2>/dev/null || date -jf "%Y-%m-%dT%H:%M:%S" "$updated" +%s 2>/dev/null);
+    if [ -n "$upd_ts" ]; then
+      age_days=$(( (today - upd_ts) / 86400 ));
+      if [ "$age_days" -ge {{stale_days}} ]; then echo "STALE: \"$title\" last updated $age_days days ago"; fi;
+    fi;
+  done
+variables:
+  kb_api_url:
+    default: "https://api.example-helpdesk.com/help_center/articles?status=published"
+    description: Help center API endpoint listing published articles with title and updated_at fields.
+  api_token:
+    default: "your-api-token"
+    description: Bearer token for the help center API.
+  stale_days:
+    default: 365
+    description: Days since last update before an article counts as stale.
+compatible_agents: [generic, claude, codex]
+notes: >
+  The JSON field extraction here is deliberately simple (grep/sed, no jq
+  dependency) — if your help center API's JSON is nested or multi-line,
+  swap in `jq` for reliable parsing instead.

package/jobs/team/new-hire-onboarding-task-check.yaml

@@ -0,0 +1,32 @@
+id: new-hire-onboarding-task-check
+version: 1
+name: New Hire Onboarding Task Check
+description: >
+  Checks which new hires have onboarding tasks (accounts, equipment,
+  paperwork) that are still open past their target date. Use this if a
+  new hire has ever shown up without laptop access or benefits paperwork
+  because a checklist item silently slipped through the cracks.
+category: team
+tags: [team, onboarding, new-hire, checklist]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    $4 == "open" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      age_days = (today - due_epoch) / 86400;
+      if (age_days >= 0) {
+        printf "OVERDUE: %s — task \"%s\" due %s (%d day(s) late)\n", $1, $2, $3, age_days;
+      }
+    }
+  ' "{{onboarding_tasks_csv_path}}"
+variables:
+  onboarding_tasks_csv_path:
+    default: "./onboarding-tasks.csv"
+    description: "Path to a CSV with columns: new_hire_name,task_name,due_date (YYYY-MM-DD),status (open/done)."
+compatible_agents: [generic, claude, codex]
+notes: Assumes a maintained onboarding checklist export (from an HRIS or a spreadsheet) — this is the backstop that flags what's still open past its due date, not a source of truth for the checklist itself.

package/jobs/travel/flight-layover-buffer-check.yaml

@@ -0,0 +1,35 @@
+id: flight-layover-buffer-check
+version: 1
+name: Flight Layover Buffer Check
+description: >
+  Checks your upcoming itinerary for connections shorter than a safe
+  minimum layover time. Use this if you've ever booked a multi-leg trip
+  and only noticed a 35-minute connection the night before flying.
+category: travel
+tags: [travel, flights, layover, itinerary]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min_minutes="{{min_layover_minutes}}" '
+    NR==1 {next}
+    {
+      cmd1 = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f \"%Y-%m-%d %H:%M\" \"" $2 "\" +%s 2>/dev/null";
+      cmd1 | getline arrival_epoch; close(cmd1);
+      cmd2 = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f \"%Y-%m-%d %H:%M\" \"" $3 "\" +%s 2>/dev/null";
+      cmd2 | getline next_departure_epoch; close(cmd2);
+      layover_minutes = (next_departure_epoch - arrival_epoch) / 60;
+      if (layover_minutes < min_minutes) {
+        printf "TIGHT LAYOVER: %s — only %d minute(s) between arrival and next departure\n", $1, layover_minutes;
+      }
+    }
+  ' "{{itinerary_csv_path}}"
+variables:
+  itinerary_csv_path:
+    default: "./flight-itinerary.csv"
+    description: "Path to a CSV with columns: connection_airport,arrival_time (YYYY-MM-DD HH:MM),next_departure_time (YYYY-MM-DD HH:MM)."
+  min_layover_minutes:
+    default: 60
+    description: Minimum minutes between arrival and next departure before a connection counts as tight. Raise this for connections requiring a terminal change, customs, or international-to-domestic transfers.
+compatible_agents: [generic, claude, codex]
+notes: Zero-token. You maintain the itinerary CSV yourself — this doesn't pull from any airline or booking system. Times should be in the connection airport's local timezone.

package/jobs/veterinary/lab-result-turnaround-check.yaml

@@ -0,0 +1,35 @@
+id: lab-result-turnaround-check
+version: 1
+name: Lab Result Turnaround Check
+description: >
+  Checks which submitted lab orders still have no result logged past
+  their expected turnaround time. Use this if a sample has ever sat at
+  an outside lab for a week with nobody following up because no one was
+  tracking orders against their expected turnaround.
+category: veterinary
+tags: [veterinary, lab-results, patients, turnaround]
+schedule: "0 9 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn_days="{{overdue_after_days}}" '
+    NR==1 {next}
+    $4 == "pending" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline submitted_epoch; close(cmd);
+      age_days = (today - submitted_epoch) / 86400;
+      if (age_days >= warn_days) {
+        printf "OVERDUE RESULT: %s (%s) — %s submitted %s (%d day(s) ago, still pending)\n", $1, $2, $5, $3, age_days;
+      }
+    }
+  ' "{{lab_orders_csv_path}}"
+variables:
+  lab_orders_csv_path:
+    default: "./lab-orders.csv"
+    description: "Path to a CSV with columns: pet_name,owner_name,submitted_date (YYYY-MM-DD),status (pending/resulted),test_type."
+  overdue_after_days:
+    default: 5
+    description: Days since a sample was submitted before a still-pending result counts as overdue for follow-up with the lab.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a maintained export from your practice management or lab-ordering system — this flags orders that fell out of tracking, it doesn't chase the lab itself.