@wonsukchoi/crondex 0.22.0 → 0.23.0

package/jobs/marketing/attribution-discrepancy-check.yaml

@@ -0,0 +1,42 @@
+id: attribution-discrepancy-check
+version: 1
+name: Marketing Attribution Discrepancy Check
+description: >
+  Compares conversions or revenue attributed to a channel across two
+  systems — the ad platform's own reporting and your analytics/CRM — and
+  flags when they diverge significantly. Use this if you've ever reported
+  two different numbers for the same campaign's results in the same
+  meeting because the ad platform and the analytics tool didn't agree.
+category: marketing
+tags: [marketing, attribution, analytics, reporting]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Compare attributed results for channel "{{channel_name}}" over the last
+  {{lookback_days}} days between {{source_a_hint}} and {{source_b_hint}}.
+  1. Pull conversions (or revenue) attributed to the channel from each
+     source.
+  2. Compute the percent difference between the two numbers.
+  3. Flag if the difference exceeds {{discrepancy_threshold_pct}}%.
+  4. If flagged, suggest likely causes (attribution window mismatch,
+     UTM tagging gaps, view-through vs. click-through counting, deduping
+     differences) based on what's visible.
+variables:
+  channel_name:
+    default: "your channel (e.g. Google Ads, Meta Ads, Email)"
+    description: Marketing channel to compare attribution for.
+  source_a_hint:
+    default: "the ad platform's own conversion reporting"
+    description: First source of attributed conversions/revenue.
+  source_b_hint:
+    default: "your analytics tool or CRM (GA4, PostHog, Salesforce, HubSpot)"
+    description: Second source of attributed conversions/revenue.
+  lookback_days:
+    default: 30
+    description: Window of results to compare.
+  discrepancy_threshold_pct:
+    default: 20
+    description: Percent difference between sources that triggers a flag.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — pulling from two different reporting systems and reasoning about why they diverge needs judgment, not just a threshold comparison.

package/jobs/marketing/brand-share-of-voice-check.yaml

@@ -0,0 +1,43 @@
+id: brand-share-of-voice-check
+version: 1
+name: Brand Share of Voice Check
+description: >
+  Compares how often your brand is mentioned online versus a list of
+  named competitors over a recent window, flagging a real shift in share
+  of voice. Use this if a competitor has ever quietly out-marketed you
+  and the first sign was a sales rep mentioning it in a deal review
+  instead of a share-of-voice report catching the trend.
+category: marketing
+tags: [marketing, competitor, share-of-voice, brand]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Search for mentions of "{{brand_name}}" and each of these competitors —
+  {{competitor_names}} — from the last {{lookback_days}} days across
+  whatever sources you have access to (web search, X/Twitter, Reddit,
+  news).
+  1. Estimate a rough mention count for the brand and each competitor.
+  2. Compute the brand's approximate share of voice (brand mentions /
+     total mentions across all names).
+  3. Compare to the prior period if you can find historical data, and
+     flag a meaningful drop in share.
+  4. If one competitor stands out as gaining ground, name it and note
+     what seems to be driving it (launch, campaign, controversy) if
+     visible.
+variables:
+  brand_name:
+    default: "your brand"
+    description: Your brand/product name to track.
+  competitor_names:
+    default: "Competitor A, Competitor B"
+    description: Comma-separated list of named competitors to compare against.
+  lookback_days:
+    default: 30
+    description: Window of mentions to consider.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  No generic script mode — needs live search across sources and judgment
+  to estimate relative volume. Distinct from content/social-mentions-watch
+  (reads sentiment/triage of your own brand's mentions one by one) — this
+  compares mention volume across named competitors instead.

package/jobs/marketing/campaign-roas-cpa-anomaly-check.yaml

@@ -0,0 +1,41 @@
+id: campaign-roas-cpa-anomaly-check
+version: 1
+name: Campaign ROAS/CPA Anomaly Check
+description: >
+  Checks a campaign's return-on-ad-spend against a minimum threshold and
+  flags a real collapse. Use this if a campaign has ever kept spending its
+  normal daily budget while ROAS quietly cratered because a bid strategy
+  or targeting change nobody caught broke conversion efficiency.
+category: marketing
+tags: [marketing, ads, roas, performance]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  stats=$(curl -s -H "Authorization: Bearer {{ad_platform_api_token}}" "{{ad_platform_stats_api_url}}");
+  roas=$(echo "$stats" | grep -o '"roas":[0-9.]*' | head -n1 | cut -d: -f2);
+  if [ -z "$roas" ]; then echo "ERROR: could not fetch ROAS from {{ad_platform_stats_api_url}}"; exit 1; fi;
+  if awk "BEGIN{exit !($roas < {{min_roas}})}"; then
+    echo "WARNING: ROAS ${roas}x for campaign {{campaign_name}} is below minimum threshold {{min_roas}}x";
+    exit 1;
+  else echo "OK: ROAS ${roas}x for campaign {{campaign_name}}"; fi
+variables:
+  ad_platform_stats_api_url:
+    default: "https://api.example-ads.com/campaigns/{{campaign_name}}/stats"
+    description: Ad platform reporting API endpoint returning a roas field for the campaign.
+  ad_platform_api_token:
+    default: "your-api-token"
+    description: API token for the ad platform.
+  campaign_name:
+    default: "your campaign"
+    description: Name/ID of the ad campaign to check.
+  min_roas:
+    default: 2
+    description: Minimum acceptable return-on-ad-spend multiple before flagging.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Generic REST pattern — point at your ad platform's (Google Ads, Meta Ads,
+  TikTok Ads) reporting API; if it doesn't report ROAS directly, compute it
+  as conversion value / spend before comparing. Distinct from
+  ad-spend-pacing-check (tracks spend velocity vs. budget) — this tracks
+  spend efficiency instead.

package/jobs/marketing/competitor-ad-creative-watch.yaml

@@ -0,0 +1,40 @@
+id: competitor-ad-creative-watch
+version: 1
+name: Competitor Ad Creative Watch
+description: >
+  Scans a competitor's public ad library (Meta Ad Library, Google Ads
+  Transparency Center, or similar) for new or changed ad creative and
+  summarizes what's new. Use this if a competitor has ever launched a new
+  campaign, offer, or positioning angle and you found out from a
+  customer instead of watching their ad library yourself.
+category: marketing
+tags: [marketing, competitor, ads, monitoring]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{competitor_name}}'s ads at {{ad_library_url_hint}} for anything
+  new in the last {{lookback_days}} days.
+  1. List any new creative, offer, or messaging angle that wasn't running
+     before.
+  2. Note the format (video, static, carousel) and apparent target
+     audience if visible.
+  3. If nothing new, say so in one line.
+  4. If something new stands out, note why it might matter (new offer,
+     new positioning, entering a new channel).
+variables:
+  competitor_name:
+    default: "competitor name"
+    description: Competitor whose ads to check.
+  ad_library_url_hint:
+    default: "Meta Ad Library or Google Ads Transparency Center, searched by advertiser name"
+    description: Where to look up the competitor's running ads.
+  lookback_days:
+    default: 7
+    description: Window of new/changed ads to consider.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  No generic script mode — ad library sites vary and usually require a
+  live search rather than a stable API. Distinct from
+  competitor-page-diff-watch (tracks a competitor's own website) — this
+  tracks what they're actively advertising instead.

package/jobs/marketing/email-list-growth-rate-check.yaml

@@ -0,0 +1,43 @@
+id: email-list-growth-rate-check
+version: 1
+name: Email List Growth Rate Check
+description: >
+  Compares net email list growth (new subscribers minus unsubscribes and
+  bounces) over a recent period against a minimum growth rate, flagging a
+  stalled or shrinking list. Use this if a list has ever been quietly
+  shrinking for months because unsubscribes were outpacing signups and
+  nobody was tracking the net number.
+category: marketing
+tags: [marketing, email, list-growth, retention]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  stats=$(curl -s -H "Authorization: Bearer {{esp_api_token}}" "{{esp_list_stats_api_url}}");
+  current=$(echo "$stats" | grep -o '"current_count":[0-9]*' | head -n1 | cut -d: -f2);
+  previous=$(echo "$stats" | grep -o '"previous_count":[0-9]*' | head -n1 | cut -d: -f2);
+  if [ -z "$current" ] || [ -z "$previous" ] || [ "$previous" -eq 0 ]; then echo "ERROR: could not compute growth rate from {{esp_list_stats_api_url}}"; exit 1; fi;
+  growth_pct=$(awk "BEGIN{printf \"%.2f\", (($current-$previous)/$previous)*100}");
+  if awk "BEGIN{exit !($growth_pct < {{min_growth_rate_pct}})}"; then
+    echo "WARNING: list grew ${growth_pct}% over {{lookback_days}} days (min {{min_growth_rate_pct}}%) — $previous to $current subscribers";
+    exit 1;
+  else echo "OK: list grew ${growth_pct}% — $previous to $current subscribers"; fi
+variables:
+  esp_list_stats_api_url:
+    default: "https://api.example-esp.com/lists/main/stats?days={{lookback_days}}"
+    description: Email service provider endpoint returning current_count and previous_count subscriber totals for the window.
+  esp_api_token:
+    default: "your-api-token"
+    description: API token for the email service provider.
+  lookback_days:
+    default: 30
+    description: Window over which to measure net list growth.
+  min_growth_rate_pct:
+    default: 0
+    description: Minimum acceptable net growth rate percent over the window (0 means "must not shrink").
+compatible_agents: [generic, claude, codex]
+notes: >
+  Generic REST pattern — point at your ESP's (Mailchimp, Klaviyo,
+  SendGrid) list stats endpoint; adjust field names to match its response
+  shape. Distinct from newsletter-unsubscribe-spike-check (per-send
+  unsubscribe rate) — this tracks net list size trend over time instead.

package/jobs/marketing/landing-page-conversion-drop-check.yaml

@@ -0,0 +1,44 @@
+id: landing-page-conversion-drop-check
+version: 1
+name: Landing Page Conversion Drop Check
+description: >
+  Reviews a landing page's conversion rate over a recent window against
+  its baseline and flags a real drop. Use this if a landing page has ever
+  quietly stopped converting — a broken form, a slow load, a redesign
+  that hurt clarity — while traffic and ad spend kept flowing in as if
+  nothing changed.
+category: marketing
+tags: [marketing, landing-page, conversion, analytics]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check conversion rate for {{page_url}} using {{analytics_hint}}.
+  1. Compare the conversion rate over the last {{recent_days}} days to the
+     prior {{baseline_days}}-day baseline.
+  2. Flag a drop of {{drop_threshold_pct}}% or more.
+  3. If flagged, note any accompanying signal that's visible (bounce rate
+     spike, page load time, form error rate, traffic source mix shift)
+     that might explain the drop.
+variables:
+  page_url:
+    default: "https://example.com/landing-page"
+    description: Landing page URL to check conversion rate for.
+  analytics_hint:
+    default: "your web analytics tool (GA4, PostHog, Mixpanel, etc.)"
+    description: Where conversion data lives.
+  recent_days:
+    default: 7
+    description: Recent window to evaluate.
+  baseline_days:
+    default: 30
+    description: Prior window used as the baseline for comparison.
+  drop_threshold_pct:
+    default: 20
+    description: Percent drop in conversion rate that counts as a real regression.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  No generic script mode — pulling conversion rate needs an analytics API
+  and judgment on which accompanying signals matter. Distinct from
+  broken-campaign-link-check (page reachability only) — this catches a
+  page that loads fine but stopped converting.

package/jobs/marketing/mql-to-sql-handoff-sla-check.yaml

@@ -0,0 +1,29 @@
+id: mql-to-sql-handoff-sla-check
+version: 1
+name: MQL-to-SQL Handoff SLA Check
+description: >
+  Checks how long marketing-qualified leads have been sitting since
+  becoming an MQL without sales accepting them as sales-qualified, and
+  flags leads stuck past the handoff SLA. Use this if a hot lead has ever
+  gone cold sitting in the queue between marketing handing it off and
+  sales actually picking it up.
+category: marketing
+tags: [marketing, mql, handoff, funnel, sla]
+schedule: "0 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select name, email, mql_at from leads where status = 'mql' and sql_accepted_at is null and mql_at < now() - interval '{{handoff_sla_hours}} hours';"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the marketing/CRM leads database.
+  handoff_sla_hours:
+    default: 4
+    description: Hours an MQL can wait for sales acceptance before it's flagged as stuck.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `leads` table with `status`, `mql_at`, and `sql_accepted_at`
+  columns — adjust to your CRM's schema. Distinct from
+  sales/lead-response-time-check (first-touch response time on any new
+  lead) — this checks the specific marketing-to-sales handoff stage.

package/jobs/marketing/mql-volume-pace-check.yaml

@@ -0,0 +1,34 @@
+id: mql-volume-pace-check
+version: 1
+name: MQL Volume Pace Check
+description: >
+  Compares marketing-qualified-lead (MQL) volume so far this period
+  against the target pace and flags under-delivery early. Use this if a
+  quarter has ever ended short on MQLs and sales only found out during
+  the pipeline review, instead of marketing catching it mid-quarter with
+  enough runway to fix it.
+category: marketing
+tags: [marketing, mql, funnel, pipeline]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  count=$(psql "{{database_url}}" -t -c "select count(*) from leads where status = 'mql' and created_at >= date_trunc('quarter', current_date);");
+  target={{quarterly_mql_target}};
+  day_of_quarter=$(( ( $(date +%j) - 1 ) % 91 + 1 ));
+  expected=$(awk "BEGIN{printf \"%.0f\", ($target/91)*$day_of_quarter}");
+  echo "MQL pace check: $count MQLs so far this quarter vs. expected ~$expected (target $target)";
+  if [ "$count" -lt "$expected" ]; then echo "WARNING: MQL volume behind pace"; exit 1; fi
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the marketing/CRM leads database.
+  quarterly_mql_target:
+    default: 900
+    description: Target MQL count for the quarter.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `leads` table with a `status` column that includes an `mql`
+  value and a `created_at` timestamp — adjust the query to your marketing
+  automation/CRM schema. Uses a flat 91-day quarter approximation for
+  pacing; swap in exact fiscal quarter boundaries if yours differ.

package/jobs/marketing/paid-search-negative-keyword-waste-check.yaml

@@ -0,0 +1,37 @@
+id: paid-search-negative-keyword-waste-check
+version: 1
+name: Paid Search Negative Keyword Waste Check
+description: >
+  Reviews the recent search terms report for a paid search account and
+  flags spend on queries that are clearly irrelevant to what's being
+  sold and should be added as negative keywords. Use this if a paid
+  search account has ever burned budget for weeks on obviously mismatched
+  search terms because nobody reviewed the search terms report.
+category: marketing
+tags: [marketing, paid-search, ads, waste, negative-keywords]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull the search terms report for {{ad_account_hint}} over the last
+  {{lookback_days}} days.
+  1. Identify search terms that triggered ads but are clearly irrelevant
+     to the product/service being sold (mismatched intent, wrong
+     category, competitor brand names if that's not the strategy, junk
+     queries).
+  2. Sum the spend attributed to those irrelevant terms.
+  3. Flag if total wasted spend exceeds ${{min_wasted_spend_usd}}.
+  4. List the worst offending terms with spend and clicks, as candidates
+     to add to the negative keyword list.
+variables:
+  ad_account_hint:
+    default: "your paid search account (Google Ads, Microsoft Ads)"
+    description: Which paid search account/platform to review.
+  lookback_days:
+    default: 30
+    description: Window of search terms data to review.
+  min_wasted_spend_usd:
+    default: 200
+    description: Total wasted spend in USD that triggers a flag.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — judging whether a search term is "clearly irrelevant" to your specific product needs judgment a keyword-matching script can't reliably provide.

package/jobs/marketing/press-release-pickup-tracking.yaml

@@ -0,0 +1,32 @@
+id: press-release-pickup-tracking
+version: 1
+name: Press Release Pickup Tracking
+description: >
+  Searches for media pickups of a recent press release and reports which
+  outlets ran it. Use this if a press release has ever gone out and
+  nobody actually confirmed whether any outlets picked it up.
+category: marketing
+tags: [marketing, pr, press, media]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Search for coverage of the press release "{{press_release_title}}"
+  (issued {{press_release_date}}) from the last {{lookback_days}} days.
+  1. List each outlet that picked it up, with a link and whether it ran
+     verbatim or as an original story.
+  2. Note the apparent reach/tier of each outlet if you can tell
+     (major trade press, niche blog, syndication network).
+  3. If no pickups found yet, say so — don't fabricate results.
+variables:
+  press_release_title:
+    default: "your press release headline"
+    description: Title of the press release to track.
+  press_release_date:
+    default: "2026-01-01"
+    description: Date the press release was issued (YYYY-MM-DD).
+  lookback_days:
+    default: 14
+    description: Window since issue date to search for pickups.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — finding pickups needs live web/news search, and judging outlet tier/reach needs judgment a script can't reliably automate.

package/jobs/marketing/webinar-registration-attendance-check.yaml

@@ -0,0 +1,38 @@
+id: webinar-registration-attendance-check
+version: 1
+name: Webinar Registration/Attendance Check
+description: >
+  Checks a webinar's registration count and show-up (attendance) rate
+  against targets, with enough lead time to boost promotion or send
+  reminders. Use this if a webinar has ever gone live to a nearly empty
+  room because registration numbers looked fine on paper but nobody
+  checked the actual show-up rate trend.
+category: marketing
+tags: [marketing, webinar, events, registration]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  stats=$(curl -s -H "Authorization: Bearer {{webinar_platform_api_token}}" "{{webinar_platform_stats_api_url}}");
+  registrations=$(echo "$stats" | grep -o '"registrations":[0-9]*' | head -n1 | cut -d: -f2);
+  attendance_rate=$(echo "$stats" | grep -o '"attendance_rate":[0-9.]*' | head -n1 | cut -d: -f2);
+  if [ -z "$registrations" ]; then echo "ERROR: could not fetch stats from {{webinar_platform_stats_api_url}}"; exit 1; fi;
+  flagged=0;
+  if [ "$registrations" -lt "{{min_registrations}}" ]; then echo "WARNING: only $registrations registrations, below minimum {{min_registrations}}"; flagged=1; fi;
+  if [ -n "$attendance_rate" ] && awk "BEGIN{exit !($attendance_rate < {{min_attendance_rate_pct}})}"; then echo "WARNING: projected attendance rate ${attendance_rate}% below minimum {{min_attendance_rate_pct}}%"; flagged=1; fi;
+  if [ "$flagged" -eq 0 ]; then echo "OK: $registrations registrations, attendance rate ${attendance_rate}%"; else exit 1; fi
+variables:
+  webinar_platform_stats_api_url:
+    default: "https://api.example-webinar.com/events/upcoming/stats"
+    description: Webinar platform API endpoint returning registrations and attendance_rate for the upcoming event.
+  webinar_platform_api_token:
+    default: "your-api-token"
+    description: API token for the webinar platform.
+  min_registrations:
+    default: 50
+    description: Minimum registration count before flagging.
+  min_attendance_rate_pct:
+    default: 35
+    description: Minimum projected/historical show-up rate percent before flagging.
+compatible_agents: [generic, claude, codex]
+notes: Generic REST pattern — point at your webinar platform's (Zoom, ON24, Livestorm) API; attendance_rate may only be available after the event, so schedule a same-day-before-event run for registrations and a next-day run for actual attendance.

package/jobs/restaurant/comp-void-anomaly-tracker.yaml

@@ -0,0 +1,39 @@
+id: comp-void-anomaly-tracker
+version: 1
+name: Comp/Void Transaction Anomaly Tracker
+description: >
+  Reviews comped and voided POS transactions for the period and flags
+  patterns worth a second look — an employee with an outsized comp
+  rate, comps clustered right before closeout, or repeated same-item
+  voids. Use this if comps and voids have ever quietly become a hole in
+  the till that nobody added up until year-end.
+category: restaurant
+tags: [restaurant, pos, loss-prevention, comps, voids]
+schedule: "0 9 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull comp and void transaction records from {{pos_system}} for the
+  past {{lookback_days}} days, including employee_id, amount, reason
+  code (if logged), and timestamp.
+  1. Total comp/void dollar amount and count, and as a percentage of
+     total sales for the period.
+  2. Rank employees by comp/void dollar amount and by comp/void rate
+     relative to their sales volume — flag anyone meaningfully above
+     the team average.
+  3. Flag any comps/voids clustered suspiciously close to shift end or
+     drawer close, or missing a reason code where one is normally
+     required.
+  4. List repeated voids of the same menu item, which may point to a
+     kitchen/prep problem rather than a POS misuse issue.
+  5. Present findings neutrally as patterns to review, not conclusions
+     of wrongdoing.
+variables:
+  pos_system:
+    default: "your POS system"
+    description: Name of the point-of-sale system (e.g. "Toast", "Square", "Aloha").
+  lookback_days:
+    default: 30
+    description: Window of comp/void history to analyze.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only pattern surfacing — any disciplinary or policy action based on findings is a manager decision, not something this job should recommend directly.

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.