@wonsukchoi/crondex 0.21.0 → 0.23.0

package/jobs/automotive/ase-certification-expiry-check.yaml

@@ -0,0 +1,36 @@
+id: ase-certification-expiry-check
+version: 1
+name: ASE Certification Expiry Check
+description: >
+  Checks technician ASE (or equivalent manufacturer) certifications
+  against their expiration date and flags any expiring soon. Use this if
+  a tech has ever kept working on certified-only repair categories after
+  their certification quietly lapsed, putting warranty reimbursement at
+  risk.
+category: automotive
+tags: [automotive, technician, certification, compliance]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v warn="{{warn_days}}" -v today="$today" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline exp_ts; close(cmd);
+      days_left = (exp_ts - today) / 86400;
+      if (days_left <= warn) {
+        printf "EXPIRING: %s — %s certification expires %s (%d days left)\n", $1, $2, $3, days_left;
+      }
+    }
+  ' "{{tech_certs_csv_path}}"
+variables:
+  tech_certs_csv_path:
+    default: "./technician-certifications.csv"
+    description: "Path to a CSV with columns: technician_name,certification_name,expiry_date (YYYY-MM-DD)."
+  warn_days:
+    default: 45
+    description: Days before expiry to start warning, giving time to schedule recertification testing.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from fieldservice's `tech-license-renewal-check` — same pattern applied to a different credential (ASE/manufacturer certs for auto technicians vs EPA/electrician/plumbing licenses for field trades).

package/jobs/automotive/csi-score-monitor.yaml

@@ -0,0 +1,33 @@
+id: csi-score-monitor
+version: 1
+name: Customer Satisfaction Index (CSI) Score Monitor
+description: >
+  Checks incoming customer satisfaction (CSI) survey scores from service
+  and sales against a minimum threshold and flags any individual score
+  low enough to put the dealership's manufacturer standing at risk. Use
+  this if a bad CSI score has ever sat unnoticed in a survey inbox until
+  the manufacturer's monthly report flagged it first.
+category: automotive
+tags: [automotive, csi, customer-satisfaction, survey]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min="{{minimum_score}}" '
+    NR==1 {next}
+    {
+      score = $3 + 0;
+      if (score < min) {
+        printf "LOW CSI: %s — score %s for %s (%s)\n", $1, $3, $4, $2;
+      }
+    }
+  ' "{{csi_surveys_csv_path}}"
+variables:
+  csi_surveys_csv_path:
+    default: "./csi-surveys.csv"
+    description: "Path to a CSV with columns: ro_or_sale_id,survey_date (YYYY-MM-DD),score (e.g. 1-10),department (service/sales)."
+  minimum_score:
+    default: 7
+    description: Score below which a survey response counts as low and worth a manager follow-up.
+compatible_agents: [generic, claude, codex]
+notes: A low score is worth a direct callback while the visit is still fresh in the customer's mind — this job only flags it, it doesn't reach out.

package/jobs/automotive/customer-pay-warranty-pay-mix-tracker.yaml

@@ -0,0 +1,47 @@
+id: customer-pay-warranty-pay-mix-tracker
+version: 1
+name: Customer-Pay vs Warranty-Pay Mix Tracker
+description: >
+  Checks the weekly split of repair order revenue between customer-pay,
+  warranty-pay, and internal-pay against your target mix and flags a
+  drift. Use this if a service department has ever found out at
+  month-end that warranty work quietly ate into the higher-margin
+  customer-pay volume nobody was tracking day to day.
+category: automotive
+tags: [automotive, revenue-mix, warranty, service-department]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v target="{{target_customer_pay_pct}}" -v tolerance="{{tolerance_pct}}" '
+    NR==1 {next}
+    {
+      pay_type = $3;
+      amount = $4 + 0;
+      total += amount;
+      sums[pay_type] += amount;
+    }
+    END {
+      if (total <= 0) { print "NO DATA: no repair order revenue found for the period"; exit; }
+      cp_pct = (sums["customer-pay"] / total) * 100;
+      printf "MIX: customer-pay %.1f%%, warranty-pay %.1f%%, internal-pay %.1f%% (total $%.2f)\n", \
+        cp_pct, (sums["warranty-pay"] / total) * 100, (sums["internal-pay"] / total) * 100, total;
+      diff = cp_pct - target;
+      if (diff < 0) diff = -diff;
+      if (diff > tolerance) {
+        printf "DRIFT: customer-pay share %.1f%% is more than %.1f points off target %.1f%%\n", cp_pct, tolerance, target;
+      }
+    }
+  ' "{{repair_order_revenue_csv_path}}"
+variables:
+  repair_order_revenue_csv_path:
+    default: "./repair-order-revenue.csv"
+    description: "Path to a CSV with columns: ro_number,closed_date,pay_type (customer-pay/warranty-pay/internal-pay),amount."
+  target_customer_pay_pct:
+    default: 65
+    description: Target share of revenue that should be customer-pay.
+  tolerance_pct:
+    default: 8
+    description: Percentage points of drift from target allowed before flagging.
+compatible_agents: [generic, claude, codex]
+notes: A drift toward warranty-pay isn't automatically bad — it can mean a recall push — but it's worth knowing before it shows up as a margin surprise.

package/jobs/automotive/fi-product-attachment-rate-tracker.yaml

@@ -0,0 +1,39 @@
+id: fi-product-attachment-rate-tracker
+version: 1
+name: F&I Product Attachment Rate Tracker
+description: >
+  Reviews the past week's vehicle sales against how many attached an F&I
+  product (extended warranty, gap insurance, service contract) and flags
+  a drop against target, plus which products are underperforming. Use
+  this if F&I income has ever slipped for weeks before anyone noticed the
+  attach rate had quietly drifted down.
+category: automotive
+tags: [automotive, finance-insurance, fi, attachment-rate]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review the vehicle sales and F&I product records in {{sales_records_path}}
+  for the last 7 days at {{dealership_name}}.
+  1. Calculate the overall attachment rate: percent of vehicle sales with
+     at least one F&I product attached.
+  2. Break the rate down per product (extended warranty, gap insurance,
+     service contract, etc.) if the data supports it.
+  3. Compare the overall rate to the target of {{target_attachment_rate_pct}}
+     percent and flag if it's below target.
+  4. Call out which individual F&I manager or salesperson, if tracked in
+     the data, has the lowest attach rate this week.
+  5. Summarize as: overall rate vs target, per-product breakdown, and any
+     notable underperformer.
+variables:
+  sales_records_path:
+    default: "./vehicle-sales-fi-records.csv"
+    description: "Path to a CSV of the week's vehicle sales with F&I product flags, e.g. columns like sale_id, fi_manager, extended_warranty, gap_insurance, service_contract."
+  dealership_name:
+    default: "the dealership"
+    description: Name of the dealership, for report context.
+  target_attachment_rate_pct:
+    default: 45
+    description: Target percent of vehicle sales that should carry at least one F&I product.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Coaching or process changes still need a manager's judgment — this job only surfaces where the attach rate is slipping.

package/jobs/automotive/loaner-fleet-availability-check.yaml

@@ -0,0 +1,40 @@
+id: loaner-fleet-availability-check
+version: 1
+name: Loaner Fleet Availability Check
+description: >
+  Checks how many loaner vehicles are currently available against
+  tomorrow's scheduled service appointments that requested one, and flags
+  a shortfall before it becomes a counter argument. Use this if a
+  customer has ever shown up for a scheduled loaner only to be told the
+  fleet was already fully checked out.
+category: automotive
+tags: [automotive, loaner, fleet, availability]
+schedule: "0 16 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    $2 == "available" {available++}
+    {total++}
+    END {
+      printf "LOANER FLEET: %d of %d loaners available\n", available+0, total+0;
+    }
+  ' "{{loaner_fleet_csv_path}}";
+  requested=$(awk -F',' -v d="{{tomorrow_date}}" 'NR>1 && $1==d && $2=="loaner-requested" {c++} END{print c+0}' "{{appointments_csv_path}}");
+  available=$(awk -F',' 'NR>1 && $2=="available" {c++} END{print c+0}' "{{loaner_fleet_csv_path}}");
+  if [ "$requested" -gt "$available" ]; then
+    echo "SHORTFALL: $requested loaners requested for {{tomorrow_date}}, only $available currently available";
+  fi
+variables:
+  loaner_fleet_csv_path:
+    default: "./loaner-fleet-status.csv"
+    description: "Path to a CSV with columns: loaner_vehicle_id,status (available/checked-out/in-service)."
+  appointments_csv_path:
+    default: "./service-appointments.csv"
+    description: "Path to a CSV with columns: appointment_date (YYYY-MM-DD),status (loaner-requested/no-loaner/...)."
+  tomorrow_date:
+    default: "$(date -v+1d +%Y-%m-%d 2>/dev/null || date -d '+1 day' +%Y-%m-%d)"
+    description: Date to check demand against, defaults to tomorrow.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from `loaner-vehicle-return-reminder` — that job chases individual overdue loaners; this one looks at fleet-wide availability against near-term demand.

package/jobs/automotive/manufacturer-recall-notice-check.yaml

@@ -0,0 +1,39 @@
+id: manufacturer-recall-notice-check
+version: 1
+name: Manufacturer Recall Notice Check
+description: >
+  Cross-references newly issued manufacturer recall notices against
+  vehicles in service history and current inventory, flagging any match
+  that hasn't been contacted or scheduled yet. Use this if a customer has
+  ever found out about a safety recall on their own before the shop that
+  services their car did.
+category: automotive
+tags: [automotive, recall, safety, compliance]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Compare the new recall bulletins in {{recall_bulletins_path}} against
+  the vehicle records in {{vehicle_records_path}} for {{shop_name}}.
+  1. Match recalls by make/model/year range and, where given, VIN range
+     against the vehicle records.
+  2. For each match, check whether the vehicle record already shows a
+     "recall_contacted" or "recall_scheduled" status for that recall
+     campaign number.
+  3. List every matched vehicle without that status: VIN, owner contact
+     info if available, recall campaign number, and a one-line summary of
+     the defect/remedy from the bulletin.
+  4. Flag any recall bulletin that mentions a stop-drive or do-not-drive
+     warning separately at the top, since those need same-day outreach.
+variables:
+  recall_bulletins_path:
+    default: "./recall-bulletins.csv"
+    description: "Path to a CSV/export of open recall bulletins with columns like campaign_number, make, model, year_range, vin_range, defect_summary."
+  vehicle_records_path:
+    default: "./vehicle-service-records.csv"
+    description: "Path to the shop's vehicle records (service history and/or inventory) with VIN, make, model, year, owner_contact, recall_status columns."
+  shop_name:
+    default: "the shop"
+    description: Name of the dealership or repair shop, for report context.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Outreach and scheduling still need a human or a separate workflow — this job only identifies which vehicles are affected and unresolved.

package/jobs/automotive/parts-reorder-point-check.yaml

@@ -0,0 +1,36 @@
+id: parts-reorder-point-check
+version: 1
+name: Parts Department Reorder Point Check
+description: >
+  Checks parts counter stock-on-hand against each SKU's reorder point and
+  flags anything that's dropped below it, so a routine oil filter or brake
+  pad isn't out of stock when a tech needs it mid-repair. Use this if a
+  common part has ever run out because nobody was watching the shelf until
+  it was already empty.
+category: automotive
+tags: [automotive, parts, inventory, reorder]
+schedule: "0 6 * * 1-6"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      onhand = $2 + 0;
+      reorder_point = $3 + 0;
+      if (onhand <= reorder_point) {
+        printf "REORDER: %s (%s) — %d on hand, reorder point %d\n", $1, $4, onhand, reorder_point;
+      }
+    }
+  ' "{{parts_stock_csv_path}}"
+variables:
+  parts_stock_csv_path:
+    default: "./parts-stock.csv"
+    description: "Path to a CSV with columns: part_number,qty_on_hand,reorder_point,description."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Distinct from `parts-backorder-check` — that job tracks parts already
+  ordered and now late from the supplier; this one tracks shelf stock
+  levels before an order is even placed. Also distinct from fieldservice's
+  `parts-low-stock-reorder-check`, which watches traveling techs' truck
+  and warehouse stock rather than a dealership parts counter.

package/jobs/automotive/repair-cycle-time-trend-monitor.yaml

@@ -0,0 +1,42 @@
+id: repair-cycle-time-trend-monitor
+version: 1
+name: Repair Order Cycle Time Trend Monitor
+description: >
+  Reviews closed repair orders from the past week and compares the
+  average check-in-to-checkout cycle time against your rolling baseline,
+  flagging a trend drift even when no single order looks late. Use this
+  if turnaround has ever quietly crept up week over week without any one
+  repair order tripping an aging alert.
+category: automotive
+tags: [automotive, repair-shop, cycle-time, trend]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Using the closed repair orders in {{closed_ros_path}} for the last 7
+  days, for {{shop_name}}:
+  1. Calculate the average cycle time (checkin_date to checkout_date, in
+     hours) across all closed repair orders in the period.
+  2. Compare it to the rolling baseline of {{baseline_cycle_hours}} hours.
+  3. Flag a drift if the weekly average is more than {{drift_threshold_pct}}
+     percent above baseline.
+  4. Break down the average by repair type or department if that data is
+     present, and call out which category is driving the drift.
+  5. Summarize as: this week's average, baseline, percent change, and the
+     likely driver if identifiable (e.g. one tech, one repair type, parts
+     delays).
+variables:
+  closed_ros_path:
+    default: "./closed-repair-orders.csv"
+    description: "Path to a CSV of closed ROs with columns like ro_number, checkin_date, checkout_date, repair_type, technician."
+  shop_name:
+    default: "the shop"
+    description: Name of the dealership or repair shop, for report context.
+  baseline_cycle_hours:
+    default: 48
+    description: The shop's target/rolling-average cycle time in hours to compare against.
+  drift_threshold_pct:
+    default: 15
+    description: Percent above baseline that counts as a meaningful drift worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Distinct from `repair-order-aging-check` — that job flags individual open ROs sitting past a per-repair target today; this one watches the trend across closed ROs over time to catch slow process drift.

package/jobs/automotive/service-appointment-no-show-tracker.yaml

@@ -0,0 +1,38 @@
+id: service-appointment-no-show-tracker
+version: 1
+name: Service Appointment No-Show Tracker
+description: >
+  Checks today's service appointment schedule partway through the day
+  and flags customers who booked a slot but never checked in, so the bay
+  can be reopened to a walk-in instead of sitting empty. Use this if a
+  bay has ever sat idle all morning because a no-show was never noticed
+  until the tech asked what happened to their 9 o'clock.
+category: automotive
+tags: [automotive, service-bay, no-show, scheduling]
+schedule: "30 9,13 * * 1-6"
+timezone: "UTC"
+runner: shell
+command: >
+  now=$(date +%H:%M);
+  awk -F',' -v now="$now" -v grace="{{grace_minutes}}" '
+    NR==1 {next}
+    $3 == "scheduled" {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %H:%M \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline slot_epoch; close(cmd);
+      cmd2 = "date -d \"" now "\" +%s 2>/dev/null || date -j -f %H:%M \"" now "\" +%s 2>/dev/null";
+      cmd2 | getline now_epoch; close(cmd2);
+      late_min = (now_epoch - slot_epoch) / 60;
+      if (late_min >= grace) {
+        printf "NO-SHOW: %s — appointment %s (%d min past slot, not checked in)\n", $1, $2, late_min;
+      }
+    }
+  ' "{{appointments_csv_path}}"
+variables:
+  appointments_csv_path:
+    default: "./service-appointments-today.csv"
+    description: "Path to a CSV with columns: customer_name,appointment_time (HH:MM),status (scheduled/checked-in/completed)."
+  grace_minutes:
+    default: 30
+    description: Minutes past the scheduled time before a missed appointment counts as a no-show.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from fieldservice's `tech-eta-no-show-check` — that job flags the shop's own technician running late to a customer site; this one flags the customer not showing up to the shop.

package/jobs/automotive/service-bay-utilization-check.yaml

@@ -0,0 +1,38 @@
+id: service-bay-utilization-check
+version: 1
+name: Service Bay Utilization Check
+description: >
+  Checks each service bay's scheduled hours against its available hours
+  for the day and flags bays running well under or over target
+  utilization. Use this if a shop has ever had techs standing around on
+  one side of the floor while the other side is double-booked, and
+  nobody noticed until the day was already gone.
+category: automotive
+tags: [automotive, service-bay, scheduling, utilization]
+schedule: "0 7 * * 1-6"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v low="{{low_utilization_pct}}" -v high="{{high_utilization_pct}}" '
+    NR==1 {next}
+    {
+      available = $2 + 0;
+      scheduled = $3 + 0;
+      if (available <= 0) next;
+      pct = (scheduled / available) * 100;
+      if (pct < low) printf "UNDER-BOOKED: bay %s — %.0f%% scheduled (%s of %s hrs)\n", $1, pct, $3, $2;
+      else if (pct > high) printf "OVER-BOOKED: bay %s — %.0f%% scheduled (%s of %s hrs)\n", $1, pct, $3, $2;
+    }
+  ' "{{bay_schedule_csv_path}}"
+variables:
+  bay_schedule_csv_path:
+    default: "./bay-schedule.csv"
+    description: "Path to a CSV with columns: bay_id,available_hours,scheduled_hours (both for today)."
+  low_utilization_pct:
+    default: 50
+    description: Below this percent scheduled, a bay counts as under-booked and available for walk-ins.
+  high_utilization_pct:
+    default: 95
+    description: Above this percent scheduled, a bay counts as over-booked and at risk of running late all day.
+compatible_agents: [generic, claude, codex]
+notes: Rebalance jobs across bays/techs once flagged — this job only surfaces the imbalance, it doesn't move appointments.

package/jobs/automotive/shop-supply-reorder-check.yaml

@@ -0,0 +1,31 @@
+id: shop-supply-reorder-check
+version: 1
+name: Shop Supply & Consumables Reorder Check
+description: >
+  Checks bulk shop consumables (shop towels, degreaser, disposable
+  gloves, oil dry, bulk fluids) against reorder thresholds and flags
+  anything running low. Use this if a tech has ever had to stop mid-job
+  because the shop ran out of a supply nobody tracks as closely as
+  billable parts.
+category: automotive
+tags: [automotive, shop-supplies, consumables, reorder]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    {
+      onhand = $2 + 0;
+      reorder_point = $3 + 0;
+      if (onhand <= reorder_point) {
+        printf "REORDER: %s — %s %s on hand, reorder point %s %s\n", $1, $2, $4, $3, $4;
+      }
+    }
+  ' "{{shop_supplies_csv_path}}"
+variables:
+  shop_supplies_csv_path:
+    default: "./shop-supplies-stock.csv"
+    description: "Path to a CSV with columns: supply_name,qty_on_hand,reorder_point,unit."
+compatible_agents: [generic, claude, codex]
+notes: Distinct from `parts-reorder-point-check` — that job tracks customer-billable repair parts; this one tracks internal bulk consumables that never hit a repair order.

package/jobs/automotive/trade-in-appraisal-variance-check.yaml

@@ -0,0 +1,39 @@
+id: trade-in-appraisal-variance-check
+version: 1
+name: Trade-In Appraisal Variance Check
+description: >
+  Compares trade-in vehicles' initial appraised value against their
+  actual wholesale/auction sale price once sold, and flags appraisers or
+  vehicle categories with a consistent gap. Use this if trade-in
+  appraisals have ever quietly run high (or low) for months before
+  anyone lined them up against what the cars actually brought at auction.
+category: automotive
+tags: [automotive, trade-in, appraisal, wholesale]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review the trade-in records in {{trade_in_records_path}} for
+  {{dealership_name}} covering vehicles both appraised and subsequently
+  sold wholesale/at auction in the last month.
+  1. For each vehicle, calculate the variance between appraised_value and
+     actual_sale_price as both a dollar amount and a percent.
+  2. Flag any vehicle where the variance exceeds {{variance_threshold_pct}}
+     percent in either direction.
+  3. Aggregate variance by appraiser (if tracked) and by vehicle category
+     to identify whether the gap is a person-specific or category-specific
+     pattern rather than noise.
+  4. Summarize: average variance overall, worst individual outliers, and
+     any appraiser or category trending consistently high or low.
+variables:
+  trade_in_records_path:
+    default: "./trade-in-appraisals.csv"
+    description: "Path to a CSV with columns like vin, appraiser, category, appraised_value, actual_sale_price, sale_date."
+  dealership_name:
+    default: "the dealership"
+    description: Name of the dealership, for report context.
+  variance_threshold_pct:
+    default: 10
+    description: Percent variance between appraised and actual sale price that counts as worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: A pattern here can mean retraining an appraiser or adjusting a valuation guide — this job only surfaces the gap.

package/jobs/automotive/used-vehicle-inventory-aging-check.yaml

@@ -0,0 +1,35 @@
+id: used-vehicle-inventory-aging-check
+version: 1
+name: Used Vehicle Inventory Aging Check
+description: >
+  Checks used vehicle inventory against days-on-lot and flags anything
+  past your reconditioning or pricing review threshold. Use this if a
+  used car has ever sat on the lot for two months quietly losing value
+  before anyone noticed it needed a price cut.
+category: automotive
+tags: [automotive, used-vehicle, inventory, aging]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v days="{{aging_threshold_days}}" -v today="$today" '
+    NR==1 {next}
+    $4 != "sold" {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline acquired_epoch; close(cmd);
+      age_days = (today - acquired_epoch) / 86400;
+      if (age_days >= days) {
+        printf "AGING: %s (%s) — %d days on lot, listed at $%s\n", $1, $3, age_days, $5;
+      }
+    }
+  ' "{{used_inventory_csv_path}}"
+variables:
+  used_inventory_csv_path:
+    default: "./used-vehicle-inventory.csv"
+    description: "Path to a CSV with columns: vin,acquired_date (YYYY-MM-DD),description,status,listed_price."
+  aging_threshold_days:
+    default: 60
+    description: Days on lot before a used vehicle counts as aging and worth a pricing/reconditioning review.
+compatible_agents: [generic, claude, codex]
+notes: Pricing decisions still need a human call — this job only surfaces which units have crossed the aging threshold.

package/jobs/construction/critical-path-material-lead-time-review.yaml

@@ -0,0 +1,43 @@
+id: critical-path-material-lead-time-review
+version: 1
+name: Critical-Path Material Lead Time Review
+description: >
+  Reviews long-lead-time materials (elevators, structural steel, custom
+  windows, switchgear, and similar) against the project schedule to catch
+  items that haven't been ordered yet but need to be, given their lead
+  time. Use this if a schedule has ever slipped months because a
+  long-lead item wasn't placed on order until someone finally asked "wait,
+  did we order that yet?"
+category: construction
+tags: [construction, procurement, schedule, long-lead]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Compare the long-lead material procurement log ({{procurement_log_path}})
+  against the project schedule milestones ({{schedule_path}}) for project
+  {{project_name}}.
+  1. For each material not yet marked "ordered," calculate the latest safe
+     order date by working backward from its need-by milestone using its
+     stated lead time.
+  2. Flag any item where today is at or past that latest safe order date,
+     or within {{buffer_days}} days of it.
+  3. Note which milestone each flagged item threatens if the order slips
+     further.
+  4. Summarize as a short action list: item, days of buffer remaining
+     (negative if already late), milestone at risk.
+variables:
+  procurement_log_path:
+    default: "./long-lead-procurement-log.csv"
+    description: "Path to the procurement log — expects columns like material, lead_time_days, need_by_milestone, status (ordered/not ordered)."
+  schedule_path:
+    default: "./project-schedule.csv"
+    description: Path to the project schedule with milestone dates.
+  project_name:
+    default: "the project"
+    description: Name of the project being reviewed.
+  buffer_days:
+    default: 14
+    description: How many days of buffer before the safe-order deadline to start flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Distinct from material-delivery-delay-check — that job flags materials already ordered and now overdue; this one catches items that should have been ordered already but weren't.

package/jobs/construction/daily-jobsite-log-compliance-check.yaml

@@ -0,0 +1,34 @@
+id: daily-jobsite-log-compliance-check
+version: 1
+name: Daily Jobsite Log Compliance Check
+description: >
+  Reviews whether each active site's daily log/report was actually
+  submitted and contains the expected substance (crew count, weather,
+  work performed, delays) rather than being a rubber-stamped copy of the
+  day before. Use this if a dispute has ever come down to "what actually
+  happened on site that day" and the daily logs were too thin to help.
+category: construction
+tags: [construction, daily-log, documentation, compliance]
+schedule: "0 7 * * 2-6"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review yesterday's daily jobsite logs ({{daily_logs_path}}) for each
+  active site listed in {{active_sites_path}}.
+  1. Flag any active site with no log submitted for yesterday.
+  2. For submitted logs, check each includes: crew headcount, weather
+     conditions, a description of work performed, and any delays or
+     issues noted.
+  3. Flag logs that look copy-pasted from the prior day (near-identical
+     wording with no site-specific detail) as low-substance.
+  4. Summarize: sites missing a log, sites with thin/low-substance logs,
+     sites fully compliant.
+variables:
+  daily_logs_path:
+    default: "./daily-logs/"
+    description: Folder containing yesterday's daily jobsite log submissions, one per site.
+  active_sites_path:
+    default: "./active-sites.csv"
+    description: CSV or list of currently active jobsite names/IDs expected to submit a daily log.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Judging log substance and copy-paste patterns needs reading comprehension, not a fit for a fixed script.

package/jobs/construction/equipment-utilization-cost-check.yaml

@@ -0,0 +1,35 @@
+id: equipment-utilization-cost-check
+version: 1
+name: Equipment Utilization & Cost Check
+description: >
+  Calculates how many billable/working days each piece of rented or owned
+  equipment actually logged against its rental or ownership cost, and flags
+  anything sitting idle while still costing money. Use this if a rental has
+  ever been kept "just in case" for weeks with nothing to show for it on a
+  timesheet.
+category: construction
+tags: [construction, equipment, cost, utilization]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v min_util="{{min_utilization_pct}}" '
+    NR==1 {next}
+    {
+      equip=$1; days_on_site=$2; days_used=$3; daily_cost=$4;
+      utilization = (days_on_site > 0) ? (days_used / days_on_site * 100) : 0;
+      total_cost = days_on_site * daily_cost;
+      if (utilization < min_util) {
+        printf "LOW UTILIZATION: %s — used %d of %d days on site (%.0f%%), cost so far $%.2f\n", equip, days_used, days_on_site, utilization, total_cost;
+      }
+    }
+  ' "{{equipment_log_csv}}"
+variables:
+  equipment_log_csv:
+    default: "./equipment-utilization-log.csv"
+    description: "Path to a CSV with columns: equipment_name,days_on_site,days_used,daily_cost."
+  min_utilization_pct:
+    default: 50
+    description: Minimum acceptable utilization percentage before it's flagged as underused.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from equipment-rental-return-reminder — that job watches the return-by deadline; this one watches whether idle equipment is worth the cost while it's still on site.

package/jobs/construction/heavy-equipment-inspection-compliance-check.yaml

@@ -0,0 +1,34 @@
+id: heavy-equipment-inspection-compliance-check
+version: 1
+name: Heavy Equipment Inspection Compliance Check
+description: >
+  Checks owned heavy equipment (excavators, cranes, lifts, and similar)
+  against their required annual/periodic safety inspection dates and
+  flags anything overdue or coming due. Use this if a piece of owned
+  equipment has ever kept running past its inspection date because
+  nobody was tracking it the way rentals get tracked.
+category: construction
+tags: [construction, equipment, inspection, safety, compliance]
+schedule: "0 7 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn="{{warn_days}}" '
+    NR==1 {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline due_ts; close(cmd);
+      days_left = int((due_ts - today) / 86400);
+      if (days_left <= warn) printf "INSPECTION DUE: %s (%s) — due %s (%d days)\n", $1, $3, $2, days_left;
+    }
+  ' "{{owned_equipment_csv}}"
+variables:
+  owned_equipment_csv:
+    default: "./owned-equipment-inspections.csv"
+    description: "Path to a CSV with columns: equipment_name,next_inspection_due (YYYY-MM-DD),equipment_id."
+  warn_days:
+    default: 21
+    description: Days before the inspection due date to start warning.
+compatible_agents: [generic, claude, codex]
+notes: Distinct from equipment-rental-return-reminder — that job covers rented equipment due back to the rental company; this one covers company-owned equipment's own safety inspection cycle.