@wonsukchoi/crondex 0.22.0 → 0.23.0

package/jobs/growth/dau-mau-engagement-ratio-check.yaml

@@ -0,0 +1,39 @@
+id: dau-mau-engagement-ratio-check
+version: 1
+name: DAU/MAU Engagement Ratio Check
+description: >
+  Computes the daily-active-to-monthly-active user ratio (a standard
+  stickiness measure) and flags when it drops below a healthy floor. Use
+  this if "engagement feels down lately" has ever been a gut feeling
+  nobody could confirm with a number until the next board deck.
+category: growth
+tags: [growth, engagement, stickiness, dau-mau]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  stats=$(curl -s -H "Authorization: Bearer {{analytics_api_token}}" "{{analytics_api_url}}");
+  dau=$(echo "$stats" | grep -o '"dau":[0-9]*' | head -n1 | cut -d: -f2);
+  mau=$(echo "$stats" | grep -o '"mau":[0-9]*' | head -n1 | cut -d: -f2);
+  if [ -z "$dau" ] || [ -z "$mau" ] || [ "$mau" -eq 0 ]; then echo "ERROR: could not compute DAU/MAU from {{analytics_api_url}}"; exit 1; fi;
+  ratio=$(awk "BEGIN{printf \"%.1f\", ($dau/$mau)*100}");
+  if awk "BEGIN{exit !($ratio < {{min_ratio_pct}})}"; then
+    echo "WARNING: DAU/MAU ratio ${ratio}% (min {{min_ratio_pct}}%) — $dau DAU / $mau MAU";
+    exit 1;
+  else echo "OK: DAU/MAU ratio ${ratio}% — $dau DAU / $mau MAU"; fi
+variables:
+  analytics_api_url:
+    default: "https://api.example-analytics.com/v1/engagement/summary"
+    description: Product analytics endpoint returning current dau and mau counts.
+  analytics_api_token:
+    default: "your-api-token"
+    description: API token for the analytics platform.
+  min_ratio_pct:
+    default: 15
+    description: Minimum acceptable DAU/MAU ratio percent before flagging.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Generic REST pattern — point at your analytics platform's (Amplitude,
+  Mixpanel, PostHog) engagement summary endpoint; adjust field names to
+  match its response shape. 15-20% is a common "sticky product" floor for
+  B2B SaaS, but tune to your product's natural usage cadence.

package/jobs/growth/dormant-account-reactivation-check.yaml

@@ -0,0 +1,39 @@
+id: dormant-account-reactivation-check
+version: 1
+name: Dormant Account Reactivation Check
+description: >
+  Flags accounts that have gone completely silent — no login at all for
+  an extended stretch — regardless of payment status, so they can be
+  routed into a reactivation effort instead of being written off
+  silently. Use this if accounts that stopped logging in months ago only
+  come up again when finance asks why you're still paying to host them.
+category: growth
+tags: [growth, dormant-accounts, reactivation, retention]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  file={{accounts_csv_path}}; dormant_days={{dormant_days}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  today=$(date +%s);
+  tail -n +2 "$file" | while IFS=',' read -r account email last_login flagged; do
+    [ "$flagged" = "yes" ] && continue;
+    l_epoch=$(date -d "$last_login" +%s 2>/dev/null || date -j -f "%Y-%m-%d" "$last_login" +%s 2>/dev/null);
+    [ -z "$l_epoch" ] && continue;
+    days=$(( (today-l_epoch)/86400 ));
+    if [ "$days" -ge "$dormant_days" ]; then echo "DORMANT: $account ($email) — last login $days day(s) ago"; fi
+  done
+variables:
+  accounts_csv_path:
+    default: "./account-last-login.csv"
+    description: "Path to a CSV with header: account_name,email,last_login_date,already_flagged (last_login_date is YYYY-MM-DD, already_flagged is yes/no)."
+  dormant_days:
+    default: 60
+    description: Days with no login before an account counts as dormant.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token. You maintain account-last-login.csv yourself (or export
+  from your user database) — mark already_flagged=yes after routing an
+  account into reactivation outreach. Distinct from churn-risk-watch
+  (partial usage drop-off on paying accounts) — this catches accounts
+  with zero activity at all, paying or not.

package/jobs/growth/expansion-revenue-opportunity-tracker.yaml

@@ -0,0 +1,44 @@
+id: expansion-revenue-opportunity-tracker
+version: 1
+name: Expansion Revenue Opportunity Tracker
+description: >
+  Reviews usage-based consumption (API calls, storage, records processed,
+  etc.) against each account's plan allowance and flags accounts
+  regularly running over, before it becomes a support complaint about
+  being throttled. Use this if the first sign of an account outgrowing
+  its plan is a "why did my job fail" ticket instead of a proactive
+  expansion conversation.
+category: growth
+tags: [growth, expansion, upsell, usage-based]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull consumption metrics (e.g. API calls, storage used, records
+  processed — whatever your plan limits are metered on) for each paying
+  account from {{usage_source}} over the last {{lookback_days}} days.
+  1. Compare each account's usage against its plan's included allowance.
+  2. Flag accounts that exceeded the allowance, or came within
+     {{near_limit_pct}}% of it, on {{repeat_occurrences}} or more days in
+     the window.
+  3. List flagged accounts with their overage amount and current plan, so
+     the account owner can start an expansion conversation.
+variables:
+  usage_source:
+    default: "your metering/billing system or usage database"
+    description: Where consumption/usage-metering data lives.
+  lookback_days:
+    default: 30
+    description: Window of usage to evaluate.
+  near_limit_pct:
+    default: 90
+    description: Percent of plan allowance that counts as "near the limit."
+  repeat_occurrences:
+    default: 3
+    description: Number of days within the window an account must hit/near the limit to be flagged.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  No generic script mode — usage-metering schemas vary too much per
+  product to hardcode a query. Distinct from seat-utilization-upsell-check
+  (seat-count based) — this looks at metered/consumption-based usage
+  instead of seat count, since not every plan is priced per seat.

package/jobs/growth/feature-adoption-rate-tracker.yaml

@@ -0,0 +1,44 @@
+id: feature-adoption-rate-tracker
+version: 1
+name: Feature Adoption Rate Tracker
+description: >
+  Tracks what percent of active accounts have used a specific feature at
+  least once, and flags when adoption is stuck below target. Use this if
+  you shipped a feature, called it done, and never actually checked
+  whether anyone uses it.
+category: growth
+tags: [growth, feature-adoption, activation, product]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  file={{accounts_csv_path}}; feature="{{feature_column}}"; target={{target_adoption_pct}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  header=$(head -1 "$file");
+  col=$(echo "$header" | tr ',' '\n' | grep -nx "$feature" | cut -d: -f1);
+  [ -n "$col" ] || { echo "ERROR: column $feature not found in $file"; exit 1; };
+  total=0; used=0;
+  tail -n +2 "$file" | while IFS=',' read -ra row; do
+    total=$((total+1));
+    val="${row[$((col-1))]}";
+    [ "$val" = "yes" ] || [ "$val" = "1" ] || [ "$val" = "true" ] && used=$((used+1));
+    echo "$total $used";
+  done | tail -1 | { read -r t u;
+    pct=$(awk "BEGIN{printf \"%.1f\", ($u/$t)*100}");
+    echo "Feature adoption for $feature: $u/$t accounts (${pct}%)";
+    if awk "BEGIN{exit !($pct < $target)}"; then echo "WARNING: adoption below target (${target}%)"; exit 1; fi;
+  }
+variables:
+  accounts_csv_path:
+    default: "./account-feature-usage.csv"
+    description: "Path to a CSV with an account identifier column plus one column per tracked feature (yes/no, 1/0, or true/false)."
+  feature_column:
+    default: "used_new_dashboard"
+    description: Column name for the feature to check adoption of.
+  target_adoption_pct:
+    default: 30
+    description: Minimum adoption percent expected before flagging as behind.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token. You export account-feature-usage.csv from your product
+  analytics tool (one boolean column per feature you want to track).

package/jobs/growth/nps-trend-tracker.yaml

@@ -0,0 +1,40 @@
+id: nps-trend-tracker
+version: 1
+name: NPS Trend Tracker
+description: >
+  Computes Net Promoter Score from a survey response log and flags when
+  it drops meaningfully from the prior period. Use this if NPS only gets
+  looked at once a quarter in a slide, instead of catching a slide in
+  sentiment while there's still time to find out why.
+category: growth
+tags: [growth, nps, sentiment, retention]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  file={{nps_responses_csv_path}}; drop_threshold={{drop_threshold_points}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  total=$(tail -n +2 "$file" | wc -l | tr -d ' ');
+  if [ "$total" -eq 0 ]; then echo "No NPS responses recorded in $file"; exit 0; fi;
+  promoters=$(tail -n +2 "$file" | awk -F',' '$2>=9 {c++} END{print c+0}');
+  detractors=$(tail -n +2 "$file" | awk -F',' '$2<=6 {c++} END{print c+0}');
+  nps=$(awk "BEGIN{printf \"%.0f\", (($promoters-$detractors)/$total)*100}");
+  prev={{previous_nps_score}};
+  drop=$((prev - nps));
+  echo "NPS: $nps (from $total responses; $promoters promoters, $detractors detractors) — previous: $prev";
+  if [ "$drop" -ge "$drop_threshold" ]; then echo "WARNING: NPS dropped $drop points since last period"; exit 1; fi
+variables:
+  nps_responses_csv_path:
+    default: "./nps-responses.csv"
+    description: "Path to a CSV with header: respondent_email,score (score is 0-10)."
+  previous_nps_score:
+    default: 40
+    description: NPS score from the prior period, to compare against (update after each run).
+  drop_threshold_points:
+    default: 10
+    description: Point drop in NPS from the previous period that triggers a warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token. Export nps-responses.csv from your survey tool (Delighted,
+  Wootric, or your own in-app survey) and update previous_nps_score after
+  each run to track period-over-period movement.

package/jobs/growth/onboarding-funnel-dropoff-check.yaml

@@ -0,0 +1,39 @@
+id: onboarding-funnel-dropoff-check
+version: 1
+name: Onboarding Funnel Drop-off Check
+description: >
+  Computes the step-by-step completion rate across your onboarding funnel
+  and flags whichever step is losing the most users. Use this if you know
+  onboarding completion isn't great but have never actually seen where in
+  the funnel people give up.
+category: growth
+tags: [growth, onboarding, funnel, activation]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  file={{funnel_csv_path}}; drop_threshold={{step_dropoff_threshold_pct}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  prev_count=0; prev_step="start";
+  tail -n +2 "$file" | while IFS=',' read -r step count; do
+    if [ "$prev_count" -gt 0 ]; then
+      drop_pct=$(awk "BEGIN{printf \"%.1f\", (($prev_count-$count)/$prev_count)*100}");
+      flag="";
+      awk "BEGIN{exit !($drop_pct >= $drop_threshold)}" && flag=" <-- HIGH DROP-OFF";
+      echo "$prev_step -> $step: $prev_count -> $count (-${drop_pct}%)$flag";
+    fi;
+    prev_count=$count; prev_step=$step;
+  done
+variables:
+  funnel_csv_path:
+    default: "./onboarding-funnel.csv"
+    description: "Path to a CSV with header: step,users_reached, ordered from first onboarding step to last, one row per step."
+  step_dropoff_threshold_pct:
+    default: 30
+    description: Step-over-step drop percent that flags a step as a major leak.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token. Export onboarding-funnel.csv from your product analytics
+  tool's funnel report. Distinct from onboarding-completion-stall-check
+  (flags individual users stuck on a step) — this looks at aggregate
+  step-to-step drop-off across the whole funnel instead.

package/jobs/growth/paywall-upgrade-prompt-conversion-check.yaml

@@ -0,0 +1,40 @@
+id: paywall-upgrade-prompt-conversion-check
+version: 1
+name: Paywall/Upgrade Prompt Conversion Check
+description: >
+  Reviews how often users who hit a paywall or upgrade prompt actually
+  convert, and flags prompts that are being seen a lot but converting
+  poorly. Use this if an upgrade prompt has ever quietly annoyed users for
+  months with a near-zero conversion rate and nobody looked at the
+  numbers until a redesign project asked "does this even work?"
+category: growth
+tags: [growth, paywall, upgrade-prompt, conversion, product-led-growth]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull paywall/upgrade-prompt impression and conversion data from
+  {{analytics_hint}} for the last {{lookback_days}} days, broken down by
+  prompt location or trigger (e.g. feature-gate modal, usage-limit
+  banner, pricing page CTA).
+  1. Compute the view-to-upgrade conversion rate for each prompt.
+  2. Flag any prompt with {{min_impressions}}+ impressions but a
+     conversion rate under {{min_conversion_rate_pct}}%.
+  3. For flagged prompts, suggest likely causes based on what's visible
+     (wrong audience being shown the prompt, unclear value proposition,
+     price shown too early, friction in the upgrade flow itself).
+variables:
+  analytics_hint:
+    default: "product analytics tool (e.g. Amplitude, Mixpanel, PostHog)"
+    description: Where paywall/upgrade-prompt impression and conversion events are tracked.
+  lookback_days:
+    default: 30
+    description: Window of prompt data to evaluate.
+  min_impressions:
+    default: 100
+    description: Minimum impressions a prompt needs before its conversion rate is judged.
+  min_conversion_rate_pct:
+    default: 2
+    description: Conversion rate percent below which a well-seen prompt gets flagged.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — diagnosing why a specific prompt underconverts needs judgment about UX and audience, not just a rate comparison.

package/jobs/growth/product-qualified-lead-tracker.yaml

@@ -0,0 +1,42 @@
+id: product-qualified-lead-tracker
+version: 1
+name: Product-Qualified Lead (PQL) Tracker
+description: >
+  Reviews free/trial users' in-product usage for signals that they're
+  ready for a sales conversation — hitting usage limits, inviting
+  teammates, using premium-gated features — and flags them as PQLs. Use
+  this if self-serve users who are clearly ready to buy only get noticed
+  when they email support asking how to upgrade.
+category: growth
+tags: [growth, pql, product-led-growth, activation]
+schedule: "0 9 * * 2"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review usage data for free/trial accounts from {{analytics_hint}} over
+  the last {{lookback_days}} days.
+  1. Identify accounts showing buying-intent signals: approaching or
+     hitting a usage limit, inviting {{team_invite_threshold}}+ teammates,
+     repeatedly hitting a paywalled/premium feature, or a sustained
+     increase in core-feature usage.
+  2. Score each candidate account as a PQL if it shows two or more of
+     these signals.
+  3. List PQLs ranked by signal strength, with which signals triggered
+     the flag, so sales/success can prioritize outreach.
+variables:
+  analytics_hint:
+    default: "product analytics tool (e.g. Amplitude, Mixpanel, PostHog)"
+    description: Where in-product usage data lives.
+  lookback_days:
+    default: 14
+    description: Window of usage activity to evaluate.
+  team_invite_threshold:
+    default: 2
+    description: Number of teammate invites within the window that counts as a buying-intent signal.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  No generic script mode — combining multiple usage signals into a
+  qualification judgment needs reasoning about the product's specific
+  activation moments. Distinct from marketing's MQL jobs (marketing-sourced
+  leads from campaigns/forms) — this looks at existing free/trial users'
+  in-product behavior instead.

package/jobs/growth/referral-program-performance-tracker.yaml

@@ -0,0 +1,35 @@
+id: referral-program-performance-tracker
+version: 1
+name: Referral Program Performance Tracker
+description: >
+  Computes referral-to-signup and referral-to-paid conversion rates from
+  a referral log and flags when the program's performance drops. Use this
+  if a referral program launched with fanfare and nobody has checked its
+  numbers since.
+category: growth
+tags: [growth, referrals, virality, conversion]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  file={{referrals_csv_path}}; min_rate={{min_conversion_rate_pct}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  total=$(tail -n +2 "$file" | wc -l | tr -d ' ');
+  converted=$(tail -n +2 "$file" | awk -F',' '$3=="paid" {c++} END{print c+0}');
+  signed_up=$(tail -n +2 "$file" | awk -F',' '$3=="signed_up" || $3=="paid" {c++} END{print c+0}');
+  if [ "$total" -eq 0 ]; then echo "No referrals recorded in $file"; exit 0; fi;
+  signup_rate=$(awk "BEGIN{printf \"%.1f\", ($signed_up/$total)*100}");
+  paid_rate=$(awk "BEGIN{printf \"%.1f\", ($converted/$total)*100}");
+  echo "Referral performance: $total referrals, ${signup_rate}% signed up, ${paid_rate}% converted to paid";
+  if awk "BEGIN{exit !($paid_rate < $min_rate)}"; then echo "WARNING: referral-to-paid rate below ${min_rate}%"; exit 1; fi
+variables:
+  referrals_csv_path:
+    default: "./referrals.csv"
+    description: "Path to a CSV with header: referral_id,referrer_email,status (status is one of: pending,signed_up,paid)."
+  min_conversion_rate_pct:
+    default: 10
+    description: Minimum acceptable referral-to-paid conversion rate percent.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token. Export referrals.csv from your referral program tool
+  (ReferralCandy, Rewardful, or your own tracking table).

package/jobs/growth/trial-to-paid-conversion-rate-tracker.yaml

@@ -0,0 +1,48 @@
+id: trial-to-paid-conversion-rate-tracker
+version: 1
+name: Trial-to-Paid Conversion Rate Tracker
+description: >
+  Computes the trial-to-paid conversion rate for recently-ended trial
+  cohorts and can summarize what's changed if the rate moves. Use this if
+  trial conversion rate is a number that only gets calculated by hand
+  once a quarter for a board deck, instead of being watched continuously.
+category: growth
+tags: [growth, trials, conversion, activation]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: hybrid
+command: >
+  file={{trials_csv_path}}; min_rate={{min_conversion_rate_pct}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  ended=$(tail -n +2 "$file" | awk -F',' '$2=="ended" {c++} END{print c+0}');
+  converted=$(tail -n +2 "$file" | awk -F',' '$2=="converted" {c++} END{print c+0}');
+  total=$((ended+converted));
+  if [ "$total" -eq 0 ]; then echo "No ended trials recorded in $file"; exit 0; fi;
+  rate=$(awk "BEGIN{printf \"%.1f\", ($converted/$total)*100}");
+  echo "Trial-to-paid conversion: $converted/$total (${rate}%)";
+  if awk "BEGIN{exit !($rate < $min_rate)}"; then echo "WARNING: conversion rate below ${min_rate}%"; exit 1; fi
+prompt: |
+  The trial-to-paid conversion rate for the recent trial cohort in
+  {{trials_csv_path}} is below {{min_conversion_rate_pct}}%.
+  1. Look at the trials that ended without converting and note any
+     pattern visible in the data (e.g. low usage before expiry, specific
+     plan tier, signup source).
+  2. Suggest one or two concrete follow-ups (e.g. targeted win-back
+     outreach, a longer trial for a specific segment) based on what the
+     data shows.
+script_note: >
+  `command` computes the trial-to-paid conversion rate with zero tokens
+  and flags if it's below target. `prompt` (only needed when the rate is
+  flagged) digs into why and suggests a fix, which needs judgment.
+variables:
+  trials_csv_path:
+    default: "./trial-outcomes.csv"
+    description: "Path to a CSV with header: user_email,outcome (outcome is 'ended' for trials that expired without converting or 'converted' for trials that became paid)."
+  min_conversion_rate_pct:
+    default: 15
+    description: Minimum acceptable trial-to-paid conversion rate percent.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Distinct from trial-expiring-nudge (per-user nudge before expiry) —
+  this tracks the aggregate conversion rate after trials have already
+  ended, as a health metric rather than an outreach trigger.

package/jobs/growth/winback-reactivation-campaign-tracker.yaml

@@ -0,0 +1,46 @@
+id: winback-reactivation-campaign-tracker
+version: 1
+name: Win-Back Reactivation Campaign Tracker
+description: >
+  Tracks how canceled customers targeted by a win-back campaign are
+  responding, and can draft the next outreach touch for non-responders.
+  Use this if a win-back campaign has ever gone out once and then nobody
+  followed up with the customers who didn't respond.
+category: growth
+tags: [growth, winback, reactivation, churn]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: hybrid
+command: >
+  file={{winback_csv_path}}; wait_days={{followup_wait_days}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  today=$(date +%s);
+  tail -n +2 "$file" | while IFS=',' read -r email canceled_date sent_date status; do
+    [ "$status" = "reactivated" ] || [ "$status" = "declined" ] && continue;
+    s_epoch=$(date -d "$sent_date" +%s 2>/dev/null || date -j -f "%Y-%m-%d" "$sent_date" +%s 2>/dev/null);
+    [ -z "$s_epoch" ] && continue;
+    days=$(( (today-s_epoch)/86400 ));
+    if [ "$days" -ge "$wait_days" ]; then echo "NO RESPONSE: $email — canceled $canceled_date, win-back sent $days day(s) ago"; fi
+  done
+prompt: |
+  For each customer flagged as "NO RESPONSE" (from {{winback_csv_path}},
+  win-back email sent {{followup_wait_days}}+ days ago with no reply):
+  1. Draft a short, low-pressure follow-up touch — a different angle than
+     the first email (e.g. a specific improvement made since they left,
+     or a direct ask for feedback on why they canceled).
+  2. Keep it under 100 words. Don't send — draft only.
+script_note: >
+  `command` lists which canceled customers were sent a win-back email and
+  haven't responded, zero tokens. `prompt` drafts the follow-up touch for
+  each, which needs judgment on tone and angle.
+variables:
+  winback_csv_path:
+    default: "./winback-campaign.csv"
+    description: "Path to a CSV with header: email,canceled_date,winback_sent_date,status (status is one of: sent,reactivated,declined)."
+  followup_wait_days:
+    default: 10
+    description: Days to wait after the win-back email before flagging for a follow-up touch.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  You maintain winback-campaign.csv yourself (update status as customers
+  respond) — doesn't integrate with any CRM/ESP directly.

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

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

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

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

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

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

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

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

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

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