@wonsukchoi/crondex 0.21.0 → 0.23.0

package/jobs/restaurant/daily-sales-flash-report.yaml

@@ -0,0 +1,36 @@
+id: daily-sales-flash-report
+version: 1
+name: Daily Sales Flash Report
+description: >
+  Pulls yesterday's key sales numbers (net sales, covers, average check,
+  comp/void total) and compares them against the same day last week and
+  last year, then writes a short flash summary. Use this if you've ever
+  wanted a same-day read on how the restaurant performed without
+  waiting for the full weekly P&L close.
+category: restaurant
+tags: [restaurant, sales, flash-report, reporting]
+schedule: "0 7 * * *"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull yesterday's sales summary from {{pos_system}}: net sales, covers,
+  average check, comp/void total, and sales by daypart if available.
+  1. Also pull the same weekday from last week and, if available, the
+     same date last year for comparison.
+  2. Present a short flash summary: yesterday's numbers, % change vs.
+     last week same day, and % change vs. last year same date.
+  3. Flag anything notably off-trend (net sales or covers down more
+     than {{flag_threshold_pct}}% vs. last week same day) with a
+     one-line possible explanation if context is available (weather,
+     local event, holiday).
+  4. Keep the whole report to a few sentences plus the numbers table —
+     this is a same-day pulse check, not a full P&L.
+variables:
+  pos_system:
+    default: "your POS system"
+    description: Name of the point-of-sale system (e.g. "Toast", "Square", "Aloha").
+  flag_threshold_pct:
+    default: 15
+    description: Percentage decline vs. last week same day that triggers a flag in the summary.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: A same-day directional pulse check, not a substitute for the formal weekly/period close that feeds food-cost-percentage-watch and labor-cost-percentage-watch.

package/jobs/restaurant/delivery-platform-commission-reconciliation.yaml

@@ -0,0 +1,33 @@
+id: delivery-platform-commission-reconciliation
+version: 1
+name: Third-Party Delivery Commission Reconciliation
+description: >
+  Recalculates what a delivery platform (DoorDash, Uber Eats, Grubhub)
+  should have paid out after commission and fees, and flags orders
+  where the actual payout came in lower than expected. Use this if
+  you've ever suspected a delivery platform's payout report doesn't
+  quite match its own published commission rate but never checked.
+category: restaurant
+tags: [restaurant, delivery, commission, reconciliation, third-party]
+schedule: "0 9 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{variance_tolerance_usd}}" '
+    NR==1 {next}
+    {
+      expected = $2 * (1 - ($3 / 100)) - $4;
+      diff = expected - $5;
+      absdiff = (diff < 0) ? -diff : diff;
+      if (absdiff > tolerance) printf "PAYOUT MISMATCH: order %s (%s) — expected payout $%.2f, actual $%.2f (diff $%.2f)\n", $1, $6, expected, $5, diff;
+    }
+  ' "{{delivery_payout_csv}}"
+variables:
+  delivery_payout_csv:
+    default: "./delivery-payouts.csv"
+    description: "CSV with header row, columns: order_id,order_subtotal_usd,commission_pct,other_fees_usd,actual_payout_usd,platform_name."
+  variance_tolerance_usd:
+    default: 1
+    description: Dollar variance allowed between expected and actual payout before an order is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Pull order_subtotal_usd and actual_payout_usd from the platform's own payout CSV export; commission_pct should match your current contracted rate, which platforms occasionally change without a clear notice.

package/jobs/restaurant/delivery-receiving-discrepancy-check.yaml

@@ -0,0 +1,33 @@
+id: delivery-receiving-discrepancy-check
+version: 1
+name: Supplier Delivery Receiving Discrepancy Check
+description: >
+  Compares what was ordered from a supplier against what was actually
+  received on the delivery receiving log and flags shortages or
+  overages. Use this if a supplier has ever shorted a case of product
+  and it only got noticed mid-service when the kitchen ran out.
+category: restaurant
+tags: [restaurant, suppliers, receiving, inventory]
+schedule: "0 12 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{qty_tolerance_pct}}" '
+    NR==1 {next}
+    {
+      if ($2 > 0) {
+        diff_pct = (($3 - $2) / $2) * 100;
+        absdiff = (diff_pct < 0) ? -diff_pct : diff_pct;
+        if (absdiff > tolerance) printf "DISCREPANCY: %s from %s — ordered %d, received %d (%.1f%% off)\n", $1, $4, $2, $3, diff_pct;
+      }
+    }
+  ' "{{receiving_log_csv}}"
+variables:
+  receiving_log_csv:
+    default: "./receiving-log.csv"
+    description: "CSV with header row, columns: item_name,qty_ordered,qty_received,supplier_name — one row per delivered line item."
+  qty_tolerance_pct:
+    default: 5
+    description: Percentage difference between ordered and received quantity allowed before a line item is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Have whoever signs for the delivery log qty_received per line before signing — this catches shortages/overages that a total-case-count check would miss.

package/jobs/restaurant/food-handler-permit-expiry-tracker.yaml

@@ -0,0 +1,33 @@
+id: food-handler-permit-expiry-tracker
+version: 1
+name: Food Handler Permit Expiry Tracker
+description: >
+  Checks staff food handler permits and manager certifications
+  (ServSafe or your local equivalent) against their expiration dates
+  and flags anyone expiring soon. Use this if a health inspector has
+  ever asked for a permit that had quietly lapsed weeks earlier.
+category: restaurant
+tags: [restaurant, compliance, certification, staff]
+schedule: "0 8 1 * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn="{{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 expiry_epoch; close(cmd);
+      days_left = (expiry_epoch - today) / 86400;
+      if (days_left <= warn) printf "PERMIT EXPIRING: %s — %s expires %s (%d days left)\n", $1, $2, $3, days_left;
+    }
+  ' "{{food_handler_permits_csv}}"
+variables:
+  food_handler_permits_csv:
+    default: "./food-handler-permits.csv"
+    description: "CSV with header row, columns: employee_name,permit_type,expiration_date (YYYY-MM-DD)."
+  warn_days_before:
+    default: 30
+    description: Days before expiration to start warning, giving time to schedule recertification.
+compatible_agents: [generic, claude, codex]
+notes: Requirements (which roles need a permit, renewal cadence) vary by state/county — confirm against your local health department before relying on this alone.

package/jobs/restaurant/gift-card-liability-check.yaml

@@ -0,0 +1,45 @@
+id: gift-card-liability-check
+version: 1
+name: Gift Card Liability Reconciliation
+description: >
+  Reconciles total outstanding gift card balance (liability) against
+  cards sold minus cards redeemed for the period, and flags a mismatch
+  worth investigating. Use this if you've ever had to guess at your
+  gift card liability for the books instead of actually reconciling it.
+category: restaurant
+tags: [restaurant, gift-cards, finance, reconciliation]
+schedule: "0 9 1 * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  sold="{{gift_cards_sold_usd}}";
+  redeemed="{{gift_cards_redeemed_usd}}";
+  prior="{{prior_period_liability_usd}}";
+  ledger="{{current_ledger_balance_usd}}";
+  tolerance="{{variance_tolerance_usd}}";
+  expected=$(awk -v p="$prior" -v s="$sold" -v r="$redeemed" 'BEGIN{printf "%.2f", p+s-r}');
+  diff=$(awk -v e="$expected" -v l="$ledger" 'BEGIN{d=e-l; if (d<0) d=-d; printf "%.2f", d}');
+  if awk -v d="$diff" -v t="$tolerance" 'BEGIN{exit !(d > t)}'; then
+    echo "MISMATCH: expected liability \$$expected, ledger shows \$$ledger (diff \$$diff)";
+    exit 1;
+  else
+    echo "OK: gift card liability reconciles within tolerance (\$$diff diff)";
+  fi
+variables:
+  gift_cards_sold_usd:
+    default: 0
+    description: Total value of gift cards sold during the period.
+  gift_cards_redeemed_usd:
+    default: 0
+    description: Total value of gift cards redeemed during the period.
+  prior_period_liability_usd:
+    default: 0
+    description: Outstanding gift card liability carried over from the prior period.
+  current_ledger_balance_usd:
+    default: 0
+    description: Current outstanding gift card balance as recorded in your accounting ledger.
+  variance_tolerance_usd:
+    default: 25
+    description: Dollar variance allowed before the reconciliation is flagged as a mismatch.
+compatible_agents: [generic, claude, codex]
+notes: This reconciles aggregate liability for the books, not individual card expiry — pair with a per-card expiry check if your state allows gift cards to expire.

package/jobs/restaurant/kitchen-ticket-time-watch.yaml

@@ -0,0 +1,38 @@
+id: kitchen-ticket-time-watch
+version: 1
+name: Kitchen Ticket Time Watch
+description: >
+  Reviews kitchen display system ticket times (fire to plate-up) and
+  flags stations or dayparts running consistently slower than target.
+  Use this if slow ticket times have ever driven complaints or comps
+  before anyone traced it back to a specific station falling behind.
+category: restaurant
+tags: [restaurant, kitchen, kds, speed-of-service]
+schedule: "0 10 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull ticket time data from {{kds_system}} for the past
+  {{lookback_days}} days, including station, item, fire time, and
+  plate-up time.
+  1. Calculate average ticket time overall and by station.
+  2. Flag any station averaging above {{target_minutes}} minutes, and
+     note whether the slowness is concentrated at specific dayparts
+     (peak lunch/dinner rushes vs. slow periods).
+  3. Identify the specific menu items driving the slowest tickets at
+     each flagged station.
+  4. Suggest one concrete fix per flagged station — additional prep,
+     station staffing, or menu item batching — without recommending
+     cutting a dish outright unless it's clearly the only lever.
+variables:
+  kds_system:
+    default: "your kitchen display system"
+    description: Name of the KDS (e.g. "Toast KDS", "QSR Automations", "a manual ticket-time log").
+  lookback_days:
+    default: 14
+    description: Window of ticket data to analyze.
+  target_minutes:
+    default: 15
+    description: Target average ticket time in minutes before a station is flagged as running slow.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only speed-of-service analysis — pair with kitchen leadership before making staffing changes based on the findings.

package/jobs/restaurant/liquor-pour-cost-variance-check.yaml

@@ -0,0 +1,34 @@
+id: liquor-pour-cost-variance-check
+version: 1
+name: Liquor Pour Cost Variance Check
+description: >
+  Compares each bottle's theoretical usage (from drinks sold) against
+  actual bottle depletion from inventory counts, and flags bottles
+  showing a variance that points to over-pouring, spillage, or theft.
+  Use this if the bar's overall liquor cost percentage looks fine but
+  you suspect a specific bottle is walking off faster than it's rung up.
+category: restaurant
+tags: [restaurant, bar, liquor-cost, inventory, loss-prevention]
+schedule: "0 7 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{variance_tolerance_pct}}" '
+    NR==1 {next}
+    {
+      if ($2 > 0) {
+        variance_pct = (($3 - $2) / $2) * 100;
+        absvar = (variance_pct < 0) ? -variance_pct : variance_pct;
+        if (absvar > tolerance) printf "POUR VARIANCE: %s — theoretical usage %.1f oz, actual depletion %.1f oz (%.1f%% variance)\n", $1, $2, $3, variance_pct;
+      }
+    }
+  ' "{{pour_cost_csv}}"
+variables:
+  pour_cost_csv:
+    default: "./liquor-pour-cost.csv"
+    description: "CSV with header row, columns: bottle_name,theoretical_usage_oz,actual_depletion_oz — theoretical comes from POS drink sales times recipe pour size, actual from physical bottle counts."
+  variance_tolerance_pct:
+    default: 10
+    description: Percentage variance (either direction) allowed before a bottle is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from food-cost-percentage-watch and menu-item-profitability-check — this drills into per-bottle variance at the bar rather than an overall cost ratio or a food dish's margin.

package/jobs/restaurant/menu-86-frequency-tracker.yaml

@@ -0,0 +1,39 @@
+id: menu-86-frequency-tracker
+version: 1
+name: Menu Item 86 Frequency Tracker
+description: >
+  Reviews how often each menu item gets 86'd (marked sold out) mid-
+  service and flags items that run out repeatedly, which usually points
+  to a par-level or ordering problem rather than one bad night. Use
+  this if the same dish has ever been 86'd three Fridays in a row
+  before anyone connected the dots.
+category: restaurant
+tags: [restaurant, menu, kitchen, ordering, par-levels]
+schedule: "0 10 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull 86 (sold-out) log entries from {{pos_or_kitchen_log}} for the
+  past {{lookback_days}} days, including item name, time 86'd, and
+  time (if any) it came back available.
+  1. Rank menu items by number of times 86'd in the window.
+  2. For each item 86'd more than {{repeat_threshold}} times, note the
+     typical time of day/day of week it runs out, which suggests
+     whether it's a prep-quantity or a purchasing-quantity issue.
+  3. Flag any item that's been 86'd on back-to-back service days —
+     that's a stronger signal than scattered one-offs.
+  4. Suggest a par-level or prep-batch adjustment per repeatedly-86'd
+     item, distinct from a general waste-log review which looks at
+     over-ordering rather than under-ordering.
+variables:
+  pos_or_kitchen_log:
+    default: "your POS 86 list or kitchen display system"
+    description: Where 86'd items get logged (e.g. "Toast 86 list", "a kitchen whiteboard log transcribed daily").
+  lookback_days:
+    default: 30
+    description: Window of 86-log history to analyze.
+  repeat_threshold:
+    default: 3
+    description: Minimum number of times an item must be 86'd in the window to be called out individually.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Complements inventory-waste-log-review — that job catches over-ordering (waste), this one catches under-ordering (running out).

package/jobs/restaurant/menu-item-profitability-check.yaml

@@ -0,0 +1,33 @@
+id: menu-item-profitability-check
+version: 1
+name: Menu Item Profitability Check
+description: >
+  Compares each menu item's plate cost against its menu price and flags
+  items whose contribution margin has dropped below target. Use this if
+  an ingredient cost has ever crept up on a specific dish until it was
+  quietly losing money on every order, unlike the overall food-cost
+  percentage which only shows the average.
+category: restaurant
+tags: [restaurant, menu-engineering, margin, food-cost]
+schedule: "0 8 1 * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v target="{{min_margin_pct}}" '
+    NR==1 {next}
+    {
+      if ($3 > 0) {
+        margin_pct = (($3 - $2) / $3) * 100;
+        if (margin_pct < target) printf "LOW MARGIN: %s — plate cost $%.2f, price $%.2f, margin %.1f%% (target %.0f%%)\n", $1, $2, $3, margin_pct, target;
+      }
+    }
+  ' "{{menu_cost_csv}}"
+variables:
+  menu_cost_csv:
+    default: "./menu-item-costs.csv"
+    description: "CSV with header row, columns: item_name,plate_cost_usd,menu_price_usd — one row per active menu item."
+  min_margin_pct:
+    default: 65
+    description: Minimum acceptable contribution margin percentage before an item is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Rebuild menu-item-costs.csv whenever a recipe or ingredient price changes — this compares per-item margin, not the restaurant-wide average that food-cost-percentage-watch checks.

package/jobs/restaurant/pos-end-of-day-reconciliation-check.yaml

@@ -0,0 +1,31 @@
+id: pos-end-of-day-reconciliation-check
+version: 1
+name: POS End-of-Day Reconciliation Check
+description: >
+  Compares the POS system's expected cash-drawer total against what was
+  actually counted at close and flags any shift over the acceptable
+  variance. Use this if a drawer has ever come up short (or suspiciously
+  over) and nobody traced it back to which shift it happened on.
+category: restaurant
+tags: [restaurant, pos, cash-handling, reconciliation]
+schedule: "0 6 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{variance_tolerance_usd}}" '
+    NR==1 {next}
+    {
+      diff = $4 - $3;
+      absdiff = (diff < 0) ? -diff : diff;
+      if (absdiff > tolerance) printf "VARIANCE: %s shift %s — expected $%.2f, counted $%.2f (diff $%.2f)\n", $1, $2, $3, $4, diff;
+    }
+  ' "{{eod_close_csv}}"
+variables:
+  eod_close_csv:
+    default: "./eod-close-log.csv"
+    description: "CSV with header row, columns: close_date,shift_name,pos_expected_usd,counted_usd — one row per drawer close."
+  variance_tolerance_usd:
+    default: 10
+    description: Dollar variance (either direction) allowed before a shift close is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Export the close log from your POS's end-of-day/drawer-count report — this only compares totals, it doesn't investigate the cause of a variance.

package/jobs/restaurant/table-turnover-rate-tracker.yaml

@@ -0,0 +1,36 @@
+id: table-turnover-rate-tracker
+version: 1
+name: Table Turnover Rate Tracker
+description: >
+  Analyzes seating and table-clear timestamps to calculate average
+  table turnover time by section, day, and shift, and flags where
+  tables are sitting occupied well past the typical dining window. Use
+  this if you suspect one section or server is quietly slowing down
+  the whole dining room's throughput on busy nights.
+category: restaurant
+tags: [restaurant, front-of-house, tables, throughput]
+schedule: "0 10 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull seated and table-cleared timestamps from {{pos_or_reservation_system}}
+  for the past {{lookback_days}} days.
+  1. Calculate average table turnover time (seated to cleared) overall,
+     then broken down by section, day of week, and shift (lunch/dinner).
+  2. Flag any section or shift where average turnover time is
+     meaningfully above the overall average, and estimate the covers
+     lost to the slowdown based on typical table demand at that time.
+  3. Note any pattern tied to a specific server or table size, if that
+     data is available, without naming individuals punitively — this is
+     for staffing/floor-plan decisions, not performance write-ups.
+  4. Recommend one concrete adjustment (seating flow, bussing staffing,
+     course pacing) for the slowest-flagged segment.
+variables:
+  pos_or_reservation_system:
+    default: "your POS or table-management system"
+    description: System that logs seat and clear timestamps (e.g. "Toast", "OpenTable", "SevenRooms").
+  lookback_days:
+    default: 14
+    description: Window of turnover data to analyze.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only analysis for floor-plan and staffing decisions — do not use this to single out individual servers without corroborating context.

package/jobs/restaurant/waitlist-conversion-check.yaml

@@ -0,0 +1,37 @@
+id: waitlist-conversion-check
+version: 1
+name: Waitlist-to-Seated Conversion Check
+description: >
+  Analyzes waitlist app data to see what share of people who joined the
+  waitlist actually got seated versus walked away, and whether quoted
+  wait times matched reality. Use this if you suspect an overly
+  optimistic quoted wait time is quietly driving guests to leave before
+  their table is ready.
+category: restaurant
+tags: [restaurant, front-of-house, waitlist, guest-experience]
+schedule: "0 11 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull waitlist entries from {{waitlist_app}} for the past
+  {{lookback_days}} days, including join time, quoted wait, actual seated
+  time (or abandoned/no-show status), and party size.
+  1. Calculate overall waitlist-to-seated conversion rate and the
+     abandonment rate (left before being seated).
+  2. Compare quoted wait time to actual wait time — flag any pattern
+     where actual wait consistently runs longer than quoted, which
+     likely drives abandonment.
+  3. Break down conversion rate by day of week, time slot, and party
+     size — flag the weakest-converting segments.
+  4. Recommend whether quoted wait times need adjusting for the
+     flagged segments, or whether a text-notification/callback flow
+     would reduce walk-aways.
+variables:
+  waitlist_app:
+    default: "your waitlist/reservation app"
+    description: Name of the waitlist system (e.g. "Yelp Waitlist", "NoWait", "Toast Tables").
+  lookback_days:
+    default: 30
+    description: Window of waitlist history to analyze.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only analysis — any change to quoted-wait logic or staffing is a floor-management decision for a human to make.

package/jobs/retail/cash-office-deposit-variance-check.yaml

@@ -0,0 +1,34 @@
+id: cash-office-deposit-variance-check
+version: 1
+name: Cash Office Deposit Variance Check
+description: >
+  Compares the bank deposit slip amount against the store's total
+  reported cash sales for the day and flags a mismatch. Use this if a
+  bank deposit has ever come up short of what the registers reported for
+  days before anyone in accounting reconciled it back to a specific
+  store.
+category: retail
+tags: [retail, cash, deposit, reconciliation]
+schedule: "0 10 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v tolerance="{{tolerance_usd}}" '
+    NR==1 {next}
+    {
+      diff = $2 - $3;
+      abs_diff = (diff < 0) ? -diff : diff;
+      if (abs_diff > tolerance) {
+        printf "DEPOSIT VARIANCE: store %s — reported cash $%.2f, bank deposit $%.2f (diff $%.2f)\n", $1, $2, $3, diff;
+      }
+    }
+  ' "{{deposit_log_csv}}"
+variables:
+  deposit_log_csv:
+    default: "./cash-deposit-log.csv"
+    description: "CSV with header row, columns: store_id,pos_reported_cash_total,bank_deposit_amount — one row per store per deposit day."
+  tolerance_usd:
+    default: 10.00
+    description: Acceptable variance in dollars between reported cash and the actual bank deposit before flagging.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from `pos-till-reconciliation-check` (per-register count at close) — this checks the far end of the process, the actual bank deposit against total reported store cash.

package/jobs/retail/competitor-price-monitoring-check.yaml

@@ -0,0 +1,42 @@
+id: competitor-price-monitoring-check
+version: 1
+name: Competitor Price Monitoring Check
+description: >
+  Reviews a nearby competitor's weekly ad/flyer or in-store price shots
+  against your own shelf prices for a shortlist of high-traffic items.
+  Use this if you've ever found out you were losing foot traffic to a
+  competitor's price on a staple item only because a customer mentioned
+  it at the register.
+category: retail
+tags: [retail, pricing, competitor, monitoring]
+schedule: "0 9 * * 5"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Compare the competitor's current weekly ad/flyer or in-store price
+  photos ({{competitor_source_path}}) against our own shelf prices
+  ({{our_price_list_csv}}) for the tracked item list.
+  1. For each tracked item, find the competitor's current price if it
+     appears in the source material.
+  2. Flag any item where the competitor's price is at least
+     ${{diff_threshold_usd}} cheaper than ours.
+  3. Note any item the competitor doesn't appear to be carrying anymore
+     versus one you simply couldn't find a price for.
+  4. Summarize as a short list ranked by dollar gap, for the store
+     manager to decide on a price-match or promo response this week.
+variables:
+  competitor_source_path:
+    default: "./competitor-flyers/"
+    description: Folder of this week's competitor flyer scans or in-store price photos.
+  our_price_list_csv:
+    default: "./tracked-items-price-list.csv"
+    description: "CSV with columns: sku,item_name,our_price — the shortlist of high-traffic items being watched."
+  diff_threshold_usd:
+    default: 1.00
+    description: Minimum price gap in dollars worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Physical-store competitor price checks off flyers/photos, distinct from
+  ecommerce's `competitor-price-watch`, which scrapes a competitor's live
+  product page URL per SKU — there's no comparable URL for a
+  brick-and-mortar competitor's shelf price. See duplicates-allowlist.js.

package/jobs/retail/damaged-merchandise-writeoff-tracker.yaml

@@ -0,0 +1,41 @@
+id: damaged-merchandise-writeoff-tracker
+version: 1
+name: Damaged Merchandise Write-Off Tracker
+description: >
+  Reviews logged damaged/defective merchandise write-offs for patterns
+  worth a closer look — a single SKU with a recurring damage reason, or
+  one store writing off well above the chain average. Use this if
+  write-offs have ever just gotten rubber-stamped monthly instead of
+  getting checked for a root cause (bad packaging, a rough receiving
+  process, or something less innocent).
+category: retail
+tags: [retail, damage, write-off, loss-prevention]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review this period's damaged merchandise write-off log
+  ({{writeoff_log_path}}) across stores.
+  1. Identify any SKU that recurs as a write-off reason more than
+     {{recurring_sku_threshold}} times — that points at a packaging or
+     handling issue worth escalating to the vendor or receiving process,
+     not just re-approving the write-off.
+  2. Flag any store whose total write-off dollar amount is more than
+     {{store_outlier_multiplier}}x the average store in the file.
+  3. Separate write-offs with a documented cause (damaged in transit,
+     customer damage, expired) from those marked "unknown" — a high rate
+     of "unknown" is itself worth flagging.
+  4. Summarize findings in a short list a loss-prevention or merchandising
+     manager could act on.
+variables:
+  writeoff_log_path:
+    default: "./damaged-merchandise-writeoffs.csv"
+    description: "CSV with columns: store_id,sku,writeoff_amount,reason — one row per write-off in the period."
+  recurring_sku_threshold:
+    default: 3
+    description: Number of times a SKU must recur as a write-off before flagging a possible systemic cause.
+  store_outlier_multiplier:
+    default: 2
+    description: How many times the average store's write-off total counts as an outlier worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Judging what counts as a meaningful pattern versus normal variance across stores and reasons needs an agent, not a fixed threshold script.

package/jobs/retail/employee-discount-abuse-check.yaml

@@ -0,0 +1,39 @@
+id: employee-discount-abuse-check
+version: 1
+name: Employee Discount Abuse Check
+description: >
+  Reviews employee discount usage for patterns that look like abuse —
+  unusually high dollar volume, discounts applied to gift cards, or
+  discounts rung up under an employee's number when they weren't
+  scheduled to work. Use this if employee-discount abuse has ever quietly
+  eaten margin for months because each transaction looked fine in
+  isolation.
+category: retail
+tags: [retail, employee-discount, fraud, loss-prevention]
+schedule: "0 7 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review this period's employee discount transaction log
+  ({{discount_log_path}}) against the shift schedule
+  ({{schedule_csv_path}}).
+  1. Flag any employee whose total discounted purchase volume for the
+     period exceeds ${{monthly_volume_threshold_usd}}.
+  2. Flag any discount applied to a gift card purchase — most policies
+     disallow this.
+  3. Cross-reference discount timestamps against the schedule and flag
+     any discount rung up on a day the employee wasn't scheduled to work
+     (a common sign of a shared or misused employee number).
+  4. Summarize flagged employees with the specific reason for each flag.
+variables:
+  discount_log_path:
+    default: "./employee-discount-log.csv"
+    description: "CSV with columns: employee_id,transaction_date,amount,item_type,discount_pct."
+  schedule_csv_path:
+    default: "./employee-schedule.csv"
+    description: CSV of scheduled shifts to cross-reference against discount timestamps.
+  monthly_volume_threshold_usd:
+    default: 500
+    description: Total discounted purchase volume per employee in the period that triggers a flag.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: A flag is a prompt for HR/loss prevention review, not an accusation — cross-referencing two data sources and judging intent needs an agent, not a fixed script.

package/jobs/retail/layaway-special-order-pickup-tracker.yaml

@@ -0,0 +1,33 @@
+id: layaway-special-order-pickup-tracker
+version: 1
+name: Layaway & Special Order Pickup Tracker
+description: >
+  Flags layaway and special-order items that have been ready for pickup
+  past a set number of days. Use this if a paid-for special order has
+  ever sat in the back room for weeks because nobody was tracking pickup
+  age, only whether the item had arrived.
+category: retail
+tags: [retail, layaway, special-order, customer-service]
+schedule: "0 9 * * 2"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn={{overdue_days_threshold}} '
+    NR==1 {next}
+    $4 == "ready" {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline ready_ts; close(cmd);
+      days_waiting = int((today - ready_ts) / 86400);
+      if (days_waiting >= warn) printf "OVERDUE PICKUP: order %s for %s ready %d days (since %s)\n", $1, $2, days_waiting, $3;
+    }
+  ' "{{orders_csv}}"
+variables:
+  orders_csv:
+    default: "./layaway-special-orders.csv"
+    description: "CSV with header row, columns: order_id,customer_name,ready_date(YYYY-MM-DD),status(pending/ready/picked-up)."
+  overdue_days_threshold:
+    default: 14
+    description: Days an order can sit marked "ready" before it counts as overdue for pickup.
+compatible_agents: [generic, claude, codex]
+notes: A long-overdue pickup is worth a courtesy call before it becomes a restocking/refund headache or a customer dispute.