@wonsukchoi/crondex 0.21.0 → 0.23.0

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/healthcare/appointment-slot-utilization-check.yaml

@@ -0,0 +1,56 @@
+id: appointment-slot-utilization-check
+version: 1
+name: Appointment Slot Utilization and Schedule Gap Check
+description: >
+  Computes daily/weekly appointment slot utilization from the schedule and
+  flags days running well under capacity, then suggests what to do about
+  the gaps. Use this if provider schedules have ever had large unbooked
+  gaps that nobody noticed until the day arrived nearly empty, wasting
+  billable capacity that a recall push or same-day-opening alert could
+  have filled.
+category: healthcare
+tags: [healthcare, scheduling, utilization, operations, capacity]
+schedule: "0 16 * * 5"
+timezone: "America/New_York"
+runner: hybrid
+command: >
+  awk -F',' -v threshold="{{low_utilization_threshold_pct}}" '
+    NR==1 {next}
+    {
+      total += $2; booked += $3;
+      pct = ($2 > 0) ? ($3 / $2 * 100) : 0;
+      if (pct < threshold) {
+        printf "LOW UTILIZATION: %s — %d/%d slots booked (%.1f%%)\n", $1, $3, $2, pct;
+      }
+    }
+    END {
+      overall = (total > 0) ? (booked / total * 100) : 0;
+      printf "WEEK OVERALL: %d/%d slots booked (%.1f%%)\n", booked, total, overall;
+    }
+  ' "{{schedule_utilization_csv_path}}"
+prompt: |
+  Look at the low-utilization days and overall weekly rate flagged above
+  (from {{schedule_utilization_csv_path}}).
+  1. Note which specific days/providers are consistently under
+     {{low_utilization_threshold_pct}}% booked versus a one-off dip.
+  2. For consistently low days, suggest a concrete fix: a targeted recall
+     push (see patient-recall-reminder) for that provider's open slots, a
+     schedule consolidation (fewer open days, more density), or a same-day
+     opening alert to a waitlist — whichever fits the pattern.
+  3. Keep it to a short, actionable list — this is a capacity-planning
+     nudge, not a full operations review.
+variables:
+  schedule_utilization_csv_path:
+    default: "./schedule-utilization.csv"
+    description: "Path to a CSV with columns: date_or_provider_day,total_slots,booked_slots."
+  low_utilization_threshold_pct:
+    default: 70
+    description: Utilization percentage below which a day is flagged as under capacity.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+script_note: >
+  The command gives you the per-day and weekly utilization percentages for free.
+  Only the prompt pass distinguishes a one-off dip from a real pattern and
+  recommends a specific fix — that judgment call is what the LLM pass adds.
+notes: >
+  Assumes an already-exported CSV from your scheduling/practice-management system.
+  Read-only analysis — it doesn't rebook anyone or change the schedule itself.

package/jobs/healthcare/claims-denial-resubmission-check.yaml

@@ -0,0 +1,43 @@
+id: claims-denial-resubmission-check
+version: 1
+name: Claims Denial Resubmission Check
+description: >
+  Checks denied insurance claims against their payer resubmission or appeal
+  deadline and flags anything still open as the deadline approaches or has
+  already passed. Use this if a denied claim has ever quietly aged past the
+  window to resubmit or appeal it, turning recoverable revenue into a
+  write-off nobody meant to take.
+category: healthcare
+tags: [healthcare, billing, claims, denials, revenue-cycle]
+schedule: "0 8 * * 1-5"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn_days="{{warn_days_before_deadline}}" '
+    NR==1 {next}
+    $6 != "open" {next}
+    {
+      cmd = "date -d \"" $5 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $5 "\" +%s 2>/dev/null";
+      cmd | getline deadline_epoch; close(cmd);
+      diff_days = (deadline_epoch - today) / 86400;
+      if (diff_days < 0) {
+        printf "PAST DEADLINE: %s — claim %s (%s) resubmission deadline was %s (%d days ago)\n", $1, $2, $3, $5, -diff_days;
+      } else if (diff_days <= warn_days) {
+        printf "RESUBMIT SOON: %s — claim %s (%s) deadline %s (%d days left)\n", $1, $2, $3, $5, diff_days;
+      }
+    }
+  ' "{{denied_claims_csv_path}}"
+variables:
+  denied_claims_csv_path:
+    default: "./denied-claims.csv"
+    description: "Path to a CSV with columns: patient_name,claim_number,payer,denial_date (YYYY-MM-DD),resubmission_deadline (YYYY-MM-DD),status (open/resubmitted/appealed/written-off)."
+  warn_days_before_deadline:
+    default: 7
+    description: How many days before the resubmission/appeal deadline to start warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes an already-exported CSV from your billing/clearinghouse system rather than
+  live PHI system access. Distinct from insurance-eligibility-verification-check
+  (pre-visit) and prior-authorization-expiry-check (treatment approval) — this is
+  post-visit claims that already got denied.

package/jobs/healthcare/clinical-supply-low-stock-check.yaml

@@ -0,0 +1,30 @@
+id: clinical-supply-low-stock-check
+version: 1
+name: Clinical Supply and PPE Low-Stock Check
+description: >
+  Scans clinical supply and PPE inventory (gloves, masks, gowns, syringes,
+  exam table paper, sanitizer) against reorder thresholds and flags what's
+  running low. Use this if a clinic has ever discovered it was out of
+  gloves or exam paper mid-morning because nobody was watching stock levels
+  between deliveries.
+category: healthcare
+tags: [healthcare, inventory, supplies, ppe, operations]
+schedule: "0 7 * * 1,4"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    ($3 + 0) <= ($4 + 0) {
+      printf "LOW STOCK: %s (%s) — %d on hand, reorder threshold %d\n", $1, $2, $3, $4;
+    }
+  ' "{{supply_inventory_csv_path}}"
+variables:
+  supply_inventory_csv_path:
+    default: "./clinical-supply-inventory.csv"
+    description: "Path to a CSV with columns: item_name,category,current_qty,reorder_threshold."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token, read-only check. Assumes a maintained inventory export (manual count
+  or supply-management software) — this is the "did anyone check the shelf" backstop,
+  it doesn't place the reorder itself.

package/jobs/healthcare/controlled-substance-inventory-reconciliation.yaml

@@ -0,0 +1,42 @@
+id: controlled-substance-inventory-reconciliation
+version: 1
+name: Controlled Substance Inventory Reconciliation
+description: >
+  Reviews the practice's controlled-substance dispensing/administration log
+  (e.g. in-office injectable opioids, ketamine, testosterone, Schedule II-V
+  medications kept on site) for gaps or unreconciled counts. Use this if a
+  discrepancy in a controlled-drug count has ever gone unnoticed for weeks
+  in a human practice instead of being caught same-day — this covers a
+  clinic's own in-office stock, the same DEA-style pattern as
+  jobs/veterinary/controlled-substance-log-audit.yaml but for a human
+  medical/dental practice rather than an animal clinic, so both are kept as
+  separate jobs.
+category: healthcare
+tags: [healthcare, controlled-substances, compliance, audit, dea]
+schedule: "0 20 * * *"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Read today's controlled-substance log from {{log_source}} for
+  {{substances_tracked}}.
+  1. Check that every entry has a matching patient/encounter reference —
+     flag any entry missing one.
+  2. Compare the running balance against the last physical count on record;
+     flag any mismatch.
+  3. Flag any day with zero entries logged if the practice was open and
+     controlled substances are known to be in regular use — a suspiciously
+     quiet log is itself worth a second look.
+  4. If everything reconciles, say so in one line.
+variables:
+  log_source:
+    default: "your controlled-substance log (paper log photographed/transcribed, or e-log system)"
+    description: Where the controlled-substance usage log is recorded.
+  substances_tracked:
+    default: "injectable opioids, ketamine, and other Schedule II-V substances kept on site"
+    description: Which substances this log covers.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Read-only reconciliation check — does not replace your practice's actual
+  DEA-compliant logging system, and any discrepancy found should go through your
+  normal reporting/investigation process. Assumes an already-exported or
+  transcribed log rather than live PHI system access.

package/jobs/healthcare/hipaa-access-log-audit.yaml

@@ -0,0 +1,74 @@
+id: hipaa-access-log-audit
+version: 1
+name: HIPAA Chart Access Log Audit
+description: >
+  Scans the EHR's chart-access log for high-volume, off-hours, or otherwise
+  unusual access patterns and has an agent judge which are worth a closer
+  look. Use this if unauthorized or curious chart access (a coworker's
+  family member, a local celebrity, an ex-spouse) has ever gone unnoticed
+  because nobody was reviewing the access log until an audit or complaint
+  forced it.
+category: healthcare
+tags: [healthcare, hipaa, compliance, audit, security]
+schedule: "0 7 * * 1"
+timezone: "America/New_York"
+runner: hybrid
+command: >
+  awk -F',' -v threshold="{{daily_access_threshold}}" -v off_start="{{off_hours_start}}" -v off_end="{{off_hours_end}}" '
+    NR==1 {next}
+    {
+      day = substr($3,1,10); hour = substr($3,12,2) + 0;
+      key = $1 SUBSEP day;
+      count[key]++;
+      staffname[key] = $1; dayval[key] = day;
+      if (hour >= off_start || hour < off_end) {
+        printf "OFF-HOURS ACCESS: %s accessed %s at %s (action: %s)\n", $1, $2, $3, $4;
+      }
+    }
+    END {
+      for (k in count) {
+        if (count[k] > threshold) {
+          printf "HIGH-VOLUME ACCESS: %s accessed %d distinct log entries on %s (threshold %d)\n", staffname[k], count[k], dayval[k], threshold;
+        }
+      }
+    }
+  ' "{{access_log_csv_path}}"
+prompt: |
+  Run the flagged entries from the access-log scan above (high-volume days
+  and off-hours access events) through a closer read.
+  1. For each flagged staff member/day, look at which patient records were
+     touched and whether the access pattern looks consistent with normal
+     clinical or front-desk duties for that role (e.g. a nurse pulling
+     charts for today's patient panel) versus inconsistent with it (e.g.
+     access to a patient not on that staff member's schedule, repeated
+     access to the same non-assigned patient, or a name match suggesting a
+     coworker, family member, or public figure).
+  2. Rank flags from "likely benign, no action" to "recommend compliance
+     officer review."
+  3. Do not name a possible relationship as fact — describe the pattern
+     observed and let a human confirm it.
+  4. If nothing stands out beyond routine volume, say so in one line.
+variables:
+  access_log_csv_path:
+    default: "./chart-access-log.csv"
+    description: "Path to a CSV with columns: staff_name,patient_name,access_timestamp (YYYY-MM-DD HH:MM),action (view/edit/print)."
+  daily_access_threshold:
+    default: 40
+    description: Number of chart access events by one staff member in one day that triggers a high-volume flag.
+  off_hours_start:
+    default: 20
+    description: Hour (0-23, local clinic time) after which access counts as off-hours.
+  off_hours_end:
+    default: 6
+    description: Hour (0-23) before which access still counts as off-hours.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+script_note: >
+  The command gives you the raw high-volume and off-hours flags for free, purely
+  from counts and timestamps. Only the prompt pass can judge whether a flagged
+  pattern looks like inappropriate snooping versus legitimate clinical coverage —
+  that judgment call is what the LLM pass adds.
+notes: >
+  Assumes an already-exported, de-identified-where-possible access log rather than
+  live EHR/PHI system access — export staff name, patient identifier, timestamp,
+  and action only. Any confirmed concern should go through your practice's actual
+  HIPAA compliance/privacy officer process, not this job.