@wonsukchoi/crondex 0.18.0 → 0.20.0

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/nonprofit/event-rsvp-shortfall-check.yaml

@@ -0,0 +1,40 @@
+id: event-rsvp-shortfall-check
+version: 1
+name: Fundraising Event RSVP Shortfall Check
+description: >
+  Checks confirmed RSVPs for an upcoming fundraising event against your
+  goal and flags it if you're falling short as the date approaches. Use
+  this if an event has ever snuck up with half-empty RSVPs and no time
+  left to push more invitations.
+category: nonprofit
+tags: [nonprofit, events, fundraising, rsvp]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  rsvp_count=$(psql "{{database_url}}" -t -A -c "select count(*) from rsvps where event_id = '{{event_id}}' and status = 'confirmed';");
+  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 [ "$rsvp_count" -lt "{{rsvp_goal}}" ] && [ "$days_left" -le "{{warn_days_before}}" ]; then
+    echo "WARNING: event {{event_id}} has $rsvp_count/{{rsvp_goal}} RSVPs with $days_left days left";
+    exit 1;
+  else echo "OK: event {{event_id}} has $rsvp_count/{{rsvp_goal}} RSVPs, $days_left days left"; fi
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the events/RSVP database.
+  event_id:
+    default: "your-event-id"
+    description: Identifier of the event to track, matching the rsvps table.
+  event_date:
+    default: "2027-01-01"
+    description: Event date (YYYY-MM-DD).
+  rsvp_goal:
+    default: 100
+    description: Target number of confirmed RSVPs.
+  warn_days_before:
+    default: 14
+    description: Days before the event to start warning if under goal.
+compatible_agents: [generic, claude, codex]
+notes: Assumes an `rsvps` table with `event_id` and a `status` column set to 'confirmed' for accepted invites — adjust the query to your CRM/registration schema.

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/podcast/transcript-publish-lag-check.yaml

@@ -0,0 +1,31 @@
+id: transcript-publish-lag-check
+version: 1
+name: Transcript Publish Lag Check
+description: >
+  Flags episodes that published without a transcript still missing after a
+  grace period. Use this if you've ever promised accessible, searchable
+  transcripts but had episodes quietly sit for weeks without one.
+category: podcast
+tags: [podcast, transcript, accessibility, publishing]
+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 pub_ts; close(cmd);
+      days_since = int((today - pub_ts) / 86400);
+      if ($3 == "missing" && days_since >= warn) print "WARNING: " $1 " published " days_since " days ago with no transcript (" $2 ")";
+    }
+  ' {{episodes_csv}}
+variables:
+  episodes_csv:
+    default: "episodes.csv"
+    description: "CSV with header row, columns: episode_title,publish_date(YYYY-MM-DD),transcript_status(ready/missing)."
+  warn_days:
+    default: 3
+    description: Days after publish to allow before flagging a missing transcript.
+compatible_agents: [generic, claude, codex]
+notes: Update transcript_status to "ready" in episodes.csv once a transcript is posted, so the row stops flagging.

package/jobs/realestate/hoa-fee-collection-check.yaml

@@ -0,0 +1,35 @@
+id: hoa-fee-collection-check
+version: 1
+name: HOA Fee Collection Check
+description: >
+  Scans an HOA/association dues ledger for owners who are past due and
+  totals what's outstanding. Use this if unpaid association dues have ever
+  piled up silently until the reserve fund came up short.
+category: realestate
+tags: [realestate, hoa, dues, collections]
+schedule: "0 8 5 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v grace="{{grace_days}}" -v today="$(date +%s)" '
+    NR==1 {next}
+    {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline due_ts; close(cmd);
+      days_late = int((today - due_ts) / 86400);
+      if ($4 == "unpaid" && days_late >= grace) {
+        printf "PAST DUE: unit %s owes %s, %d days late (due %s)\n", $1, $2, days_late, $3;
+        total += $2; count++;
+      }
+    }
+    END { if (count > 0) printf "TOTAL OUTSTANDING: $%.2f across %d unit(s)\n", total, count; else print "OK: no past-due dues"; }
+  ' "{{dues_ledger_csv}}"
+variables:
+  dues_ledger_csv:
+    default: "./hoa-dues-ledger.csv"
+    description: "Path to a CSV with columns: unit,amount_due,due_date(YYYY-MM-DD),status(paid/unpaid)."
+  grace_days:
+    default: 10
+    description: Days past the due date before a balance counts as past due.
+compatible_agents: [generic, claude, codex]
+notes: Update hoa-dues-ledger.csv status to "paid" as payments land so this only ever flags true outstanding balances.

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/supplier-price-increase-watch.yaml

@@ -0,0 +1,36 @@
+id: supplier-price-increase-watch
+version: 1
+name: Supplier Price Increase Watch
+description: >
+  Compares this week's supplier invoice prices against your reference cost
+  sheet and flags ingredients that jumped more than a set percentage. Use
+  this if a supplier has ever quietly raised prices for months before
+  anyone noticed the food cost creeping up.
+category: restaurant
+tags: [restaurant, suppliers, cost, invoices]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v threshold="{{pct_increase_threshold}}" '
+    FNR==NR { if (FNR>1) ref[$1]=$2; next }
+    FNR==1 { next }
+    {
+      if ($1 in ref && ref[$1] > 0) {
+        pct = (($2 - ref[$1]) / ref[$1]) * 100;
+        if (pct >= threshold) printf "PRICE UP: %s reference $%.2f -> invoice $%.2f (+%.1f%%)\n", $1, ref[$1], $2, pct;
+      }
+    }
+  ' "{{reference_cost_csv}}" "{{latest_invoice_csv}}"
+variables:
+  reference_cost_csv:
+    default: "./reference-costs.csv"
+    description: "CSV with header row, columns: ingredient,unit_cost — your baseline/expected price per ingredient."
+  latest_invoice_csv:
+    default: "./latest-invoice.csv"
+    description: "CSV with header row, columns: ingredient,unit_cost — the same ingredients priced on this week's invoice."
+  pct_increase_threshold:
+    default: 8
+    description: Percentage increase over the reference cost that counts as worth flagging.
+compatible_agents: [generic, claude, codex]
+notes: Ingredient names must match exactly between the two CSVs (same spelling/casing) or a row won't be compared.

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/retail/markdown-aging-inventory-check.yaml

@@ -0,0 +1,33 @@
+id: markdown-aging-inventory-check
+version: 1
+name: Markdown Aging Inventory Check
+description: >
+  Flags SKUs that have sat unsold past a set number of days so they can be
+  marked down before they become dead stock. Use this if slow-moving
+  inventory has ever tied up cash for months because nobody was tracking
+  how long items had actually been sitting on the shelf.
+category: retail
+tags: [retail, inventory, markdown, aging]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn={{aging_days_threshold}} '
+    NR==1 {next}
+    {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline received_ts; close(cmd);
+      days_on_shelf = int((today - received_ts) / 86400);
+      if ($3 == "in-stock" && days_on_shelf >= warn) printf "MARKDOWN CANDIDATE: SKU %s in stock %d days (received %s)\n", $1, days_on_shelf, $2;
+    }
+  ' "{{inventory_csv}}"
+variables:
+  inventory_csv:
+    default: "./inventory-log.csv"
+    description: "CSV with header row, columns: sku,received_date(YYYY-MM-DD),status(in-stock/sold)."
+  aging_days_threshold:
+    default: 60
+    description: Days on the shelf before a SKU counts as a markdown candidate.
+compatible_agents: [generic, claude, codex]
+notes: Update inventory-log.csv status to "sold" as items move so this only ever flags genuinely aging stock.

package/jobs/sales/proposal-followup-nudge.yaml

@@ -0,0 +1,31 @@
+id: proposal-followup-nudge
+version: 1
+name: Proposal Follow-Up Nudge
+description: >
+  Checks which sent proposals/quotes have had no reply after a set number
+  of days and drafts a short follow-up nudge for each. Use this if a
+  proposal has ever gone quiet after you sent it, and only much later did
+  you realize nobody had followed up.
+category: sales
+tags: [sales, proposals, follow-up, outreach]
+schedule: "0 9 * * 1-5"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Read {{proposals_source}} and find proposals/quotes sent more than
+  {{followup_days}} days ago with no recorded reply or status change.
+  1. List each: prospect name, proposal sent date, deal value if known.
+  2. Draft a short, low-pressure follow-up message per prospect that
+     references what was proposed and asks one specific question to
+     re-open the conversation, rather than a generic "just checking in."
+  3. Skip anything already marked closed-won, closed-lost, or explicitly
+     "do not contact" in {{proposals_source}}.
+variables:
+  proposals_source:
+    default: "your CRM's proposal/quote list, or a proposals.csv with columns: prospect,sent_date,status,value"
+    description: Where sent proposals and their status live.
+  followup_days:
+    default: 5
+    description: Days of silence after sending before a proposal counts as due for a follow-up.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Draft-only — review each nudge before sending, and skip anything the prospect asked not to be contacted about.

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/support/macro-usage-staleness-check.yaml

@@ -0,0 +1,33 @@
+id: macro-usage-staleness-check
+version: 1
+name: Macro/Canned Response Staleness Check
+description: >
+  Flags saved canned responses (macros) that haven't been used in a long
+  time so someone can check whether they're still accurate. Use this if
+  a stale macro has ever gone out with outdated pricing, a dead link, or
+  a policy that changed months ago.
+category: support
+tags: [support, macros, canned-responses, knowledge-base]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn={{stale_days_threshold}} '
+    NR==1 {next}
+    {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline last_used_ts; close(cmd);
+      days_idle = int((today - last_used_ts) / 86400);
+      if (days_idle >= warn) printf "STALE MACRO: \"%s\" last used %d days ago (%s)\n", $1, days_idle, $2;
+    }
+  ' "{{macro_usage_csv}}"
+variables:
+  macro_usage_csv:
+    default: "./macro-usage-log.csv"
+    description: "CSV with header row, columns: macro_name,last_used_date(YYYY-MM-DD) — export this from your helpdesk's macro usage report."
+  stale_days_threshold:
+    default: 90
+    description: Days since last use before a macro counts as stale and worth a content review.
+compatible_agents: [generic, claude, codex]
+notes: A flagged macro isn't necessarily wrong — low usage can just mean a rare scenario — but it's worth a quick read for outdated info before it fires again.

package/jobs/team/expense-report-deadline-reminder.yaml

@@ -0,0 +1,28 @@
+id: expense-report-deadline-reminder
+version: 1
+name: Expense Report Deadline Reminder
+description: >
+  Warns you before the monthly expense report submission deadline
+  passes. Use this if you've ever missed reimbursement because the
+  expense window closed before you got around to submitting receipts.
+category: team
+tags: [team, expenses, finance, deadline]
+schedule: "0 9 * * *"
+timezone: "America/Los_Angeles"
+runner: shell
+command: >
+  today=$(date +%d); deadline={{deadline_day_of_month}};
+  days_left=$(( deadline - 10#$today ));
+  if [ "$days_left" -lt 0 ]; then echo "note: this month's deadline (day $deadline) has passed — nothing due until next month.";
+  elif [ "$days_left" -le {{warn_days_before}} ]; then
+    echo "REMINDER: expense report due in $days_left day(s), by day $deadline of this month.";
+  else echo "OK: $days_left day(s) until expense report deadline (day $deadline)."; fi
+variables:
+  deadline_day_of_month:
+    default: 25
+    description: Day of the month expense reports are due (use 1-28 for portability across months).
+  warn_days_before:
+    default: 5
+    description: Start warning this many days before the deadline.
+compatible_agents: [generic, claude, codex]
+notes: Zero-token. Assumes a fixed day-of-month deadline; adjust deadline_day_of_month if your company's cycle differs.

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/travel/hotel-cancellation-deadline-reminder.yaml

@@ -0,0 +1,32 @@
+id: hotel-cancellation-deadline-reminder
+version: 1
+name: Hotel Cancellation Deadline Reminder
+description: >
+  Warns you before a hotel booking's free-cancellation window closes.
+  Use this if you've ever gotten charged for a hotel you meant to
+  cancel because the deadline passed while you were still deciding.
+category: travel
+tags: [travel, hotel, cancellation, deadline]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  name="{{booking_name}}"; deadline={{cancellation_deadline}}; warn={{warn_hours_before}};
+  deadline_epoch=$(date -j -f "%Y-%m-%dT%H:%M" "$deadline" +%s 2>/dev/null || date -d "$deadline" +%s);
+  now_epoch=$(date +%s);
+  hours_left=$(( (deadline_epoch-now_epoch)/3600 ));
+  if [ "$hours_left" -le 0 ]; then echo "note: cancellation window for $name has passed — booking is now non-refundable (or already handled).";
+  elif [ "$hours_left" -le "$warn" ]; then echo "WARNING: free cancellation for $name closes in $hours_left hour(s) ($deadline)."; exit 1;
+  else echo "OK: $name, $hours_left hour(s) until cancellation deadline."; fi
+variables:
+  booking_name:
+    default: "hotel booking"
+    description: Name/label for this booking (hotel name or confirmation number).
+  cancellation_deadline:
+    default: "2026-12-31T23:59"
+    description: "Date and time (YYYY-MM-DDTHH:MM, local timezone) the free-cancellation window closes."
+  warn_hours_before:
+    default: 48
+    description: Start warning this many hours before the deadline.
+compatible_agents: [generic, claude, codex]
+notes: Zero-token. One job per booking — copy it and adjust for each reservation you're tracking.

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.