@wonsukchoi/crondex 0.21.0 → 0.23.0

package/jobs/healthcare/patient-balance-collections-aging-check.yaml

@@ -0,0 +1,41 @@
+id: patient-balance-collections-aging-check
+version: 1
+name: Overdue Patient Balance Aging Check
+description: >
+  Buckets outstanding self-pay patient balances by how long they've been
+  unpaid (30/60/90+ days) and flags the oldest ones for collections
+  follow-up. Use this if patient balances have ever quietly aged past the
+  point of easy recovery because nobody was reviewing accounts receivable
+  by age, only by total dollar amount.
+category: healthcare
+tags: [healthcare, billing, collections, accounts-receivable, patients]
+schedule: "0 8 1,15 * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v flag_days="{{flag_after_days}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline invoice_epoch; close(cmd);
+      age_days = (today - invoice_epoch) / 86400;
+      bucket = (age_days < 30) ? "current" : (age_days < 60) ? "30-59" : (age_days < 90) ? "60-89" : "90+";
+      if (age_days >= flag_days) {
+        printf "OVERDUE BALANCE: %s — $%s, invoiced %s (%d days, bucket %s)\n", $1, $2, $3, age_days, bucket;
+      }
+    }
+  ' "{{patient_balances_csv_path}}"
+variables:
+  patient_balances_csv_path:
+    default: "./patient-balances.csv"
+    description: "Path to a CSV with columns: patient_name,balance_amount,invoice_date (YYYY-MM-DD)."
+  flag_after_days:
+    default: 60
+    description: Days since invoicing before an unpaid balance is flagged for collections follow-up.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes an already-exported CSV from your billing/practice-management system
+  rather than live PHI system access. Read-only aging report — actual collections
+  outreach should follow your practice's billing/compliance policy (e.g. FDCPA-style
+  notice requirements where applicable).

package/jobs/healthcare/patient-immunization-schedule-check.yaml

@@ -0,0 +1,41 @@
+id: patient-immunization-schedule-check
+version: 1
+name: Patient Immunization Schedule Check
+description: >
+  Checks which patients are due or overdue for a scheduled immunization and
+  lists them for outreach. Use this if a patient (child or adult) has ever
+  fallen behind on a vaccine series because nobody was tracking due dates
+  against the immunization schedule between visits — this is for human
+  patients, distinct from jobs/veterinary/pet-vaccine-due-reminder.yaml
+  which tracks pet vaccines at an animal clinic.
+category: healthcare
+tags: [healthcare, immunization, vaccine, patients, preventive-care]
+schedule: "0 8 * * *"
+timezone: "America/New_York"
+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 due_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (due_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "IMMUNIZATION DUE: %s — %s due %s (%d days)\n", $1, $4, $3, diff_days;
+      }
+    }
+  ' "{{patients_csv_path}}"
+variables:
+  patients_csv_path:
+    default: "./patient-immunizations.csv"
+    description: "Path to a CSV with columns: patient_name,date_of_birth,due_date (YYYY-MM-DD),vaccine_name."
+  warn_days_before:
+    default: 21
+    description: How many days before (or past) the due date to start listing.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes an already-exported CSV from your EHR/immunization registry rather than
+  live PHI system access. Read-only backstop check — cross-verify against your
+  state immunization registry before contacting patients, since due dates can shift
+  based on catch-up schedules.

package/jobs/healthcare/patient-portal-message-backlog-check.yaml

@@ -0,0 +1,39 @@
+id: patient-portal-message-backlog-check
+version: 1
+name: Patient Portal Message Backlog Check
+description: >
+  Checks unanswered patient portal messages against a response-time SLA and
+  flags anything overdue. Use this if a patient message has ever sat
+  unanswered in the portal inbox for days because it scrolled off the top
+  of a busy staff member's queue and nobody was tracking age.
+category: healthcare
+tags: [healthcare, patient-portal, messaging, sla, patients]
+schedule: "0 */2 * * 1-6"
+timezone: "America/New_York"
+runner: shell
+command: >
+  now=$(date +%s);
+  awk -F',' -v now="$now" -v sla="{{sla_hours}}" '
+    NR==1 {next}
+    $4 == "unanswered" {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f \"%Y-%m-%d %H:%M\" \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline received_epoch; close(cmd);
+      age_hours = (now - received_epoch) / 3600;
+      if (age_hours >= sla) {
+        printf "OVERDUE MESSAGE: %s — \"%s\" received %s (%d hrs ago, unanswered)\n", $1, $3, $2, age_hours;
+      }
+    }
+  ' "{{portal_messages_csv_path}}"
+variables:
+  portal_messages_csv_path:
+    default: "./portal-messages.csv"
+    description: "Path to a CSV with columns: patient_name,received_at (YYYY-MM-DD HH:MM),subject,status (unanswered/answered)."
+  sla_hours:
+    default: 24
+    description: Hours a message can go unanswered before it's flagged overdue.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes an already-exported CSV from your patient portal/EHR messaging module
+  rather than live access to message content — export subject lines only if full
+  message bodies raise PHI-export concerns for your practice. Read-only — does not
+  reply to patients.

package/jobs/healthcare/patient-satisfaction-survey-tracking.yaml

@@ -0,0 +1,59 @@
+id: patient-satisfaction-survey-tracking
+version: 1
+name: Patient Satisfaction Survey Response Tracking
+description: >
+  Tallies patient satisfaction survey response rates and surfaces low
+  scores with comments for follow-up. Use this if low-scoring survey
+  responses have ever sat unread in an inbox, or a slipping response rate
+  went unnoticed for months — distinct from generic online reviews, this
+  tracks a practice's own post-visit survey instrument.
+category: healthcare
+tags: [healthcare, patient-satisfaction, survey, feedback, patients]
+schedule: "0 9 * * 1"
+timezone: "America/New_York"
+runner: hybrid
+command: >
+  awk -F',' -v low="{{low_score_threshold}}" '
+    NR==1 {next}
+    { sent++; }
+    $3 != "" { responded++; }
+    ($3 != "" && $4 != "" && ($4+0) <= low) {
+      printf "LOW SCORE: %s — score %s: \"%s\" (responded %s)\n", $1, $4, $5, $3;
+    }
+    END {
+      rate = (sent > 0) ? (responded / sent * 100) : 0;
+      printf "RESPONSE RATE: %d/%d sent (%.1f%%)\n", responded, sent, rate;
+    }
+  ' "{{survey_csv_path}}"
+prompt: |
+  Look at the low-score rows and comments flagged by the tally above (from
+  {{survey_csv_path}}).
+  1. Group the comments into common themes (e.g. wait time, billing
+     confusion, communication, front-desk experience).
+  2. For each theme, note how many respondents mentioned it and give one
+     representative quote.
+  3. For any response that names a specific, addressable problem, draft a
+     short, warm outreach note to that patient acknowledging the feedback —
+     draft-only, for staff to review before sending.
+  4. If the response rate this run is notably lower than
+     {{expected_response_rate}}%, flag that as worth investigating
+     separately from the score themes.
+variables:
+  survey_csv_path:
+    default: "./patient-satisfaction-surveys.csv"
+    description: "Path to a CSV with columns: patient_name,visit_date,response_date (blank if no response),score (1-5, blank if no response),comment."
+  low_score_threshold:
+    default: 3
+    description: Scores at or below this value are flagged as low.
+  expected_response_rate:
+    default: 25
+    description: Expected survey response rate (%) — used only as a reference point for flagging an unusually low run.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+script_note: >
+  The command gives you the response rate and raw low-score rows for free. Only the
+  prompt pass groups comments into themes and drafts a tactful outreach note to an
+  unhappy patient — that synthesis is what the LLM pass adds.
+notes: >
+  Assumes an already-exported CSV from your survey tool (e.g. post-visit SMS/email
+  survey) rather than live PHI system access. Outreach drafts must be reviewed by
+  staff before sending.

package/jobs/healthcare/prescription-refill-request-backlog-check.yaml

@@ -0,0 +1,38 @@
+id: prescription-refill-request-backlog-check
+version: 1
+name: Prescription Refill Request Backlog Check
+description: >
+  Checks pending prescription refill requests against how long they've been
+  waiting and flags anything past a reasonable turnaround. Use this if a
+  refill request has ever sat in a queue long enough that a patient ran out
+  of a maintenance medication before the practice got to it.
+category: healthcare
+tags: [healthcare, prescriptions, refills, patients, medication]
+schedule: "0 9,15 * * 1-5"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v hours="{{escalate_after_hours}}" '
+    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 requested_epoch; close(cmd);
+      age_hours = (today - requested_epoch) / 3600;
+      if (age_hours >= hours) {
+        printf "REFILL PENDING: %s — %s requested %s (%d hrs ago)\n", $1, $2, $3, age_hours;
+      }
+    }
+  ' "{{refill_requests_csv_path}}"
+variables:
+  refill_requests_csv_path:
+    default: "./refill-requests.csv"
+    description: "Path to a CSV with columns: patient_name,medication,requested_date (YYYY-MM-DD),status (pending/approved/denied)."
+  escalate_after_hours:
+    default: 48
+    description: Hours a refill request can sit pending before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes an already-exported CSV from your e-prescribing/EHR system rather than
+  live PHI system access. Read-only triage — actual approval/denial of a refill is a
+  clinical decision made by the prescriber, not this job.

package/jobs/healthcare/prior-authorization-expiry-check.yaml

@@ -0,0 +1,53 @@
+id: prior-authorization-expiry-check
+version: 1
+name: Prior Authorization Expiry Check
+description: >
+  Checks treatment-specific prior-authorization requests for approvals about
+  to expire before the procedure happens, and for requests still stuck
+  awaiting payer response. Use this if a procedure has ever been delayed or
+  denied because the prior auth expired, or the payer never responded and
+  nobody was tracking it — distinct from insurance-eligibility-verification-check,
+  which covers general visit eligibility rather than a specific treatment's
+  authorization.
+category: healthcare
+tags: [healthcare, prior-authorization, billing, insurance, compliance]
+schedule: "0 9 * * 1-5"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn_days="{{warn_days_before_expiry}}" -v stale_days="{{pending_stale_days}}" '
+    NR==1 {next}
+    {
+      if ($4 == "approved" && $6 != "") {
+        cmd = "date -d \"" $6 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $6 "\" +%s 2>/dev/null";
+        cmd | getline expiry_epoch; close(cmd);
+        diff_days = (expiry_epoch - today) / 86400;
+        if (diff_days <= warn_days) {
+          printf "AUTH EXPIRING: %s — %s (%s) expires %s (%d days)\n", $1, $2, $3, $6, diff_days;
+        }
+      } else if ($4 == "pending") {
+        cmd = "date -d \"" $5 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $5 "\" +%s 2>/dev/null";
+        cmd | getline submitted_epoch; close(cmd);
+        pending_days = (today - submitted_epoch) / 86400;
+        if (pending_days >= stale_days) {
+          printf "AUTH STUCK PENDING: %s — %s (%s) submitted %s (%d days, no payer decision)\n", $1, $2, $3, $5, pending_days;
+        }
+      }
+    }
+  ' "{{prior_auth_csv_path}}"
+variables:
+  prior_auth_csv_path:
+    default: "./prior-authorizations.csv"
+    description: "Path to a CSV with columns: patient_name,procedure,payer,status (pending/approved/denied),submitted_date (YYYY-MM-DD),auth_expiry_date (YYYY-MM-DD, blank if still pending)."
+  warn_days_before_expiry:
+    default: 14
+    description: How many days before an approved auth expires to start warning.
+  pending_stale_days:
+    default: 10
+    description: Days a request can sit pending with no payer decision before it's flagged as stuck.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes an already-exported CSV from your billing/prior-auth tracking system rather
+  than live EHR or payer-portal access. Read-only — this flags what needs a call to
+  the payer, it doesn't submit or chase the request itself.

package/jobs/healthcare/staff-cme-credit-tracking.yaml

@@ -0,0 +1,41 @@
+id: staff-cme-credit-tracking
+version: 1
+name: Staff CME Credit Tracking
+description: >
+  Checks each clinician's continuing medical education (CME) credit hours
+  completed against what's required by their cycle end date and warns
+  before anyone falls short. Use this if a provider has ever discovered
+  close to renewal that they were short on CME hours needed to keep their
+  license active — distinct from license-credential-expiry-check, which
+  tracks the license's own expiry date rather than the ongoing education
+  requirement to renew it.
+category: healthcare
+tags: [healthcare, cme, compliance, licensing, staff]
+schedule: "0 8 1 * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn_days="{{warn_days_before_cycle_end}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $5 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $5 "\" +%s 2>/dev/null";
+      cmd | getline cycle_end_epoch; close(cmd);
+      diff_days = (cycle_end_epoch - today) / 86400;
+      shortfall = ($4 + 0) - ($3 + 0);
+      if (diff_days <= warn_days && shortfall > 0) {
+        printf "CME SHORTFALL: %s — %d/%d hours completed, %d short, cycle ends %s (%d days)\n", $1, $3, $4, shortfall, $5, diff_days;
+      }
+    }
+  ' "{{cme_tracking_csv_path}}"
+variables:
+  cme_tracking_csv_path:
+    default: "./staff-cme-credits.csv"
+    description: "Path to a CSV with columns: staff_name,license_type,cme_hours_completed,cme_hours_required,cycle_end_date (YYYY-MM-DD)."
+  warn_days_before_cycle_end:
+    default: 90
+    description: How many days before the CME cycle ends to start warning about a shortfall.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained CSV export from your CME tracking or HR/credentialing
+  system, updated whenever a provider logs completed CME hours.

package/jobs/healthcare/telehealth-session-issue-check.yaml

@@ -0,0 +1,51 @@
+id: telehealth-session-issue-check
+version: 1
+name: Telehealth Session No-Show/Tech-Failure Check
+description: >
+  Reviews recent telehealth appointments for no-shows and technical-failure
+  disconnects, and flags patients hitting either problem repeatedly. Use
+  this if a telehealth visit has ever quietly failed to happen — patient
+  never joined, or the call dropped and was never rebooked — with nobody
+  tracking it the way an in-person no-show would normally get tracked.
+category: healthcare
+tags: [healthcare, telehealth, no-show, appointments, patients]
+schedule: "0 18 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v lookback="{{lookback_days}}" -v repeat_threshold="{{repeat_issue_threshold}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline appt_epoch; close(cmd);
+      age_days = (today - appt_epoch) / 86400;
+      if (age_days < 0 || age_days > lookback) next;
+      if ($3 == "no-show" || $3 == "tech-failure" || $3 == "disconnected") {
+        printf "SESSION ISSUE: %s — %s on %s (%s)\n", $1, $3, $2, $4;
+        count[$1]++;
+      }
+    }
+    END {
+      for (p in count) {
+        if (count[p] >= repeat_threshold) {
+          printf "REPEAT ISSUE: %s has had %d telehealth issues in the last %d days\n", p, count[p], lookback;
+        }
+      }
+    }
+  ' "{{telehealth_sessions_csv_path}}"
+variables:
+  telehealth_sessions_csv_path:
+    default: "./telehealth-sessions.csv"
+    description: "Path to a CSV with columns: patient_name,appointment_date (YYYY-MM-DD),status (completed/no-show/tech-failure/disconnected),provider_name."
+  lookback_days:
+    default: 7
+    description: How many days back to review telehealth sessions.
+  repeat_issue_threshold:
+    default: 2
+    description: Number of session issues within the lookback window before a patient is flagged as a repeat case (may need an in-person alternative offered).
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes an already-exported CSV from your telehealth platform or scheduling
+  system rather than live PHI system access. Read-only — repeat cases are worth
+  offering an in-person or phone alternative rather than retrying video indefinitely.

package/jobs/hospitality/adr-revpar-tracker.yaml

@@ -0,0 +1,43 @@
+id: adr-revpar-tracker
+version: 1
+name: ADR and RevPAR Tracker
+description: >
+  Calculates yesterday's average daily rate (ADR) and revenue per
+  available room (RevPAR) from your rooms-sold export and flags a drop
+  against your target. Use this if a soft revenue night has ever gone
+  unnoticed for a week because nobody was watching the daily numbers,
+  only the monthly total.
+category: hospitality
+tags: [hospitality, revenue-management, adr, revpar]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target_adr="{{target_adr_usd}}" -v target_revpar="{{target_revpar_usd}}" -v rooms="{{total_rooms}}" '
+    NR==1 {next}
+    { rooms_sold += 1; revenue += $2 }
+    END {
+      if (rooms_sold > 0) {
+        adr = revenue / rooms_sold;
+        revpar = revenue / rooms;
+        printf "ADR: $%.2f (target $%.2f) | RevPAR: $%.2f (target $%.2f) | rooms sold: %d/%d\n", adr, target_adr, revpar, target_revpar, rooms_sold, rooms;
+        if (adr < target_adr) printf "LOW ADR: $%.2f below target $%.2f\n", adr, target_adr;
+        if (revpar < target_revpar) printf "LOW REVPAR: $%.2f below target $%.2f\n", revpar, target_revpar;
+      } else print "WARNING: no rooms sold recorded for the date";
+    }
+  ' "{{rooms_sold_csv}}"
+variables:
+  rooms_sold_csv:
+    default: "./rooms-sold-yesterday.csv"
+    description: "CSV with header row, columns: room_number,rate_paid_usd — one row per room sold yesterday."
+  total_rooms:
+    default: 100
+    description: Total available rooms in the property (denominator for RevPAR).
+  target_adr_usd:
+    default: 175
+    description: Target average daily rate in USD.
+  target_revpar_usd:
+    default: 120
+    description: Target revenue per available room in USD.
+compatible_agents: [generic, claude, codex]
+notes: Export the rooms-sold CSV from your PMS nightly before this runs; ADR = revenue / rooms sold, RevPAR = revenue / total available rooms.

package/jobs/hospitality/cancellation-rate-spike-check.yaml

@@ -0,0 +1,21 @@
+id: cancellation-rate-spike-check
+version: 1
+name: Cancellation Rate Spike Check
+description: >
+  Checks yesterday's reservation cancellation rate against your trailing
+  baseline and flags a spike. Use this if a booking-engine glitch, a rate
+  error, or bad local news has ever driven a wave of cancellations that
+  wasn't caught until the week's occupancy numbers came in soft.
+category: hospitality
+tags: [hospitality, reservations, cancellations, revenue-management]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select round(100.0 * sum(case when status = 'cancelled' then 1 else 0 end) / nullif(count(*), 0), 1) from reservations where booked_date = current_date - interval '1 day';"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the reservations database.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a `reservations` table with `status` and `booked_date` columns tracking same-day cancellations against bookings made that day — adjust the query for your PMS schema and compare the printed rate against your normal baseline manually. Complements reservation-noshow-check, which tracks no-shows rather than advance cancellations.

package/jobs/hospitality/group-booking-space-utilization-check.yaml

@@ -0,0 +1,40 @@
+id: group-booking-space-utilization-check
+version: 1
+name: Group Booking and Event Space Utilization Check
+description: >
+  Reviews upcoming event space bookings against total bookable hours for
+  the week and flags rooms sitting mostly empty, plus any booking missing
+  a signed contract or deposit close to the event date. Use this if event
+  space has ever gone underbooked for weeks with nobody noticing until
+  the sales team reviewed the quarter.
+category: hospitality
+tags: [hospitality, events, group-sales, revenue-management]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull the event space booking calendar from {{events_system}} for the
+  next {{lookback_weeks}} weeks.
+  1. Calculate utilization percentage (booked hours / bookable hours) per
+     event space/room, and flag any space below {{min_utilization_pct}}%.
+  2. List any booking within {{deposit_deadline_days}} days of its event
+     date that's still missing a signed contract or deposit.
+  3. Note any space with a pattern of last-minute cancellations, since
+     that's worth a stricter deposit policy.
+  4. Suggest one action for the most underbooked space (promo, package
+     deal, or reallocating it to guest room inventory for that period).
+variables:
+  events_system:
+    default: "your events/catering management system"
+    description: System tracking event space bookings (e.g. "Cvent", "Tripleseat", "Delphi").
+  lookback_weeks:
+    default: 4
+    description: How many weeks ahead to review bookings.
+  min_utilization_pct:
+    default: 40
+    description: Utilization percentage below which a space is flagged as underbooked.
+  deposit_deadline_days:
+    default: 14
+    description: Days before an event that a missing contract/deposit becomes urgent.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Utilization targets vary a lot by property size and market — adjust min_utilization_pct to your historical baseline rather than a generic number.

package/jobs/hospitality/guest-complaint-sla-tracker.yaml

@@ -0,0 +1,34 @@
+id: guest-complaint-sla-tracker
+version: 1
+name: Guest Complaint Resolution SLA Tracker
+description: >
+  Checks logged guest complaints (not maintenance requests) against your
+  resolution SLA and flags any still open past the deadline. Use this if
+  a service complaint has ever sat unresolved long enough that the guest
+  checked out still angry, instead of getting a recovery gesture while
+  they were still on property.
+category: hospitality
+tags: [hospitality, guest-experience, complaints, sla]
+schedule: "0 */4 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v hours="{{sla_hours}}" '
+    NR==1 {next}
+    $3 == "open" {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f \"%Y-%m-%d %H:%M\" \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline logged_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      age_hours = (now_epoch - logged_epoch) / 3600;
+      if (age_hours >= hours) printf "OVERDUE: room %s — %s (open %d hrs, category: %s)\n", $1, $4, age_hours, $5;
+    }
+  ' "{{complaints_csv_path}}"
+variables:
+  complaints_csv_path:
+    default: "./guest-complaints.csv"
+    description: "CSV with columns: room_number,logged_at (YYYY-MM-DD HH:MM),status (open/closed),summary,category (noise/cleanliness/service/billing/other)."
+  sla_hours:
+    default: 2
+    description: Target hours to resolve or acknowledge a guest complaint before it's flagged overdue.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from guest-maintenance-request-backlog-check — this tracks service/experience complaints logged by front desk or guest services, not physical repair tickets.

package/jobs/hospitality/guest-satisfaction-score-monitor.yaml

@@ -0,0 +1,41 @@
+id: guest-satisfaction-score-monitor
+version: 1
+name: Guest Satisfaction Score Monitor
+description: >
+  Tracks your rolling average guest satisfaction score (post-stay survey
+  or aggregated review rating) and flags a meaningful drop against your
+  trailing baseline. Use this if satisfaction has ever slid gradually
+  over several weeks without triggering any single alarm, until it shows
+  up as a rate hit in the OTA ranking algorithm.
+category: hospitality
+tags: [hospitality, guest-experience, satisfaction, reputation]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v window="{{trailing_weeks}}" -v drop="{{alert_drop_points}}" '
+    NR==1 {next}
+    { scores[NR-1]=$2; dates[NR-1]=$1; n=NR-1 }
+    END {
+      if (n < window*2) { print "Not enough data yet for a trailing comparison"; exit 0; }
+      recent_sum=0; baseline_sum=0;
+      for (i=n-window+1; i<=n; i++) recent_sum += scores[i];
+      for (i=n-window*2+1; i<=n-window; i++) baseline_sum += scores[i];
+      recent_avg = recent_sum/window; baseline_avg = baseline_sum/window;
+      diff = baseline_avg - recent_avg;
+      printf "Recent %d-week avg: %.2f | Prior %d-week avg: %.2f\n", window, recent_avg, window, baseline_avg;
+      if (diff >= drop) printf "ALERT: satisfaction dropped %.2f points (threshold %.2f)\n", diff, drop;
+    }
+  ' "{{weekly_scores_csv}}"
+variables:
+  weekly_scores_csv:
+    default: "./weekly-satisfaction-scores.csv"
+    description: "CSV with header row, columns: week_start_date,avg_score — one row per week, oldest first, ordered chronologically."
+  trailing_weeks:
+    default: 4
+    description: Number of weeks in each comparison window (recent vs. prior).
+  alert_drop_points:
+    default: 0.3
+    description: Point drop (on your survey's scale) between the two windows that triggers an alert.
+compatible_agents: [generic, claude, codex]
+notes: Score scale depends on your source (5-point survey, 10-point NPS-style, or 100-point aggregate) — keep alert_drop_points proportional to whatever scale weekly-satisfaction-scores.csv uses. Complements guest-review-response-check, which handles individual review replies rather than the trend.

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.