@wonsukchoi/crondex 0.22.0 → 0.23.0

package/jobs/education/standardized-test-registration-deadline-check.yaml

@@ -0,0 +1,35 @@
+id: standardized-test-registration-deadline-check
+version: 1
+name: Standardized Test Registration Deadline Check
+description: >
+  Warns before the registration cutoff for a standardized test (state
+  assessment, AP, SAT, etc.). Use this if a student has ever missed the
+  window to register for a test because the deadline landed during a busy
+  stretch of the term and nobody flagged it in advance.
+category: education
+tags: [education, testing, deadlines]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  due_ts=$(date -d "{{registration_deadline}}" +%s 2>/dev/null || date -jf "%Y-%m-%d" "{{registration_deadline}}" +%s);
+  days_left=$(( (due_ts - today) / 86400 ));
+  if [ "$days_left" -le "{{warn_days}}" ] && [ "$days_left" -ge 0 ]; then
+    echo "WARNING: {{test_name}} registration closes in $days_left days ({{registration_deadline}})";
+    exit 1;
+  else
+    echo "OK: {{test_name}} registration closes in $days_left days";
+  fi
+variables:
+  test_name:
+    default: "state standardized assessment"
+    description: Name of the test whose registration window this tracks.
+  registration_deadline:
+    default: "2026-12-15"
+    description: Registration cutoff date (YYYY-MM-DD).
+  warn_days:
+    default: 10
+    description: Days before the deadline to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Run one instance per test/deadline you need to track — AP, SAT, and state assessments usually have different windows.

package/jobs/education/substitute-teacher-fill-rate-tracker.yaml

@@ -0,0 +1,35 @@
+id: substitute-teacher-fill-rate-tracker
+version: 1
+name: Substitute Teacher Fill Rate Tracker
+description: >
+  Compares substitute requests against how many were actually filled and
+  flags days or schools with a low fill rate. Use this if classes have
+  ever gone uncovered because nobody was tracking whether sub requests
+  were actually getting filled.
+category: education
+tags: [education, staffing, substitute-teachers]
+schedule: "0 6 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v minRate="{{min_fill_rate_pct}}" '
+    NR==1 {next}
+    { requested[$1] += 1; if ($3 == "filled") filled[$1] += 1; }
+    END {
+      for (school in requested) {
+        rate = (filled[school] / requested[school]) * 100;
+        if (rate < minRate) {
+          printf "LOW FILL RATE: %s — %.1f%% (%d/%d requests filled)\n", school, rate, filled[school], requested[school];
+        }
+      }
+    }
+  ' "{{sub_requests_csv_path}}"
+variables:
+  sub_requests_csv_path:
+    default: "./sub-requests.csv"
+    description: "Path to a CSV with columns: school,request_date,status (filled or unfilled)."
+  min_fill_rate_pct:
+    default: 85
+    description: Fill rate percentage below which a school is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Run this early in the morning before the school day starts so unfilled slots can still be covered.

package/jobs/education/teacher-certification-expiry-tracker.yaml

@@ -0,0 +1,35 @@
+id: teacher-certification-expiry-tracker
+version: 1
+name: Teacher Certification Expiry Tracker
+description: >
+  Checks teaching certifications and endorsements against their renewal
+  dates and flags anything expiring soon. Use this if a teacher has ever
+  had their state license lapse mid-year because the renewal deadline
+  wasn't on anyone's radar until an audit or licensing-board notice.
+category: education
+tags: [education, staff, certification, compliance]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review teaching certification/endorsement records from
+  {{credentialing_system_hint}} for all instructional staff.
+  1. List any certification or endorsement expiring within
+     {{warn_days}} days.
+  2. Separate staff whose core teaching license is expiring (cannot
+     legally teach without it) from those with a secondary endorsement
+     lapsing (may still teach, but affects course assignments).
+  3. Note any continuing-education or renewal-credit requirements that
+     still need to be completed before the deadline, if that data is
+     available.
+  4. Summarize so HR/administration can start the renewal process with
+     enough lead time.
+variables:
+  credentialing_system_hint:
+    default: "your state licensing portal or HR credentialing system"
+    description: Where certification/endorsement records and expiration dates live.
+  warn_days:
+    default: 60
+    description: Days before expiration to start warning — certification renewals often take longer than typical HR paperwork.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Distinct from general HR compliance training tracking — this is specifically about the state teaching license/endorsements required to legally hold a classroom assignment.

package/jobs/education/textbook-inventory-shortage-check.yaml

@@ -0,0 +1,32 @@
+id: textbook-inventory-shortage-check
+version: 1
+name: Textbook Inventory Shortage Check
+description: >
+  Compares textbook/material stock counts against enrolled class sizes and
+  flags courses that are short. Use this if a class has ever started the
+  term with more students than available textbooks because nobody checked
+  inventory against the roster ahead of time.
+category: education
+tags: [education, inventory, textbooks, materials]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v buffer="{{buffer_copies}}" '
+    NR==1 {next}
+    {
+      needed = $2 + buffer;
+      if ($3 < needed) {
+        printf "SHORTAGE: %s — %d in stock, %d needed (%d enrolled + %d buffer)\n", $1, $3, needed, $2, buffer;
+      }
+    }
+  ' "{{inventory_csv_path}}"
+variables:
+  inventory_csv_path:
+    default: "./textbook-inventory.csv"
+    description: "Path to a CSV with columns: course_title,enrolled_count,copies_in_stock."
+  buffer_copies:
+    default: 3
+    description: Extra copies to keep on hand beyond the enrolled count.
+compatible_agents: [generic, claude, codex]
+notes: Run this before the start of term and again a few weeks in, since enrollment (and thus the shortfall) can shift after add/drop.

package/jobs/fleet/accident-incident-report-tracker.yaml

@@ -0,0 +1,34 @@
+id: accident-incident-report-tracker
+version: 1
+name: Accident/Incident Report Tracker
+description: >
+  Flags open accident or incident reports that have gone too long without
+  being closed out. Use this if a fender-bender report has ever sat
+  unresolved for weeks because nobody was tracking it after the initial
+  paperwork was filed.
+category: fleet
+tags: [fleet, safety, incidents, compliance]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v max_days="{{max_open_days}}" '
+    NR==1 {next}
+    $4 == "open" {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline reported_ts; close(cmd);
+      days_open = int((today - reported_ts) / 86400);
+      if (days_open >= max_days)
+        print "STALE REPORT: vehicle " $1 " incident reported " $2 " (" days_open " days open, driver " $3 ")";
+    }
+  ' "{{incidents_csv_path}}"
+variables:
+  incidents_csv_path:
+    default: "./fleet-incidents.csv"
+    description: "Path to a CSV with columns: vehicle_id,reported_date(YYYY-MM-DD),driver_name,status(open/closed)."
+  max_open_days:
+    default: 10
+    description: Days an incident can stay open before it's flagged as stale.
+compatible_agents: [generic, claude, codex]
+notes: Tracks report closure aging, not the claim payout itself — see `fleet-insurance-expiry-check` for policy coverage lapses.

package/jobs/fleet/driver-mvr-review-tracker.yaml

@@ -0,0 +1,34 @@
+id: driver-mvr-review-tracker
+version: 1
+name: Driver MVR Review Tracker
+description: >
+  Tracks when each driver's motor vehicle record (MVR) was last pulled and
+  reviewed, and flags drivers overdue for their periodic re-check. Use
+  this if a driver has ever kept racking up points or violations on their
+  record for a year or more before anyone at the company noticed.
+category: fleet
+tags: [fleet, drivers, mvr, compliance]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v max_days="{{max_days_since_review}}" '
+    NR==1 {next}
+    {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline last_ts; close(cmd);
+      days_since = int((today - last_ts) / 86400);
+      if (days_since >= max_days)
+        print "MVR REVIEW OVERDUE: " $1 " — last pulled " $2 " (" days_since " days ago)";
+    }
+  ' "{{mvr_review_csv_path}}"
+variables:
+  mvr_review_csv_path:
+    default: "./driver-mvr-reviews.csv"
+    description: "Path to a CSV with columns: driver_name,last_mvr_pull_date(YYYY-MM-DD)."
+  max_days_since_review:
+    default: 365
+    description: Days since a driver's last MVR pull before it's flagged as overdue for a re-check.
+compatible_agents: [generic, claude, codex]
+notes: Tracks the periodic driving-record re-check cadence, distinct from `driver-license-cdl-expiry-check`, which tracks license/CDL expiry dates specifically.

package/jobs/fleet/driver-safety-score-monitor.yaml

@@ -0,0 +1,39 @@
+id: driver-safety-score-monitor
+version: 1
+name: Driver Safety Score Monitor
+description: >
+  Reviews telematics-derived driver safety scores (harsh braking, hard
+  acceleration, speeding events) and flags drivers trending toward risky
+  behavior. Use this if a driver's habits have ever gone unaddressed until
+  an accident or a spiked insurance premium made it impossible to ignore.
+category: fleet
+tags: [fleet, drivers, safety, telematics]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull this week's driver safety scorecards from {{telematics_provider_hint}}
+  for all tracked drivers.
+  1. Flag any driver whose composite safety score fell below
+     {{min_safety_score}} (0-100 scale).
+  2. Flag any driver with more than {{max_harsh_events}} combined harsh
+     braking/hard acceleration/speeding events this week.
+  3. Note drivers trending downward over the last {{trend_weeks}} weeks even
+     if still above threshold.
+  4. Report flagged drivers with score, event counts, and week-over-week
+     trend so a manager can decide on coaching.
+variables:
+  telematics_provider_hint:
+    default: "your telematics/GPS provider (Samsara, Motive, Geotab, etc.)"
+    description: Name of the telematics provider/portal driver scorecards come from.
+  min_safety_score:
+    default: 70
+    description: Composite safety score (0-100) below which a driver is flagged.
+  max_harsh_events:
+    default: 5
+    description: Combined harsh-driving events per week that triggers a flag.
+  trend_weeks:
+    default: 4
+    description: Number of trailing weeks to check for a declining trend.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — telematics scorecard formats vary by provider and trend judgment benefits from an agent rather than a fixed CSV parse. Distinct from `vehicle-idle-time-check`, which tracks fuel waste, not driving behavior.

package/jobs/fleet/ev-battery-health-check.yaml

@@ -0,0 +1,36 @@
+id: ev-battery-health-check
+version: 1
+name: EV Battery Health & Charging Check
+description: >
+  Checks electric fleet vehicles' battery state-of-health and charging
+  session logs, flagging vehicles with degrading batteries or charging
+  problems. Use this if an EV has ever shown up for a route with far less
+  range than expected because nobody was watching battery degradation
+  between scheduled services.
+category: fleet
+tags: [fleet, ev, battery, charging]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min_soh="{{min_battery_soh_pct}}" -v max_hours="{{max_hours_since_charge}}" '
+    NR==1 {next}
+    {
+      if ($2 < min_soh)
+        printf "DEGRADED BATTERY: vehicle %s — %s%% state of health (min %s%%)\n", $1, $2, min_soh;
+      if ($3 > max_hours)
+        printf "NOT CHARGED: vehicle %s — %s hours since last charge (max %s)\n", $1, $3, max_hours;
+    }
+  ' "{{ev_fleet_csv_path}}"
+variables:
+  ev_fleet_csv_path:
+    default: "./ev-fleet-status.csv"
+    description: "Path to a CSV with columns: vehicle_id,battery_soh_pct,hours_since_last_charge."
+  min_battery_soh_pct:
+    default: 80
+    description: Battery state-of-health percentage below which a vehicle is flagged for degradation review.
+  max_hours_since_charge:
+    default: 24
+    description: Hours since last charging session before a vehicle is flagged as possibly not charging on schedule.
+compatible_agents: [generic, claude, codex]
+notes: Requires an EV telematics/charging-network export with state-of-health and last-charge data; format varies by provider (Ford Pro, Geotab EV, ChargePoint, etc.).

package/jobs/fleet/fuel-efficiency-trend-monitor.yaml

@@ -0,0 +1,33 @@
+id: fuel-efficiency-trend-monitor
+version: 1
+name: Fuel Efficiency Trend Monitor
+description: >
+  Tracks each vehicle's miles-per-gallon (or equivalent) trend over time
+  and flags vehicles losing efficiency, which often signals a mechanical
+  problem before it shows up as a breakdown. Use this if a vehicle's fuel
+  costs have ever crept up for months before a mechanic found the actual
+  cause.
+category: fleet
+tags: [fleet, fuel, efficiency, maintenance]
+schedule: "0 7 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v drop_pct="{{efficiency_drop_pct}}" '
+    NR==1 {next}
+    {
+      baseline=$2; current=$3;
+      drop = ((baseline - current) / baseline) * 100;
+      if (drop >= drop_pct)
+        printf "EFFICIENCY DROP: vehicle %s — %.1f%% below baseline (%.1f -> %.1f mpg)\n", $1, drop, baseline, current;
+    }
+  ' "{{fuel_efficiency_csv_path}}"
+variables:
+  fuel_efficiency_csv_path:
+    default: "./fleet-fuel-efficiency.csv"
+    description: "Path to a monthly CSV with columns: vehicle_id,baseline_mpg,current_month_mpg."
+  efficiency_drop_pct:
+    default: 15
+    description: Percentage drop from baseline mpg before a vehicle is flagged for a possible mechanical issue.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from `fuel-card-anomaly-check` (fraud/misuse in individual transactions) and `vehicle-idle-time-check` (fuel burned while stationary) — this tracks actual driving efficiency degradation over time.

package/jobs/fleet/geofence-violation-check.yaml

@@ -0,0 +1,37 @@
+id: geofence-violation-check
+version: 1
+name: GPS Geofence Violation Check
+description: >
+  Reviews telematics geofence alerts for fleet vehicles that left
+  authorized zones or moved outside approved hours, and flags them for
+  follow-up. Use this if a vehicle has ever turned up far outside its
+  assigned route or job site and nobody knew until a fuel bill or mileage
+  report gave it away.
+category: fleet
+tags: [fleet, gps, geofence, telematics]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review geofence alerts from {{telematics_provider_hint}} for the last
+  24 hours.
+  1. Flag any vehicle that exited an assigned geofence zone without a
+     matching dispatch/job assignment.
+  2. Flag any vehicle movement recorded outside approved operating hours
+     ({{operating_hours}}).
+  3. Group repeat offenders (same vehicle or driver flagged more than
+     {{repeat_offense_threshold}} times this week) separately.
+  4. Report flagged events with vehicle, driver (if known), zone/time, and
+     duration outside bounds.
+variables:
+  telematics_provider_hint:
+    default: "your telematics/GPS provider (Samsara, Motive, Geotab, etc.)"
+    description: Name of the telematics provider/portal geofence alerts come from.
+  operating_hours:
+    default: "06:00-19:00"
+    description: Normal operating hours; movement outside this window is flagged.
+  repeat_offense_threshold:
+    default: 2
+    description: Number of flagged events in a week that marks a vehicle/driver as a repeat offender.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — geofence alert volume and false-positive rate vary too much by provider/zone setup for a fixed script; judgment is needed to separate legitimate detours from real violations. Distinct from `vehicle-idle-time-check` (fuel waste) and `driver-safety-score-monitor` (driving behavior).

package/jobs/fleet/lease-return-condition-check.yaml

@@ -0,0 +1,33 @@
+id: lease-return-condition-check
+version: 1
+name: End-of-Lease Vehicle Return Condition Check
+description: >
+  Reviews vehicles approaching lease-end and flags condition issues
+  (excess mileage, damage, missing equipment) that could trigger return
+  fees, giving time to fix them before turn-in. Use this if a leased
+  vehicle has ever come back with a surprise excess-wear bill because
+  nobody inspected it until the leasing company did.
+category: fleet
+tags: [fleet, leasing, inspection, cost]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review fleet lease records and identify vehicles reaching lease-end
+  within the next {{lookahead_days}} days.
+  1. For each vehicle, compare current mileage against the lease's
+     allowed mileage; flag any vehicle projected to exceed the allowance
+     by return date.
+  2. Review the most recent condition/inspection notes for damage beyond
+     normal wear, missing equipment, or aftermarket modifications that
+     would need reverting.
+  3. Estimate likely excess-wear/excess-mileage fees where the lease
+     terms make that possible.
+  4. Report flagged vehicles with lease-end date, projected mileage
+     overage, and condition concerns, ranked by estimated fee exposure.
+variables:
+  lookahead_days:
+    default: 60
+    description: How many days ahead of lease-end to start reviewing a vehicle.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — estimating fee exposure from mileage and freeform condition notes needs judgment, not a fixed threshold. Distinct from `vehicle-maintenance-due-check`, which tracks routine service, not lease turn-in condition.

package/jobs/fleet/tire-wear-replacement-check.yaml

@@ -0,0 +1,30 @@
+id: tire-wear-replacement-check
+version: 1
+name: Tire Wear & Replacement Check
+description: >
+  Checks tread depth readings against a safe minimum and flags tires
+  approaching replacement. Use this if a fleet vehicle has ever failed a
+  roadside inspection, or blown a tire on the road, because tread wear was
+  only checked at annual service instead of tracked between visits.
+category: fleet
+tags: [fleet, tires, maintenance, safety]
+schedule: "0 7 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min_tread="{{min_tread_depth_32nds}}" '
+    NR==1 {next}
+    {
+      if ($3 <= min_tread)
+        printf "REPLACE TIRE: vehicle %s, position %s — %s/32\" tread (min %s/32\")\n", $1, $2, $3, min_tread;
+    }
+  ' "{{tire_tread_csv_path}}"
+variables:
+  tire_tread_csv_path:
+    default: "./fleet-tire-tread.csv"
+    description: "Path to a CSV with columns: vehicle_id,tire_position,tread_depth_32nds_inch."
+  min_tread_depth_32nds:
+    default: 4
+    description: Minimum tread depth in 32nds of an inch before a tire is flagged for replacement (legal minimum is commonly 2/32).
+compatible_agents: [generic, claude, codex]
+notes: Update fleet-tire-tread.csv from tread depth readings taken at fuel stops, inspections, or a telematics tire-pressure/tread add-on.

package/jobs/fleet/toll-violation-tracker.yaml

@@ -0,0 +1,34 @@
+id: toll-violation-tracker
+version: 1
+name: Toll & Parking Violation Tracker
+description: >
+  Flags unpaid tolls and parking citations against fleet vehicles before
+  they escalate into late fees, registration holds, or collections. Use
+  this if a parking ticket has ever turned into a much bigger bill because
+  it sat unnoticed until a renewal got blocked.
+category: fleet
+tags: [fleet, tolls, violations, compliance]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn_days="{{warn_days_before_due}}" '
+    NR==1 {next}
+    $4 == "unpaid" {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline due_ts; close(cmd);
+      days_left = int((due_ts - today) / 86400);
+      if (days_left <= warn_days)
+        print "UNPAID: vehicle " $1 " — " $2 " (" $5 " USD, due " $3 ", " days_left " days left)";
+    }
+  ' "{{violations_csv_path}}"
+variables:
+  violations_csv_path:
+    default: "./fleet-toll-parking-violations.csv"
+    description: "Path to a CSV with columns: vehicle_id,violation_type,due_date(YYYY-MM-DD),status(unpaid/paid),amount_usd."
+  warn_days_before_due:
+    default: 5
+    description: Days before the due date to start warning about an unpaid violation.
+compatible_agents: [generic, claude, codex]
+notes: Pull unpaid toll/citation exports from your toll transponder provider and city/county ticket portals into the CSV before each run.

package/jobs/fleet/vehicle-pool-scheduling-conflict-check.yaml

@@ -0,0 +1,37 @@
+id: vehicle-pool-scheduling-conflict-check
+version: 1
+name: Vehicle Pool Scheduling Conflict Check
+description: >
+  Scans upcoming pool vehicle reservations for double-bookings and flags
+  overlaps before two employees show up for the same vehicle. Use this if
+  a pool vehicle has ever been double-booked because reservations were
+  tracked in a shared calendar or spreadsheet with no overlap check.
+category: fleet
+tags: [fleet, scheduling, pool-vehicles]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      vehicle=$1; start=$3; end=$4; requester=$2;
+      key = vehicle;
+      if ((key SUBSEP "count") in count) {
+        n = count[key SUBSEP "count"];
+      } else { n = 0; }
+      for (i = 0; i < n; i++) {
+        s2 = starts[key, i]; e2 = ends[key, i]; r2 = reqs[key, i];
+        if (start < e2 && s2 < end)
+          printf "CONFLICT: vehicle %s booked by %s (%s-%s) overlaps %s (%s-%s)\n", vehicle, requester, start, end, r2, s2, e2;
+      }
+      starts[key, n] = start; ends[key, n] = end; reqs[key, n] = requester;
+      count[key SUBSEP "count"] = n + 1;
+    }
+  ' "{{reservations_csv_path}}"
+variables:
+  reservations_csv_path:
+    default: "./pool-vehicle-reservations.csv"
+    description: "Path to a CSV with columns: vehicle_id,requester_name,start_datetime(sortable string, e.g. ISO 8601),end_datetime(sortable string)."
+compatible_agents: [generic, claude, codex]
+notes: Reservation times must sort correctly as strings (ISO 8601 recommended) for the overlap comparison to work; re-export sorted by vehicle_id if your booking tool doesn't already group by vehicle.

package/jobs/fleet/vehicle-tco-tracker.yaml

@@ -0,0 +1,41 @@
+id: vehicle-tco-tracker
+version: 1
+name: Vehicle Total Cost of Ownership Tracker
+description: >
+  Reviews each vehicle's running cost per mile (fuel, maintenance,
+  insurance, depreciation) against a threshold and flags vehicles that
+  have quietly become more expensive to keep than to replace. Use this if
+  an aging vehicle has ever stayed on the road years past the point it
+  made financial sense.
+category: fleet
+tags: [fleet, cost, depreciation, tco]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review this month's fleet cost data from {{fleet_management_system_hint}}
+  covering fuel, maintenance, insurance, and depreciation for each vehicle.
+  1. Calculate or pull the trailing {{trailing_months}}-month cost per mile
+     (or cost per day if mileage isn't tracked) for each vehicle.
+  2. Flag any vehicle whose cost per mile exceeds {{max_cost_per_mile_usd}}
+     USD, or whose costs have risen more than {{cost_increase_pct}}% versus
+     the prior period.
+  3. For flagged vehicles, note vehicle age/mileage and whether recent
+     costs are dominated by maintenance (repair spiral) or fuel
+     (efficiency loss).
+  4. Report flagged vehicles ranked by cost per mile, highest first.
+variables:
+  fleet_management_system_hint:
+    default: "your fleet management/telematics system"
+    description: Name of the system fuel, maintenance, insurance, and depreciation data comes from.
+  trailing_months:
+    default: 3
+    description: Number of trailing months to average costs over.
+  max_cost_per_mile_usd:
+    default: 0.75
+    description: Cost per mile (USD) above which a vehicle is flagged.
+  cost_increase_pct:
+    default: 20
+    description: Percentage cost increase versus the prior period that triggers a flag.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — cost data is scattered across fuel cards, maintenance logs, and insurance statements, and judging whether a rising cost trend means "replace this vehicle" needs more than a threshold check.

package/jobs/fleet/vehicle-utilization-rate-check.yaml

@@ -0,0 +1,37 @@
+id: vehicle-utilization-rate-check
+version: 1
+name: Vehicle Utilization Rate Check
+description: >
+  Flags fleet vehicles running well below or above a target utilization
+  rate (miles or days driven per period). Use this if a vehicle has ever
+  sat mostly idle in a lot racking up lease and insurance costs while
+  another vehicle got run into the ground.
+category: fleet
+tags: [fleet, vehicles, utilization]
+schedule: "0 7 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v low="{{low_utilization_pct}}" -v high="{{high_utilization_pct}}" '
+    NR==1 {next}
+    {
+      pct = ($3 / $2) * 100;
+      if (pct < low) {
+        printf "UNDERUSED: vehicle %s — %.1f%% utilization (target %d-%d%%)\n", $1, pct, low, high;
+      } else if (pct > high) {
+        printf "OVERUSED: vehicle %s — %.1f%% utilization (target %d-%d%%)\n", $1, pct, low, high;
+      }
+    }
+  ' "{{utilization_csv_path}}"
+variables:
+  utilization_csv_path:
+    default: "./vehicle-utilization.csv"
+    description: "Path to a monthly CSV with columns: vehicle_id,available_days_or_miles,used_days_or_miles."
+  low_utilization_pct:
+    default: 30
+    description: Utilization percentage below which a vehicle is flagged as underused.
+  high_utilization_pct:
+    default: 90
+    description: Utilization percentage above which a vehicle is flagged as overused/at risk of premature wear.
+compatible_agents: [generic, claude, codex]
+notes: Pulls whatever "used" metric you track (days checked out, miles driven) against "available" — pick one unit and stay consistent across rows.

package/jobs/growth/cohort-retention-curve-monitor.yaml

@@ -0,0 +1,39 @@
+id: cohort-retention-curve-monitor
+version: 1
+name: Cohort Retention Curve Monitor
+description: >
+  Compares a new signup cohort's early retention (e.g. week-1, week-4)
+  against your historical baseline and flags when a cohort is retaining
+  worse than usual. Use this if a bad cohort has ever only been noticed
+  months later when overall retention numbers had already softened.
+category: growth
+tags: [growth, retention, cohort-analysis, activation]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  file={{cohort_retention_csv_path}}; baseline={{baseline_retention_pct}}; drop={{drop_threshold_pct}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  tail -n +2 "$file" | while IFS=',' read -r cohort_week cohort_size retained; do
+    [ "$cohort_size" -eq 0 ] 2>/dev/null && continue;
+    pct=$(awk "BEGIN{printf \"%.1f\", ($retained/$cohort_size)*100}");
+    below=$(awk "BEGIN{print ($pct < ($baseline - $drop)) ? 1 : 0}");
+    if [ "$below" = "1" ]; then
+      echo "BELOW BASELINE: cohort $cohort_week — ${pct}% retained ($retained/$cohort_size), baseline ${baseline}%";
+    fi
+  done
+variables:
+  cohort_retention_csv_path:
+    default: "./cohort-retention.csv"
+    description: "Path to a CSV with header: cohort_week,cohort_size,retained_at_checkpoint (retained_at_checkpoint is the count still active at your chosen checkpoint, e.g. week 4)."
+  baseline_retention_pct:
+    default: 60
+    description: Your historical average retention percent at the checkpoint being measured.
+  drop_threshold_pct:
+    default: 10
+    description: Percentage points below baseline that flags a cohort as underperforming.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token. You maintain cohort-retention.csv yourself (export from
+  product analytics, one row per signup cohort with its retention count
+  at a fixed checkpoint like week 4).

package/jobs/growth/customer-health-score-monitor.yaml

@@ -0,0 +1,37 @@
+id: customer-health-score-monitor
+version: 1
+name: Customer Health Score Monitor
+description: >
+  Rolls up usage, support, billing, and sentiment signals into a
+  per-account health score and flags accounts that dropped into the red
+  zone. Use this if account health only ever comes up in a QBR deck, long
+  after an account has already quietly gone cold.
+category: growth
+tags: [growth, health-score, retention, customer-success]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull recent signals for each active account from {{signal_sources}}:
+  product usage trend, open support ticket volume/severity, days since
+  last login, payment status, and (if available) latest NPS/CSAT
+  response.
+  1. Combine the signals into a rough health score per account (e.g.
+     green/yellow/red), weighting usage decline and payment issues most
+     heavily.
+  2. List accounts that land in the red zone, with the specific signals
+     that dragged them down.
+  3. Note any account that moved from green/yellow to red since the last
+     run, since a sudden drop is more urgent than a chronically weak
+     score.
+variables:
+  signal_sources:
+    default: "your product analytics, support/helpdesk tool, and billing system"
+    description: Where usage, support, and billing signals come from.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  No generic script mode — combining several signal types into one score
+  and judging what counts as "red" needs reasoning across sources, not a
+  single threshold. Distinct from churn-risk-watch (which only looks at
+  usage drop-off) — this rolls up multiple signal types into one composite
+  score.