@wonsukchoi/crondex 0.11.0 → 0.12.0

package/jobs/events/event-staffing-shortfall-check.yaml

@@ -0,0 +1,34 @@
+id: event-staffing-shortfall-check
+version: 1
+name: Event Staffing Shortfall Check
+description: >
+  Compares confirmed staff/volunteer signups against how many the event
+  actually needs, and flags a shortfall while there's still time to
+  recruit. Use this if you've ever realized you were short-staffed the day
+  before an event instead of weeks before.
+category: events
+tags: [events, staffing, volunteers, planning]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  confirmed=$(wc -l < "{{signups_csv_path}}");
+  confirmed=$((confirmed - 1));
+  needed="{{staff_needed}}";
+  if [ "$confirmed" -lt "$needed" ]; then
+    echo "SHORTFALL: $confirmed of $needed staff/volunteer slots confirmed for {{event_name}}";
+  else
+    echo "OK: $confirmed of $needed staff/volunteer slots confirmed for {{event_name}}";
+  fi
+variables:
+  event_name:
+    default: "your event"
+    description: Name of the event, for the output message.
+  signups_csv_path:
+    default: "./event-staff-signups.csv"
+    description: Path to a CSV of confirmed staff/volunteer signups (one header row plus one row per person).
+  staff_needed:
+    default: 10
+    description: Total staff/volunteer slots the event needs filled.
+compatible_agents: [generic, claude, codex]
+notes: Simple headcount comparison — doesn't check role-specific coverage (e.g. enough registration desk vs. setup crew); split into multiple CSVs/jobs per role if that granularity matters for your event.

package/jobs/fitness/class-utilization-check.yaml

@@ -0,0 +1,32 @@
+id: class-utilization-check
+version: 1
+name: Class Utilization Check
+description: >
+  Checks upcoming class signups against capacity and flags classes
+  running well under-booked. Use this if a class has ever quietly run
+  half-empty for months before anyone pulled the numbers and considered
+  cutting or rescheduling it.
+category: fitness
+tags: [fitness, classes, utilization, scheduling]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min_pct="{{min_utilization_pct}}" '
+    NR==1 {next}
+    {
+      pct = ($3 / $2) * 100;
+      if (pct < min_pct) {
+        printf "UNDER-BOOKED: %s on %s — %d of %d spots (%.0f%%)\n", $1, $4, $3, $2, pct;
+      }
+    }
+  ' "{{classes_csv_path}}"
+variables:
+  classes_csv_path:
+    default: "./upcoming-classes.csv"
+    description: "Path to a CSV with columns: class_name,capacity,signed_up,class_date."
+  min_utilization_pct:
+    default: 40
+    description: Minimum percentage of capacity filled before a class is flagged as under-booked.
+compatible_agents: [generic, claude, codex]
+notes: A pattern of under-booking on the same class/time slot is worth more attention than a single slow week — track over time before deciding to cut anything.

package/jobs/fitness/gym-equipment-maintenance-check.yaml

@@ -0,0 +1,35 @@
+id: gym-equipment-maintenance-check
+version: 1
+name: Gym Equipment Maintenance Check
+description: >
+  Tracks usage hours or calendar time against manufacturer service
+  intervals for cardio and strength equipment, and flags what's coming
+  due. Use this if a treadmill has ever broken down mid-workout because
+  its service interval quietly passed unnoticed.
+category: fitness
+tags: [fitness, equipment, maintenance, gym]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (due_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "SERVICE DUE: %s — due %s (%d days)\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{equipment_csv_path}}"
+variables:
+  equipment_csv_path:
+    default: "./gym-equipment-service.csv"
+    description: "Path to a CSV with columns: equipment_name,next_service_due_date (YYYY-MM-DD)."
+  warn_days_before:
+    default: 14
+    description: How many days before service is due to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Taking equipment out of rotation for service before it fails is safer for members than waiting for a breakdown mid-use.

package/jobs/fitness/gym-membership-renewal-reminder.yaml

@@ -0,0 +1,35 @@
+id: gym-membership-renewal-reminder
+version: 1
+name: Gym Membership Renewal Reminder
+description: >
+  Warns you before a member's contract term ends so there's time to reach
+  out before they quietly let it lapse. Use this if a membership has ever
+  ended and the member just never came back, without anyone reaching out
+  during the window when a renewal conversation could've happened.
+category: fitness
+tags: [fitness, membership, renewal, retention]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline expiry_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (expiry_epoch - now_epoch) / 86400;
+      if (diff_days <= days && diff_days >= 0) {
+        printf "RENEWAL DUE: %s — membership ends %s (%d days)\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{members_csv_path}}"
+variables:
+  members_csv_path:
+    default: "./gym-memberships.csv"
+    description: "Path to a CSV with columns: member_name,membership_end_date (YYYY-MM-DD)."
+  warn_days_before:
+    default: 21
+    description: How many days before membership end to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Export from your gym management software (Mindbody, Glofox, Zen Planner) on a schedule to keep this current.

package/jobs/fleet/driver-license-cdl-expiry-check.yaml

@@ -0,0 +1,35 @@
+id: driver-license-cdl-expiry-check
+version: 1
+name: Driver License/CDL Expiry Check
+description: >
+  Checks tracked drivers' license or CDL expiry dates and warns before any
+  lapse. Use this if a driver has ever kept driving a fleet vehicle on an
+  expired license because nobody was tracking renewal dates separately
+  from vehicle registration.
+category: fleet
+tags: [fleet, drivers, license, compliance]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline expiry_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (expiry_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "LICENSE EXPIRING: %s — expires %s (%d days)\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{drivers_csv_path}}"
+variables:
+  drivers_csv_path:
+    default: "./driver-licenses.csv"
+    description: "Path to a CSV with columns: driver_name,license_expiry_date (YYYY-MM-DD)."
+  warn_days_before:
+    default: 45
+    description: How many days before expiry to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Tracks the driver's own license/CDL — separate from `vehicle-registration-expiry-check`, which tracks the vehicle's registration.

package/jobs/fleet/vehicle-inspection-due-check.yaml

@@ -0,0 +1,35 @@
+id: vehicle-inspection-due-check
+version: 1
+name: Vehicle State/DOT Inspection Due Check
+description: >
+  Checks fleet vehicles against their state or DOT inspection due dates
+  and warns before any lapse. Use this if a vehicle has ever gotten pulled
+  off a job by an inspector because its inspection sticker quietly
+  expired — separate from routine maintenance or registration renewal.
+category: fleet
+tags: [fleet, inspection, dot, compliance]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline expiry_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (expiry_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "INSPECTION DUE: %s — expires %s (%d days)\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{vehicles_csv_path}}"
+variables:
+  vehicles_csv_path:
+    default: "./vehicle-inspections.csv"
+    description: "Path to a CSV with columns: vehicle_name,inspection_expiry_date (YYYY-MM-DD)."
+  warn_days_before:
+    default: 30
+    description: How many days before the inspection expires to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Tracks the state/DOT safety inspection specifically — distinct from `vehicle-maintenance-due-check` (service intervals) and `vehicle-registration-expiry-check` (registration renewal).

package/jobs/gaming/game-server-uptime-check.yaml

@@ -0,0 +1,34 @@
+id: game-server-uptime-check
+version: 1
+name: Self-Hosted Game Server Uptime Check
+description: >
+  Checks that your self-hosted game server (Minecraft, ARK, Valheim, etc.)
+  is actually up and accepting connections. Use this if your community
+  server has ever gone down overnight and players just assumed you took it
+  offline on purpose.
+category: gaming
+tags: [gaming, server, uptime, hosting]
+schedule: "*/10 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  if command -v nc >/dev/null 2>&1; then
+    if nc -z -w5 "{{server_host}}" "{{server_port}}" 2>/dev/null; then
+      echo "OK: {{server_host}}:{{server_port}} is accepting connections";
+    else
+      echo "DOWN: {{server_host}}:{{server_port}} is not responding";
+      exit 1;
+    fi
+  else
+    echo "ERROR: nc not installed — can't check port connectivity";
+    exit 1;
+  fi
+variables:
+  server_host:
+    default: "your.server.host"
+    description: Hostname or IP of the game server.
+  server_port:
+    default: 25565
+    description: Port the game server listens on.
+compatible_agents: [generic, claude, codex]
+notes: Checks raw TCP connectivity only, not that the game itself is responding correctly inside that port — good enough to catch a crashed process or a down host.

package/jobs/gaming/tournament-registration-deadline-check.yaml

@@ -0,0 +1,34 @@
+id: tournament-registration-deadline-check
+version: 1
+name: Tournament Registration Deadline Check
+description: >
+  Warns you before a tournament's registration window closes. Use this if
+  you've ever missed signing up for a tournament because the deadline
+  passed while you were heads-down practicing instead of checking dates.
+category: gaming
+tags: [gaming, tournament, esports, deadline]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (due_epoch - now_epoch) / 86400;
+      if (diff_days <= days && diff_days >= 0) {
+        printf "REGISTRATION CLOSING: %s — closes %s (%d days)\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{tournaments_csv_path}}"
+variables:
+  tournaments_csv_path:
+    default: "./tournament-deadlines.csv"
+    description: "Path to a CSV with columns: tournament_name,registration_deadline (YYYY-MM-DD)."
+  warn_days_before:
+    default: 5
+    description: How many days before registration closes to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Maintain the CSV from whatever tournament listing sites/organizers you follow — this is a plain date-threshold reminder, not a tournament discovery tool.

package/jobs/government/constituent-casework-followup-check.yaml

@@ -0,0 +1,33 @@
+id: constituent-casework-followup-check
+version: 1
+name: Constituent Casework Follow-Up Check
+description: >
+  Checks open constituent casework (a resident's request for help with a
+  government agency, benefit, or service issue) and flags anything
+  sitting without an update. Use this if a constituent has ever called
+  back asking for a status update because their case quietly went quiet
+  on staff's end too.
+category: government
+tags: [government, constituent-services, casework, followup]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{casework_system}} for open constituent cases with no update
+  logged in the last {{stale_after_days}} days.
+  1. List each: constituent name (or case ID), issue summary, and days
+     since the last update.
+  2. Flag anything involving a time-sensitive issue (eviction, benefits
+     cutoff, utility shutoff) as higher priority regardless of how long
+     it's been open.
+  3. Draft a short status-check message per stale case for the assigned
+     staffer.
+variables:
+  casework_system:
+    default: "your constituent services/casework tracking system"
+    description: Where casework and update history are tracked.
+  stale_after_days:
+    default: 10
+    description: Days without an update before a case counts as stale.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Draft-only — status updates to constituents or follow-ups with the relevant agency go through whatever process your office already uses.

package/jobs/government/foia-request-deadline-check.yaml

@@ -0,0 +1,36 @@
+id: foia-request-deadline-check
+version: 1
+name: Public Records Request Deadline Check
+description: >
+  Checks open public records (FOIA/state equivalent) requests against
+  their statutory response deadline and flags anything close to due. Use
+  this if a records request has ever blown past its legal response
+  window because it sat in an inbox instead of on a tracked deadline
+  list.
+category: government
+tags: [government, foia, public-records, deadline]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    $3 == "open" {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (due_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "RESPONSE DUE: request %s — due %s (%d days)\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{requests_csv_path}}"
+variables:
+  requests_csv_path:
+    default: "./records-requests.csv"
+    description: "Path to a CSV with columns: request_id,statutory_due_date (YYYY-MM-DD),status (open/closed)."
+  warn_days_before:
+    default: 5
+    description: How many days before the statutory deadline to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Statutory response windows vary by jurisdiction and request type — compute `statutory_due_date` per your actual applicable law before loading it into the CSV.

package/jobs/government/permit-application-backlog-check.yaml

@@ -0,0 +1,37 @@
+id: permit-application-backlog-check
+version: 1
+name: Permit Application Backlog Check
+description: >
+  Checks how many permit applications are sitting in review past your
+  target processing time, from the issuing agency's side. Use this if
+  applications have ever piled up in a queue for weeks with no one
+  tracking total backlog size or average age.
+category: government
+tags: [government, permits, backlog, processing]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v days="{{target_processing_days}}" -v today="$today" '
+    NR==1 {next}
+    $2 == "in-review" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline submitted_epoch; close(cmd);
+      age_days = (today - submitted_epoch) / 86400;
+      total++;
+      if (age_days > days) over_target++;
+    }
+    END {
+      printf "%d applications in review, %d over the %d-day target\n", total, over_target, days;
+    }
+  ' "{{applications_csv_path}}"
+variables:
+  applications_csv_path:
+    default: "./permit-applications.csv"
+    description: "Path to a CSV with columns: application_id,status (in-review/approved/denied),submitted_date (YYYY-MM-DD)."
+  target_processing_days:
+    default: 30
+    description: Target number of days to process a permit application.
+compatible_agents: [generic, claude, codex]
+notes: This is the issuing agency's view of the backlog — distinct from `permit-expiry-check` in construction, which tracks an already-issued permit's expiry from the applicant's side.

package/jobs/healthcare/insurance-eligibility-verification-check.yaml

@@ -0,0 +1,32 @@
+id: insurance-eligibility-verification-check
+version: 1
+name: Insurance Eligibility Verification Check
+description: >
+  Checks upcoming appointments for patients whose insurance eligibility
+  hasn't been verified yet, so it gets confirmed before the visit instead
+  of at checkout. Use this if a patient has ever been surprised with a
+  denied claim because eligibility was never checked ahead of time.
+category: healthcare
+tags: [healthcare, insurance, eligibility, appointments]
+schedule: "0 15 * * *"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Check {{scheduling_system}} for appointments in the next
+  {{lookahead_days}} days that don't have insurance eligibility marked as
+  verified.
+  1. List each: patient name, appointment date, and insurance plan on
+     file.
+  2. Flag anyone with no insurance information on file at all as highest
+     priority — that's the one most likely to cause a billing problem.
+  3. Note which need a same-day eligibility check (appointment within 24
+     hours) versus which have more lead time.
+variables:
+  scheduling_system:
+    default: "your scheduling/EHR system"
+    description: Name of the scheduling or EHR system to check.
+  lookahead_days:
+    default: 3
+    description: How far ahead to check for unverified appointments.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only check — running the actual eligibility verification (via clearinghouse or payer portal) is a separate step this job just prioritizes.

package/jobs/healthcare/lab-result-followup-check.yaml

@@ -0,0 +1,34 @@
+id: lab-result-followup-check
+version: 1
+name: Lab Result Follow-Up Check
+description: >
+  Checks for lab results that came back a while ago but haven't been
+  reviewed by a provider or communicated to the patient yet. Use this if a
+  result has ever sat in a queue for days because nobody was tracking
+  turnaround from result-received to patient-notified.
+category: healthcare
+tags: [healthcare, lab-results, patients, followup]
+schedule: "0 */4 * * *"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Check {{lab_system}} for results received in the last
+  {{lookback_hours}} hours that show no provider review or patient
+  notification logged yet.
+  1. List each: patient, test type, and how long ago the result came in.
+  2. Flag anything past {{escalate_after_hours}} hours as needing
+     immediate attention — especially flag any result marked abnormal or
+     critical regardless of how recently it arrived.
+  3. If nothing is overdue, say so in one line.
+variables:
+  lab_system:
+    default: "your lab/EHR system"
+    description: Name of the system where lab results and review status are tracked.
+  lookback_hours:
+    default: 48
+    description: How far back to check for unreviewed results.
+  escalate_after_hours:
+    default: 24
+    description: Hours after a result arrives before it counts as overdue for review.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only check — flags gaps in review/notification, doesn't interpret clinical results or contact patients itself. Follow your practice's actual critical-value notification protocol for anything flagged abnormal.

package/jobs/hiring/background-check-status-check.yaml

@@ -0,0 +1,35 @@
+id: background-check-status-check
+version: 1
+name: Background Check Status Check
+description: >
+  Checks pending background/reference checks for offered candidates and
+  flags anything stalling close to their planned start date. Use this if a
+  start date has ever slipped because a background check was still
+  pending and nobody noticed until the week before.
+category: hiring
+tags: [hiring, background-check, onboarding, compliance]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{background_check_vendor}} for candidates with a background
+  check still pending, and cross-reference against {{ats_system}} for
+  their planned start dates.
+  1. List each pending check: candidate name, days pending, and planned
+     start date.
+  2. Flag anyone whose start date is within {{escalate_within_days}} days
+     and still has no completed check — that's the one worth chasing the
+     vendor about today.
+  3. If everything's on track, say so in one line.
+variables:
+  background_check_vendor:
+    default: "your background check provider (e.g. Checkr, Sterling)"
+    description: Where background/reference check status is tracked.
+  ats_system:
+    default: "your applicant tracking system"
+    description: Where candidate start dates are recorded.
+  escalate_within_days:
+    default: 5
+    description: Days before start date at which a still-pending check becomes urgent.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only status check — actually chasing the vendor or adjusting a start date is a decision for HR/recruiting to make.

package/jobs/hiring/interview-feedback-overdue-check.yaml

@@ -0,0 +1,33 @@
+id: interview-feedback-overdue-check
+version: 1
+name: Interview Feedback Overdue Check
+description: >
+  Flags interviews that happened but still have no feedback submitted, so
+  the decision doesn't stall waiting on one interviewer. Use this if a
+  candidate has ever been left hanging because feedback from one
+  interviewer never showed up and nobody chased it down.
+category: hiring
+tags: [hiring, interviews, feedback, recruiting]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{ats_system}} for interviews completed in the last
+  {{lookback_hours}} hours with no feedback/scorecard submitted yet.
+  1. List each: candidate name, interviewer, and how long ago the
+     interview happened.
+  2. Flag anyone past {{escalate_after_hours}} hours as needing a direct
+     nudge, not just a passive reminder.
+  3. Draft a short reminder message per overdue interviewer.
+variables:
+  ats_system:
+    default: "your applicant tracking system (e.g. Greenhouse, Lever, Ashby)"
+    description: Where interview feedback/scorecards are recorded.
+  lookback_hours:
+    default: 48
+    description: How far back to check for interviews missing feedback.
+  escalate_after_hours:
+    default: 24
+    description: Hours after an interview before a missing scorecard counts as urgent.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Draft-only — nudge messages should go out through whatever channel your team already uses for interviewer reminders.

package/jobs/hospitality/guest-maintenance-request-backlog-check.yaml

@@ -0,0 +1,35 @@
+id: guest-maintenance-request-backlog-check
+version: 1
+name: Guest Maintenance Request Backlog Check
+description: >
+  Checks how many guest-reported maintenance issues are still open and
+  flags any sitting past your target resolution time. Use this if a
+  reported issue (broken AC, leaking faucet) has ever gone unresolved for
+  days because the request lived in a notebook nobody checked.
+category: hospitality
+tags: [hospitality, maintenance, guest-experience, backlog]
+schedule: "0 */6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v hours="{{sla_hours}}" '
+    NR==1 {next}
+    $2 == "open" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f \"%Y-%m-%d %H:%M\" \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline reported_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      age_hours = (now_epoch - reported_epoch) / 3600;
+      if (age_hours >= hours) {
+        printf "OVERDUE: room %s — %s (open %d hrs)\n", $1, $4, age_hours;
+      }
+    }
+  ' "{{requests_csv_path}}"
+variables:
+  requests_csv_path:
+    default: "./maintenance-requests.csv"
+    description: "Path to a CSV with columns: room_number,status (open/closed),reported_at (YYYY-MM-DD HH:MM),description."
+  sla_hours:
+    default: 4
+    description: Target hours to resolve a guest maintenance request before it counts as overdue.
+compatible_agents: [generic, claude, codex]
+notes: Assumes requests are logged as they come in from front desk/housekeeping — this just cross-checks the log against your SLA, it doesn't dispatch anyone.

package/jobs/hospitality/guest-review-response-check.yaml

@@ -0,0 +1,35 @@
+id: guest-review-response-check
+version: 1
+name: Guest Review Response Check
+description: >
+  Checks for recent guest reviews across your listing platforms that
+  haven't gotten a response yet. Use this if a review has ever sat
+  unanswered for weeks, which future guests read as nobody's paying
+  attention.
+category: hospitality
+tags: [hospitality, reviews, guest-experience, reputation]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{review_platforms}} for reviews posted in the last
+  {{lookback_hours}} hours with no owner/manager response yet.
+  1. List each: platform, rating, and a one-line summary of the review.
+  2. Draft a short, specific response per review (not a copy-paste
+     template) — thank them and reference something specific from their
+     stay if mentioned.
+  3. Flag any review below {{alert_threshold_stars}} stars as needing a
+     more careful, service-recovery-style response rather than a quick
+     thank-you.
+variables:
+  review_platforms:
+    default: "Google, TripAdvisor, Booking.com"
+    description: Comma-separated list of platforms to check.
+  lookback_hours:
+    default: 24
+    description: How far back to check for new unanswered reviews.
+  alert_threshold_stars:
+    default: 3
+    description: Star rating at or below which a review needs a more careful response (out of 5).
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Draft-only — review responses before posting, since they're public and permanent once submitted.

package/jobs/hr/exit-interview-completion-check.yaml

@@ -0,0 +1,33 @@
+id: exit-interview-completion-check
+version: 1
+name: Exit Interview Completion Check
+description: >
+  Flags departing employees whose exit interview hasn't happened yet as
+  their last day approaches. Use this if someone has ever left without an
+  exit interview simply because scheduling it got lost in the handoff
+  paperwork.
+category: hr
+tags: [hr, offboarding, exit-interview, compliance]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{hris_system}} for employees with a last day within
+  {{lookahead_days}} days who don't have an exit interview scheduled or
+  completed.
+  1. List each: name, last day, and manager.
+  2. Flag anyone with a last day inside {{urgent_within_days}} days and no
+     exit interview on the calendar as urgent.
+  3. Draft a short note to HR/the manager to get one scheduled.
+variables:
+  hris_system:
+    default: "your HRIS/offboarding system"
+    description: Name of the system tracking departures and exit interview status.
+  lookahead_days:
+    default: 14
+    description: How far ahead to check for upcoming departures.
+  urgent_within_days:
+    default: 3
+    description: Days before last day at which a missing exit interview becomes urgent.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Draft-only — actually scheduling the interview goes through whatever process HR already uses.