@wonsukchoi/crondex 0.21.0 → 0.22.0

package/jobs/ecommerce/affiliate-commission-payout-check.yaml

@@ -0,0 +1,38 @@
+id: affiliate-commission-payout-check
+version: 1
+name: Affiliate Commission Payout Check
+description: >
+  Checks commissions owed to affiliates who drive sales to your store
+  against your payout schedule and flags anything overdue and still
+  unpaid. Use this if an affiliate has ever had to chase you for a
+  commission payment because nobody was tracking payout due dates on
+  your side.
+category: ecommerce
+tags: [ecommerce, affiliates, commissions, payouts, finance]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    $4 == "unpaid" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      if (today > due_epoch) {
+        overdue_days = (today - due_epoch) / 86400;
+        printf "OVERDUE PAYOUT: %s owed $%s — due %s (%d days late)\n", $1, $2, $3, overdue_days;
+      }
+    }
+  ' "{{affiliate_commissions_csv_path}}"
+variables:
+  affiliate_commissions_csv_path:
+    default: "./affiliate-commissions.csv"
+    description: "Path to a CSV with columns: affiliate_name,commission_due_usd,due_date (YYYY-MM-DD),status (unpaid/paid)."
+compatible_agents: [generic, claude, codex]
+notes: >
+  This is the merchant's side of paying affiliates who sell for the
+  store — the reverse direction of `brand-deal-payment-followup-check` in
+  the creator category, which tracks a creator waiting to be paid by a
+  sponsor. Also distinct from `affiliate-link-expiry-check` in creator,
+  which tracks a creator's own link/code expiry, not commission payouts.

package/jobs/ecommerce/back-in-stock-notification-backlog-check.yaml

@@ -0,0 +1,30 @@
+id: back-in-stock-notification-backlog-check
+version: 1
+name: Back-in-Stock Notification Backlog Check
+description: >
+  Checks products that customers asked to be notified about against
+  current stock levels, and flags any that are back in stock with a
+  waiting list that never got notified. Use this if an item has ever
+  restocked while a list of interested customers sat unnotified until
+  the item sold out again, missing the sale entirely.
+category: ecommerce
+tags: [ecommerce, back-in-stock, notifications, inventory]
+schedule: "0 */3 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      sku=$1; current_stock=$2; waitlist_count=$3; notified=$4;
+      if (current_stock+0 > 0 && waitlist_count+0 > 0 && notified == "no") {
+        printf "NOTIFY BACKLOG: %s — %d units in stock, %d customers waiting, not yet notified\n", sku, current_stock, waitlist_count;
+      }
+    }
+  ' "{{waitlist_csv_path}}"
+variables:
+  waitlist_csv_path:
+    default: "./back-in-stock-waitlist.csv"
+    description: "Path to a CSV with columns: sku,current_stock,waitlist_count,notified (yes/no) — one row per SKU with an active back-in-stock waitlist."
+compatible_agents: [generic, claude, codex]
+notes: Mark a SKU "notified" once your ESP/app actually sends the alert, so this only ever flags a genuine backlog rather than re-flagging sent notifications every run.

package/jobs/ecommerce/bundle-component-stock-mismatch-check.yaml

@@ -0,0 +1,37 @@
+id: bundle-component-stock-mismatch-check
+version: 1
+name: Bundle Component Stock Mismatch Check
+description: >
+  Checks each product bundle/kit against the stock of its individual
+  components and flags any bundle still marked in-stock while one of its
+  components is actually out. Use this if a bundle has ever sold through
+  checkout only for fulfillment to discover one piece of it was
+  unavailable, because the bundle's own stock flag wasn't tied to its
+  components.
+category: ecommerce
+tags: [ecommerce, bundles, inventory, kitting]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      bundle=$1; component_stock=$3; listed_status=$4;
+      if (component_stock+0 <= 0) out_of_stock_component[bundle] = out_of_stock_component[bundle] " " $2;
+      bundle_status[bundle] = listed_status;
+    }
+    END {
+      for (b in bundle_status) {
+        if (bundle_status[b] == "in-stock" && (b in out_of_stock_component)) {
+          printf "MISMATCH: bundle %s is listed in-stock but missing component(s):%s\n", b, out_of_stock_component[b];
+        }
+      }
+    }
+  ' "{{bundle_components_csv_path}}"
+variables:
+  bundle_components_csv_path:
+    default: "./bundle-components.csv"
+    description: "Path to a CSV with columns: bundle_sku,component_sku,component_stock,bundle_listed_status (in-stock/out-of-stock) — one row per component of each bundle."
+compatible_agents: [generic, claude, codex]
+notes: Distinct from `low-stock-reorder-alert`, which tracks a single SKU's own stock velocity — this checks whether a bundle's listed availability is actually consistent with what it's made of.

package/jobs/ecommerce/chargeback-fraud-risk-order-review.yaml

@@ -0,0 +1,43 @@
+id: chargeback-fraud-risk-order-review
+version: 1
+name: Chargeback Fraud Risk Order Review
+description: >
+  Scores new orders against common fraud signals — billing/shipping
+  country mismatch, high order value from a first-time customer, and
+  rush shipping on an unverified address — and flags the risky ones
+  before they ship. Use this if a chargeback has ever landed on an order
+  that, in hindsight, had obvious red flags nobody checked before
+  fulfillment.
+category: ecommerce
+tags: [ecommerce, fraud, chargebacks, risk, orders]
+schedule: "0 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v minval="{{high_value_threshold}}" '
+    NR==1 {next}
+    {
+      order_id=$1; billing_country=$2; shipping_country=$3;
+      value=$4; is_new_customer=$5; shipping_method=$6;
+      score=0; reasons="";
+      if (billing_country != shipping_country) { score++; reasons = reasons "billing/shipping country mismatch; "; }
+      if (value+0 >= minval) { score++; reasons = reasons "high order value; "; }
+      if (is_new_customer == "yes") { score++; reasons = reasons "first-time customer; "; }
+      if (shipping_method == "rush" || shipping_method == "expedited") { score++; reasons = reasons "rush shipping; "; }
+      if (score >= {{flag_score_threshold}}) {
+        printf "REVIEW: order %s (score %d) — %s\n", order_id, score, reasons;
+      }
+    }
+  ' "{{orders_csv_path}}"
+variables:
+  orders_csv_path:
+    default: "./new-orders.csv"
+    description: "Path to a CSV with columns: order_id,billing_country,shipping_country,order_value,is_new_customer(yes/no),shipping_method."
+  high_value_threshold:
+    default: 300
+    description: Order value in your currency at or above which it counts as a fraud-risk signal.
+  flag_score_threshold:
+    default: 2
+    description: Number of matching risk signals (0-4) required before an order is flagged for manual review.
+compatible_agents: [generic, claude, codex]
+notes: A flag is a prompt for manual review before shipping, not proof of fraud — legitimate customers trigger these signals too (gifts, travel, new-to-you shoppers). Distinct from `return-fraud-pattern-check` in the retail category, which looks at return abuse after the sale, not pre-fulfillment order risk.

package/jobs/ecommerce/competitor-price-watch.yaml

@@ -0,0 +1,60 @@
+id: competitor-price-watch
+version: 1
+name: Competitor Price Watch
+description: >
+  Fetches a competitor's product page for each SKU you're tracking, pulls
+  out the price, and flags any SKU where their price has moved enough to
+  matter relative to yours. Use this if you've ever found out you were
+  underpricing (or getting undercut on) a product only because a customer
+  mentioned it.
+category: ecommerce
+tags: [ecommerce, pricing, competitor, monitoring]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: hybrid
+command: >
+  while IFS=',' read -r sku your_price url; do
+    [ "$sku" = "sku" ] && continue;
+    [ -z "$url" ] && continue;
+    page=$(curl -s -A "Mozilla/5.0" --max-time {{timeout_seconds}} "$url");
+    comp_price=$(echo "$page" | grep -oE "{{price_regex}}" | head -n1 | grep -oE "[0-9]+\.[0-9]{2}");
+    if [ -z "$comp_price" ]; then
+      echo "UNPARSED: $sku — could not extract a price from $url";
+      continue;
+    fi;
+    diff=$(awk -v y="$your_price" -v c="$comp_price" 'BEGIN{d=y-c; if(d<0)d=-d; printf "%.2f", d}');
+    if awk -v d="$diff" -v t="{{diff_threshold_usd}}" 'BEGIN{exit !(d >= t)}'; then
+      echo "PRICE GAP: $sku — you: \$$your_price, competitor: \$$comp_price (diff \$$diff) at $url";
+    fi;
+  done < "{{tracked_skus_csv_path}}"
+prompt: |
+  The script above tried to scrape a competitor price per SKU from
+  {{tracked_skus_csv_path}} using a regex and reported any it couldn't
+  parse, plus any SKU with a price gap of at least ${{diff_threshold_usd}}.
+  1. For any "UNPARSED" line, open the competitor URL yourself and find
+     the current price (the site likely renders price via JavaScript or
+     uses a layout the regex doesn't match).
+  2. For any "PRICE GAP" line, note whether the competitor is now cheaper
+     or more expensive than you, and by what percentage.
+  3. Summarize in one short list: which SKUs need a pricing decision this
+     week, ranked by gap size.
+script_note: >
+  `command` gives you a fast, zero-token first pass using a regex against
+  raw HTML — it will miss JS-rendered prices and misses on unusual page
+  layouts. `prompt` catches what the regex missed and turns the raw diffs
+  into a prioritized, human-readable pricing summary.
+variables:
+  tracked_skus_csv_path:
+    default: "./competitor-price-tracking.csv"
+    description: "Path to a CSV with columns: sku,your_price,competitor_product_url — one row per SKU you want to price-watch."
+  price_regex:
+    default: "\\$[0-9]+\\.[0-9]{2}"
+    description: Regex used to extract a dollar price from the competitor's raw page HTML; adjust per site if it isn't matching.
+  diff_threshold_usd:
+    default: 2.00
+    description: Minimum price difference in dollars worth flagging.
+  timeout_seconds:
+    default: 10
+    description: Seconds to wait for each competitor page before giving up.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Respect the target site's robots.txt/terms before scraping. Distinct from `competitor-page-diff-watch` in marketing, which diffs whole-page content/messaging — this is narrowly a per-SKU price comparison against your own price list.

package/jobs/ecommerce/economic-nexus-threshold-check.yaml

@@ -0,0 +1,43 @@
+id: economic-nexus-threshold-check
+version: 1
+name: Economic Nexus Threshold Check
+description: >
+  Checks your year-to-date sales revenue and transaction count per state
+  against economic nexus thresholds and flags states you're approaching
+  or have crossed. Use this if you've ever registered for sales tax in a
+  state only after crossing the threshold months earlier, because nobody
+  was tracking cumulative sales by state.
+category: ecommerce
+tags: [ecommerce, sales-tax, nexus, compliance, finance]
+schedule: "0 6 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v rev_thresh="{{revenue_threshold_usd}}" -v txn_thresh="{{transaction_threshold}}" -v warn_pct="{{warn_pct}}" '
+    NR==1 {next}
+    {
+      state=$1; revenue=$2; transactions=$3;
+      rev_warn = rev_thresh * (1 - warn_pct/100);
+      txn_warn = txn_thresh * (1 - warn_pct/100);
+      if (revenue+0 >= rev_thresh || transactions+0 >= txn_thresh) {
+        printf "NEXUS CROSSED: %s — revenue $%.2f, transactions %d (already registered? verify)\n", state, revenue, transactions;
+      } else if (revenue+0 >= rev_warn || transactions+0 >= txn_warn) {
+        printf "APPROACHING NEXUS: %s — revenue $%.2f, transactions %d\n", state, revenue, transactions;
+      }
+    }
+  ' "{{state_sales_csv_path}}"
+variables:
+  state_sales_csv_path:
+    default: "./state-sales-ytd.csv"
+    description: "Path to a CSV with columns: state,ytd_revenue_usd,ytd_transaction_count — one row per state you ship to."
+  revenue_threshold_usd:
+    default: 100000
+    description: "Default economic nexus revenue threshold (varies by state — check each state's actual rule; $100k/200 transactions is common but not universal)."
+  transaction_threshold:
+    default: 200
+    description: Default economic nexus transaction-count threshold.
+  warn_pct:
+    default: 20
+    description: Percent below the threshold at which a state counts as "approaching" and worth watching.
+compatible_agents: [generic, claude, codex]
+notes: Thresholds genuinely vary by state (some have no transaction-count prong, some use different dollar amounts) — this uses one configurable default across all states as a first-pass filter, not a substitute for checking each state's actual rule before registering or not registering.

package/jobs/ecommerce/failed-payment-dunning-check.yaml

@@ -0,0 +1,35 @@
+id: failed-payment-dunning-check
+version: 1
+name: Failed Payment Dunning Check
+description: >
+  Checks recurring/subscription orders with a failed payment and flags
+  ones that have been retrying too long without success, so you can step
+  in before the customer silently churns. Use this if a subscriber has
+  ever stayed on "payment failed" for weeks with nobody following up,
+  quietly costing you recurring revenue.
+category: ecommerce
+tags: [ecommerce, subscriptions, payments, dunning, churn]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v max_days="{{max_retry_days}}" -v max_attempts="{{max_retry_attempts}}" '
+    NR==1 {next}
+    $2 == "failed" {
+      if ($3+0 >= max_days || $4+0 >= max_attempts) {
+        printf "NEEDS ACTION: subscription %s — %d days failing, %d retry attempts\n", $1, $3, $4;
+      }
+    }
+  ' "{{subscriptions_csv_path}}"
+variables:
+  subscriptions_csv_path:
+    default: "./subscriptions.csv"
+    description: "Path to a CSV with columns: subscription_id,status (failed/active),days_since_first_failure,retry_attempt_count."
+  max_retry_days:
+    default: 7
+    description: Days a subscription can sit in failed-payment status before it needs a manual touch (update card, human outreach, or cancel).
+  max_retry_attempts:
+    default: 4
+    description: Number of automatic retry attempts before it needs a manual touch instead of another silent retry.
+compatible_agents: [generic, claude, codex]
+notes: This flags when automatic dunning has run its course — pair with an actual outreach step (email, SMS, or account pause) since the job itself only identifies who needs it.

package/jobs/ecommerce/marketplace-listing-sync-drift-check.yaml

@@ -0,0 +1,48 @@
+id: marketplace-listing-sync-drift-check
+version: 1
+name: Marketplace Listing Sync Drift Check
+description: >
+  Compares price and stock on your source-of-truth catalog against what's
+  actually live on a marketplace (Amazon, eBay, Etsy) and flags any SKU
+  that's drifted out of sync. Use this if a marketplace listing has ever
+  shown a stale price or "in stock" on an item you'd already sold out of
+  on your own store, because the sync job silently failed.
+category: ecommerce
+tags: [ecommerce, marketplace, sync, inventory, pricing]
+schedule: "0 */4 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    FNR==NR {
+      if (FNR==1) {next}
+      truth_price[$1]=$2; truth_stock[$1]=$3; next
+    }
+    {
+      if (FNR==1) {next}
+      sku=$1; mkt_price=$2; mkt_stock=$3; marketplace=$4;
+      if (sku in truth_price) {
+        price_diff = truth_price[sku] - mkt_price; if (price_diff < 0) price_diff = -price_diff;
+        if (price_diff > {{price_tolerance_usd}}) {
+          printf "PRICE DRIFT: %s on %s — source: $%.2f, listed: $%.2f\n", sku, marketplace, truth_price[sku], mkt_price;
+        }
+        if ((truth_stock[sku]+0 <= 0) != (mkt_stock+0 <= 0)) {
+          printf "STOCK DRIFT: %s on %s — source stock: %s, listed stock: %s\n", sku, marketplace, truth_stock[sku], mkt_stock;
+        }
+      } else {
+        printf "UNMATCHED SKU: %s on %s not found in source-of-truth catalog\n", sku, marketplace;
+      }
+    }
+  ' "{{source_of_truth_csv_path}}" "{{marketplace_export_csv_path}}"
+variables:
+  source_of_truth_csv_path:
+    default: "./catalog-source-of-truth.csv"
+    description: "Path to a CSV with columns: sku,price,stock — your own store's authoritative price/stock."
+  marketplace_export_csv_path:
+    default: "./marketplace-listings.csv"
+    description: "Path to a CSV export with columns: sku,listed_price,listed_stock,marketplace — one row per live listing per marketplace."
+  price_tolerance_usd:
+    default: 1.00
+    description: Acceptable price difference in dollars between source and marketplace before flagging drift.
+compatible_agents: [generic, claude, codex]
+notes: Requires both exports to use the same SKU values — normalize SKU formatting on export if a marketplace mangles it (e.g. adds a prefix).

package/jobs/ecommerce/product-feed-health-check.yaml

@@ -0,0 +1,35 @@
+id: product-feed-health-check
+version: 1
+name: Product Feed Health Check
+description: >
+  Scans your product catalog export for listings that are live but broken
+  in some way — missing title, missing description, missing image, a
+  zero/blank price, or marked out-of-stock while still visible to
+  shoppers. Use this if a product has ever sat on your storefront for
+  weeks with a broken image or a $0 price because nobody was checking
+  feed quality after the initial upload.
+category: ecommerce
+tags: [ecommerce, product-feed, seo, catalog, data-quality]
+schedule: "0 5 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      sku=$1; title=$2; description=$3; image_url=$4; price=$5; in_stock=$6; visible=$7;
+      issues="";
+      if (title == "") issues = issues "missing title; ";
+      if (description == "") issues = issues "missing description; ";
+      if (image_url == "") issues = issues "missing image; ";
+      if (price+0 <= 0) issues = issues "zero/blank price; ";
+      if (in_stock == "false" && visible == "true") issues = issues "out-of-stock but still visible; ";
+      if (issues != "") printf "ISSUE: %s — %s\n", sku, issues;
+    }
+  ' "{{product_feed_csv_path}}"
+variables:
+  product_feed_csv_path:
+    default: "./product-feed.csv"
+    description: "Path to a CSV export with columns: sku,title,description,image_url,price,in_stock(true/false),visible(true/false)."
+compatible_agents: [generic, claude, codex]
+notes: Export this from whatever generates your storefront/Google Shopping feed on a schedule — the checks are only as fresh as the export. Distinct from `low-stock-reorder-alert`, which tracks stock levels, not listing data quality.

package/jobs/ecommerce/purchase-order-overdue-check.yaml

@@ -0,0 +1,32 @@
+id: purchase-order-overdue-check
+version: 1
+name: Purchase Order Overdue Check
+description: >
+  Checks open purchase orders to suppliers against their expected
+  delivery date and flags anything that hasn't arrived on time. Use this
+  if a supplier has ever gone quiet on a PO and you only found out stock
+  wasn't coming when you were already out of the item.
+category: ecommerce
+tags: [ecommerce, purchase-orders, suppliers, inventory]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    $4 == "pending" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline expected_epoch; close(cmd);
+      if (today > expected_epoch) {
+        overdue_days = (today - expected_epoch) / 86400;
+        printf "OVERDUE PO: %s from %s — expected %s (%d days late)\n", $1, $2, $3, overdue_days;
+      }
+    }
+  ' "{{purchase_orders_csv_path}}"
+variables:
+  purchase_orders_csv_path:
+    default: "./purchase-orders.csv"
+    description: "Path to a CSV with columns: po_id,supplier_name,expected_delivery_date (YYYY-MM-DD),status (pending/received)."
+compatible_agents: [generic, claude, codex]
+notes: Mark a PO "received" as soon as stock lands so this only ever flags genuinely overdue orders. Distinct from `low-stock-reorder-alert` (decides when to place an order) and `shipping-delay-check` (tracks outbound orders to customers) — this tracks inbound supplier orders after they've been placed.

package/jobs/ecommerce/storefront-ssl-domain-expiry-check.yaml

@@ -0,0 +1,46 @@
+id: storefront-ssl-domain-expiry-check
+version: 1
+name: Storefront SSL & Domain Expiry Check
+description: >
+  Checks your storefront's SSL certificate and domain registration expiry
+  dates and flags anything expiring soon. Use this if your store has ever
+  gone down — or thrown a scary browser security warning at checkout —
+  because an SSL cert or domain renewal quietly lapsed.
+category: ecommerce
+tags: [ecommerce, ssl, domain, uptime, infrastructure]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  domain="{{storefront_domain}}";
+  warn_days="{{warn_days}}";
+  cert_end=$(echo | openssl s_client -servername "$domain" -connect "$domain":443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2);
+  if [ -n "$cert_end" ]; then
+    cert_epoch=$(date -d "$cert_end" +%s 2>/dev/null || date -j -f "%b %d %T %Y %Z" "$cert_end" +%s 2>/dev/null);
+    now_epoch=$(date +%s);
+    cert_days_left=$(( (cert_epoch - now_epoch) / 86400 ));
+    if [ "$cert_days_left" -le "$warn_days" ]; then
+      echo "SSL WARNING: cert for $domain expires in $cert_days_left days ($cert_end)";
+    fi;
+  else
+    echo "ERROR: could not read SSL cert for $domain";
+  fi;
+  domain_end=$(whois "$domain" 2>/dev/null | grep -iE "registry expiry|expiration date" | head -n1 | sed -E 's/.*: *//');
+  if [ -n "$domain_end" ]; then
+    dom_epoch=$(date -d "$domain_end" +%s 2>/dev/null);
+    if [ -n "$dom_epoch" ]; then
+      dom_days_left=$(( (dom_epoch - now_epoch) / 86400 ));
+      if [ "$dom_days_left" -le "$warn_days" ]; then
+        echo "DOMAIN WARNING: $domain registration expires in $dom_days_left days ($domain_end)";
+      fi;
+    fi;
+  fi
+variables:
+  storefront_domain:
+    default: "example.com"
+    description: The domain your storefront is served from (no protocol/path).
+  warn_days:
+    default: 21
+    description: Days before SSL cert or domain expiry to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Requires `openssl` and `whois` on the runner; whois output format varies by registrar/TLD, so treat a missing DOMAIN WARNING line as inconclusive rather than "all clear" and spot-check manually a few times after setup.

package/jobs/ecommerce/vip-tier-reclassification-check.yaml

@@ -0,0 +1,55 @@
+id: vip-tier-reclassification-check
+version: 1
+name: VIP Tier Reclassification Check
+description: >
+  Checks each customer's year-to-date spend against your VIP tier
+  thresholds and flags anyone due to move up or down a tier, drafting a
+  short outreach note for new upgrades. Use this if a top customer has
+  ever crossed your VIP spend threshold months ago and never got the
+  perks (or the acknowledgment) because nobody was tracking tier
+  crossings.
+category: ecommerce
+tags: [ecommerce, vip, customers, ltv, segmentation]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: hybrid
+command: >
+  awk -F',' -v gold="{{gold_threshold_usd}}" -v platinum="{{platinum_threshold_usd}}" '
+    NR==1 {next}
+    {
+      customer=$1; spend=$2; current_tier=$3;
+      new_tier = "standard";
+      if (spend+0 >= platinum) new_tier = "platinum";
+      else if (spend+0 >= gold) new_tier = "gold";
+      if (new_tier != current_tier) {
+        printf "TIER CHANGE: %s — %s -> %s (YTD spend $%.2f)\n", customer, current_tier, new_tier, spend;
+      }
+    }
+  ' "{{customers_csv_path}}"
+prompt: |
+  The script above compared each customer's YTD spend to the VIP tier
+  thresholds and listed everyone whose tier should change.
+  1. For each upgrade (moving to a higher tier), draft a short, warm
+     note acknowledging the milestone and naming the specific new perk
+     they've unlocked.
+  2. For each downgrade, just list it plainly — no outreach needed, this
+     is usually just for internal tracking/perk removal timing.
+  3. Group the final output into "Upgrades (draft ready)" and
+     "Downgrades (no action needed)".
+script_note: >
+  `command` gives you the raw list of who crossed a threshold in either
+  direction, at zero token cost. `prompt` adds the human touch: a
+  genuine, specific congratulations note for upgrades instead of a
+  generic template, which is the part worth spending tokens on.
+variables:
+  customers_csv_path:
+    default: "./customer-ytd-spend.csv"
+    description: "Path to a CSV with columns: customer_name,ytd_spend_usd,current_tier (standard/gold/platinum)."
+  gold_threshold_usd:
+    default: 500
+    description: YTD spend at or above which a customer qualifies for gold tier.
+  platinum_threshold_usd:
+    default: 2000
+    description: YTD spend at or above which a customer qualifies for platinum tier.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Distinct from `loyalty-points-expiry-reminder` in retail, which tracks points balances expiring — this tracks total spend against tier thresholds, independent of any points program.

package/jobs/ecommerce/wishlist-abandonment-check.yaml

@@ -0,0 +1,37 @@
+id: wishlist-abandonment-check
+version: 1
+name: Wishlist Abandonment Check
+description: >
+  Checks customer wishlists for items that have sat untouched for a while
+  and drafts a nudge email when there's a real reason to reach out — a
+  price drop or the item is back in stock — instead of a generic
+  "you still want this?" reminder. Use this if you've ever had a wishlist
+  feature that quietly collects intent and never converts any of it back
+  into a sale.
+category: ecommerce
+tags: [ecommerce, wishlist, recovery, conversion, sales]
+schedule: "0 11 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{store_platform}} for wishlist items added at least
+  {{min_days_on_wishlist}} days ago that are still in the customer's
+  wishlist (not purchased).
+  1. For each, check whether the item's price has dropped or it went
+     from out-of-stock to in-stock since it was wishlisted.
+  2. Only draft an outreach email for items with one of those real
+     triggers — skip items where nothing has changed, since a nudge with
+     no news performs worse than no email at all.
+  3. Draft a short, specific email per triggered item: name the item, the
+     specific change (price/stock), and a clear link back to it.
+  4. Report how many wishlist items were checked, how many had a real
+     trigger, and how many drafts were produced.
+variables:
+  store_platform:
+    default: "your storefront platform"
+    description: Name of the e-commerce platform with wishlist data (e.g. "Shopify", "WooCommerce").
+  min_days_on_wishlist:
+    default: 14
+    description: Minimum days an item must have sat on a wishlist before it's eligible for a re-engagement check.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Draft-only — review before sending, and confirm your platform's marketing-consent rules cover wishlist-triggered email. Distinct from `abandoned-cart-recovery-check`, which targets items already added to an active cart; this targets earlier-funnel intent that never reached checkout, and only fires on a real trigger rather than time elapsed alone.

package/jobs/finance/accounts-payable-aging-check.yaml

@@ -0,0 +1,40 @@
+id: accounts-payable-aging-check
+version: 1
+name: Accounts Payable Aging Check
+description: >
+  Buckets bills you owe (not invoices you've sent) into aging ranges —
+  current, 30, 60, 90+ days past due — so nothing quietly slips into a
+  late-fee zone. Use this if you or your business pay vendors on terms
+  and want a standing view of what's coming due versus already overdue.
+category: finance
+tags: [accounts-payable, bills, aging, finance]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  file={{payables_file}};
+  [ -f "$file" ] || { echo "ERROR: $file not found"; exit 1; };
+  today=$(date +%s);
+  tail -n +2 "$file" | while IFS=, read -r vendor invoice_id amount due paid; do
+    [ "$paid" = "yes" ] && continue;
+    due_epoch=$(date -j -f %Y-%m-%d "$due" +%s 2>/dev/null || date -d "$due" +%s);
+    days=$(( (today-due_epoch)/86400 ));
+    if [ "$days" -le 0 ]; then bucket="current";
+    elif [ "$days" -le 30 ]; then bucket="1-30 days";
+    elif [ "$days" -le 60 ]; then bucket="31-60 days";
+    elif [ "$days" -le 90 ]; then bucket="61-90 days";
+    else bucket="90+ days"; fi;
+    echo "$bucket | $vendor invoice $invoice_id — \$$amount (due $due)";
+  done | sort
+variables:
+  payables_file:
+    default: "./accounts-payable.csv"
+    description: >
+      CSV with header "vendor,invoice_id,amount,due_date,paid" (due_date
+      is YYYY-MM-DD, paid is yes/no) — bills you owe, not invoices you've
+      sent (see invoice-overdue-check for receivables).
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token. You maintain accounts-payable.csv yourself (mark paid=yes
+  once settled) — this is the payables mirror of invoice-overdue-check,
+  which tracks receivables instead.

package/jobs/finance/bank-statement-reconciliation-check.yaml

@@ -0,0 +1,40 @@
+id: bank-statement-reconciliation-check
+version: 1
+name: Bank Statement Reconciliation Check
+description: >
+  Compares your internal ledger against a bank/card statement export and
+  flags transactions present in one but not the other, plus any balance
+  mismatch. Use this if your books have ever quietly drifted from what
+  the bank actually shows and you only found out at tax time.
+category: finance
+tags: [reconciliation, bookkeeping, bank, finance]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  ledger={{ledger_csv}}; statement={{statement_csv}};
+  [ -f "$ledger" ] || { echo "ERROR: $ledger not found"; exit 1; };
+  [ -f "$statement" ] || { echo "ERROR: $statement not found"; exit 1; };
+  echo "-- in statement but missing from ledger --";
+  tail -n +2 "$statement" | cut -d, -f1,3 | sort > /tmp/_stmt_ids.$$;
+  tail -n +2 "$ledger" | cut -d, -f1,3 | sort > /tmp/_ledger_ids.$$;
+  comm -23 /tmp/_stmt_ids.$$ /tmp/_ledger_ids.$$;
+  echo "-- in ledger but missing from statement --";
+  comm -13 /tmp/_stmt_ids.$$ /tmp/_ledger_ids.$$;
+  rm -f /tmp/_stmt_ids.$$ /tmp/_ledger_ids.$$
+variables:
+  ledger_csv:
+    default: "./ledger.csv"
+    description: >
+      CSV with header "date,description,amount" — your internal
+      bookkeeping record of transactions.
+  statement_csv:
+    default: "./bank-statement.csv"
+    description: >
+      CSV with header "date,description,amount" exported from your bank
+      or card provider for the same period.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Zero-token, matches on date+amount only (description text often differs
+  between ledger and bank export) — near-matches on rounding or
+  same-day-different-amount won't be caught, review flagged rows by hand.