@wonsukchoi/crondex 0.21.0 → 0.23.0

package/jobs/retail/loyalty-enrollment-redemption-rate-tracker.yaml

@@ -0,0 +1,37 @@
+id: loyalty-enrollment-redemption-rate-tracker
+version: 1
+name: Loyalty Enrollment & Redemption Rate Tracker
+description: >
+  Tracks new loyalty program enrollments and reward redemptions against
+  targets, not just whether individual points are about to expire. Use
+  this if enrollment has ever quietly stalled, or redemption has ever
+  dropped off a cliff, for months before anyone looked at the trend.
+category: retail
+tags: [retail, loyalty, customers, rewards, metrics]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v enroll_target="{{monthly_enrollment_target}}" -v redeem_floor="{{redemption_rate_floor_pct}}" '
+    NR==1 {next}
+    { enrolled += $2; redeemed += $3; eligible += $4 }
+    END {
+      redeem_pct = (eligible > 0) ? (redeemed / eligible) * 100 : 0;
+      printf "New enrollments this period: %d (target %d)\n", enrolled, enroll_target;
+      if (enrolled < enroll_target) printf "BELOW TARGET: enrollment %d short of target %d\n", enroll_target - enrolled, enroll_target;
+      printf "Redemption rate: %.1f%% (%d redeemed of %d eligible)\n", redeem_pct, redeemed, eligible;
+      if (redeem_pct < redeem_floor) printf "LOW REDEMPTION: %.1f%% is below the %.1f%% floor\n", redeem_pct, redeem_floor;
+    }
+  ' "{{loyalty_activity_csv}}"
+variables:
+  loyalty_activity_csv:
+    default: "./loyalty-activity.csv"
+    description: "CSV with header row, columns: store_id,new_enrollments,points_redeemed,points_eligible_for_redemption — one row per store or period."
+  monthly_enrollment_target:
+    default: 100
+    description: Target number of new loyalty enrollments for the period across the file.
+  redemption_rate_floor_pct:
+    default: 20
+    description: Minimum acceptable redemption rate (redeemed / eligible) before flagging.
+compatible_agents: [generic, claude, codex]
+notes: Complements `loyalty-points-expiry-reminder` (individual point expiry) by tracking program health as an aggregate trend — enrollment growth and redemption engagement, not per-customer expiry.

package/jobs/retail/markdown-execution-audit-check.yaml

@@ -0,0 +1,29 @@
+id: markdown-execution-audit-check
+version: 1
+name: Markdown Execution Audit Check
+description: >
+  Confirms that approved markdowns were actually applied at the register,
+  not just flagged as candidates. Use this if a markdown has ever been
+  approved on paper but never keyed into the POS, so the item kept
+  ringing at full price for weeks while it sat on the clearance rack.
+category: retail
+tags: [retail, markdown, pricing, audit]
+schedule: "0 8 * * 2"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      approved = $2; pos_current = $3;
+      if (approved != pos_current) {
+        printf "NOT APPLIED: SKU %s — approved markdown price $%s, POS still shows $%s\n", $1, approved, pos_current;
+      }
+    }
+  ' "{{markdown_approvals_csv}}"
+variables:
+  markdown_approvals_csv:
+    default: "./markdown-approvals.csv"
+    description: "CSV with header row, columns: sku,approved_markdown_price,pos_current_price — one row per approved markdown."
+compatible_agents: [generic, claude, codex]
+notes: Complements `markdown-aging-inventory-check` (flags candidates for markdown) by auditing the other end — whether an already-approved markdown was actually executed at the register.

package/jobs/retail/planogram-compliance-audit-check.yaml

@@ -0,0 +1,36 @@
+id: planogram-compliance-audit-check
+version: 1
+name: Planogram Compliance Audit Check
+description: >
+  Reviews a store's shelf/floor photos against the current planogram and
+  flags sections that are out of compliance. Use this if a reset has ever
+  quietly drifted out of plan for weeks — wrong facings, missing
+  end-caps, product in the wrong bay — before a district visit caught it.
+category: retail
+tags: [retail, planogram, merchandising, compliance]
+schedule: "0 8 * * 3"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Compare this week's shelf photos ({{shelf_photos_path}}) against the
+  current planogram document ({{planogram_doc_path}}) for store
+  {{store_id}}.
+  1. Go section by section and note any bay where product placement,
+     facing count, or signage doesn't match the planogram.
+  2. Flag missing or expired promotional signage separately from pure
+     placement drift.
+  3. Rank findings by sections that drive the most revenue first (per the
+     planogram's priority notes, if included).
+  4. Produce a short punch list a store associate could act on today.
+variables:
+  shelf_photos_path:
+    default: "./planogram-photos/"
+    description: Folder or path containing this cycle's shelf/section photos for the store.
+  planogram_doc_path:
+    default: "./current-planogram.pdf"
+    description: Path to the current approved planogram document or image set.
+  store_id:
+    default: "store-001"
+    description: Identifier for the store being audited.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Needs visual comparison and judgment about what counts as meaningful drift versus a shopper-caused mess — not a fit for a fixed script.

package/jobs/retail/pos-void-refund-anomaly-tracker.yaml

@@ -0,0 +1,42 @@
+id: pos-void-refund-anomaly-tracker
+version: 1
+name: POS Void & Refund Anomaly Tracker
+description: >
+  Flags cashiers or registers with an unusually high rate of transaction
+  voids and refunds instead of treating each one as an isolated event.
+  Use this if register-level fraud or sweethearting has ever gone
+  unnoticed for months because void/refund activity was never rolled up
+  per employee.
+category: retail
+tags: [retail, pos, fraud, loss-prevention]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v void_pct_max="{{void_rate_threshold_pct}}" '
+    NR==1 {next}
+    {
+      employee[$1] += 1;
+      total[$1] += 1;
+      if ($2 == "void" || $2 == "refund") flagged[$1] += 1;
+    }
+    END {
+      for (e in total) {
+        if (total[e] > 0) {
+          pct = (flagged[e] / total[e]) * 100;
+          if (pct >= void_pct_max) {
+            printf "HIGH VOID/REFUND RATE: %s — %.1f%% of %d transactions (%d void/refund)\n", e, pct, total[e], flagged[e];
+          }
+        }
+      }
+    }
+  ' "{{transactions_csv_path}}"
+variables:
+  transactions_csv_path:
+    default: "./pos-transactions.csv"
+    description: "Path to a CSV with columns: employee_id,transaction_type (sale/void/refund) — one row per transaction in the period."
+  void_rate_threshold_pct:
+    default: 8
+    description: Percentage of an employee's transactions that are voids/refunds before flagging for review.
+compatible_agents: [generic, claude, codex]
+notes: A flag is a prompt for a manager to review video/receipts, not proof of wrongdoing — some roles (returns desk) will legitimately run higher.

package/jobs/retail/price-tag-audit-accuracy-check.yaml

@@ -0,0 +1,37 @@
+id: price-tag-audit-accuracy-check
+version: 1
+name: Price Tag Audit Accuracy Check
+description: >
+  Reviews photos of shelf price tags against the current POS price file
+  and flags mismatches. Use this if a customer has ever caught a
+  scan-versus-tag price discrepancy at the register before the store did
+  — those add up fast in refunds, complaints, and occasional fines.
+category: retail
+tags: [retail, pricing, audit, compliance]
+schedule: "0 8 * * 4"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Compare this week's shelf tag photos ({{tag_photos_path}}) against the
+  current POS price export ({{pos_price_file}}) for store {{store_id}}.
+  1. Read the SKU and posted price off each tag photo (OCR/read the
+     image directly).
+  2. Match each tag to its POS price by SKU and flag any mismatch,
+     noting whether the tag is higher or lower than the register price.
+  3. Prioritize mismatches where the tag price is lower than the POS
+     price — those are the ones customers will notice and complain about
+     first, and in some states are a pricing-accuracy compliance risk.
+  4. Summarize as a punch list: SKU, tag price, POS price, and which tag
+     needs reprinting.
+variables:
+  tag_photos_path:
+    default: "./shelf-tag-photos/"
+    description: Folder of this week's shelf price tag photos for the store.
+  pos_price_file:
+    default: "./pos-price-export.csv"
+    description: Current POS price export, columns sku,price.
+  store_id:
+    default: "store-001"
+    description: Identifier for the store being audited.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Reading prices off photographed tags and matching them against a price list needs visual judgment a fixed script can't reliably do.

package/jobs/retail/sales-per-square-foot-tracker.yaml

@@ -0,0 +1,36 @@
+id: sales-per-square-foot-tracker
+version: 1
+name: Sales Per Square Foot Tracker
+description: >
+  Calculates each store's sales-per-square-foot for the period and flags
+  stores falling below a benchmark. Use this if underperforming store
+  footprints have ever gone unnoticed until an annual real-estate review
+  instead of getting flagged while there was still time to act.
+category: retail
+tags: [retail, sales, performance, benchmarking]
+schedule: "0 7 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v floor="{{benchmark_sales_per_sqft}}" '
+    NR==1 {next}
+    {
+      sqft = $3;
+      if (sqft > 0) {
+        rate = $2 / sqft;
+        status = (rate < floor) ? "BELOW BENCHMARK" : "ok";
+        if (status == "BELOW BENCHMARK") {
+          printf "BELOW BENCHMARK: store %s — $%.2f/sqft (benchmark $%.2f/sqft)\n", $1, rate, floor;
+        }
+      }
+    }
+  ' "{{store_sales_csv}}"
+variables:
+  store_sales_csv:
+    default: "./store-sales-sqft.csv"
+    description: "CSV with header row, columns: store_id,period_sales_usd,selling_sqft — one row per store for the period."
+  benchmark_sales_per_sqft:
+    default: 300
+    description: Minimum acceptable sales-per-square-foot for the period before a store gets flagged.
+compatible_agents: [generic, claude, codex]
+notes: A single low period isn't necessarily a problem store — track the trend across periods before drawing conclusions about a location.

package/jobs/retail/seasonal-staffing-coverage-check.yaml

@@ -0,0 +1,35 @@
+id: seasonal-staffing-coverage-check
+version: 1
+name: Seasonal Staffing Coverage Check
+description: >
+  Compares scheduled labor hours against a forecasted seasonal-peak
+  staffing plan and flags stores that are under-scheduled. Use this if a
+  store has ever gone into a holiday or back-to-school rush understaffed
+  because the seasonal plan and the actual schedule quietly drifted apart.
+category: retail
+tags: [retail, staffing, seasonal, scheduling]
+schedule: "0 9 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v gap_pct="{{coverage_gap_threshold_pct}}" '
+    NR==1 {next}
+    {
+      planned = $2; scheduled = $3;
+      if (planned > 0) {
+        gap = ((planned - scheduled) / planned) * 100;
+        if (gap >= gap_pct) {
+          printf "UNDER-SCHEDULED: store %s — planned %.0f hrs, scheduled %.0f hrs (%.1f%% short)\n", $1, planned, scheduled, gap;
+        }
+      }
+    }
+  ' "{{seasonal_staffing_csv}}"
+variables:
+  seasonal_staffing_csv:
+    default: "./seasonal-staffing-plan.csv"
+    description: "CSV with header row, columns: store_id,planned_hours,scheduled_hours — one row per store for the upcoming seasonal window."
+  coverage_gap_threshold_pct:
+    default: 10
+    description: Percentage shortfall between planned and scheduled hours that triggers a flag.
+compatible_agents: [generic, claude, codex]
+notes: Complements `employee-shift-gap-check` (day-to-day unfilled shifts) by checking whether the whole store is resourced against a seasonal peak plan, weeks ahead of the rush rather than shift by shift.

package/jobs/retail/store-closing-checklist-compliance-check.yaml

@@ -0,0 +1,32 @@
+id: store-closing-checklist-compliance-check
+version: 1
+name: Store Closing Checklist Compliance Check
+description: >
+  Reviews logged closing checklist completions and flags stores or shifts
+  that skipped required steps, rather than just reminding staff of the
+  checklist. Use this if a store has ever opened the next morning to a
+  safe left unlocked, alarm not set, or cash not dropped because closing
+  execution was never actually checked afterward.
+category: retail
+tags: [retail, checklist, closing, compliance, loss-prevention]
+schedule: "0 7 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      if ($3 == "incomplete" || $3 == "") {
+        printf "INCOMPLETE CLOSE: store %s on %s — missing step: %s\n", $1, $2, $4;
+      }
+    }
+  ' "{{closing_log_csv}}"
+variables:
+  closing_log_csv:
+    default: "./closing-checklist-log.csv"
+    description: "CSV with header row, columns: store_id,close_date,status(complete/incomplete),missing_step — one row per required closing step per night."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Distinct from `store-opening-checklist-reminder`, which just prints the
+  standard checklist as a reminder — this audits a logged closing record
+  after the fact to catch steps that were actually skipped.

package/jobs/retail/visual-merchandising-compliance-check.yaml

@@ -0,0 +1,40 @@
+id: visual-merchandising-compliance-check
+version: 1
+name: Visual Merchandising Compliance Check
+description: >
+  Reviews store-front and window display photos against the current
+  visual merchandising directive and flags stores that haven't executed
+  it. Use this if a seasonal window or entrance display has ever stayed
+  up stale for weeks after corporate sent the new directive.
+category: retail
+tags: [retail, merchandising, visual, compliance]
+schedule: "0 8 * * 5"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Compare this week's store-front/window/entrance photos
+  ({{store_photos_path}}) against the current visual merchandising
+  directive ({{vm_directive_path}}) for store {{store_id}}.
+  1. Note whether the required theme, signage, mannequin styling, and
+     entrance table match the directive.
+  2. Flag anything stale (a prior season's display still up) separately
+     from anything simply missing.
+  3. Note any obviously damaged or faded display elements that need
+     replacing regardless of the current directive.
+  4. Give a short, actionable punch list, not a general aesthetic
+     critique.
+variables:
+  store_photos_path:
+    default: "./vm-photos/"
+    description: Folder of this week's store-front and window display photos.
+  vm_directive_path:
+    default: "./current-vm-directive.pdf"
+    description: Path to the current corporate visual merchandising directive.
+  store_id:
+    default: "store-001"
+    description: Identifier for the store being reviewed.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Distinct from `planogram-compliance-audit-check`, which audits shelf/bay
+  product placement inside the store — this covers window, entrance, and
+  seasonal display execution instead.

package/jobs/sales/champion-departure-watch.yaml

@@ -0,0 +1,44 @@
+id: champion-departure-watch
+version: 1
+name: Champion Departure Watch
+description: >
+  Checks whether your champion or economic-buyer contact at open or
+  recently-closed accounts has left the company, using bounce signals or
+  a job-change lookup, and drafts a plan to find the new point of contact.
+  Use this if a deal has ever gone quiet for weeks before you found out
+  your one internal advocate had already left the company.
+category: sales
+tags: [sales, champion, contact-departure, account-risk]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review the champion/decision-maker contacts listed in {{contacts_source}}
+  for accounts with an open deal or a contract within
+  {{renewal_lookback_days}} days of renewal.
+  1. For each contact, check for signs they've left the company: a bounced
+     email address, an outdated title, or a job-change signal on
+     {{signal_source}} (e.g. LinkedIn).
+  2. List any contact flagged as likely departed, with the account name,
+     deal/contract at risk, and what signal triggered the flag.
+  3. For each flagged account, suggest the most likely replacement contact
+     if one is visible in the account (another named stakeholder, or a
+     generic role like "VP of [department]"), and draft a short
+     re-introduction email to that person or a warm-intro request to
+     another contact at the account.
+  4. If no departures are found, say so in one line.
+variables:
+  contacts_source:
+    default: "your CRM's contact list, or a champions.csv with columns: account,contact_name,contact_email,title,deal_or_contract"
+    description: Where champion/decision-maker contacts and the account/deal they're tied to are recorded.
+  signal_source:
+    default: "LinkedIn, or email bounce logs from your email platform"
+    description: Where to check for a job-change or departure signal.
+  renewal_lookback_days:
+    default: 90
+    description: How far ahead to include upcoming renewals when scoping which accounts' champions to check.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Draft-only — review the suggested replacement contact and re-intro email
+  before sending. Respect LinkedIn's terms of use; a manual check or a
+  licensed data provider is safer than scraping.

package/jobs/sales/closed-lost-reason-audit.yaml

@@ -0,0 +1,42 @@
+id: closed-lost-reason-audit
+version: 1
+name: Closed-Lost Reason Audit
+description: >
+  Finds recently closed-lost deals with no loss reason recorded, and
+  summarizes the reasons that were captured into a short pattern report.
+  Use this if closed-lost deals have ever piled up with a blank reason
+  field, making it impossible to tell whether you're losing to a
+  competitor, on price, or on missing features.
+category: sales
+tags: [sales, closed-lost, win-loss, reporting]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: hybrid
+command: >
+  psql "{{database_url}}" -t -c "select name, owner, amount, loss_reason from deals where stage = 'closed_lost' and closed_at > now() - interval '{{lookback_days}} days' order by closed_at desc;"
+prompt: |
+  Review closed-lost deals from the last {{lookback_days}} days (from the
+  script output above, or by querying {{database_url}} directly).
+  1. List every deal with a blank/missing loss_reason — these need a rep
+     follow-up to fill in before the data is usable.
+  2. For deals that do have a loss_reason, group them into a short summary
+     of the top 3-5 recurring themes (e.g. "price", "lost to [competitor]",
+     "missing feature X", "no budget/timing").
+  3. Note if one theme is trending upward compared to what you'd normally
+     expect, so it can be raised with product/pricing.
+script_note: >
+  `command` lists closed-lost deals and their recorded (or missing) loss
+  reason with zero tokens. `prompt` adds the missing-reason follow-up list
+  and the qualitative theme summary across free-text reasons.
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database.
+  lookback_days:
+    default: 30
+    description: How many days of closed-lost deals to review.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Assumes a `deals` table with `stage`, `closed_at`, and a free-text
+  `loss_reason` column — adjust to your CRM's schema and loss-reason
+  taxonomy if it uses a fixed picklist instead of free text.

package/jobs/sales/commission-payout-tracker.yaml

@@ -0,0 +1,32 @@
+id: commission-payout-tracker
+version: 1
+name: Commission Payout Tracker
+description: >
+  Finds closed-won deals whose sales commission hasn't been marked as paid
+  even though the payout grace period has passed, and totals what's owed
+  per rep. Use this if a rep has ever had to chase finance to find out why
+  a commission from weeks ago never showed up in their paycheck.
+category: sales
+tags: [sales, commission, payroll-adjacent, compensation]
+schedule: "0 8 1,15 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select owner, count(*) as unpaid_deals, sum(amount) as unpaid_revenue, round(sum(amount) * {{commission_rate_pct}} / 100.0, 2) as commission_owed from deals where stage = 'closed_won' and commission_paid = false and closed_at < now() - interval '{{grace_days}} days' group by owner order by commission_owed desc;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database.
+  commission_rate_pct:
+    default: 10
+    description: Flat commission rate percent applied to closed-won revenue, for the estimate.
+  grace_days:
+    default: 15
+    description: Days after close before an unpaid commission counts as overdue for payout.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `deals` table with a `commission_paid` boolean column and a
+  flat commission rate — replace the flat-rate math with your real
+  commission plan (tiers, accelerators, clawbacks) if it's more complex.
+  This is separate from any HR payroll job — it only flags CRM-side deal
+  data, it does not run payroll.

package/jobs/sales/contract-renewal-opportunity-tracker.yaml

@@ -0,0 +1,28 @@
+id: contract-renewal-opportunity-tracker
+version: 1
+name: Contract Renewal Opportunity Tracker
+description: >
+  Flags existing customer contracts approaching their renewal date so
+  account management can start the renewal conversation early. Use this
+  if a contract has ever auto-lapsed or renewed on unfavorable terms
+  because nobody flagged it until it was almost too late.
+category: sales
+tags: [sales, renewals, contracts, account-management]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select customer_name, owner, contract_value, renewal_date from contracts where status = 'active' and renewal_date < now() + interval '{{warn_days}} days' order by renewal_date;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the contracts/CRM database.
+  warn_days:
+    default: 60
+    description: Days before renewal_date to start flagging a contract for renewal outreach.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `contracts` table with `status`, `renewal_date`, `owner`, and
+  `contract_value` columns — adjust to your schema. Distinct from
+  `quote-expiry-reminder` (pre-sale quotes that haven't been signed yet);
+  this tracks signed, active customer contracts nearing their renewal date.

package/jobs/sales/discount-approval-pending-check.yaml

@@ -0,0 +1,31 @@
+id: discount-approval-pending-check
+version: 1
+name: Discount Approval Pending Check
+description: >
+  Flags deals with a discount above your standard threshold that are
+  still waiting on manager approval, especially ones that have been
+  sitting for a while. Use this if a rep has ever quoted a customer a
+  deep discount and the deal stalled for days waiting on an approval
+  nobody knew was pending.
+category: sales
+tags: [sales, discounts, approvals, deal-desk]
+schedule: "0 */4 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select name, owner, discount_pct, approval_requested_at from deals where discount_pct >= {{discount_threshold_pct}} and approval_status = 'pending' and approval_requested_at < now() - interval '{{stale_hours}} hours' order by approval_requested_at;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database.
+  discount_threshold_pct:
+    default: 15
+    description: Discount percent that requires manager approval in your process.
+  stale_hours:
+    default: 24
+    description: Hours an approval request can sit pending before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `deals` table with `discount_pct`, `approval_status`, and
+  `approval_requested_at` columns from a deal-desk/CPQ approval workflow
+  — adjust field names to match your process.

package/jobs/sales/forecast-submission-compliance-check.yaml

@@ -0,0 +1,42 @@
+id: forecast-submission-compliance-check
+version: 1
+name: Forecast Submission Compliance Check
+description: >
+  Compares your active rep roster against submitted forecast records for
+  the current period and flags anyone who hasn't submitted yet. Use this
+  if sales leadership has ever walked into a forecast review meeting only
+  to find out half the team never actually submitted numbers.
+category: sales
+tags: [sales, forecasting, compliance, sales-ops]
+schedule: "0 9 * * 5"
+timezone: "UTC"
+runner: shell
+command: >
+  period="{{current_period}}";
+  if [ -z "$period" ]; then period=$(date +%G-W%V); fi;
+  awk -F',' -v period="$period" '
+    NR==FNR { if (FNR>1) reps[$1]=1; next }
+    FNR==1 { next }
+    $2 == period { submitted[$1]=1 }
+    END {
+      for (r in reps) {
+        if (!(r in submitted)) print "MISSING FORECAST: " r " has not submitted for " period;
+      }
+    }
+  ' "{{reps_csv_path}}" "{{forecasts_csv_path}}"
+variables:
+  reps_csv_path:
+    default: "./active-reps.csv"
+    description: "Path to a CSV with header row and column: rep_name — one row per active rep expected to submit a forecast."
+  forecasts_csv_path:
+    default: "./forecast-submissions.csv"
+    description: "Path to a CSV with header row and columns: rep_name,period,submitted_at — one row per submitted forecast."
+  current_period:
+    default: ""
+    description: 'The period identifier to check submissions against (e.g. ISO week or "2026-Q3"). Leave blank to default to the current ISO week (YYYY-Www) — override if your forecasts CSV uses a different period format.'
+compatible_agents: [generic, claude, codex]
+notes: >
+  You maintain both CSVs yourself (export active-reps.csv from your HRIS
+  or CRM user list, and forecast-submissions.csv from wherever forecasts
+  are logged) — the `current_period` value must match how periods are
+  written in forecast-submissions.csv exactly.

package/jobs/sales/multi-year-renewal-escalation-tracker.yaml

@@ -0,0 +1,31 @@
+id: multi-year-renewal-escalation-tracker
+version: 1
+name: Multi-Year Renewal Escalation Tracker
+description: >
+  Flags multi-year contracts approaching their next contract-year
+  anniversary, where a pre-agreed price escalation kicks in, so the
+  customer gets notice before the higher invoice arrives. Use this if a
+  customer has ever been surprised by a built-in price increase on a
+  multi-year deal because nobody sent the required notice ahead of the
+  anniversary date.
+category: sales
+tags: [sales, renewals, multi-year, pricing, account-management]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select customer_name, owner, escalation_pct, next_anniversary_date from multi_year_contracts where next_anniversary_date < now() + interval '{{notice_days}} days' order by next_anniversary_date;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the contracts/CRM database.
+  notice_days:
+    default: 45
+    description: Days of advance notice required before a contract's next anniversary/escalation date.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `multi_year_contracts` table with `next_anniversary_date` and
+  `escalation_pct` columns tracking the pre-agreed annual price increase
+  — adjust to your schema. Distinct from `contract-renewal-opportunity-tracker`,
+  which covers the end-of-term renewal decision rather than an in-term
+  contractual price step-up.

package/jobs/sales/pipeline-hygiene-audit.yaml

@@ -0,0 +1,26 @@
+id: pipeline-hygiene-audit
+version: 1
+name: Pipeline Hygiene Audit
+description: >
+  Finds open deals missing basic required fields, like an amount, a close
+  date, or a next step, so forecasts and reports aren't quietly built on
+  bad data. Use this if a forecast has ever been wrong because half the
+  pipeline had blank fields nobody was checking for.
+category: sales
+tags: [sales, pipeline, data-quality, crm-hygiene]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select name, owner, stage, (case when amount is null then 'missing amount' end) || (case when close_date is null then ' missing close_date' end) || (case when next_step is null or next_step = '' then ' missing next_step' end) as issues from deals where stage not in ('closed_won','closed_lost') and (amount is null or close_date is null or next_step is null or next_step = '');"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `deals` table with `amount`, `close_date`, and `next_step`
+  columns — adjust the query and the required-field list to what your
+  team actually treats as mandatory. Distinct from `stale-deal-nudge`
+  (which flags deals with no recent activity) — this flags deals with
+  incomplete data regardless of how recently they were touched.

package/jobs/sales/poc-trial-conversion-tracker.yaml

@@ -0,0 +1,29 @@
+id: poc-trial-conversion-tracker
+version: 1
+name: Sales-Led POC Conversion Tracker
+description: >
+  Flags sales-assisted proof-of-concept (POC) engagements approaching or
+  past their end date with no closed-won or closed-lost outcome recorded.
+  Use this if an enterprise POC has ever quietly run past its agreed end
+  date with no clear owner pushing toward a decision.
+category: sales
+tags: [sales, poc, enterprise, conversion]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select account_name, owner, poc_end_date, stage from pocs where stage = 'in_progress' and poc_end_date < now() + interval '{{lookahead_days}} days' order by poc_end_date;"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database (a `pocs` table or equivalent stage on `deals`).
+  lookahead_days:
+    default: 7
+    description: How many days ahead (or past, if negative logic is added) to flag a POC nearing its end date.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a `pocs` table (or a `deals` table filtered to a POC stage) with
+  `poc_end_date` and `stage` columns — adjust to your CRM's schema. This
+  is a sales-assisted enterprise POC tracked in the CRM by a rep, distinct
+  from growth's `trial-expiring-nudge`, which tracks self-serve product
+  trials nearing expiration.