@wonsukchoi/crondex 0.22.0 → 0.23.0

package/jobs/logistics/proof-of-delivery-reconciliation-check.yaml

@@ -0,0 +1,38 @@
+id: proof-of-delivery-reconciliation-check
+version: 1
+name: Proof-of-Delivery Reconciliation Check
+description: >
+  Checks shipments marked delivered against whether a signed proof-of-
+  delivery has actually been received and filed. Use this if a delivery
+  dispute has ever dragged on for weeks because nobody could produce the
+  POD to settle it.
+category: logistics
+tags: [logistics, delivery, pod, reconciliation]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{missing_pod_warn_days}}" '
+    NR==1 {next}
+    {
+      shipment=$1; delivered_date=$2; pod_received=$3;
+      if (pod_received == "no" || pod_received == "") {
+        cmd = "date -d \"" delivered_date "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" delivered_date "\" +%s 2>/dev/null";
+        cmd | getline delivered_epoch; close(cmd);
+        "date +%s" | getline now_epoch; close("date +%s");
+        age_days = (now_epoch - delivered_epoch) / 86400;
+        if (age_days >= days) {
+          printf "MISSING POD: shipment %s delivered %s (%d days ago), no proof-of-delivery on file\n", shipment, delivered_date, age_days;
+        }
+      }
+    }
+  ' "{{delivered_shipments_csv}}"
+variables:
+  delivered_shipments_csv:
+    default: "./delivered-shipments.csv"
+    description: "Path to a CSV with columns: shipment_id,delivered_date,pod_received (yes/no) — export from your TMS or carrier POD feed."
+  missing_pod_warn_days:
+    default: 3
+    description: Days after delivery a POD can be missing before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Assumes delivered status and POD receipt are both tracked in your TMS/carrier feed — this is the reconciliation backstop, not a POD capture system itself.

package/jobs/logistics/route-load-optimization-check.yaml

@@ -0,0 +1,32 @@
+id: route-load-optimization-check
+version: 1
+name: Route Load Optimization Check
+description: >
+  Checks planned truckload trailer fill rates and flags loads shipping
+  significantly under capacity. Use this if a half-empty trailer has
+  ever gone out the door because nobody checked fill rate before
+  dispatch, paying full linehaul cost for a fraction of the freight.
+category: logistics
+tags: [logistics, routing, load-planning, optimization]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v threshold="{{min_fill_pct}}" '
+    NR==1 {next}
+    {
+      load=$1; fill_pct=$2;
+      if (fill_pct < threshold) {
+        printf "UNDERFILLED: load %s — %.1f%% trailer fill, below %d%% target\n", load, fill_pct, threshold;
+      }
+    }
+  ' "{{planned_loads_csv_path}}"
+variables:
+  planned_loads_csv_path:
+    default: "./planned-loads.csv"
+    description: "Path to a CSV with columns: load_id,fill_pct — one row per load planned for today's dispatch, exported from your routing/load planning system."
+  min_fill_pct:
+    default: 80
+    description: Minimum acceptable trailer fill percentage before a load is flagged as underfilled.
+compatible_agents: [generic, claude, codex]
+notes: Assumes your routing/load-building system can export planned fill rate per load before dispatch — this is the pre-dispatch check, not a route optimization engine itself.

package/jobs/manufacturing/changeover-time-tracker.yaml

@@ -0,0 +1,29 @@
+id: changeover-time-tracker
+version: 1
+name: Changeover Time Tracker
+description: >
+  Compares logged changeover/setup durations against a target and flags
+  the ones that ran long. Use this if a slow product changeover has ever
+  eaten into a shift's output without anyone tracing the lost hours back
+  to the setup itself.
+category: manufacturing
+tags: [manufacturing, changeover, setup, efficiency]
+schedule: "0 6 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target={{changeover_target_minutes}} '
+    NR==1 {next}
+    {
+      if ($3 > target) printf "LONG CHANGEOVER: line %s, %s -> %s, took %d min (target %d min)\n", $1, $2, $4, $3, target;
+    }
+  ' "{{changeover_log_csv}}"
+variables:
+  changeover_log_csv:
+    default: "./changeover-log.csv"
+    description: "CSV with header row, columns: line_id,from_product,duration_minutes,to_product — one row per changeover event."
+  changeover_target_minutes:
+    default: 45
+    description: Maximum acceptable changeover duration in minutes before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: Log each changeover's start/end from the line's MES event stream or a shift supervisor's log — this job only compares durations against target, it doesn't time the changeover itself.

package/jobs/manufacturing/critical-spare-parts-stock-check.yaml

@@ -0,0 +1,29 @@
+id: critical-spare-parts-stock-check
+version: 1
+name: Critical Spare Parts Stock Check
+description: >
+  Compares on-hand stock of critical maintenance spare parts against a
+  set minimum and flags anything running low. Use this if a machine has
+  ever sat down for days waiting on a spare part that a stock check
+  would have caught weeks earlier.
+category: manufacturing
+tags: [manufacturing, maintenance, spare-parts, inventory]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    { if ($2 < $3) printf "LOW STOCK: critical spare \"%s\" — %d on hand, minimum %d\n", $1, $2, $3; }
+  ' "{{spare_parts_csv}}"
+variables:
+  spare_parts_csv:
+    default: "./critical-spare-parts.csv"
+    description: "CSV with header row, columns: part_name,qty_on_hand,min_qty — limited to parts flagged critical for equipment uptime, not general MRO stock."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Scoped to critical maintenance spares tied to specific equipment
+  (bearings, belts, sensors for machines on the floor), not general
+  warehouse/retail inventory — see inventory category's low-stock-alert
+  for that. Export critical-spare-parts.csv from your CMMS spare parts
+  module.

package/jobs/manufacturing/first-pass-yield-report.yaml

@@ -0,0 +1,37 @@
+id: first-pass-yield-report
+version: 1
+name: First-Pass Yield Report
+description: >
+  Calculates yesterday's first-pass yield (units that passed inspection
+  without rework) per production line and flags any line below target.
+  Use this if rework has ever been quietly absorbed as "normal" until
+  someone finally rolled up the numbers and saw how much it was costing.
+category: manufacturing
+tags: [manufacturing, quality, yield, production]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target={{fpy_target_pct}} '
+    NR==1 {next}
+    {
+      total[$1] += $2;
+      passed[$1] += $3;
+    }
+    END {
+      for (line in total) {
+        fpy = (passed[line] / total[line]) * 100;
+        status = (fpy < target) ? "BELOW TARGET" : "OK";
+        printf "%s: line %s — %.1f%% first-pass yield (%d of %d units), target %d%%\n", status, line, fpy, passed[line], total[line], target;
+      }
+    }
+  ' "{{production_log_csv}}"
+variables:
+  production_log_csv:
+    default: "./production-yield-log.csv"
+    description: "CSV with header row, columns: line_id,units_produced,units_passed_first_time — one row per shift/day for the reporting window."
+  fpy_target_pct:
+    default: 95
+    description: Minimum acceptable first-pass yield percentage per line.
+compatible_agents: [generic, claude, codex]
+notes: Export production-yield-log.csv from your MES's inspection/rework records before each run — a unit only counts as "passed" if it needed no rework or re-inspection.

package/jobs/manufacturing/lot-traceability-audit.yaml

@@ -0,0 +1,37 @@
+id: lot-traceability-audit
+version: 1
+name: Lot Traceability Audit
+description: >
+  Spot-checks that finished-goods lots have complete genealogy back to
+  their raw material lots and process records. Use this if a recall has
+  ever turned into a scramble because a lot's traceability records had
+  gaps nobody caught until they were needed under pressure.
+category: manufacturing
+tags: [manufacturing, traceability, quality, compliance, lots]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull the list of finished-goods lots produced in the last
+  {{lookback_days}} days from {{traceability_system}}. For a sample of
+  {{sample_size}} lots (or all of them if fewer), verify each has:
+  1. A linked raw material lot / component lot record.
+  2. A linked process record (line, operator, date, key process
+     parameters).
+  3. A linked QC/inspection record with a disposition (pass/hold/reject).
+
+  Report any lot missing one of these links as a traceability gap, with
+  the lot ID and which link is missing. Summarize overall: lots checked,
+  lots with complete genealogy, lots with gaps.
+variables:
+  traceability_system:
+    default: "your MES/QMS lot genealogy records"
+    description: System of record for lot genealogy and production/QC linkage.
+  lookback_days:
+    default: 30
+    description: How many days back to pull finished-goods lots from.
+  sample_size:
+    default: 20
+    description: Number of lots to spot-check per run (use a full audit periodically instead of every run for large volumes).
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: This is a spot-check, not a full recall-readiness audit — schedule a complete review of all lots on a longer cadence (e.g. quarterly) separately.

package/jobs/manufacturing/non-conformance-report-backlog-check.yaml

@@ -0,0 +1,34 @@
+id: non-conformance-report-backlog-check
+version: 1
+name: Non-Conformance Report Backlog Check
+description: >
+  Counts open non-conformance reports (NCRs) that have gone past their
+  disposition deadline without a root cause or corrective action logged.
+  Use this if an NCR has ever sat open for months with the nonconforming
+  material still floating around because nobody was tracking the
+  disposition clock.
+category: manufacturing
+tags: [manufacturing, quality, ncr, corrective-action, compliance]
+schedule: "0 7 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    $2 == "open" {
+      cmd="date -d \"" $3 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $3 "\" +%s";
+      cmd | getline due_ts; close(cmd);
+      if (due_ts < today) { overdue++; printf "OVERDUE: NCR %s (\"%s\") past disposition deadline of %s\n", $1, $4, $3 }
+      else open_count++;
+    }
+    END {
+      printf "Summary: %d NCR(s) open and on track, %d overdue past disposition deadline\n", open_count+0, overdue+0;
+    }
+  ' "{{ncr_log_csv}}"
+variables:
+  ncr_log_csv:
+    default: "./ncr-log.csv"
+    description: "CSV with header row, columns: ncr_id,status (open/closed),disposition_due_date(YYYY-MM-DD),description."
+compatible_agents: [generic, claude, codex]
+notes: Export ncr-log.csv from your QMS's non-conformance module before each run — this checks the disposition clock, it doesn't evaluate root cause quality.

package/jobs/manufacturing/oee-efficiency-check.yaml

@@ -0,0 +1,37 @@
+id: oee-efficiency-check
+version: 1
+name: OEE Efficiency Check
+description: >
+  Calculates Overall Equipment Effectiveness (availability x performance x
+  quality) for a line from a production log and flags it when it drops
+  below target. Use this if a line has ever "felt slow" for weeks before
+  anyone put a single number on how much effectiveness it was actually
+  losing.
+category: manufacturing
+tags: [manufacturing, oee, efficiency, production]
+schedule: "0 7 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target={{oee_target_pct}} '
+    NR==1 {next}
+    {
+      planned=$2; runtime=$3; ideal_rate=$4; total_count=$5; good_count=$6;
+      availability = runtime / planned;
+      performance = (ideal_rate > 0) ? (total_count / (runtime * ideal_rate)) : 0;
+      if (performance > 1) performance = 1;
+      quality = (total_count > 0) ? (good_count / total_count) : 0;
+      oee = availability * performance * quality * 100;
+      status = (oee < target) ? "BELOW TARGET" : "OK";
+      printf "%s: line %s — OEE %.1f%% (avail %.0f%%, perf %.0f%%, qual %.0f%%), target %d%%\n", status, $1, oee, availability*100, performance*100, quality*100, target;
+    }
+  ' "{{oee_log_csv}}"
+variables:
+  oee_log_csv:
+    default: "./oee-log.csv"
+    description: "CSV with header row, columns: line_id,planned_minutes,runtime_minutes,ideal_units_per_minute,total_units,good_units — one row per line/day."
+  oee_target_pct:
+    default: 85
+    description: Minimum acceptable OEE percentage per line (world-class benchmark is often ~85%; adjust to your baseline).
+compatible_agents: [generic, claude, codex]
+notes: Export oee-log.csv from your MES's downtime and count records — this is a standard availability x performance x quality OEE calculation, not a substitute for the line-level downtime-cause detail in production-line-downtime-watch.

package/jobs/manufacturing/osha-recordable-incident-audit.yaml

@@ -0,0 +1,37 @@
+id: osha-recordable-incident-audit
+version: 1
+name: OSHA Recordable Incident Log Audit
+description: >
+  Checks the incident log for recordable injuries that haven't been
+  logged on the OSHA 300 form within the required window. Use this if a
+  recordable incident has ever slipped past the logging deadline because
+  the person who handled the report forgot to also update the 300 log.
+category: manufacturing
+tags: [manufacturing, safety, osha, compliance]
+schedule: "0 7 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v deadline={{logging_deadline_days}} '
+    NR==1 {next}
+    $3 == "yes" && $4 == "no" {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline inc_ts; close(cmd);
+      days_since = int((today - inc_ts) / 86400);
+      if (days_since >= deadline) printf "OVERDUE: incident %s (%s) is recordable and unlogged, %d days since it happened (deadline %d days)\n", $1, $2, days_since, deadline;
+      else printf "PENDING: incident %s (%s) recordable and unlogged, %d days left to log\n", $1, $2, (deadline - days_since);
+    }
+  ' "{{incident_log_csv}}"
+variables:
+  incident_log_csv:
+    default: "./incident-log.csv"
+    description: "CSV with header row, columns: incident_id,incident_date(YYYY-MM-DD),recordable(yes/no),logged_on_300(yes/no)."
+  logging_deadline_days:
+    default: 7
+    description: Days allowed to record a qualifying incident on the OSHA 300 log before it's flagged overdue.
+compatible_agents: [generic, claude, codex]
+notes: >
+  This checks logging timeliness against a configurable window you set —
+  confirm current OSHA recordkeeping deadlines with your safety officer
+  or counsel, this job doesn't determine recordability itself.

package/jobs/manufacturing/production-schedule-adherence-check.yaml

@@ -0,0 +1,35 @@
+id: production-schedule-adherence-check
+version: 1
+name: Production Schedule Adherence Check
+description: >
+  Compares actual output against the planned production schedule and
+  explains any meaningful variance. Use this if a schedule slip has ever
+  gone unexplained until it was too late to recover the shift, because
+  nobody compared plan vs. actual until the week was already over.
+category: manufacturing
+tags: [manufacturing, production-planning, schedule, variance]
+schedule: "0 6 * * 1-5"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Pull yesterday's planned vs. actual production output per line from
+  {{data_source}}. For any line where actual output missed plan by more
+  than {{variance_threshold_pct}}%:
+  1. Report the planned quantity, actual quantity, and variance.
+  2. Check downtime/quality logs for that line for the same period and
+     note any likely cause (downtime event, quality hold, changeover,
+     staffing).
+  3. If no clear cause is found in the logs, flag it as "unexplained
+     variance" for a supervisor to look into.
+
+  Summarize lines on plan, lines behind with an identified cause, and
+  lines with unexplained variance.
+variables:
+  data_source:
+    default: "your MES/ERP production schedule and output records"
+    description: System of record for planned schedule, actual output, and downtime/quality logs.
+  variance_threshold_pct:
+    default: 10
+    description: Percentage variance from plan that triggers a variance investigation.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Complements production-line-downtime-watch and quality-defect-rate-check by tying variance back to a likely cause instead of just reporting the stoppage or defect rate in isolation.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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