@wonsukchoi/crondex 0.21.0 → 0.23.0

package/jobs/construction/jobsite-safety-incident-near-miss-tracker.yaml

@@ -0,0 +1,35 @@
+id: jobsite-safety-incident-near-miss-tracker
+version: 1
+name: Jobsite Safety Incident & Near-Miss Tracker
+description: >
+  Reviews recently logged safety incidents and near-misses across active
+  sites for repeat causes, escalating severity, or a site racking up more
+  reports than its peers. Use this if a serious incident has ever happened
+  after a string of smaller near-misses that, in hindsight, pointed right
+  at it.
+category: construction
+tags: [construction, safety, incidents, near-miss]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review the safety incident and near-miss log ({{incident_log_path}}) for
+  entries from the last {{lookback_days}} days.
+  1. Group entries by jobsite and by root cause category (falls, struck-by,
+     equipment, electrical, other).
+  2. Flag any site with more reports than its trailing average, and any
+     cause category that's recurring across 2+ separate incidents.
+  3. Call out any near-miss whose description suggests it could plausibly
+     have been a serious injury or fatality if circumstances were slightly
+     different.
+  4. Produce a short list of sites/causes that warrant a toolbox talk or
+     stand-down this week, in priority order.
+variables:
+  incident_log_path:
+    default: "./safety-incident-log.csv"
+    description: "Path to the incident/near-miss log — expects columns like date, site, description, severity, cause_category."
+  lookback_days:
+    default: 30
+    description: How many days of incident history to review each run.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Distinct from crew-safety-cert-expiry-check — that job tracks individual worker certification dates, not incident/near-miss event patterns across sites.

package/jobs/construction/lien-waiver-collection-tracker.yaml

@@ -0,0 +1,27 @@
+id: lien-waiver-collection-tracker
+version: 1
+name: Lien Waiver Collection Tracker
+description: >
+  Checks that a signed lien waiver was collected from each subcontractor
+  before their next payment goes out, so payments never run ahead of the
+  paperwork that protects against a mechanic's lien. Use this if a
+  subcontractor has ever been paid without a waiver on file, leaving the
+  project exposed to a lien claim on money that was already paid out.
+category: construction
+tags: [construction, lien-waiver, payments, compliance, subcontractor]
+schedule: "0 7 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    $4 == "scheduled" && $3 != "received" {
+      printf "MISSING WAIVER: %s — payment of $%s scheduled for %s, waiver status: %s\n", $1, $2, $5, $3;
+    }
+  ' "{{payments_waivers_csv}}"
+variables:
+  payments_waivers_csv:
+    default: "./payments-lien-waivers.csv"
+    description: "Path to a CSV with columns: subcontractor_name,payment_amount,waiver_status (received/pending/none),payment_status (scheduled/held/paid),payment_date."
+compatible_agents: [generic, claude, codex]
+notes: Distinct from subcontractor-insurance-expiry-check — that job tracks COI expiry dates, not per-payment lien waiver paperwork.

package/jobs/construction/permit-application-approval-backlog-check.yaml

@@ -0,0 +1,33 @@
+id: permit-application-approval-backlog-check
+version: 1
+name: Permit Application Approval Backlog Check
+description: >
+  Flags submitted permit applications that are still awaiting municipal
+  approval past a reasonable turnaround window. Use this if a project has
+  ever sat idle at the "waiting on the city" stage far longer than expected
+  because nobody was tracking submission-to-approval time.
+category: construction
+tags: [construction, permits, approvals, backlog]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn="{{stale_days}}" '
+    NR==1 {next}
+    $4 == "submitted" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline sub_ts; close(cmd);
+      days_waiting = int((today - sub_ts) / 86400);
+      if (days_waiting >= warn) printf "STILL PENDING: %s permit for %s — submitted %s (%d days awaiting approval)\n", $2, $1, $3, days_waiting;
+    }
+  ' "{{permit_applications_csv}}"
+variables:
+  permit_applications_csv:
+    default: "./permit-applications.csv"
+    description: "Path to a CSV with columns: project_name,permit_type,submitted_date (YYYY-MM-DD),status (submitted/approved/rejected)."
+  stale_days:
+    default: 21
+    description: Days a submission can sit before it's flagged for a follow-up call to the jurisdiction.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from permit-expiry-check — that job watches active, already-issued permits nearing expiry; this one watches new applications stuck before issuance.

package/jobs/construction/project-budget-variance-check.yaml

@@ -0,0 +1,34 @@
+id: project-budget-variance-check
+version: 1
+name: Project Budget vs. Actual Cost Variance Check
+description: >
+  Compares actual spend against budget by cost code for each active
+  project and flags codes running over threshold. Use this if a project
+  has ever "felt fine" right up until closeout, when the actual cost
+  report showed a cost code had been bleeding over budget for months
+  unnoticed.
+category: construction
+tags: [construction, budget, cost-control, project-accounting]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v warn="{{overrun_threshold_pct}}" '
+    NR==1 {next}
+    {
+      project=$1; cost_code=$2; budget=$3; actual=$4;
+      if (budget + 0 > 0) {
+        variance_pct = ((actual - budget) / budget) * 100;
+        if (variance_pct >= warn) printf "OVER BUDGET: %s / %s — budget $%.2f, actual $%.2f (%.1f%% over)\n", project, cost_code, budget, actual, variance_pct;
+      }
+    }
+  ' "{{cost_codes_csv}}"
+variables:
+  cost_codes_csv:
+    default: "./project-cost-codes.csv"
+    description: "Path to a CSV with columns: project_name,cost_code,budget_amount,actual_amount."
+  overrun_threshold_pct:
+    default: 10
+    description: Percentage over budget on a cost code before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Export budget/actual figures from your project accounting or job-costing system; this is a per-cost-code variance scan, not a full WIP report.

package/jobs/construction/punch-list-completion-tracker.yaml

@@ -0,0 +1,36 @@
+id: punch-list-completion-tracker
+version: 1
+name: Punch List Completion Tracker
+description: >
+  Tracks open punch list items against the project's target closeout date
+  and flags projects falling behind on completion rate. Use this if a
+  closeout has ever dragged on for months because punch items trickled in
+  one at a time with nobody watching the overall burn-down.
+category: construction
+tags: [construction, punch-list, closeout, completion]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min_pct="{{min_completion_pct}}" '
+    NR==1 {next}
+    {
+      project=$1; total[project]+=1;
+      if ($3 == "closed") closed[project]+=1;
+    }
+    END {
+      for (p in total) {
+        pct = (total[p] > 0) ? (closed[p] / total[p] * 100) : 0;
+        if (pct < min_pct) printf "BEHIND: %s — %d of %d punch items closed (%.0f%%)\n", p, closed[p], total[p], pct;
+      }
+    }
+  ' "{{punch_list_csv}}"
+variables:
+  punch_list_csv:
+    default: "./punch-list.csv"
+    description: "Path to a CSV with columns: project_name,item_description,status (open/closed)."
+  min_completion_pct:
+    default: 90
+    description: Minimum percentage of punch items that should be closed before closeout is considered on track.
+compatible_agents: [generic, claude, codex]
+notes: Aggregate burn-down view, not item-by-item detail — pair with the punch list document itself when a project shows up here.

package/jobs/construction/retainage-holdback-release-tracker.yaml

@@ -0,0 +1,33 @@
+id: retainage-holdback-release-tracker
+version: 1
+name: Retainage / Holdback Release Tracker
+description: >
+  Flags subcontractor retainage (holdback) that's eligible for release
+  based on project completion percentage or elapsed lien period, so it
+  doesn't sit uncollected for months after it was earned. Use this if a
+  sub has ever had to chase a general contractor for retainage that was
+  technically releasable but nobody flagged it.
+category: construction
+tags: [construction, retainage, payments, subcontractor]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min_pct="{{release_threshold_pct}}" '
+    NR==1 {next}
+    $5 != "released" {
+      completion_pct=$3; retainage_amt=$4;
+      if (completion_pct + 0 >= min_pct + 0) {
+        printf "RELEASE ELIGIBLE: %s (%s) — %s%% complete, $%.2f retainage held, status: %s\n", $1, $2, completion_pct, retainage_amt, $5;
+      }
+    }
+  ' "{{retainage_ledger_csv}}"
+variables:
+  retainage_ledger_csv:
+    default: "./retainage-ledger.csv"
+    description: "Path to a CSV with columns: subcontractor_name,contract_number,completion_pct,retainage_amount,status (held/pending/released)."
+  release_threshold_pct:
+    default: 95
+    description: Completion percentage at or above which held retainage should be reviewed for release.
+compatible_agents: [generic, claude, codex]
+notes: Confirm local lien-period and contract terms before actually releasing funds — this job only surfaces eligibility, it doesn't authorize payment.

package/jobs/construction/rfi-response-time-tracker.yaml

@@ -0,0 +1,33 @@
+id: rfi-response-time-tracker
+version: 1
+name: RFI Response Time Tracker
+description: >
+  Flags open Requests for Information (RFIs) that have gone unanswered
+  longer than the agreed response window. Use this if a crew has ever
+  stalled on a detail because an RFI sent to the architect or engineer sat
+  unanswered for weeks with nobody chasing it.
+category: construction
+tags: [construction, rfi, design-coordination, deadline]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn="{{overdue_days}}" '
+    NR==1 {next}
+    $4 == "open" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline sent_ts; close(cmd);
+      days_open = int((today - sent_ts) / 86400);
+      if (days_open >= warn) printf "RFI OVERDUE: #%s — %s — sent to %s on %s (%d days open)\n", $1, $2, $5, $3, days_open;
+    }
+  ' "{{rfi_log_csv}}"
+variables:
+  rfi_log_csv:
+    default: "./rfi-log.csv"
+    description: "Path to a CSV with columns: rfi_number,subject,sent_date (YYYY-MM-DD),status (open/answered/closed),sent_to."
+  overdue_days:
+    default: 7
+    description: Days an RFI can stay open before it's flagged for escalation.
+compatible_agents: [generic, claude, codex]
+notes: Design-coordination requests, not client-facing scope changes — see change-order-approval-reminder for the cost/scope side of the conversation.

package/jobs/construction/subcontractor-pay-application-approval-tracker.yaml

@@ -0,0 +1,35 @@
+id: subcontractor-pay-application-approval-tracker
+version: 1
+name: Subcontractor Pay Application Approval Tracker
+description: >
+  Flags subcontractor pay applications (AIA G702/G703-style draw
+  requests) that are still waiting on GC or owner approval past the
+  normal turnaround, separate from the retainage that eventually gets
+  held back on approved amounts. Use this if a sub has ever gone weeks
+  without payment because their draw request just sat unreviewed in
+  someone's queue.
+category: construction
+tags: [construction, pay-application, payments, subcontractor, approvals]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn="{{overdue_days}}" '
+    NR==1 {next}
+    $4 == "submitted" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline sub_ts; close(cmd);
+      days_pending = int((today - sub_ts) / 86400);
+      if (days_pending >= warn) printf "PAY APP PENDING: %s — draw #%s for $%s submitted %s (%d days pending review)\n", $1, $2, $5, $3, days_pending;
+    }
+  ' "{{pay_apps_csv}}"
+variables:
+  pay_apps_csv:
+    default: "./subcontractor-pay-applications.csv"
+    description: "Path to a CSV with columns: subcontractor_name,draw_number,submitted_date (YYYY-MM-DD),status (submitted/approved/rejected),amount_requested."
+  overdue_days:
+    default: 10
+    description: Days a pay application can sit unreviewed before it's flagged for follow-up.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from retainage-holdback-release-tracker — that job watches already-approved retainage becoming eligible for release; this one watches the underlying draw request getting approved in the first place.

package/jobs/construction/submittal-shop-drawing-review-check.yaml

@@ -0,0 +1,45 @@
+id: submittal-shop-drawing-review-check
+version: 1
+name: Submittal / Shop Drawing Review Check
+description: >
+  Reviews the submittal log for shop drawings, product data, and samples
+  sitting past their review due date, and spot-checks whether returned
+  reviews actually addressed the spec section they were submitted
+  against. Use this if a submittal has ever come back "approved" from a
+  quick rubber stamp that missed a spec conflict, only to surface as a
+  costly field problem later.
+category: construction
+tags: [construction, submittals, shop-drawings, design-coordination]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review the submittal log ({{submittal_log_path}}) for project
+  {{project_name}}.
+  1. Flag any submittal past its {{review_due_days}}-day review window
+     with no status update (still "under review" or "not submitted").
+  2. For submittals marked "approved" or "approved as noted" in the last
+     {{lookback_days}} days, spot-check a sample against the referenced
+     spec section ({{spec_index_path}}) for obvious conflicts (wrong
+     material grade, missing required data, mismatched dimensions).
+  3. Report overdue submittals separately from spot-check findings.
+  4. Summarize: submittals overdue for review, and any approved
+     submittals that look like they may need a second look.
+variables:
+  submittal_log_path:
+    default: "./submittal-log.csv"
+    description: "Path to the submittal log — expects columns like item, spec_section, submitted_date, status, review_due_date."
+  spec_index_path:
+    default: "./project-specifications/"
+    description: Folder or index of the project specification sections to check submittals against.
+  project_name:
+    default: "the project"
+    description: Name of the project being reviewed.
+  review_due_days:
+    default: 10
+    description: Standard review turnaround window in days before a submittal is considered overdue.
+  lookback_days:
+    default: 14
+    description: How many days of recently-approved submittals to spot-check.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Distinct from rfi-response-time-tracker — RFIs resolve open questions about the documents; submittals are the contractor's proposed materials/shop drawings going back for approval against those documents.

package/jobs/construction/weather-delay-impact-log.yaml

@@ -0,0 +1,44 @@
+id: weather-delay-impact-log
+version: 1
+name: Weather Delay Impact Log
+description: >
+  Reviews logged weather delay days against the project's schedule float
+  and flags when accumulated weather delays threaten a milestone, plus
+  checks whether the delay documentation is complete enough to support a
+  time-extension claim later. Use this if a weather delay claim has ever
+  been rejected because the daily documentation didn't clearly tie the
+  weather to lost work.
+category: construction
+tags: [construction, weather, delay, schedule, claims]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review the weather delay log ({{weather_delay_log_path}}) for project
+  {{project_name}} against the current schedule float
+  ({{schedule_float_days}} days).
+  1. Sum total weather delay days logged this month and compare against
+     remaining schedule float.
+  2. Flag if accumulated weather delays now exceed or come within
+     {{warn_margin_days}} days of consuming the available float.
+  3. For each logged weather delay entry, check it documents: date,
+     condition (rain/wind/extreme heat/etc.), specific work made
+     impossible, and crew affected. Flag entries missing this detail as
+     insufficient for a future claim.
+  4. Summarize: total delay days, days of float remaining, and any
+     entries needing better documentation before the record is relied on.
+variables:
+  weather_delay_log_path:
+    default: "./weather-delay-log.csv"
+    description: Path to the logged weather delay entries for the project.
+  project_name:
+    default: "the project"
+    description: Name of the project being reviewed.
+  schedule_float_days:
+    default: 10
+    description: Current schedule float/contingency in days, per the latest schedule update.
+  warn_margin_days:
+    default: 3
+    description: How close accumulated delays can get to consuming the float before flagging it.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Documentation-quality judgment doesn't fit a fixed script — pair with your contract's notice-of-delay requirements for actual claims.

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.