@wonsukchoi/crondex 0.22.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/education/chronic-absenteeism-tracker.yaml

@@ -0,0 +1,34 @@
+id: chronic-absenteeism-tracker
+version: 1
+name: Chronic Absenteeism Tracker
+description: >
+  Calculates each student's missed-day percentage for the term and flags
+  anyone crossing the chronic-absenteeism threshold. Use this if a student
+  has ever quietly racked up enough missed days to count as chronically
+  absent before anyone outside the attendance office noticed.
+category: education
+tags: [education, attendance, chronic-absenteeism, students]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v threshold="{{chronic_threshold_pct}}" '
+    NR==1 {next}
+    {
+      enrolled = $2; absent = $3;
+      if (enrolled <= 0) next;
+      pct = (absent / enrolled) * 100;
+      if (pct >= threshold) {
+        printf "CHRONIC: %s — %d/%d days missed (%.1f%%)\n", $1, absent, enrolled, pct;
+      }
+    }
+  ' "{{attendance_csv_path}}"
+variables:
+  attendance_csv_path:
+    default: "./term-attendance.csv"
+    description: "Path to a CSV with columns: student_name,enrolled_days,absent_days."
+  chronic_threshold_pct:
+    default: 10
+    description: Percentage of enrolled days missed that counts as chronically absent (10% is the common federal benchmark).
+compatible_agents: [generic, claude, codex]
+notes: This looks at the whole term to date, unlike attendance-anomaly-check which flags a short-term drop — the two catch different problems.

package/jobs/education/department-budget-variance-check.yaml

@@ -0,0 +1,37 @@
+id: department-budget-variance-check
+version: 1
+name: Department Budget Variance Check
+description: >
+  Compares each department's or program's actual spending against its
+  budget and flags meaningful overages or underspend. Use this if a
+  department has ever blown through its annual budget months early
+  because nobody was checking actual-vs-budget until year-end
+  reconciliation.
+category: education
+tags: [education, budget, finance, departments]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review department/program budget vs. actual spending from
+  {{finance_system_hint}} for the current fiscal year to date.
+  1. For each department or program, compute spend as a percentage of its
+     annual budget and compare that to the expected percentage of the
+     fiscal year elapsed.
+  2. Flag departments running more than {{variance_threshold_pct}}
+     percentage points ahead of pace (overspend risk) or behind pace
+     (possible underspend, use-it-or-lose-it risk, or a stalled
+     initiative).
+  3. Note any single large transactions that materially explain a
+     variance, if visible in the data.
+  4. Summarize so budget owners can adjust spending or reforecast before
+     the next reporting cycle.
+variables:
+  finance_system_hint:
+    default: "your district finance/ERP system"
+    description: Where budget and actuals data lives.
+  variance_threshold_pct:
+    default: 15
+    description: Percentage-point gap between spend pace and time-elapsed pace that counts as worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: This tracks department/program-level spending, not headcount or payroll cost, which HR budget jobs already cover separately.

package/jobs/education/enrollment-withdrawal-trend-tracker.yaml

@@ -0,0 +1,39 @@
+id: enrollment-withdrawal-trend-tracker
+version: 1
+name: Enrollment/Withdrawal Trend Tracker
+description: >
+  Reviews new enrollments and withdrawals over time and flags a school or
+  grade level that's losing students faster than usual. Use this if
+  enrollment decline has ever gone unnoticed for a semester because
+  individual withdrawals looked routine one at a time.
+category: education
+tags: [education, enrollment, students, trends]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review enrollment and withdrawal records from {{sis_hint}} for the last
+  {{lookback_months}} months.
+  1. Calculate net enrollment change by school and by grade level over the
+     window.
+  2. Flag any school or grade with a withdrawal rate above
+     {{withdrawal_rate_threshold_pct}}%, or a net enrollment decline that's
+     unusual compared to the same period in prior years if that data is
+     available.
+  3. Where withdrawal reasons are recorded, summarize the most common ones
+     (moved out of district, transferred to another school, homeschooling,
+     etc.) to help spot a pattern worth addressing versus normal mobility.
+  4. Summarize findings for administration, since sustained enrollment
+     decline affects staffing and funding decisions.
+variables:
+  sis_hint:
+    default: "your student information system"
+    description: Where enrollment and withdrawal records live.
+  lookback_months:
+    default: 6
+    description: How many months of enrollment history to review.
+  withdrawal_rate_threshold_pct:
+    default: 8
+    description: Withdrawal rate percentage that counts as worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — SIS platforms and how they record withdrawal reasons vary too widely to assume a common export format.

package/jobs/education/facility-work-order-backlog-check.yaml

@@ -0,0 +1,34 @@
+id: facility-work-order-backlog-check
+version: 1
+name: Facility Work Order Backlog Check
+description: >
+  Reviews open facility maintenance work orders and flags the ones that
+  have been sitting too long, especially safety-related requests. Use
+  this if a maintenance ticket has ever gone stale for weeks until it
+  turned into a bigger, more expensive problem.
+category: education
+tags: [education, facilities, maintenance, work-orders]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review open facility work orders from {{facilities_system_hint}}.
+  1. List every work order still open after {{stale_days}} days, with its
+     school/building, description, and age.
+  2. Call out anything that reads as a safety or code issue (electrical,
+     HVAC failure in occupied spaces, structural, fire/life-safety,
+     accessibility) separately from routine cosmetic or convenience
+     requests — those need different urgency.
+  3. Group the remaining backlog by building so facilities staff can see
+     where the workload is concentrated.
+  4. Summarize counts and the oldest few tickets so leadership can decide
+     where to add capacity or reprioritize.
+variables:
+  facilities_system_hint:
+    default: "your facilities/maintenance ticketing system"
+    description: Where work orders are tracked.
+  stale_days:
+    default: 14
+    description: Days a work order can stay open before it's counted as backlog.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — facilities/maintenance ticketing systems vary too widely for a single export format.

package/jobs/education/free-reduced-lunch-eligibility-renewal-check.yaml

@@ -0,0 +1,36 @@
+id: free-reduced-lunch-eligibility-renewal-check
+version: 1
+name: Free/Reduced Lunch Eligibility Renewal Check
+description: >
+  Checks free/reduced meal eligibility records for approvals that are
+  about to expire and flags families who need to renew. Use this if a
+  student has ever lost meal benefits mid-year because their eligibility
+  lapsed and nobody sent a renewal reminder in time.
+category: education
+tags: [education, meals, eligibility, compliance]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v warnDays="{{warn_days}}" '
+    NR==1 {next}
+    $3 == "no" {next}
+    {
+      cmd = "date -d \"" $2 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $2 "\" +%s 2>/dev/null";
+      cmd | getline exp_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      days_left = (exp_epoch - now_epoch) / 86400;
+      if (days_left <= warnDays) {
+        printf "%s: %s eligibility expires %s (%d days)\n", (days_left < 0 ? "EXPIRED" : "RENEW SOON"), $1, $2, days_left;
+      }
+    }
+  ' "{{eligibility_csv_path}}"
+variables:
+  eligibility_csv_path:
+    default: "./meal-eligibility.csv"
+    description: "Path to a CSV with columns: student_name,expiration_date (YYYY-MM-DD),active (yes/no)."
+  warn_days:
+    default: 21
+    description: Days before expiration to start warning, giving families time to resubmit paperwork.
+compatible_agents: [generic, claude, codex]
+notes: Route renewal notices through whatever family-communication channel the district already uses for meal program paperwork.

package/jobs/education/iep-504-review-deadline-tracker.yaml

@@ -0,0 +1,35 @@
+id: iep-504-review-deadline-tracker
+version: 1
+name: IEP/504 Review Deadline Tracker
+description: >
+  Checks upcoming IEP and 504 plan review deadlines and flags any that are
+  close or already past due. Use this if a required review has ever slipped
+  past its compliance deadline because it wasn't on anyone's calendar until
+  a parent or auditor asked about it.
+category: education
+tags: [education, iep, 504-plan, compliance, deadlines]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v warnDays="{{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_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      days_left = (due_epoch - now_epoch) / 86400;
+      if (days_left <= warnDays) {
+        printf "%s: %s review due %s (%d days)\n", (days_left < 0 ? "OVERDUE" : "DUE SOON"), $1, $2, days_left;
+      }
+    }
+  ' "{{plans_csv_path}}"
+variables:
+  plans_csv_path:
+    default: "./iep-504-plans.csv"
+    description: "Path to a CSV with columns: student_name,next_review_due (YYYY-MM-DD)."
+  warn_days:
+    default: 14
+    description: Days before the review deadline to start warning.
+compatible_agents: [generic, claude, codex]
+notes: These deadlines are legally mandated in most jurisdictions — treat overdue results as urgent, not routine.

package/jobs/education/parent-teacher-conference-noshow-tracker.yaml

@@ -0,0 +1,29 @@
+id: parent-teacher-conference-noshow-tracker
+version: 1
+name: Parent-Teacher Conference No-Show Tracker
+description: >
+  Checks scheduled parent-teacher conferences against attendance and flags
+  no-shows for follow-up. Use this if a family has ever missed a
+  conference slot and nobody rescheduled it, especially for a student
+  where that conversation actually mattered.
+category: education
+tags: [education, parent-engagement, conferences]
+schedule: "0 17 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  noshows=$(awk -F',' 'NR>1 && $4=="no-show" {print $1" (with "$2", "$3")"}' "{{conferences_csv_path}}");
+  count=$(echo "$noshows" | grep -c . || true);
+  if [ "$count" -gt 0 ]; then
+    echo "NO-SHOWS TO FOLLOW UP:";
+    echo "$noshows";
+    exit 1;
+  else
+    echo "OK: no unaddressed conference no-shows";
+  fi
+variables:
+  conferences_csv_path:
+    default: "./conference-schedule.csv"
+    description: "Path to a CSV with columns: student_name,parent_name,teacher_name,status (attended, no-show, rescheduled)."
+compatible_agents: [generic, claude, codex]
+notes: Mark a no-show as rescheduled once a follow-up slot is booked, or it will keep showing up here.

package/jobs/education/school-bus-route-ontime-check.yaml

@@ -0,0 +1,40 @@
+id: school-bus-route-ontime-check
+version: 1
+name: School Bus Route On-Time Check
+description: >
+  Reviews bus route arrival data and flags routes that are consistently
+  running late. Use this if a route has ever drifted later and later over
+  weeks with only individual parent complaints, never a pattern anyone
+  actually looked at.
+category: education
+tags: [education, transportation, bus-routes]
+schedule: "0 16 * * 1-5"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Review bus arrival/departure data from {{transportation_system_hint}} for
+  the last {{lookback_days}} days.
+  1. For each route, compare actual arrival times against the scheduled
+     times at each stop.
+  2. Flag any route that was late by more than {{late_threshold_min}}
+     minutes on {{repeat_occurrences}} or more days in the window —
+     one bad day is noise, a pattern is a scheduling or staffing problem.
+  3. For flagged routes, note whether the lateness looks tied to a specific
+     stop, time of day, or driver, since that changes what the fix is.
+  4. Summarize findings so transportation staff can adjust schedules or
+     staffing before it becomes a parent-complaint pattern.
+variables:
+  transportation_system_hint:
+    default: "your bus/transportation tracking system"
+    description: Where route timing data lives (GPS tracker, dispatch software, etc.).
+  lookback_days:
+    default: 10
+    description: How many school days of route data to review.
+  late_threshold_min:
+    default: 10
+    description: Minutes past scheduled time that counts as late.
+  repeat_occurrences:
+    default: 3
+    description: Number of late days within the window that counts as a pattern worth flagging.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — bus tracking/GPS systems vary too widely to assume a common export format.