@wonsukchoi/crondex 0.22.0 → 0.23.0

package/jobs/hospitality/linen-inventory-turnover-check.yaml

@@ -0,0 +1,35 @@
+id: linen-inventory-turnover-check
+version: 1
+name: Linen and Laundry Inventory Turnover Check
+description: >
+  Checks par levels for linens (sheets, towels, robes) against current
+  counted stock and flags anything below par or showing an unusually
+  high loss/shrink rate versus rooms serviced. Use this if a linen
+  shortage has ever forced housekeeping to hold rooms because nobody
+  reordered before the closet ran low.
+category: hospitality
+tags: [hospitality, housekeeping, inventory, laundry]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v shrink_pct="{{max_shrink_pct}}" '
+    NR==1 {next}
+    {
+      item=$1; par=$2; on_hand=$3; sent_to_laundry=$4; returned=$5;
+      if (on_hand < par) printf "BELOW PAR: %s — %d on hand, par %d\n", item, on_hand, par;
+      if (sent_to_laundry > 0) {
+        loss_pct = ((sent_to_laundry - returned) / sent_to_laundry) * 100;
+        if (loss_pct > shrink_pct) printf "HIGH SHRINK: %s — sent %d, returned %d (%.1f%% loss, threshold %.0f%%)\n", item, sent_to_laundry, returned, loss_pct, shrink_pct;
+      }
+    }
+  ' "{{linen_inventory_csv}}"
+variables:
+  linen_inventory_csv:
+    default: "./linen-inventory.csv"
+    description: "CSV with header row, columns: item_name,par_level,on_hand_count,sent_to_laundry_count,returned_count — one row per linen category (sheets, towels, robes, etc.)."
+  max_shrink_pct:
+    default: 5
+    description: Acceptable loss percentage between linens sent to laundry and returned before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Count on a consistent cycle (weekly recommended) so par-level and shrink comparisons are apples to apples; persistent high shrink on one item often points to an outside laundry vendor issue.

package/jobs/hospitality/loyalty-points-reconciliation-check.yaml

@@ -0,0 +1,33 @@
+id: loyalty-points-reconciliation-check
+version: 1
+name: Loyalty Program Points Reconciliation Check
+description: >
+  Compares points earned per stay against your program's accrual rate
+  and flags stays where the posted points don't match, plus any member
+  who crossed a tier threshold but hasn't been re-tiered yet. Use this
+  if a loyalty member has ever been shorted points from a PMS integration
+  glitch, or hit Gold status and kept getting Silver-level perks for months.
+category: hospitality
+tags: [hospitality, loyalty-program, guest-experience, revenue-assurance]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v rate="{{points_per_dollar}}" '
+    NR==1 {next}
+    {
+      expected = $3 * rate;
+      diff = $4 - expected;
+      if (diff < 0) diff = -diff;
+      if (diff > 1) printf "MISMATCH: member %s, stay %s — expected %.0f pts, posted %.0f pts\n", $1, $2, expected, $4;
+    }
+  ' "{{stays_points_csv}}"
+variables:
+  stays_points_csv:
+    default: "./loyalty-stays-points.csv"
+    description: "CSV with header row, columns: member_id,folio_id,eligible_spend_usd,points_posted."
+  points_per_dollar:
+    default: 10
+    description: Program's points-earned-per-dollar-spent accrual rate.
+compatible_agents: [generic, claude, codex]
+notes: Tier-threshold re-classification is a separate check worth pairing with this — export current tier alongside year-to-date qualifying nights/spend and compare against your program's tier cutoffs.

package/jobs/hospitality/minibar-charge-reconciliation-check.yaml

@@ -0,0 +1,38 @@
+id: minibar-charge-reconciliation-check
+version: 1
+name: Minibar Charge Reconciliation Check
+description: >
+  Compares housekeeping's logged minibar restocks against folio charges
+  posted for the same room and flags mismatches. Use this if a restocked
+  minibar has ever gone uncharged, or a guest was charged for an item
+  housekeeping never actually replaced.
+category: hospitality
+tags: [hospitality, minibar, revenue-assurance, front-desk]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    FNR==NR {
+      if (FNR > 1) restocked[$1] += $3;
+      next;
+    }
+    FNR==1 {next}
+    { charged[$1] += $3 }
+    END {
+      for (room in restocked) {
+        r = restocked[room] + 0; c = charged[room] + 0;
+        if (r != c) printf "MISMATCH: room %s — restocked $%.2f, charged $%.2f\n", room, r, c;
+      }
+      for (room in charged) if (!(room in restocked)) printf "UNMATCHED CHARGE: room %s — charged $%.2f with no restock logged\n", room, charged[room];
+    }
+  ' "{{restock_log_csv}}" "{{folio_charges_csv}}"
+variables:
+  restock_log_csv:
+    default: "./minibar-restock-log.csv"
+    description: "CSV with header row, columns: room_number,date,amount_usd — housekeeping's logged minibar restocks."
+  folio_charges_csv:
+    default: "./minibar-folio-charges.csv"
+    description: "CSV with header row, columns: room_number,date,amount_usd — minibar charges posted to guest folios."
+compatible_agents: [generic, claude, codex]
+notes: Assumes both CSVs cover the same date range; a mismatch doesn't always mean fraud — could be a delayed post or a comped item, so verify before adjusting a folio.

package/jobs/hospitality/occupancy-forecast-variance-check.yaml

@@ -0,0 +1,33 @@
+id: occupancy-forecast-variance-check
+version: 1
+name: Occupancy Forecast Variance Check
+description: >
+  Compares this week's forecasted occupancy against actual rooms sold and
+  flags a meaningful gap in either direction. Use this if a forecast has
+  ever been quietly wrong for weeks, leaving staffing either overbooked
+  on labor during a slow stretch or short-staffed during a rush nobody
+  planned for.
+category: hospitality
+tags: [hospitality, revenue-management, forecasting, staffing]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v tol="{{tolerance_pct}}" '
+    NR==1 {next}
+    {
+      diff = $3 - $2;
+      pct = ($2 > 0) ? (diff / $2) * 100 : 0;
+      if (pct < 0) pct = -pct;
+      if (pct > tol) printf "VARIANCE: %s forecast %d%%, actual %d%% (%.1f pts off, tolerance %.0f)\n", $1, $2, $3, diff, tol;
+    }
+  ' "{{forecast_vs_actual_csv}}"
+variables:
+  forecast_vs_actual_csv:
+    default: "./occupancy-forecast-vs-actual.csv"
+    description: "CSV with header row, columns: date,forecast_occupancy_pct,actual_occupancy_pct."
+  tolerance_pct:
+    default: 8
+    description: Percentage-point gap between forecast and actual occupancy before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Feed this from your revenue management system's forecast export alongside actual rooms-sold data — use recurring misses to recalibrate the forecasting model, not just a one-off flag.

package/jobs/hospitality/ota-rate-parity-check.yaml

@@ -0,0 +1,36 @@
+id: ota-rate-parity-check
+version: 1
+name: OTA Rate Parity Check
+description: >
+  Compares your listed room rates across OTAs (Booking.com, Expedia, etc.)
+  against your direct-booking rate and flags any channel undercutting you.
+  Use this if an OTA has ever quietly shown a lower rate than your own
+  website, driving bookings away from your cheapest channel.
+category: hospitality
+tags: [hospitality, revenue-management, ota, rate-parity]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check today's rate for {{room_type}} on {{ota_platforms}} and compare
+  each against the direct rate of {{direct_rate_usd}} on your own booking
+  site.
+  1. List each platform's displayed rate side by side with the direct rate.
+  2. Flag any OTA showing a rate at or below the direct rate — that's a
+     parity violation worth chasing with the channel manager or OTA.
+  3. Note any OTA showing an unusually high rate too, since that can also
+     hurt bookings if it's a stale/unsynced price.
+  4. Suggest whether the direct rate, the channel manager mapping, or a
+     stale OTA cache is the likely cause for any mismatch found.
+variables:
+  room_type:
+    default: "Standard Queen"
+    description: Room type/rate plan to compare across channels.
+  ota_platforms:
+    default: "Booking.com, Expedia, Hotels.com"
+    description: Comma-separated list of OTA platforms to check.
+  direct_rate_usd:
+    default: 189
+    description: Your current direct-booking rate in USD for the room type/date checked.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only comparison — fixing a parity violation usually means updating your channel manager or contacting the OTA's rate-parity team.

package/jobs/hospitality/overbooking-risk-alert.yaml

@@ -0,0 +1,38 @@
+id: overbooking-risk-alert
+version: 1
+name: Overbooking Risk Alert
+description: >
+  Compares confirmed reservations for each upcoming night against total
+  available rooms and flags nights where bookings exceed inventory. Use
+  this if an intentional overbooking cushion has ever tipped into an
+  actual walked guest because nobody was watching the running total as
+  last-minute bookings came in.
+category: hospitality
+tags: [hospitality, front-desk, overbooking, reservations]
+schedule: "0 */6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v rooms="{{total_rooms}}" -v cushion="{{overbook_cushion}}" '
+    NR==1 {next}
+    { booked[$1] += 1 }
+    END {
+      for (date in booked) {
+        limit = rooms + cushion;
+        if (booked[date] > limit) printf "OVERBOOKED: %s — %d bookings vs %d rooms (+%d cushion)\n", date, booked[date], rooms, cushion;
+        else if (booked[date] > rooms) printf "WITHIN CUSHION: %s — %d bookings vs %d rooms (using overbook cushion)\n", date, booked[date], rooms;
+      }
+    }
+  ' "{{reservations_by_night_csv}}"
+variables:
+  reservations_by_night_csv:
+    default: "./reservations-by-night.csv"
+    description: "CSV with header row, columns: stay_date,reservation_id — one row per room-night reserved (confirmed status only)."
+  total_rooms:
+    default: 100
+    description: Total available rooms in the property.
+  overbook_cushion:
+    default: 3
+    description: Intentional overbooking cushion above total rooms before a night counts as at-risk of a walk.
+compatible_agents: [generic, claude, codex]
+notes: A count over total_rooms but within the cushion is expected/intentional; only counts exceeding rooms + cushion need a walk plan (relocation agreement with a nearby property) lined up.

package/jobs/hospitality/room-maintenance-work-order-tracker.yaml

@@ -0,0 +1,31 @@
+id: room-maintenance-work-order-tracker
+version: 1
+name: Preventive Maintenance Work Order Tracker
+description: >
+  Checks scheduled preventive maintenance work orders (HVAC service,
+  fire safety checks, deep cleans) against their due dates and flags any
+  overdue or rooms that have gone too long without a PM cycle. Use this
+  if a room has ever gone a full year without its scheduled HVAC or
+  safety check because it only got attention when something broke.
+category: hospitality
+tags: [hospitality, maintenance, preventive, compliance]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    {
+      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);
+      days_over = (today - due_epoch) / 86400;
+      if (days_over > 0) printf "OVERDUE: room/area %s — %s work order due %s (%d days overdue)\n", $1, $2, $3, days_over;
+    }
+  ' "{{pm_schedule_csv}}"
+variables:
+  pm_schedule_csv:
+    default: "./pm-work-orders.csv"
+    description: "CSV with header row, columns: room_or_area,work_order_type,due_date (YYYY-MM-DD) — one row per open preventive maintenance work order."
+compatible_agents: [generic, claude, codex]
+notes: Distinct from guest-maintenance-request-backlog-check, which tracks guest-reported issues — this tracks scheduled/preventive work orders (PM cycles) that exist whether or not a guest complains.

package/jobs/hospitality/upsell-upgrade-conversion-tracker.yaml

@@ -0,0 +1,37 @@
+id: upsell-upgrade-conversion-tracker
+version: 1
+name: Room Upsell and Upgrade Conversion Tracker
+description: >
+  Analyzes offered room upgrades and add-on upsells (early check-in, view
+  upgrade, breakfast package) against how many guests accepted, broken
+  down by channel and shift. Use this if front desk upsell offers have
+  ever quietly tapered off because nobody was tracking whether the team
+  was actually still asking.
+category: hospitality
+tags: [hospitality, revenue-management, upsell, front-desk]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull upsell/upgrade offer logs from {{pms_or_upsell_platform}} for the
+  past {{lookback_days}} days.
+  1. Calculate overall conversion rate (accepted / offered) for each
+     upsell type (room upgrade, early check-in, late checkout, breakfast
+     package, etc.).
+  2. Break the conversion rate down by shift or agent group if that data
+     exists, and flag any shift with a rate meaningfully below the
+     property average.
+  3. Flag any upsell type with an offer count that's dropped sharply
+     versus the prior period — that usually means staff stopped asking,
+     not that demand dried up.
+  4. Estimate incremental revenue if the lowest-converting shift matched
+     the property average.
+variables:
+  pms_or_upsell_platform:
+    default: "your PMS or upsell platform"
+    description: System logging upsell offers and outcomes (e.g. "Oracle OPERA", "Zingle", "Duetto").
+  lookback_days:
+    default: 30
+    description: Window of upsell data to analyze.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Useful as a coaching input for front desk shift leads, not a scorecard for individual write-ups.

package/jobs/insurance/adjuster-caseload-balance-check.yaml

@@ -0,0 +1,45 @@
+id: adjuster-caseload-balance-check
+version: 1
+name: Adjuster Caseload Balance Check
+description: >
+  Counts open claims assigned per adjuster and flags anyone carrying a
+  caseload well above the team average, so work can be redistributed
+  before it hurts claim cycle time. Use this if one adjuster has ever
+  quietly ended up with double the caseload of everyone else on the team.
+category: insurance
+tags: [insurance, claims, adjuster, caseload, operations]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v overload="{{overload_multiplier}}" '
+    NR==1 {next}
+    {
+      count[$2]++;
+      total++;
+      n_adjusters[$2]=1;
+    }
+    END {
+      n=0;
+      for (a in n_adjusters) n++;
+      avg = (n > 0) ? total / n : 0;
+      printf "CASELOAD SUMMARY: %d open claims across %d adjusters (avg %.1f)\n", total, n, avg;
+      for (a in count) {
+        if (avg > 0 && count[a] > avg * overload) {
+          printf "OVERLOADED: %s — %d open claims (avg %.1f)\n", a, count[a], avg;
+        }
+      }
+    }
+  ' "{{open_claims_by_adjuster_csv}}"
+variables:
+  open_claims_by_adjuster_csv:
+    default: "./open-claims-by-adjuster.csv"
+    description: "Path to a CSV with columns: claim_number,adjuster_name — one row per open claim."
+  overload_multiplier:
+    default: 1.5
+    description: How many times the team average caseload counts as overloaded (e.g. 1.5 = 50% above average).
+compatible_agents: [generic, claude, codex]
+notes: >
+  Staffing-balance check across a claims team, distinct from
+  claims-aging-backlog-tracker which looks at claim age rather than
+  who's handling how many claims.

package/jobs/insurance/agent-broker-license-expiry-tracker.yaml

@@ -0,0 +1,40 @@
+id: agent-broker-license-expiry-tracker
+version: 1
+name: Agent/Broker License Expiry Tracker
+description: >
+  Checks producer (agent/broker) license and appointment expiration dates
+  across every state they're licensed in and flags anything expiring
+  soon. Use this if an agent has ever kept writing business in a state
+  after their license quietly lapsed.
+category: insurance
+tags: [insurance, agent, broker, license, compliance]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline expiry_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (expiry_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        status = (diff_days < 0) ? "EXPIRED" : "EXPIRING";
+        printf "%s: %s — %s license/appointment in %s expires %s (%d days)\n", status, $1, $2, $2, $3, diff_days;
+      }
+    }
+  ' "{{producer_licenses_csv_path}}"
+variables:
+  producer_licenses_csv_path:
+    default: "./producer-licenses.csv"
+    description: "Path to a CSV with columns: producer_name,state,expiry_date (YYYY-MM-DD) — one row per state license/appointment."
+  warn_days_before:
+    default: 45
+    description: How many days before a license or appointment expiry to start warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Tracks producer (selling agent/broker) licensing compliance across an
+  agency or MGA's distribution force — distinct from
+  certificate-of-insurance-request-check, which tracks COI requests, not
+  producer licensure.

package/jobs/insurance/cat-event-exposure-monitor.yaml

@@ -0,0 +1,37 @@
+id: cat-event-exposure-monitor
+version: 1
+name: Catastrophe Event Exposure Monitor
+description: >
+  Cross-references active policies against a catastrophe (hurricane,
+  wildfire, earthquake, flood) event footprint and estimates
+  policy-count and total insured value exposure inside the impact zone.
+  Use this if a CAT event has ever hit before anyone had a fast answer to
+  "how many policies do we have in that area, and what's our exposure."
+category: insurance
+tags: [insurance, catastrophe, cat, exposure, risk]
+schedule: "0 */6 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Given the active/forecast catastrophe event: {{cat_event_description}},
+  and the policy exposure summary: {{policy_exposure_summary}}.
+  1. Estimate how many policies and how much total insured value fall
+     within or near the event's impact footprint.
+  2. Break this down by line of business (property, auto, etc.) if the
+     exposure data allows it.
+  3. Flag any single large-limit policy that falls inside the footprint
+     for individual review.
+  4. Note this is a rough triage estimate for readiness/response
+     planning, not a final claims or reserve figure.
+variables:
+  cat_event_description:
+    default: "describe the catastrophe event and its current/forecast footprint here"
+    description: Name, type, and geographic footprint of the catastrophe event being tracked.
+  policy_exposure_summary:
+    default: "paste or summarize policy counts and insured values by geography here"
+    description: Summary of active policy counts and total insured value by geography/line of business.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Pre/during-event exposure estimation for claims and reinsurance
+  readiness planning — distinct from claims-aging-backlog-tracker, which
+  tracks already-filed claims rather than pre-loss exposure.

package/jobs/insurance/claims-aging-backlog-tracker.yaml

@@ -0,0 +1,48 @@
+id: claims-aging-backlog-tracker
+version: 1
+name: Claims Aging & Backlog Tracker
+description: >
+  Buckets open claims by how long they've been open (0-30, 31-60, 61-90,
+  90+ days) and flags any bucket that's grown past target so a claims
+  manager can rebalance the queue. Use this if a backlog of aging claims
+  has ever crept up gradually until a regulator or auditor asked why so
+  many were still open past 90 days.
+category: insurance
+tags: [insurance, claims, aging, backlog, operations]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v cap90="{{max_90plus_pct}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline opened_epoch; close(cmd);
+      age_days = (today - opened_epoch) / 86400;
+      total++;
+      if (age_days <= 30) b30++;
+      else if (age_days <= 60) b60++;
+      else if (age_days <= 90) b90++;
+      else b90plus++;
+    }
+    END {
+      printf "AGING SUMMARY: 0-30d=%d 31-60d=%d 61-90d=%d 90d+=%d (total=%d)\n", b30, b60, b90, b90plus, total;
+      pct90plus = (total > 0) ? (b90plus / total) * 100 : 0;
+      if (pct90plus > cap90) {
+        printf "OVER TARGET: %.1f%% of open claims are 90+ days old (cap %d%%)\n", pct90plus, cap90;
+      }
+    }
+  ' "{{open_claims_csv_path}}"
+variables:
+  open_claims_csv_path:
+    default: "./open-claims.csv"
+    description: "Path to a CSV with columns: claim_number,date_opened (YYYY-MM-DD)."
+  max_90plus_pct:
+    default: 10
+    description: Maximum acceptable percentage of open claims sitting at 90+ days before this counts as over target.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Portfolio-level aging distribution for a claims team, distinct from
+  claim-status-check which follows up on individual stale claims for a
+  single policyholder.

package/jobs/insurance/doi-filing-deadline-tracker.yaml

@@ -0,0 +1,42 @@
+id: doi-filing-deadline-tracker
+version: 1
+name: State DOI Regulatory Filing Deadline Tracker
+description: >
+  Warns before a state Department of Insurance filing deadline (rate
+  filings, annual statements, market conduct reports) so nothing gets
+  submitted late. Use this if a regulatory filing has ever gone out late
+  because the deadline lived only in one compliance person's memory.
+category: insurance
+tags: [insurance, compliance, regulatory, doi, filing]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    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 due_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (due_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        status = (diff_days < 0) ? "OVERDUE" : "DUE SOON";
+        printf "%s: %s — %s filing due %s (%d days)\n", status, $1, $2, $3, diff_days;
+      }
+    }
+  ' "{{doi_filings_csv_path}}"
+variables:
+  doi_filings_csv_path:
+    default: "./doi-filings.csv"
+    description: "Path to a CSV with columns: state,filing_type,due_date (YYYY-MM-DD),filed_date (blank if not yet filed)."
+  warn_days_before:
+    default: 21
+    description: How many days before a filing deadline to start warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Regulatory filing deadlines owed to state insurance regulators —
+  distinct from legal's compliance-filing-deadline-reminder, which is a
+  generic cross-industry filing tracker; this one is scoped specifically
+  to insurance-department filings (rate filings, annual statements,
+  market conduct reports).

package/jobs/insurance/loss-ratio-by-line-monitor.yaml

@@ -0,0 +1,43 @@
+id: loss-ratio-by-line-monitor
+version: 1
+name: Loss Ratio by Line of Business Monitor
+description: >
+  Calculates the incurred loss ratio for each line of business and flags
+  any line running hotter than target, so underwriting or pricing can
+  react before a bad quarter turns into a bad year. Use this if a line's
+  loss ratio has ever drifted well past target for months before anyone
+  noticed in the numbers.
+category: insurance
+tags: [insurance, loss-ratio, underwriting, finance]
+schedule: "0 7 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target="{{target_loss_ratio_pct}}" '
+    NR==1 {next}
+    {
+      earned[$1] += $2;
+      incurred[$1] += $3;
+    }
+    END {
+      for (line in earned) {
+        if (earned[line] > 0) {
+          ratio = (incurred[line] / earned[line]) * 100;
+          flag = (ratio > target) ? " OVER TARGET" : "";
+          printf "%s: loss ratio %.1f%%%s (earned %.2f, incurred %.2f)\n", line, ratio, flag, earned[line], incurred[line];
+        }
+      }
+    }
+  ' "{{loss_ratio_csv_path}}"
+variables:
+  loss_ratio_csv_path:
+    default: "./loss-ratio-by-line.csv"
+    description: "Path to a CSV with columns: line_of_business,earned_premium,incurred_losses — one row per period/line entry, aggregated across the current reporting period."
+  target_loss_ratio_pct:
+    default: 65
+    description: Target maximum loss ratio percentage per line of business before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Financial performance monitoring by line of business for underwriting
+  and actuarial review — distinct from claims-aging-backlog-tracker,
+  which tracks claim handling speed rather than loss cost.

package/jobs/insurance/policy-lapse-rate-monitor.yaml

@@ -0,0 +1,41 @@
+id: policy-lapse-rate-monitor
+version: 1
+name: Policy Cancellation & Lapse Rate Monitor
+description: >
+  Calculates the weekly policy cancellation/lapse rate and flags it when
+  it climbs past a healthy baseline, so retention teams can react before
+  a leaky book turns into a shrinking one. Use this if a rising lapse
+  rate has ever gone unnoticed until a quarterly report showed the book
+  had quietly shrunk.
+category: insurance
+tags: [insurance, retention, lapse, cancellation, operations]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v baseline="{{baseline_lapse_pct}}" '
+    NR==1 {next}
+    {
+      total++;
+      if ($2 == "cancelled" || $2 == "lapsed") lapsed++;
+    }
+    END {
+      pct = (total > 0) ? (lapsed / total) * 100 : 0;
+      printf "LAPSE RATE: %.1f%% (%d of %d policies) — baseline %d%%\n", pct, lapsed, total, baseline;
+      if (pct > baseline) {
+        printf "ABOVE BASELINE: lapse rate exceeds the %d%% target\n", baseline;
+      }
+    }
+  ' "{{policy_status_csv_path}}"
+variables:
+  policy_status_csv_path:
+    default: "./policy-status-weekly.csv"
+    description: "Path to a CSV with columns: policy_number,status (active/cancelled/lapsed) for the current reporting period's book."
+  baseline_lapse_pct:
+    default: 8
+    description: Baseline acceptable cancellation/lapse rate percentage before it's flagged as elevated.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Book-wide retention health metric, distinct from
+  premium-payment-delinquency-tracker, which flags individual accounts
+  rather than the aggregate lapse trend.

package/jobs/insurance/premium-payment-delinquency-tracker.yaml

@@ -0,0 +1,42 @@
+id: premium-payment-delinquency-tracker
+version: 1
+name: Premium Payment Delinquency Tracker
+description: >
+  Scans the book of business for policyholders past due on premium
+  payments and flags accounts approaching cancellation-for-nonpayment, so
+  collections or retention outreach can happen before a policy lapses.
+  Use this if delinquent accounts have ever piled up unnoticed until a
+  batch of policies cancelled all at once.
+category: insurance
+tags: [insurance, premium, delinquency, collections, retention]
+schedule: "0 7 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v cancel_days="{{cancellation_grace_days}}" '
+    NR==1 {next}
+    $3 != "unpaid" {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      past_due_days = (today - due_epoch) / 86400;
+      if (past_due_days > 0) {
+        remaining = cancel_days - past_due_days;
+        status = (remaining <= 0) ? "CANCELLATION ELIGIBLE" : sprintf("%d days until cancellation-eligible", remaining);
+        printf "DELINQUENT: %s — due %s, %d days past due — %s\n", $1, $2, past_due_days, status;
+      }
+    }
+  ' "{{book_of_business_csv_path}}"
+variables:
+  book_of_business_csv_path:
+    default: "./premium-payment-status.csv"
+    description: "Path to a CSV with columns: policy_number,payment_due_date (YYYY-MM-DD),status (paid/unpaid)."
+  cancellation_grace_days:
+    default: 30
+    description: Days past due before a policy becomes eligible for cancellation-for-nonpayment.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Book-wide delinquency and collections view across many policyholders,
+  distinct from premium-payment-due-reminder, which reminds a single
+  policyholder about their own upcoming payment before it's even late.