@wonsukchoi/crondex 0.21.0 → 0.23.0

package/jobs/manufacturing/safety-certification-expiry-check.yaml

@@ -0,0 +1,37 @@
+id: safety-certification-expiry-check
+version: 1
+name: Safety Equipment Operator Certification Expiry Check
+description: >
+  Warns before an operator's certification for safety-sensitive equipment
+  (forklift, overhead crane, powered industrial truck, etc.) expires. Use
+  this if an uncertified operator has ever kept running equipment for
+  weeks because nobody was tracking cert expiry dates against the roster.
+category: manufacturing
+tags: [manufacturing, safety, certification, training, compliance]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F, -v today="$today" -v warn={{warn_days}} '
+    NR>1 {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline exp_ts; close(cmd);
+      days_left = int((exp_ts - today) / 86400);
+      if (days_left <= warn) print "WARNING: " $1 "'"'"'s " $2 " certification expires in " days_left " days (" $3 ")";
+    }
+  ' {{operator_certs_csv}}
+variables:
+  operator_certs_csv:
+    default: "./operator-certifications.csv"
+    description: "CSV with header row, columns: operator_name,equipment_type,cert_expiry_date(YYYY-MM-DD)."
+  warn_days:
+    default: 21
+    description: Days before a certification expires to start warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Covers operator training certifications (who's allowed to run the
+  equipment), distinct from warehousing's forklift-inspection-check,
+  which covers pre-shift equipment condition checks, not operator
+  credentials. Keep operator-certifications.csv updated from your
+  training records after each recertification.

package/jobs/manufacturing/scrap-waste-rate-watch.yaml

@@ -0,0 +1,33 @@
+id: scrap-waste-rate-watch
+version: 1
+name: Scrap and Waste Rate Watch
+description: >
+  Tracks scrapped material as a percentage of total material consumed and
+  flags it when it runs above target. Use this if scrap has ever crept up
+  gradually until it showed up as a surprise hit to material cost at
+  month-end.
+category: manufacturing
+tags: [manufacturing, scrap, waste, cost]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target={{scrap_target_pct}} '
+    NR==1 {next}
+    { consumed += $2; scrapped += $3 }
+    END {
+      if (consumed == 0) { print "OK: no material consumption logged for the period"; exit 0 }
+      pct = (scrapped / consumed) * 100;
+      if (pct > target) printf "ABOVE TARGET: scrap rate %.2f%% (%.0f of %.0f units scrapped), target %.2f%%\n", pct, scrapped, consumed, target;
+      else printf "OK: scrap rate %.2f%% is within the %.2f%% target\n", pct, target;
+    }
+  ' "{{scrap_log_csv}}"
+variables:
+  scrap_log_csv:
+    default: "./scrap-log.csv"
+    description: "CSV with header row, columns: material,units_consumed,units_scrapped — one row per material/day for the reporting window."
+  scrap_target_pct:
+    default: 3
+    description: Maximum acceptable scrap rate as a percentage of material consumed.
+compatible_agents: [generic, claude, codex]
+notes: Export scrap-log.csv from your MES's material consumption and scrap-reason records before each run.

package/jobs/manufacturing/shift-handoff-report.yaml

@@ -0,0 +1,37 @@
+id: shift-handoff-report
+version: 1
+name: Shift Handoff Report
+description: >
+  Pulls the outgoing shift's production, downtime, and open-issue notes
+  and drafts a handoff summary for the incoming shift lead. Use this if
+  an incoming shift has ever started blind because the handoff was a
+  rushed hallway conversation instead of something written down.
+category: manufacturing
+tags: [manufacturing, shift-handoff, production, communication]
+schedule: "0 6,14,22 * * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull data for the shift that just ended on line(s) {{line_ids}} from
+  {{data_source}}: units produced vs. target, any downtime events and
+  their duration/cause, quality holds or rejects, and any open
+  maintenance or safety issues.
+
+  Draft a shift handoff note for the incoming lead covering:
+  1. Production vs. target for the shift, in one line.
+  2. Any downtime events, with cause and duration.
+  3. Open issues the incoming shift needs to watch (unresolved quality
+     holds, equipment acting up, parts running low).
+  4. Anything explicitly flagged by the outgoing lead as "don't forget."
+
+  Keep it to a few short bullets — this should be readable in under a
+  minute at the start of a shift, not a full report.
+variables:
+  line_ids:
+    default: "line-1"
+    description: Production line(s) this handoff covers.
+  data_source:
+    default: "your MES/SCADA system and shift log"
+    description: Where to pull production, downtime, and issue data from.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Draft-only — review before posting to the shift log or handing off verbally, especially anything about open safety issues.

package/jobs/manufacturing/supplier-quality-ppm-watch.yaml

@@ -0,0 +1,38 @@
+id: supplier-quality-ppm-watch
+version: 1
+name: Supplier Quality PPM Watch
+description: >
+  Calculates each supplier's defect rate in parts-per-million from
+  incoming inspection records and flags anyone above target. Use this if
+  a supplier's defective parts have ever slipped through in small enough
+  numbers each month that no one noticed the trend until a batch got bad
+  enough to stop the line.
+category: manufacturing
+tags: [manufacturing, supplier, quality, incoming-inspection, ppm]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target={{ppm_target}} '
+    NR==1 {next}
+    {
+      received[$1] += $2;
+      rejected[$1] += $3;
+    }
+    END {
+      for (s in received) {
+        ppm = (rejected[s] / received[s]) * 1000000;
+        status = (ppm > target) ? "ABOVE TARGET" : "OK";
+        printf "%s: supplier %s — %.0f PPM (%d rejected of %d received), target %d PPM\n", status, s, ppm, rejected[s], received[s], target;
+      }
+    }
+  ' "{{incoming_inspection_csv}}"
+variables:
+  incoming_inspection_csv:
+    default: "./incoming-inspection-log.csv"
+    description: "CSV with header row, columns: supplier_name,units_received,units_rejected — one row per receipt/day for the reporting window."
+  ppm_target:
+    default: 500
+    description: Maximum acceptable defective parts-per-million before a supplier is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from supplier-otd-performance-watch — that one tracks delivery timeliness, this one tracks incoming part quality. Export incoming-inspection-log.csv from your receiving/incoming-QC records.

package/jobs/manufacturing/tooling-die-wear-check.yaml

@@ -0,0 +1,31 @@
+id: tooling-die-wear-check
+version: 1
+name: Tooling and Die Wear Check
+description: >
+  Tracks cycle counts against a tool or die's rated life and flags it
+  when it's approaching end-of-life. Use this if a worn die has ever kept
+  running past its rated cycle count until it started producing bad
+  parts nobody traced back to the tooling.
+category: manufacturing
+tags: [manufacturing, tooling, dies, maintenance, wear]
+schedule: "0 6 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v warn={{warn_pct_remaining}} '
+    NR==1 {next}
+    {
+      pct_used = ($2 / $3) * 100;
+      pct_remaining = 100 - pct_used;
+      if (pct_remaining <= warn) printf "WARNING: tool \"%s\" at %.0f%% of rated life (%d of %d cycles), %.0f%% remaining\n", $1, pct_used, $2, $3, pct_remaining;
+    }
+  ' "{{tooling_cycles_csv}}"
+variables:
+  tooling_cycles_csv:
+    default: "./tooling-cycle-counts.csv"
+    description: "CSV with header row, columns: tool_id,cycles_used,rated_life_cycles."
+  warn_pct_remaining:
+    default: 15
+    description: Percentage of rated life remaining at which to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Update tooling-cycle-counts.csv from your press/molding machine's cycle counters or MES tooling module before each run — one row per active tool or die.

package/jobs/manufacturing/work-order-backlog-check.yaml

@@ -0,0 +1,37 @@
+id: work-order-backlog-check
+version: 1
+name: Work Order Backlog Check
+description: >
+  Counts open production work orders that have sat unstarted or unfinished
+  past their planned completion date. Use this if a work order has ever
+  quietly aged for weeks in the queue while everyone assumed someone else
+  had picked it up.
+category: manufacturing
+tags: [manufacturing, work-orders, production-planning, backlog]
+schedule: "0 6 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn={{overdue_warn_count}} '
+    NR==1 {next}
+    {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline due_ts; close(cmd);
+      if ($2 != "closed" && due_ts < today) { overdue++; printf "OVERDUE: work order %s (\"%s\") was due %s\n", $1, $4, $3 }
+    }
+    END {
+      if (overdue+0 >= warn) print "WARNING: " overdue " work orders are past their planned completion date";
+      else if (overdue+0 > 0) print "NOTE: " overdue " work order(s) overdue, below the " warn "-order warning threshold";
+      else print "OK: no overdue work orders";
+    }
+  ' "{{work_orders_csv}}"
+variables:
+  work_orders_csv:
+    default: "./work-orders.csv"
+    description: "CSV with header row, columns: work_order_id,status (open/in-progress/closed),due_date(YYYY-MM-DD),description."
+  overdue_warn_count:
+    default: 5
+    description: Number of overdue work orders that triggers a WARNING instead of a NOTE.
+compatible_agents: [generic, claude, codex]
+notes: Export work-orders.csv from your MES/ERP work order module before each run — this job only compares dates, it doesn't pull the data itself.

package/jobs/marketing/ad-creative-fatigue-check.yaml

@@ -0,0 +1,44 @@
+id: ad-creative-fatigue-check
+version: 1
+name: Ad Creative Fatigue Check
+description: >
+  Checks an ad creative's frequency (average times seen per user) and
+  click-through rate against thresholds, flagging fatigue before
+  performance craters. Use this if a top-performing ad has ever kept
+  running past its shelf life, burning budget on an audience that had
+  already tuned it out.
+category: marketing
+tags: [marketing, ads, creative, fatigue]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  stats=$(curl -s -H "Authorization: Bearer {{ad_platform_api_token}}" "{{ad_platform_stats_api_url}}");
+  frequency=$(echo "$stats" | grep -o '"frequency":[0-9.]*' | head -n1 | cut -d: -f2);
+  ctr=$(echo "$stats" | grep -o '"ctr":[0-9.]*' | head -n1 | cut -d: -f2);
+  if [ -z "$frequency" ] || [ -z "$ctr" ]; then echo "ERROR: could not fetch frequency/ctr from {{ad_platform_stats_api_url}}"; exit 1; fi;
+  if awk "BEGIN{exit !($frequency > {{max_frequency}} && $ctr < {{min_ctr_pct}})}"; then
+    echo "WARNING: creative {{creative_name}} fatigued — frequency ${frequency} (max {{max_frequency}}), CTR ${ctr}% (min {{min_ctr_pct}}%)";
+    exit 1;
+  else echo "OK: creative {{creative_name}} — frequency ${frequency}, CTR ${ctr}%"; fi
+variables:
+  ad_platform_stats_api_url:
+    default: "https://api.example-ads.com/creatives/{{creative_name}}/stats"
+    description: Ad platform reporting API endpoint returning frequency and ctr fields for the creative.
+  ad_platform_api_token:
+    default: "your-api-token"
+    description: API token for the ad platform.
+  creative_name:
+    default: "your creative"
+    description: Name/ID of the ad creative to check.
+  max_frequency:
+    default: 4
+    description: Average impressions per user above which fatigue is likely.
+  min_ctr_pct:
+    default: 0.5
+    description: Click-through rate percent below which, combined with high frequency, counts as fatigue.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Generic REST pattern — point at your ad platform's reporting API for a
+  single creative; both frequency and CTR must miss their thresholds
+  together so a naturally low-CTR-but-fresh creative doesn't false-flag.

package/jobs/marketing/affiliate-partner-performance-check.yaml

@@ -0,0 +1,38 @@
+id: affiliate-partner-performance-check
+version: 1
+name: Affiliate/Partner Performance Check
+description: >
+  Compares each affiliate or partner's referred conversions and revenue
+  against their target for the period and flags underperformers. Use
+  this if a partner program has ever kept paying placement fees to
+  partners who quietly stopped actually driving conversions.
+category: marketing
+tags: [marketing, affiliate, partners, performance]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  fail=0;
+  while IFS=',' read -r partner conversions revenue target_revenue; do
+    [ "$partner" = "partner_name" ] && continue;
+    [ -z "$partner" ] && continue;
+    pct=$(awk "BEGIN{printf \"%.0f\", ($revenue/$target_revenue)*100}");
+    if awk "BEGIN{exit !($pct < {{underperformance_threshold_pct}})}"; then
+      echo "UNDERPERFORMING: $partner — \$$revenue of \$$target_revenue target (${pct}%), $conversions conversions";
+      fail=1;
+    fi;
+  done < "{{partner_performance_csv_path}}";
+  exit $fail
+variables:
+  partner_performance_csv_path:
+    default: "./partner-performance.csv"
+    description: "CSV with header row, columns: partner_name,conversions,revenue,target_revenue — one row per affiliate/partner for the period."
+  underperformance_threshold_pct:
+    default: 50
+    description: Percent of target revenue below which a partner is flagged as underperforming.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Distinct from creator/affiliate-link-expiry-check (tracks individual
+  link/code expiry dates) — this tracks whether each partner relationship
+  is still actually performing, on a recurring per-period cadence rather
+  than a link-by-link deadline.

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.