@wonsukchoi/crondex 0.21.0 → 0.22.0

package/jobs/realestate/tenant-renters-insurance-compliance-check.yaml

@@ -0,0 +1,35 @@
+id: tenant-renters-insurance-compliance-check
+version: 1
+name: Tenant Renters Insurance Compliance Check
+description: >
+  Checks tenants required by their lease to carry renters insurance
+  against their certificate's expiration date and flags anyone lapsed or
+  about to lapse. Use this if a tenant's coverage has ever quietly
+  expired mid-lease, leaving the landlord exposed on a liability claim
+  the lease was supposed to cover.
+category: realestate
+tags: [realestate, renters-insurance, compliance, tenant]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn="{{warn_days}}" '
+    NR==1 {next}
+    {
+      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 < 0) printf "LAPSED: %s (unit %s) renters insurance expired %d day(s) ago\n", $1, $2, -days_left;
+      else if (days_left <= warn) printf "EXPIRING SOON: %s (unit %s) renters insurance expires in %d day(s)\n", $1, $2, days_left;
+    }
+  ' "{{renters_coi_csv}}"
+variables:
+  renters_coi_csv:
+    default: "./tenant-renters-insurance.csv"
+    description: "CSV with header row, columns: tenant_name,unit,coverage_expiration_date(YYYY-MM-DD)."
+  warn_days:
+    default: 14
+    description: Days before expiration to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from subcontractor-insurance-expiry-check in jobs/construction (which tracks contractor COIs on a job site) — this tracks tenant renters-insurance compliance required by the lease, only useful where the lease actually mandates coverage.

package/jobs/realestate/utility-billback-reconciliation-check.yaml

@@ -0,0 +1,41 @@
+id: utility-billback-reconciliation-check
+version: 1
+name: Utility Bill-Back Reconciliation Check
+description: >
+  Compares submetered tenant utility charges against the property's
+  master utility bill and flags a mismatch beyond a set tolerance. Use
+  this if tenant bill-backs have ever quietly drifted from the actual
+  master bill, either undercharging the owner or overcharging tenants.
+category: realestate
+tags: [realestate, utilities, billing, reconciliation]
+schedule: "0 8 3 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v tol="{{tolerance_pct}}" '
+    NR==1 {next}
+    {
+      billed_total += $3;
+      master = $2;
+      property = $1;
+    }
+    END {
+      diff = billed_total - master;
+      pct = (master > 0) ? (diff / master * 100) : 0;
+      if (pct < 0) pct = -pct;
+      if (pct >= tol) {
+        printf "RECONCILIATION MISMATCH: %s — tenant bill-backs total $%.2f vs master bill $%.2f (%.1f%% variance)\n", property, billed_total, master, pct;
+      } else {
+        printf "OK: %s bill-backs reconcile within tolerance ($%.2f vs $%.2f)\n", property, billed_total, master;
+      }
+    }
+  ' "{{billback_csv}}"
+variables:
+  billback_csv:
+    default: "./utility-billback-ledger.csv"
+    description: "CSV with header row, columns: property_name,master_bill_amount,tenant_billed_amount — one row per submetered unit for the current billing period, master_bill_amount repeated per row for the property."
+  tolerance_pct:
+    default: 5
+    description: Allowed percentage variance between total tenant bill-backs and the master bill before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a per-period export of submeter charges alongside the master bill amount — adjust the CSV shape to match your submetering vendor or utility management software's export.

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.

package/jobs/sales/referral-followup-tracker.yaml

@@ -0,0 +1,40 @@
+id: referral-followup-tracker
+version: 1
+name: Referral Follow-Up Tracker
+description: >
+  Flags customer referrals that were asked for or given, and haven't had a
+  logged follow-up after a set number of days. Use this if a happy
+  customer has ever offered a referral introduction and it fell through
+  the cracks because nobody owned the follow-up.
+category: sales
+tags: [sales, referrals, advocacy, follow-up]
+schedule: "0 9 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v wait_days="{{wait_days}}" '
+    NR==1 {next}
+    $5 == "yes" {next}
+    {
+      customer=$1; referred_contact=$2; requested_date=$3; owner=$4;
+      cmd = "date -d \"" requested_date "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" requested_date "\" +%s 2>/dev/null";
+      cmd | getline req_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      days = (now_epoch - req_epoch) / 86400;
+      if (days >= wait_days) {
+        printf "NEEDS FOLLOW-UP: %s referred %s (owner: %s) — %d day(s) since requested\n", customer, referred_contact, owner, days;
+      }
+    }
+  ' "{{referrals_csv_path}}"
+variables:
+  referrals_csv_path:
+    default: "./referrals.csv"
+    description: "Path to a CSV with columns: customer_name,referred_contact,requested_date,owner,followed_up (yes/no; requested_date is YYYY-MM-DD)."
+  wait_days:
+    default: 5
+    description: Days after a referral is logged before it's flagged as overdue for a follow-up.
+compatible_agents: [generic, claude, codex]
+notes: >
+  You maintain referrals.csv yourself (log it when a customer offers or
+  makes an introduction, mark followed_up=yes once the owner reaches out)
+  — doesn't integrate with any CRM directly.

package/jobs/sales/territory-coverage-gap-check.yaml

@@ -0,0 +1,43 @@
+id: territory-coverage-gap-check
+version: 1
+name: Territory Coverage Gap Check
+description: >
+  Flags target accounts that have no assigned rep, or have an assigned
+  rep but no logged activity in a long time. Use this if an account has
+  ever gone completely unworked for months simply because it fell between
+  territory reassignments and nobody noticed the gap.
+category: sales
+tags: [sales, territory, account-coverage, ops]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v stale_days="{{stale_days}}" '
+    NR==1 {next}
+    {
+      account=$1; rep=$2; last_activity=$3;
+      if (rep == "" ) {
+        printf "UNASSIGNED: %s has no assigned rep\n", account;
+        next;
+      }
+      cmd = "date -d \"" last_activity "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" last_activity "\" +%s 2>/dev/null";
+      cmd | getline last_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      days = (now_epoch - last_epoch) / 86400;
+      if (days >= stale_days) {
+        printf "NO ACTIVITY: %s (rep: %s) — %d day(s) since last activity\n", account, rep, days;
+      }
+    }
+  ' "{{accounts_csv_path}}"
+variables:
+  accounts_csv_path:
+    default: "./target-accounts.csv"
+    description: "Path to a CSV with columns: account_name,assigned_rep,last_activity_date (YYYY-MM-DD; assigned_rep blank if unowned)."
+  stale_days:
+    default: 45
+    description: Days without logged activity on an assigned account before it's flagged as a coverage gap.
+compatible_agents: [generic, claude, codex]
+notes: >
+  You maintain target-accounts.csv yourself (or export it from your CRM's
+  account list) — this is a coverage/ownership check, not a deal-level
+  staleness check (see `stale-deal-nudge` for that).

package/lib/duplicates-allowlist.js

@@ -16,6 +16,11 @@ export const ALLOWED_DUPLICATE_PAIRS = [
     "warranty-claim-expiry-check",
     "Same deadline-check pattern, different domains — automotive repair-order warranty claims vs. HVAC/appliance manufacturer warranty claims.",
   ],
+  [
+    "claim-status-check",
+    "landlord-insurance-claim-status-check",
+    "Same stale-claim-followup goal, different mechanism and scale — generic insurance job is agent-prompt for a single policyholder's claims; realestate job is a zero-token shell scan over a property portfolio's claims CSV.",
+  ],
 ];
 
 export function isAllowedPair(idA, idB) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wonsukchoi/crondex",
-  "version": "0.21.0",
+  "version": "0.22.0",
   "description": "A public directory of pre-made, agent-editable cron jobs.",
   "type": "module",
   "license": "MIT",
@@ -38,7 +38,7 @@
     "lint-shell": "node scripts/lint-shell.js",
     "check-duplicates": "node scripts/check-duplicates.js",
     "smoke-test": "node scripts/smoke-test.js",
-    "test": "node --test"
+    "test": "node --test \"test/*.test.js\""
   },
   "dependencies": {
     "js-yaml": "^4.1.0"