@wonsukchoi/crondex 0.21.0 → 0.23.0

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/hr/aca-fte-threshold-monitor.yaml

@@ -0,0 +1,44 @@
+id: aca-fte-threshold-monitor
+version: 1
+name: ACA Full-Time-Equivalent Threshold Monitor
+description: >
+  Estimates the company's total ACA full-time-equivalent count from a
+  headcount/hours export and warns when it's approaching the Applicable
+  Large Employer threshold. Use this if the company has ever crossed 50
+  FTEs without anyone noticing until a compliance filing requirement
+  suddenly applied.
+category: hr
+tags: [hr, aca, compliance, headcount]
+schedule: "0 8 1 * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v threshold="{{fte_threshold}}" -v buffer="{{warn_buffer}}" '
+    NR==1 {next}
+    $2 == "full-time" {ft_count++; next}
+    {pt_hours += $3}
+    END {
+      pt_fte = pt_hours / 120;
+      total_fte = ft_count + pt_fte;
+      printf "Full-time headcount: %d, part-time/variable FTE-equivalent: %.1f, total ACA FTE estimate: %.1f\n", ft_count, pt_fte, total_fte;
+      if (total_fte >= (threshold - buffer)) {
+        printf "WARNING: total FTE estimate %.1f is within %d of the ALE threshold of %d — review ACA Applicable Large Employer status.\n", total_fte, buffer, threshold;
+      }
+    }
+  ' "{{aca_headcount_csv_path}}"
+variables:
+  aca_headcount_csv_path:
+    default: "./aca-headcount-hours.csv"
+    description: "Path to a CSV with columns: employee_name,employment_type (full-time/part-time/variable),monthly_hours (only used for non-full-time rows)."
+  fte_threshold:
+    default: 50
+    description: The ACA Applicable Large Employer FTE threshold to watch for (50 under current federal rules; confirm against current law).
+  warn_buffer:
+    default: 5
+    description: How close to the threshold (in FTE count) triggers a warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  This is a rough monthly estimate using the standard 120-hours-per-month
+  divisor for part-time/variable-hour employees, not a substitute for the
+  IRS's official monthly measurement method — consult counsel/a benefits
+  advisor before relying on it for actual ALE determination.

package/jobs/hr/cobra-notification-deadline-tracker.yaml

@@ -0,0 +1,47 @@
+id: cobra-notification-deadline-tracker
+version: 1
+name: COBRA Notification Deadline Tracker
+description: >
+  Flags terminated employees who are approaching or past the deadline for
+  their COBRA election notice with no notice sent on record. Use this if
+  a COBRA notice has ever gone out late — or not at all — because
+  offboarding paperwork got deprioritized once the employee's last day
+  had already passed.
+category: hr
+tags: [hr, cobra, offboarding, compliance, benefits]
+schedule: "0 8 * * 1-5"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v deadline_days="{{notice_deadline_days}}" -v warn="{{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 term_epoch; close(cmd);
+      days_since_term = (today - term_epoch) / 86400;
+      days_left = deadline_days - days_since_term;
+      if (days_left < 0) {
+        printf "COBRA NOTICE OVERDUE: %s — terminated %s, %d day(s) past the %d-day notice deadline, no notice sent\n", $1, $2, -days_left, deadline_days;
+      } else if (days_left <= warn) {
+        printf "COBRA NOTICE DUE: %s — terminated %s, %d day(s) left of the %d-day notice deadline, no notice sent\n", $1, $2, days_left, deadline_days;
+      }
+    }
+  ' "{{cobra_tracking_csv_path}}"
+variables:
+  cobra_tracking_csv_path:
+    default: "./cobra-tracking.csv"
+    description: "Path to a CSV with columns: employee_name,termination_date (YYYY-MM-DD),notice_sent_date (blank if not yet sent)."
+  notice_deadline_days:
+    default: 44
+    description: Days from the qualifying event (termination) to get the COBRA election notice out, per your plan's timeline (federal rules generally allow up to 44 days combined; confirm against your plan administrator's actual deadline).
+  warn_days_before:
+    default: 10
+    description: How many days before the deadline to start flagging as due.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Federal COBRA timelines and state mini-COBRA rules vary — confirm the
+  actual notice_deadline_days with your plan administrator or counsel
+  rather than relying on the default. Assumes an already-exported
+  termination/notice CSV rather than live benefits-system access.

package/jobs/hr/compliance-training-completion-check.yaml

@@ -0,0 +1,41 @@
+id: compliance-training-completion-check
+version: 1
+name: Compliance Training Completion Check
+description: >
+  Flags employees with a required compliance training (harassment
+  prevention, safety cert, data-privacy, etc.) approaching or past its due
+  date with no completion on record. Use this if a training deadline has
+  ever been missed and only surfaced when a regulator or auditor asked for
+  proof of completion.
+category: hr
+tags: [hr, compliance, training, deadline]
+schedule: "0 8 * * 1"
+timezone: "America/New_York"
+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) {
+        printf "TRAINING DUE: %s — \"%s\" due %s (%d days), not completed\n", $1, $2, $3, diff_days;
+      }
+    }
+  ' "{{training_tracking_csv_path}}"
+variables:
+  training_tracking_csv_path:
+    default: "./compliance-training-tracking.csv"
+    description: "Path to a CSV with columns: employee_name,training_name,due_date (YYYY-MM-DD),completed_date (blank if not yet done). One row per required training per employee."
+  warn_days_before:
+    default: 14
+    description: How many days before a training's due date to start warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained export from your LMS/HRIS listing one row per
+  employee per required training. Distinct from new-hire-paperwork-check,
+  which covers one-time onboarding documents rather than recurring/annual
+  compliance training.

package/jobs/hr/eeo1-filing-deadline-reminder.yaml

@@ -0,0 +1,37 @@
+id: eeo1-filing-deadline-reminder
+version: 1
+name: EEO-1 Filing Deadline Reminder
+description: >
+  Counts down to the annual EEO-1 component filing deadline so data
+  collection and submission don't get rushed at the last minute. Use this
+  if the EEO-1 window has ever snuck up because it only comes around once
+  a year and nobody put it on a recurring calendar.
+category: hr
+tags: [hr, eeo1, compliance, filing, deadline]
+schedule: "0 9 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today_epoch=$(date +%s);
+  deadline_epoch=$(date -d "{{filing_deadline}}" +%s 2>/dev/null || date -j -f %Y-%m-%d "{{filing_deadline}}" +%s);
+  days_left=$(( (deadline_epoch - today_epoch) / 86400 ));
+  if [ "$days_left" -lt 0 ]; then
+    echo "note: this cycle's EEO-1 deadline ({{filing_deadline}}) has passed — update filing_deadline for next year's cycle.";
+  elif [ "$days_left" -le {{warn_days_before}} ]; then
+    echo "EEO-1 FILING DUE: $days_left day(s) until deadline ({{filing_deadline}}). Confirm workforce snapshot data and file via the EEOC portal.";
+  else
+    echo "OK: $days_left day(s) until EEO-1 filing deadline ({{filing_deadline}}).";
+  fi
+variables:
+  filing_deadline:
+    default: "YYYY-MM-DD"
+    description: This cycle's EEO-1 Component 1 filing deadline, published annually by the EEOC — update each cycle.
+  warn_days_before:
+    default: 30
+    description: How many days before the deadline to start reminding.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Only applies to employers required to file (generally 100+ employees, or
+  federal contractors meeting lower thresholds) — confirm your filing
+  obligation and the current cycle's exact deadline on the EEOC's site
+  rather than assuming last year's date still applies.

package/jobs/hr/handbook-acknowledgment-tracking.yaml

@@ -0,0 +1,34 @@
+id: handbook-acknowledgment-tracking
+version: 1
+name: Employee Handbook Acknowledgment Tracking
+description: >
+  Checks the full roster against the current handbook version and flags
+  anyone who hasn't signed off on it yet — including existing employees
+  after a handbook update, not just new hires. Use this if a handbook
+  revision has ever gone out and only a fraction of the company actually
+  acknowledged it, which nobody discovered until it mattered in a dispute.
+category: hr
+tags: [hr, handbook, compliance, policy]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v current="{{current_handbook_version}}" '
+    NR==1 {next}
+    $2 != current {
+      printf "NOT ACKNOWLEDGED: %s — on file for v%s, current is v%s\n", $1, ($2 == "" ? "none" : $2), current;
+    }
+  ' "{{handbook_ack_csv_path}}"
+variables:
+  handbook_ack_csv_path:
+    default: "./handbook-acknowledgments.csv"
+    description: "Path to a CSV with columns: employee_name,acknowledged_version (blank if never acknowledged any version)."
+  current_handbook_version:
+    default: "2026.1"
+    description: Version label of the currently effective handbook, updated whenever a new revision goes out.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained acknowledgment export covering the whole roster.
+  Distinct from new-hire-paperwork-check, which bundles the initial
+  handbook sign-off into a new hire's first-30-days checklist rather than
+  tracking re-acknowledgment across the whole company after updates.

package/jobs/hr/headcount-budget-variance-check.yaml

@@ -0,0 +1,37 @@
+id: headcount-budget-variance-check
+version: 1
+name: Headcount vs. Budget Variance Check
+description: >
+  Compares actual headcount per department against the planned/budgeted
+  headcount and flags departments that are over or under plan. Use this
+  if a department has ever quietly overhired (or sat understaffed) for a
+  quarter before finance and HR compared notes and noticed.
+category: hr
+tags: [hr, headcount, budget, finance, planning]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v threshold="{{variance_threshold}}" '
+    NR==1 {next}
+    {
+      variance = $3 - $2;
+      abs_variance = (variance < 0 ? -variance : variance);
+      if (abs_variance >= threshold) {
+        direction = (variance > 0 ? "OVER PLAN" : "UNDER PLAN");
+        printf "%s: %s — budgeted %d, actual %d (variance %+d)\n", direction, $1, $2, $3, variance;
+      }
+    }
+  ' "{{headcount_budget_csv_path}}"
+variables:
+  headcount_budget_csv_path:
+    default: "./headcount-budget.csv"
+    description: "Path to a CSV with columns: department,budgeted_headcount,actual_headcount."
+  variance_threshold:
+    default: 2
+    description: Minimum absolute headcount variance (in people) before a department is flagged.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained monthly export reconciling the HRIS actual
+  headcount against finance's approved plan by department. Zero-token —
+  no synthesis or interpretation beyond the raw variance.

package/jobs/hr/leave-of-absence-return-tracker.yaml

@@ -0,0 +1,42 @@
+id: leave-of-absence-return-tracker
+version: 1
+name: Leave of Absence Return Tracker
+description: >
+  Tracks employees on FMLA, parental, medical, or other formal leave and
+  flags upcoming or overdue return dates. Use this if a return-to-work
+  date has ever been missed — either the team wasn't ready for someone
+  coming back, or nobody noticed an expected return date came and went
+  with no check-in.
+category: hr
+tags: [hr, leave-of-absence, fmla, parental-leave, compliance]
+schedule: "0 8 * * 1-5"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn="{{warn_days_before}}" '
+    NR==1 {next}
+    $4 != "active" {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline return_epoch; close(cmd);
+      diff_days = (return_epoch - today) / 86400;
+      if (diff_days < 0) {
+        printf "OVERDUE RETURN: %s — %s leave, expected back %s (%d day(s) past, still marked active)\n", $1, $2, $3, -diff_days;
+      } else if (diff_days <= warn) {
+        printf "RETURN UPCOMING: %s — %s leave, expected back %s (%d day(s))\n", $1, $2, $3, diff_days;
+      }
+    }
+  ' "{{leave_tracking_csv_path}}"
+variables:
+  leave_tracking_csv_path:
+    default: "./leave-of-absence-tracking.csv"
+    description: "Path to a CSV with columns: employee_name,leave_type,expected_return_date (YYYY-MM-DD),status (active/returned)."
+  warn_days_before:
+    default: 10
+    description: How many days before the expected return date to start flagging as upcoming.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained export from HR/leave-administration tracking active
+  leaves; this is the backstop that flags dates, not a substitute for
+  legally required FMLA/state-leave notices or interactive-process steps.

package/jobs/hr/org-chart-manager-drift-check.yaml

@@ -0,0 +1,40 @@
+id: org-chart-manager-drift-check
+version: 1
+name: Org Chart Manager Drift Check
+description: >
+  Compares the manager field in the HRIS against a separately maintained
+  org-chart source of truth and flags mismatches. Use this if the
+  "reports to" field has ever gone stale after a reorg, leaving reviews,
+  approvals, or reminders routed to someone's old manager for months.
+category: hr
+tags: [hr, org-chart, data-quality, hris]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==FNR {
+      if (FNR>1) hris_mgr[$1]=$2;
+      next;
+    }
+    FNR==1 {next}
+    {
+      if (($1 in hris_mgr) && hris_mgr[$1] != $2) {
+        printf "MANAGER DRIFT: %s — HRIS says \"%s\", org chart says \"%s\"\n", $1, hris_mgr[$1], $2;
+      } else if (!($1 in hris_mgr)) {
+        printf "MISSING FROM HRIS: %s — in org chart reporting to \"%s\" but not found in HRIS export\n", $1, $2;
+      }
+    }
+  ' "{{hris_manager_csv_path}}" "{{org_chart_csv_path}}"
+variables:
+  hris_manager_csv_path:
+    default: "./hris-manager-export.csv"
+    description: "Path to a CSV export from the HRIS with columns: employee_name,manager_name."
+  org_chart_csv_path:
+    default: "./org-chart-source.csv"
+    description: "Path to a CSV from your org-chart source of truth (e.g. an org-design tool or a maintained spreadsheet) with columns: employee_name,manager_name."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Matches purely on employee_name strings — dedupe/normalize names (or
+  swap in employee IDs) before relying on this for a large or
+  name-collision-prone roster.

package/jobs/hr/pay-equity-band-outlier-check.yaml

@@ -0,0 +1,58 @@
+id: pay-equity-band-outlier-check
+version: 1
+name: Pay Equity Band Outlier Check
+description: >
+  Scans a salary-band export for employees paid outside their role's band
+  or unusually far from the band midpoint, and summarizes any patterns
+  worth a closer look. Use this if pay outliers have ever gone unnoticed
+  for a review cycle simply because nobody cross-checked salaries against
+  bands until an audit or a pay-equity complaint forced the issue.
+category: hr
+tags: [hr, pay-equity, compensation, compliance]
+schedule: "0 9 1 1,4,7,10 *"
+timezone: "UTC"
+runner: hybrid
+command: >
+  awk -F',' -v tol="{{tolerance_pct}}" '
+    NR==1 {next}
+    {
+      band_min=$3; band_max=$4; salary=$5;
+      low_bound = band_min * (1 - tol/100);
+      high_bound = band_max * (1 + tol/100);
+      if (salary < low_bound) {
+        printf "BELOW BAND: %s (%s) — $%d vs band $%d-$%d\n", $1, $2, salary, band_min, band_max;
+      } else if (salary > high_bound) {
+        printf "ABOVE BAND: %s (%s) — $%d vs band $%d-$%d\n", $1, $2, salary, band_min, band_max;
+      }
+    }
+  ' "{{salary_band_csv_path}}"
+prompt: |
+  Run the outlier check above against {{salary_band_csv_path}} (columns:
+  employee_name, role, band_min, band_max, current_salary). Using the
+  BELOW BAND / ABOVE BAND lines it produces:
+  1. Group outliers by role/level and note any pattern (e.g. one role
+     consistently under band, one department skewing above).
+  2. Do not draw conclusions about protected-class pay gaps — this export
+     has no demographic data. Just flag the raw outliers and patterns for
+     HR/legal to review with proper pay-equity analysis tooling.
+  3. Summarize as a short list HR can triage, ranked by how far outside
+     the band each person is.
+script_note: >
+  The command gives you the raw list of employees outside their band for
+  free. The prompt adds pattern-level grouping (by role/department) to
+  help HR prioritize triage — it does not perform statistical pay-equity
+  analysis or draw demographic conclusions.
+variables:
+  salary_band_csv_path:
+    default: "./salary-bands.csv"
+    description: "Path to an anonymized/exported CSV with columns: employee_name,role,band_min,band_max,current_salary. No demographic fields."
+  tolerance_pct:
+    default: 0
+    description: Percent tolerance outside the band before flagging (0 = flag anything strictly outside min/max).
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  This is a band-boundary check, not a statistical pay-equity or
+  disparate-impact analysis — it deliberately excludes demographic data.
+  Route real pay-equity audits through legal counsel and proper
+  statistical tooling. Assumes an already-exported salary-band CSV rather
+  than live comp-system access.

package/jobs/hr/pto-year-end-use-it-or-lose-it-check.yaml

@@ -0,0 +1,49 @@
+id: pto-year-end-use-it-or-lose-it-check
+version: 1
+name: Company-Wide PTO Use-It-or-Lose-It Check
+description: >
+  Scans the full employee roster for anyone whose unused PTO balance is
+  above the policy cap or won't be usable before the year-end reset, so
+  HR/payroll can send a bulk nudge. Use this if payout or forfeiture
+  disputes have ever come up in December because nobody flagged high
+  balances company-wide until it was too late to schedule time off. This
+  is the HR-wide roster check — for tracking just your own balance, use
+  team/pto-balance-check instead.
+category: hr
+tags: [hr, pto, vacation, compliance, payroll]
+schedule: "0 9 1 10,11,12 *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today_epoch=$(date +%s);
+  cutoff_epoch=$(date -d "{{year_end_date}}" +%s 2>/dev/null || date -j -f %Y-%m-%d "{{year_end_date}}" +%s);
+  days_left=$(( (cutoff_epoch - today_epoch) / 86400 ));
+  awk -F',' -v cap="{{cap_hours}}" -v days_left="$days_left" -v warn="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      if ($2 > cap) {
+        printf "OVER CAP: %s — %s hours unused (cap %s)\n", $1, $2, cap;
+      } else if (days_left <= warn && $2 > 0) {
+        printf "USE-IT-OR-LOSE-IT: %s — %s hours unused, %d day(s) until year-end reset (%s)\n", $1, $2, days_left, "{{year_end_date}}";
+      }
+    }
+  ' "{{pto_roster_csv_path}}"
+variables:
+  pto_roster_csv_path:
+    default: "./pto-balances.csv"
+    description: "Path to a CSV export with columns: employee_name,pto_balance_hours."
+  cap_hours:
+    default: 80
+    description: Company policy cap on unused PTO hours, above which balances are flagged regardless of date.
+  year_end_date:
+    default: "2026-12-31"
+    description: Date (YYYY-MM-DD) unused PTO resets or is forfeited under company policy.
+  warn_days_before:
+    default: 45
+    description: How many days before year_end_date to start flagging nonzero balances.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained roster export from payroll/HRIS with current PTO
+  balances for every employee. Distinct from team/pto-balance-check,
+  which is a single self-maintained personal reminder, not a company-wide
+  audit.