@wonsukchoi/crondex 0.11.0 → 0.12.0

package/jobs/restaurant/food-cost-percentage-watch.yaml

@@ -0,0 +1,35 @@
+id: food-cost-percentage-watch
+version: 1
+name: Food Cost Percentage Watch
+description: >
+  Checks food cost as a percentage of sales against your target and flags
+  it when it runs high. Use this if food cost has ever crept up for weeks
+  before anyone pulled the numbers and noticed margins were shrinking.
+category: restaurant
+tags: [restaurant, food-cost, margin, finance]
+schedule: "0 8 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  cogs="{{food_cost_usd}}";
+  sales="{{sales_revenue_usd}}";
+  target="{{target_food_cost_pct}}";
+  pct=$(awk -v c="$cogs" -v s="$sales" 'BEGIN{ if (s>0) printf "%.1f", (c/s)*100; else print "0" }');
+  if awk -v p="$pct" -v t="$target" 'BEGIN{exit !(p > t)}'; then
+    echo "WARNING: food cost at $pct% of sales (target $target%)";
+    exit 1;
+  else
+    echo "OK: food cost at $pct% of sales (target $target%)";
+  fi
+variables:
+  food_cost_usd:
+    default: 0
+    description: Total cost of food used for the period (from your POS/inventory system).
+  sales_revenue_usd:
+    default: 0
+    description: Total food sales revenue for the same period.
+  target_food_cost_pct:
+    default: 30
+    description: Target food cost as a percentage of sales.
+compatible_agents: [generic, claude, codex]
+notes: Feed in period totals from your POS/accounting export — this compares a single period's ratio, so schedule it to match how often you close out food-cost numbers (weekly is typical).

package/jobs/restaurant/labor-cost-percentage-watch.yaml

@@ -0,0 +1,36 @@
+id: labor-cost-percentage-watch
+version: 1
+name: Labor Cost Percentage Watch
+description: >
+  Checks labor cost as a percentage of sales against your target and
+  flags it when it runs high. Use this if overstaffing on a slow shift
+  has ever quietly eaten a week's margin before anyone pulled the labor
+  numbers and noticed.
+category: restaurant
+tags: [restaurant, labor-cost, margin, finance]
+schedule: "0 8 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  labor="{{labor_cost_usd}}";
+  sales="{{sales_revenue_usd}}";
+  target="{{target_labor_cost_pct}}";
+  pct=$(awk -v l="$labor" -v s="$sales" 'BEGIN{ if (s>0) printf "%.1f", (l/s)*100; else print "0" }');
+  if awk -v p="$pct" -v t="$target" 'BEGIN{exit !(p > t)}'; then
+    echo "WARNING: labor cost at $pct% of sales (target $target%)";
+    exit 1;
+  else
+    echo "OK: labor cost at $pct% of sales (target $target%)";
+  fi
+variables:
+  labor_cost_usd:
+    default: 0
+    description: Total labor cost (wages, not including benefits/taxes unless you want them included) for the period.
+  sales_revenue_usd:
+    default: 0
+    description: Total sales revenue for the same period.
+  target_labor_cost_pct:
+    default: 30
+    description: Target labor cost as a percentage of sales.
+compatible_agents: [generic, claude, codex]
+notes: Parallel structure to `food-cost-percentage-watch` — feed in period totals from your POS/payroll export, scheduled to match how often you close out labor numbers.

package/jobs/retail/employee-shift-gap-check.yaml

@@ -0,0 +1,35 @@
+id: employee-shift-gap-check
+version: 1
+name: Employee Shift Gap Check
+description: >
+  Checks the upcoming schedule for unfilled shifts and flags them while
+  there's still time to find coverage. Use this if a shift has ever gone
+  unfilled and nobody noticed until the store was short-staffed that
+  morning.
+category: retail
+tags: [retail, scheduling, staffing, shifts]
+schedule: "0 9 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v days="{{lookahead_days}}" '
+    NR==1 {next}
+    $3 == "unfilled" {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline shift_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (shift_epoch - now_epoch) / 86400;
+      if (diff_days >= 0 && diff_days <= days) {
+        printf "UNFILLED: %s shift on %s (%d days out)\n", $1, $2, diff_days;
+      }
+    }
+  ' "{{schedule_csv_path}}"
+variables:
+  schedule_csv_path:
+    default: "./employee-schedule.csv"
+    description: "Path to a CSV with columns: shift_name,shift_date (YYYY-MM-DD),status (filled/unfilled)."
+  lookahead_days:
+    default: 7
+    description: How many days ahead to check for unfilled shifts.
+compatible_agents: [generic, claude, codex]
+notes: Export this from your scheduling software (When I Work, Homebase, Deputy) on a schedule to keep the CSV current.

package/jobs/retail/pos-till-reconciliation-check.yaml

@@ -0,0 +1,33 @@
+id: pos-till-reconciliation-check
+version: 1
+name: POS Till Reconciliation Check
+description: >
+  Checks each register's end-of-day cash count against expected POS
+  totals and flags any discrepancy. Use this if a till has ever come up
+  short for days running before anyone connected the pattern to a
+  specific shift or register.
+category: retail
+tags: [retail, pos, cash, reconciliation]
+schedule: "0 23 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{tolerance_usd}}" '
+    NR==1 {next}
+    {
+      diff = $3 - $2;
+      abs_diff = (diff < 0) ? -diff : diff;
+      if (abs_diff > tolerance) {
+        printf "DISCREPANCY: register %s — expected $%.2f, counted $%.2f (diff $%.2f)\n", $1, $2, $3, diff;
+      }
+    }
+  ' "{{till_counts_csv_path}}"
+variables:
+  till_counts_csv_path:
+    default: "./till-counts.csv"
+    description: "Path to a CSV with columns: register_id,pos_expected_total,counted_total — one row per register per closing shift."
+  tolerance_usd:
+    default: 5.00
+    description: Acceptable discrepancy in dollars before flagging.
+compatible_agents: [generic, claude, codex]
+notes: A repeated discrepancy on the same register or shift is a much bigger signal than a single one-off — worth tracking over time, not just per-day.

package/jobs/retail/store-opening-checklist-reminder.yaml

@@ -0,0 +1,30 @@
+id: store-opening-checklist-reminder
+version: 1
+name: Store Opening Checklist Reminder
+description: >
+  Reminds the opening shift of the standard opening checklist every day,
+  not just when a manager happens to be on site to run it from memory.
+  Use this if the store has ever opened late, or opened with something
+  missed (lights, POS not booted, signage not out), because the checklist
+  lived only in one person's head.
+category: retail
+tags: [retail, checklist, opening, operations]
+schedule: "0 8 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  echo "Store opening checklist ({{checklist_path}}):";
+  if [ -f "{{checklist_path}}" ]; then cat "{{checklist_path}}"; else
+  echo "- Unlock doors, disarm alarm";
+  echo "- Turn on lights, signage, music";
+  echo "- Boot and log into POS terminals";
+  echo "- Count starting cash drawer";
+  echo "- Check overnight deliveries/restocking needs";
+  echo "- Walk the floor for cleanliness/facing";
+  fi
+variables:
+  checklist_path:
+    default: "./store-opening-checklist.txt"
+    description: Optional path to your own custom checklist file; falls back to a standard baseline if not found.
+compatible_agents: [generic, claude, codex]
+notes: A recurring reminder/checklist print, not an automated door-unlock or alarm system — pair with your actual physical security systems as needed.

package/jobs/support/agent-workload-balance-check.yaml

@@ -0,0 +1,30 @@
+id: agent-workload-balance-check
+version: 1
+name: Support Agent Workload Balance Check
+description: >
+  Checks how open tickets are distributed across agents and flags a real
+  imbalance. Use this if one agent has ever quietly ended up carrying
+  double the ticket load of a teammate because assignment was manual and
+  nobody was watching the split.
+category: support
+tags: [support, workload, agents, balance]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{helpdesk_platform}} for currently open ticket counts per agent.
+  1. List each agent's open ticket count.
+  2. Flag any agent carrying {{imbalance_multiplier}}x or more the team
+     average as overloaded.
+  3. Flag any agent with zero or very few open tickets while others are
+     overloaded — that's the other half of the imbalance worth surfacing.
+  4. If the distribution looks reasonably even, say so in one line.
+variables:
+  helpdesk_platform:
+    default: "your helpdesk (e.g. Zendesk, Intercom, Freshdesk)"
+    description: Where ticket assignment data is tracked.
+  imbalance_multiplier:
+    default: 1.5
+    description: How many times above the team average counts as overloaded.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only signal — rebalancing assignments is a team-lead decision, not something this job does automatically.

package/jobs/support/ticket-reopened-rate-watch.yaml

@@ -0,0 +1,35 @@
+id: ticket-reopened-rate-watch
+version: 1
+name: Ticket Reopened Rate Watch
+description: >
+  Checks what percentage of closed tickets get reopened and flags it when
+  the rate climbs — a quality signal that's different from SLA or backlog
+  size. Use this if tickets have ever been closed to hit a metric and
+  quietly bounced right back, without anyone tracking the reopen rate
+  itself.
+category: support
+tags: [support, tickets, quality, reopened]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{helpdesk_platform}} for tickets closed in the last
+  {{lookback_days}} days.
+  1. Calculate what percentage were reopened at least once after closing.
+  2. Compare against the target of {{target_reopen_pct}}%.
+  3. If above target, look for a pattern in the reopened tickets — same
+     agent, same issue category, same customer — rather than treating
+     each as an isolated case.
+  4. If at or below target, report the rate in one line.
+variables:
+  helpdesk_platform:
+    default: "your helpdesk (e.g. Zendesk, Intercom, Freshdesk)"
+    description: Where ticket status history is tracked.
+  lookback_days:
+    default: 7
+    description: How far back to check closed tickets.
+  target_reopen_pct:
+    default: 5
+    description: Target reopen rate percentage — above this is worth investigating.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: A high reopen rate usually points at a process problem (closing too early, incomplete fixes) rather than any single ticket being mishandled — read it as a trend, not a per-ticket blame signal.

package/jobs/team/on-call-fatigue-check.yaml

@@ -0,0 +1,39 @@
+id: on-call-fatigue-check
+version: 1
+name: On-Call Fatigue Check
+description: >
+  Checks the on-call rotation history and flags if the same person has
+  been covering on-call more often than the rotation intends. Use this if
+  someone has ever quietly ended up on-call three weeks running because
+  swaps kept landing on the same person and nobody was tracking the
+  pattern.
+category: team
+tags: [team, oncall, rotation, burnout]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v weeks="{{lookback_weeks}}" -v max_share="{{max_share_pct}}" '
+    NR==1 {next}
+    { count[$1]++; total++ }
+    END {
+      for (person in count) {
+        pct = (count[person] / total) * 100;
+        if (pct >= max_share) {
+          printf "IMBALANCE: %s covered %d of %d on-call shifts (%.0f%%) in the last %s weeks\n", person, count[person], total, pct, weeks;
+        }
+      }
+    }
+  ' "{{oncall_history_csv_path}}"
+variables:
+  oncall_history_csv_path:
+    default: "./oncall-history.csv"
+    description: "Path to a CSV with one row per on-call shift, column: person_name — covering the lookback window."
+  lookback_weeks:
+    default: 8
+    description: How many weeks of on-call history the CSV covers (for labeling output).
+  max_share_pct:
+    default: 40
+    description: Percentage share of total shifts above which one person is carrying a disproportionate load.
+compatible_agents: [generic, claude, codex]
+notes: Complements `oncall-handoff-reminder` (per-shift handoff notes) by looking at the rotation pattern over time instead of a single handoff.

package/jobs/veterinary/boarding-checkout-reminder.yaml

@@ -0,0 +1,29 @@
+id: boarding-checkout-reminder
+version: 1
+name: Boarding/Kennel Checkout Reminder
+description: >
+  Lists pets scheduled to check out of boarding today or tomorrow, plus
+  anyone past their scheduled checkout with no extension logged. Use this
+  if a boarded pet has ever stayed an extra unplanned day because nobody
+  cross-checked the boarding calendar against who was actually still
+  there.
+category: veterinary
+tags: [veterinary, boarding, kennel, schedule]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%Y-%m-%d);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    {
+      if ($3 == today) print "CHECKOUT TODAY: " $1 " (" $2 ")";
+      else if ($3 < today && $4 != "extended") print "OVERDUE CHECKOUT: " $1 " (" $2 ") — was due " $3;
+    }
+  ' "{{boarding_csv_path}}"
+variables:
+  boarding_csv_path:
+    default: "./boarding-schedule.csv"
+    description: "Path to a CSV with columns: pet_name,owner_name,checkout_date (YYYY-MM-DD),status (or 'extended' if the stay was extended)."
+compatible_agents: [generic, claude, codex]
+notes: Update the CSV whenever a stay is extended so it doesn't get flagged as overdue — this just cross-checks dates, it doesn't know about a phone call extending someone's stay.

package/jobs/veterinary/controlled-substance-log-audit.yaml

@@ -0,0 +1,33 @@
+id: controlled-substance-log-audit
+version: 1
+name: Controlled Substance Log Audit
+description: >
+  Checks the controlled-substance usage log for gaps or unreconciled
+  counts. Use this if a discrepancy in the controlled-drug log has ever
+  gone unnoticed for weeks instead of being caught the same day it
+  happened, which is exactly what a DEA/board inspection will ask about.
+category: veterinary
+tags: [veterinary, controlled-substances, compliance, audit]
+schedule: "0 20 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Read today's controlled-substance log from {{log_source}} for
+  {{substances_tracked}}.
+  1. Check that every entry has a matching patient/case reference — flag
+     any entry missing one.
+  2. Compare running balance against the last physical count on record;
+     flag any mismatch.
+  3. Flag any day with zero entries logged if the practice was open and
+     controlled substances are known to be in regular use — a
+     suspiciously quiet log is itself worth a second look.
+  4. If everything reconciles, say so in one line.
+variables:
+  log_source:
+    default: "your controlled-substance log (paper log photographed/transcribed, or e-log system)"
+    description: Where the controlled-substance usage log is recorded.
+  substances_tracked:
+    default: "ketamine, butorphanol, and other Schedule II-IV substances kept on site"
+    description: Which substances this log covers.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only reconciliation check — does not replace your practice's actual DEA-compliant logging system, and any discrepancy found should go through your normal reporting/investigation process.

package/jobs/veterinary/pet-vaccine-due-reminder.yaml

@@ -0,0 +1,34 @@
+id: pet-vaccine-due-reminder
+version: 1
+name: Pet Vaccine Due Reminder
+description: >
+  Checks which patients are due or overdue for a vaccine and lists them
+  for outreach. Use this if a pet has ever gone a year past due for a
+  core vaccine because the reminder postcard got lost in the mail.
+category: veterinary
+tags: [veterinary, vaccine, patients, reminder]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (due_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "VACCINE DUE: %s (%s) — %s due %s (%d days)\n", $1, $2, $4, $3, diff_days;
+      }
+    }
+  ' "{{patients_csv_path}}"
+variables:
+  patients_csv_path:
+    default: "./pet-vaccines.csv"
+    description: "Path to a CSV with columns: pet_name,owner_name,due_date (YYYY-MM-DD),vaccine_type."
+  warn_days_before:
+    default: 14
+    description: How many days before (or past) the due date to start listing.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a maintained export from your practice management software — this is the "did anyone actually check the due list" backstop.

package/jobs/warehousing/climate-control-compliance-check.yaml

@@ -0,0 +1,40 @@
+id: climate-control-compliance-check
+version: 1
+name: Warehouse Climate Control Compliance Check
+description: >
+  Checks temperature/humidity logs for climate-controlled storage areas
+  and flags any reading outside the safe range. Use this if product has
+  ever been damaged or spoiled because a climate-controlled zone drifted
+  out of range and nobody noticed until the next physical walk-through.
+category: warehousing
+tags: [warehousing, climate-control, compliance, storage]
+schedule: "0 */4 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min_t="{{min_temp_f}}" -v max_t="{{max_temp_f}}" -v min_h="{{min_humidity_pct}}" -v max_h="{{max_humidity_pct}}" '
+    NR==1 {next}
+    {
+      if ($2 < min_t || $2 > max_t || $3 < min_h || $3 > max_h) {
+        printf "OUT OF RANGE: %s — %sF, %s%% humidity (limits %s-%sF, %s-%s%%)\n", $1, $2, $3, min_t, max_t, min_h, max_h;
+      }
+    }
+  ' "{{readings_csv_path}}"
+variables:
+  readings_csv_path:
+    default: "./climate-readings.csv"
+    description: "Path to a CSV with columns: zone_name,temperature_f,humidity_pct — latest sensor readings per zone."
+  min_temp_f:
+    default: 60
+    description: Minimum acceptable temperature in Fahrenheit.
+  max_temp_f:
+    default: 75
+    description: Maximum acceptable temperature in Fahrenheit.
+  min_humidity_pct:
+    default: 30
+    description: Minimum acceptable relative humidity percentage.
+  max_humidity_pct:
+    default: 60
+    description: Maximum acceptable relative humidity percentage.
+compatible_agents: [generic, claude, codex]
+notes: Assumes readings are exported from your sensor/IoT system on a schedule matching this job's frequency — adjust thresholds per what's actually stored in each zone.

package/jobs/warehousing/dock-schedule-conflict-check.yaml

@@ -0,0 +1,30 @@
+id: dock-schedule-conflict-check
+version: 1
+name: Loading Dock Schedule Conflict Check
+description: >
+  Checks tomorrow's dock appointments for double-bookings or gaps too
+  tight to actually unload a truck in. Use this if two carriers have ever
+  shown up for the same dock door at the same time because scheduling was
+  done in a shared spreadsheet nobody cross-checked.
+category: warehousing
+tags: [warehousing, dock-scheduling, logistics, conflicts]
+schedule: "0 16 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check tomorrow's dock appointment schedule from {{scheduling_source}}.
+  1. Flag any two appointments assigned to the same dock door with
+     overlapping time windows.
+  2. Flag any appointment scheduled with less than
+     {{min_turnaround_minutes}} minutes between it and the next one at
+     the same door — likely too tight for an actual unload.
+  3. If the schedule is clean, say so in one line.
+variables:
+  scheduling_source:
+    default: "your dock scheduling system or shared spreadsheet"
+    description: Where dock appointments are booked.
+  min_turnaround_minutes:
+    default: 30
+    description: Minimum minutes needed between appointments at the same dock door.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only conflict check — resolving a found conflict (rebooking one carrier) is a dispatcher decision.

package/jobs/warehousing/pick-pack-error-rate-watch.yaml

@@ -0,0 +1,35 @@
+id: pick-pack-error-rate-watch
+version: 1
+name: Pick/Pack Error Rate Watch
+description: >
+  Checks recent order fulfillment error rate (wrong item, wrong quantity,
+  missing item) against a target and flags it when it climbs. Use this if
+  a fulfillment error rate has ever crept up for weeks before a spike in
+  return/complaint volume made the problem impossible to ignore.
+category: warehousing
+tags: [warehousing, fulfillment, quality, errors]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target="{{target_error_rate_pct}}" '
+    NR==1 {next}
+    { total++; if ($2 == "error") errors++ }
+    END {
+      pct = (total > 0) ? (errors / total) * 100 : 0;
+      if (pct > target) {
+        printf "ABOVE TARGET: %.2f%% error rate (%d of %d orders), target %.2f%%\n", pct, errors, total, target;
+      } else {
+        printf "OK: %.2f%% error rate (%d of %d orders)\n", pct, errors, total;
+      }
+    }
+  ' "{{orders_csv_path}}"
+variables:
+  orders_csv_path:
+    default: "./fulfillment-log.csv"
+    description: "Path to a CSV with columns: order_id,outcome (ok/error) — one row per fulfilled order in the period."
+  target_error_rate_pct:
+    default: 1.0
+    description: Target maximum error rate as a percentage.
+compatible_agents: [generic, claude, codex]
+notes: If errors cluster on a specific picker, shift, or SKU, that's worth investigating separately — this job only flags the aggregate rate crossing target.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wonsukchoi/crondex",
-  "version": "0.11.0",
+  "version": "0.12.0",
   "description": "A public directory of pre-made, agent-editable cron jobs.",
   "type": "module",
   "license": "MIT",