@wonsukchoi/crondex 0.21.0 → 0.22.0

package/jobs/hr/eeo1-filing-deadline-reminder.yaml

@@ -0,0 +1,37 @@
+id: eeo1-filing-deadline-reminder
+version: 1
+name: EEO-1 Filing Deadline Reminder
+description: >
+  Counts down to the annual EEO-1 component filing deadline so data
+  collection and submission don't get rushed at the last minute. Use this
+  if the EEO-1 window has ever snuck up because it only comes around once
+  a year and nobody put it on a recurring calendar.
+category: hr
+tags: [hr, eeo1, compliance, filing, deadline]
+schedule: "0 9 * * *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today_epoch=$(date +%s);
+  deadline_epoch=$(date -d "{{filing_deadline}}" +%s 2>/dev/null || date -j -f %Y-%m-%d "{{filing_deadline}}" +%s);
+  days_left=$(( (deadline_epoch - today_epoch) / 86400 ));
+  if [ "$days_left" -lt 0 ]; then
+    echo "note: this cycle's EEO-1 deadline ({{filing_deadline}}) has passed — update filing_deadline for next year's cycle.";
+  elif [ "$days_left" -le {{warn_days_before}} ]; then
+    echo "EEO-1 FILING DUE: $days_left day(s) until deadline ({{filing_deadline}}). Confirm workforce snapshot data and file via the EEOC portal.";
+  else
+    echo "OK: $days_left day(s) until EEO-1 filing deadline ({{filing_deadline}}).";
+  fi
+variables:
+  filing_deadline:
+    default: "YYYY-MM-DD"
+    description: This cycle's EEO-1 Component 1 filing deadline, published annually by the EEOC — update each cycle.
+  warn_days_before:
+    default: 30
+    description: How many days before the deadline to start reminding.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Only applies to employers required to file (generally 100+ employees, or
+  federal contractors meeting lower thresholds) — confirm your filing
+  obligation and the current cycle's exact deadline on the EEOC's site
+  rather than assuming last year's date still applies.

package/jobs/hr/handbook-acknowledgment-tracking.yaml

@@ -0,0 +1,34 @@
+id: handbook-acknowledgment-tracking
+version: 1
+name: Employee Handbook Acknowledgment Tracking
+description: >
+  Checks the full roster against the current handbook version and flags
+  anyone who hasn't signed off on it yet — including existing employees
+  after a handbook update, not just new hires. Use this if a handbook
+  revision has ever gone out and only a fraction of the company actually
+  acknowledged it, which nobody discovered until it mattered in a dispute.
+category: hr
+tags: [hr, handbook, compliance, policy]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v current="{{current_handbook_version}}" '
+    NR==1 {next}
+    $2 != current {
+      printf "NOT ACKNOWLEDGED: %s — on file for v%s, current is v%s\n", $1, ($2 == "" ? "none" : $2), current;
+    }
+  ' "{{handbook_ack_csv_path}}"
+variables:
+  handbook_ack_csv_path:
+    default: "./handbook-acknowledgments.csv"
+    description: "Path to a CSV with columns: employee_name,acknowledged_version (blank if never acknowledged any version)."
+  current_handbook_version:
+    default: "2026.1"
+    description: Version label of the currently effective handbook, updated whenever a new revision goes out.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained acknowledgment export covering the whole roster.
+  Distinct from new-hire-paperwork-check, which bundles the initial
+  handbook sign-off into a new hire's first-30-days checklist rather than
+  tracking re-acknowledgment across the whole company after updates.

package/jobs/hr/headcount-budget-variance-check.yaml

@@ -0,0 +1,37 @@
+id: headcount-budget-variance-check
+version: 1
+name: Headcount vs. Budget Variance Check
+description: >
+  Compares actual headcount per department against the planned/budgeted
+  headcount and flags departments that are over or under plan. Use this
+  if a department has ever quietly overhired (or sat understaffed) for a
+  quarter before finance and HR compared notes and noticed.
+category: hr
+tags: [hr, headcount, budget, finance, planning]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v threshold="{{variance_threshold}}" '
+    NR==1 {next}
+    {
+      variance = $3 - $2;
+      abs_variance = (variance < 0 ? -variance : variance);
+      if (abs_variance >= threshold) {
+        direction = (variance > 0 ? "OVER PLAN" : "UNDER PLAN");
+        printf "%s: %s — budgeted %d, actual %d (variance %+d)\n", direction, $1, $2, $3, variance;
+      }
+    }
+  ' "{{headcount_budget_csv_path}}"
+variables:
+  headcount_budget_csv_path:
+    default: "./headcount-budget.csv"
+    description: "Path to a CSV with columns: department,budgeted_headcount,actual_headcount."
+  variance_threshold:
+    default: 2
+    description: Minimum absolute headcount variance (in people) before a department is flagged.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained monthly export reconciling the HRIS actual
+  headcount against finance's approved plan by department. Zero-token —
+  no synthesis or interpretation beyond the raw variance.

package/jobs/hr/leave-of-absence-return-tracker.yaml

@@ -0,0 +1,42 @@
+id: leave-of-absence-return-tracker
+version: 1
+name: Leave of Absence Return Tracker
+description: >
+  Tracks employees on FMLA, parental, medical, or other formal leave and
+  flags upcoming or overdue return dates. Use this if a return-to-work
+  date has ever been missed — either the team wasn't ready for someone
+  coming back, or nobody noticed an expected return date came and went
+  with no check-in.
+category: hr
+tags: [hr, leave-of-absence, fmla, parental-leave, compliance]
+schedule: "0 8 * * 1-5"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" -v warn="{{warn_days_before}}" '
+    NR==1 {next}
+    $4 != "active" {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline return_epoch; close(cmd);
+      diff_days = (return_epoch - today) / 86400;
+      if (diff_days < 0) {
+        printf "OVERDUE RETURN: %s — %s leave, expected back %s (%d day(s) past, still marked active)\n", $1, $2, $3, -diff_days;
+      } else if (diff_days <= warn) {
+        printf "RETURN UPCOMING: %s — %s leave, expected back %s (%d day(s))\n", $1, $2, $3, diff_days;
+      }
+    }
+  ' "{{leave_tracking_csv_path}}"
+variables:
+  leave_tracking_csv_path:
+    default: "./leave-of-absence-tracking.csv"
+    description: "Path to a CSV with columns: employee_name,leave_type,expected_return_date (YYYY-MM-DD),status (active/returned)."
+  warn_days_before:
+    default: 10
+    description: How many days before the expected return date to start flagging as upcoming.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained export from HR/leave-administration tracking active
+  leaves; this is the backstop that flags dates, not a substitute for
+  legally required FMLA/state-leave notices or interactive-process steps.

package/jobs/hr/org-chart-manager-drift-check.yaml

@@ -0,0 +1,40 @@
+id: org-chart-manager-drift-check
+version: 1
+name: Org Chart Manager Drift Check
+description: >
+  Compares the manager field in the HRIS against a separately maintained
+  org-chart source of truth and flags mismatches. Use this if the
+  "reports to" field has ever gone stale after a reorg, leaving reviews,
+  approvals, or reminders routed to someone's old manager for months.
+category: hr
+tags: [hr, org-chart, data-quality, hris]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==FNR {
+      if (FNR>1) hris_mgr[$1]=$2;
+      next;
+    }
+    FNR==1 {next}
+    {
+      if (($1 in hris_mgr) && hris_mgr[$1] != $2) {
+        printf "MANAGER DRIFT: %s — HRIS says \"%s\", org chart says \"%s\"\n", $1, hris_mgr[$1], $2;
+      } else if (!($1 in hris_mgr)) {
+        printf "MISSING FROM HRIS: %s — in org chart reporting to \"%s\" but not found in HRIS export\n", $1, $2;
+      }
+    }
+  ' "{{hris_manager_csv_path}}" "{{org_chart_csv_path}}"
+variables:
+  hris_manager_csv_path:
+    default: "./hris-manager-export.csv"
+    description: "Path to a CSV export from the HRIS with columns: employee_name,manager_name."
+  org_chart_csv_path:
+    default: "./org-chart-source.csv"
+    description: "Path to a CSV from your org-chart source of truth (e.g. an org-design tool or a maintained spreadsheet) with columns: employee_name,manager_name."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Matches purely on employee_name strings — dedupe/normalize names (or
+  swap in employee IDs) before relying on this for a large or
+  name-collision-prone roster.

package/jobs/hr/pay-equity-band-outlier-check.yaml

@@ -0,0 +1,58 @@
+id: pay-equity-band-outlier-check
+version: 1
+name: Pay Equity Band Outlier Check
+description: >
+  Scans a salary-band export for employees paid outside their role's band
+  or unusually far from the band midpoint, and summarizes any patterns
+  worth a closer look. Use this if pay outliers have ever gone unnoticed
+  for a review cycle simply because nobody cross-checked salaries against
+  bands until an audit or a pay-equity complaint forced the issue.
+category: hr
+tags: [hr, pay-equity, compensation, compliance]
+schedule: "0 9 1 1,4,7,10 *"
+timezone: "UTC"
+runner: hybrid
+command: >
+  awk -F',' -v tol="{{tolerance_pct}}" '
+    NR==1 {next}
+    {
+      band_min=$3; band_max=$4; salary=$5;
+      low_bound = band_min * (1 - tol/100);
+      high_bound = band_max * (1 + tol/100);
+      if (salary < low_bound) {
+        printf "BELOW BAND: %s (%s) — $%d vs band $%d-$%d\n", $1, $2, salary, band_min, band_max;
+      } else if (salary > high_bound) {
+        printf "ABOVE BAND: %s (%s) — $%d vs band $%d-$%d\n", $1, $2, salary, band_min, band_max;
+      }
+    }
+  ' "{{salary_band_csv_path}}"
+prompt: |
+  Run the outlier check above against {{salary_band_csv_path}} (columns:
+  employee_name, role, band_min, band_max, current_salary). Using the
+  BELOW BAND / ABOVE BAND lines it produces:
+  1. Group outliers by role/level and note any pattern (e.g. one role
+     consistently under band, one department skewing above).
+  2. Do not draw conclusions about protected-class pay gaps — this export
+     has no demographic data. Just flag the raw outliers and patterns for
+     HR/legal to review with proper pay-equity analysis tooling.
+  3. Summarize as a short list HR can triage, ranked by how far outside
+     the band each person is.
+script_note: >
+  The command gives you the raw list of employees outside their band for
+  free. The prompt adds pattern-level grouping (by role/department) to
+  help HR prioritize triage — it does not perform statistical pay-equity
+  analysis or draw demographic conclusions.
+variables:
+  salary_band_csv_path:
+    default: "./salary-bands.csv"
+    description: "Path to an anonymized/exported CSV with columns: employee_name,role,band_min,band_max,current_salary. No demographic fields."
+  tolerance_pct:
+    default: 0
+    description: Percent tolerance outside the band before flagging (0 = flag anything strictly outside min/max).
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  This is a band-boundary check, not a statistical pay-equity or
+  disparate-impact analysis — it deliberately excludes demographic data.
+  Route real pay-equity audits through legal counsel and proper
+  statistical tooling. Assumes an already-exported salary-band CSV rather
+  than live comp-system access.

package/jobs/hr/pto-year-end-use-it-or-lose-it-check.yaml

@@ -0,0 +1,49 @@
+id: pto-year-end-use-it-or-lose-it-check
+version: 1
+name: Company-Wide PTO Use-It-or-Lose-It Check
+description: >
+  Scans the full employee roster for anyone whose unused PTO balance is
+  above the policy cap or won't be usable before the year-end reset, so
+  HR/payroll can send a bulk nudge. Use this if payout or forfeiture
+  disputes have ever come up in December because nobody flagged high
+  balances company-wide until it was too late to schedule time off. This
+  is the HR-wide roster check — for tracking just your own balance, use
+  team/pto-balance-check instead.
+category: hr
+tags: [hr, pto, vacation, compliance, payroll]
+schedule: "0 9 1 10,11,12 *"
+timezone: "America/New_York"
+runner: shell
+command: >
+  today_epoch=$(date +%s);
+  cutoff_epoch=$(date -d "{{year_end_date}}" +%s 2>/dev/null || date -j -f %Y-%m-%d "{{year_end_date}}" +%s);
+  days_left=$(( (cutoff_epoch - today_epoch) / 86400 ));
+  awk -F',' -v cap="{{cap_hours}}" -v days_left="$days_left" -v warn="{{warn_days_before}}" '
+    NR==1 {next}
+    {
+      if ($2 > cap) {
+        printf "OVER CAP: %s — %s hours unused (cap %s)\n", $1, $2, cap;
+      } else if (days_left <= warn && $2 > 0) {
+        printf "USE-IT-OR-LOSE-IT: %s — %s hours unused, %d day(s) until year-end reset (%s)\n", $1, $2, days_left, "{{year_end_date}}";
+      }
+    }
+  ' "{{pto_roster_csv_path}}"
+variables:
+  pto_roster_csv_path:
+    default: "./pto-balances.csv"
+    description: "Path to a CSV export with columns: employee_name,pto_balance_hours."
+  cap_hours:
+    default: 80
+    description: Company policy cap on unused PTO hours, above which balances are flagged regardless of date.
+  year_end_date:
+    default: "2026-12-31"
+    description: Date (YYYY-MM-DD) unused PTO resets or is forfeited under company policy.
+  warn_days_before:
+    default: 45
+    description: How many days before year_end_date to start flagging nonzero balances.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes a maintained roster export from payroll/HRIS with current PTO
+  balances for every employee. Distinct from team/pto-balance-check,
+  which is a single self-maintained personal reminder, not a company-wide
+  audit.

package/jobs/hr/retirement-plan-enrollment-deadline-check.yaml

@@ -0,0 +1,40 @@
+id: retirement-plan-enrollment-deadline-check
+version: 1
+name: Retirement Plan Enrollment Deadline Check
+description: >
+  Flags employees who are eligible for the 401(k)/retirement plan but
+  haven't enrolled or waived as their enrollment deadline approaches. Use
+  this if someone has ever missed the window to make an active election
+  and got dropped into a default auto-enrollment deferral rate they didn't
+  actually want.
+category: hr
+tags: [hr, retirement, 401k, benefits, deadline]
+schedule: "0 8 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    $4 != "" {next}
+    {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (due_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "ENROLLMENT DEADLINE: %s — eligible since %s, deadline %s (%d days), no election on file\n", $1, $2, $3, diff_days;
+      }
+    }
+  ' "{{retirement_tracking_csv_path}}"
+variables:
+  retirement_tracking_csv_path:
+    default: "./retirement-plan-tracking.csv"
+    description: "Path to a CSV with columns: employee_name,eligibility_date (YYYY-MM-DD),enrollment_deadline (YYYY-MM-DD),election_status (enrolled/waived, blank if no election yet)."
+  warn_days_before:
+    default: 14
+    description: How many days before the enrollment deadline to start warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Many plans auto-enroll non-responders at a default deferral rate after
+  the deadline rather than defaulting to no contribution — confirm your
+  plan document's actual default behavior rather than assuming.

package/jobs/hr/workers-comp-claim-status-check.yaml

@@ -0,0 +1,42 @@
+id: workers-comp-claim-status-check
+version: 1
+name: Workers' Comp Claim Status Check
+description: >
+  Checks open workers' compensation claims with the carrier and flags ones
+  that have gone quiet or are approaching an expected return-to-work date
+  with no update. Use this if an injured employee's claim has ever
+  stalled with the carrier for weeks with nobody at the company noticing
+  or following up.
+category: hr
+tags: [hr, workers-comp, compliance, safety]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{wc_carrier}} for open workers' compensation claims and
+  cross-reference against {{hris_system}} for each claimant's expected
+  return-to-work date, if any.
+  1. List each open claim: employee name, date of injury, days since last
+     status update, and expected return date (if set).
+  2. Flag any claim with no status update in the last {{stale_days}} days,
+     or with a return date within {{escalate_within_days}} days and no
+     recent update, as needing a follow-up call with the carrier.
+  3. If everything is progressing normally, say so in one line.
+variables:
+  wc_carrier:
+    default: "your workers' compensation carrier/TPA"
+    description: Where claim status is tracked (the insurance carrier or third-party administrator portal).
+  hris_system:
+    default: "your HRIS"
+    description: Where employee return-to-work dates and leave status are recorded.
+  stale_days:
+    default: 14
+    description: Days with no status update before a claim is flagged as stalled.
+  escalate_within_days:
+    default: 7
+    description: Days before an expected return date at which a claim with no recent update becomes urgent.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: >
+  Read-only status check — actually contacting the carrier, adjusting
+  duties, or making return-to-work decisions is for HR/legal/safety to
+  handle. No generic script mode since carrier portals vary widely.

package/jobs/legal/conflict-of-interest-check-tracker.yaml

@@ -0,0 +1,38 @@
+id: conflict-of-interest-check-tracker
+version: 1
+name: Conflict-of-Interest Check Tracker
+description: >
+  Checks new matters or clients waiting on a conflict-of-interest clearance
+  and flags any that have sat unresolved past a set number of days. Use
+  this if a new engagement has ever started before the conflicts check
+  actually cleared, because the request got sent and then forgotten.
+category: legal
+tags: [legal, conflicts-check, intake, compliance]
+schedule: "0 9 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{overdue_days}}" '
+    NR==1 {next}
+    $4 == "pending" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline requested_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      pending_days = (now_epoch - requested_epoch) / 86400;
+      if (pending_days >= days) {
+        printf "CONFLICTS CHECK PENDING: %s (matter: %s) — requested %s (%d days ago)\n", $1, $2, $3, pending_days;
+      }
+    }
+  ' "{{conflicts_csv_path}}"
+variables:
+  conflicts_csv_path:
+    default: "./conflict-checks.csv"
+    description: "Path to a CSV with columns: client_or_matter_name,proposed_matter,check_requested_date (YYYY-MM-DD),status (pending/cleared/conflict-identified)."
+  overdue_days:
+    default: 2
+    description: Days a conflicts check can remain pending before it's flagged.
+compatible_agents: [generic, claude, codex]
+notes: >
+  This tracks whether a conflicts check was run and resolved before
+  engagement start — it does not run the conflicts search itself, which
+  depends on your practice management/conflicts database.

package/jobs/legal/corporate-minute-book-completeness-check.yaml

@@ -0,0 +1,31 @@
+id: corporate-minute-book-completeness-check
+version: 1
+name: Corporate Minute Book Completeness Check
+description: >
+  Checks the corporate minute book against the list of resolutions and
+  actions that should be documented for the year and flags anything
+  missing. Use this if a board resolution or annual consent has ever been
+  discussed and acted on but never actually got written up and filed in
+  the minute book, which surfaces at the worst time — due diligence for
+  a financing or sale.
+category: legal
+tags: [legal, corporate-governance, board-resolutions, minute-book]
+schedule: "0 9 1 1,4,7,10 *"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' '
+    NR==1 {next}
+    $4 == "no" {
+      printf "MISSING FROM MINUTE BOOK: %s — %s (required by %s, not yet filed)\n", $1, $2, $3;
+    }
+  ' "{{minute_book_checklist_csv_path}}"
+variables:
+  minute_book_checklist_csv_path:
+    default: "./minute-book-checklist.csv"
+    description: "Path to a CSV with columns: item_id,description (e.g. 'annual board consent', 'officer appointment resolution'),required_by_date (YYYY-MM-DD or a plain label like 'Q2'),filed (yes/no)."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes someone maintains the checklist whenever a resolution, consent,
+  or corporate action is decided — this only checks whether the paper
+  trail is complete, it doesn't draft the resolutions themselves.

package/jobs/legal/data-privacy-request-deadline-tracker.yaml

@@ -0,0 +1,61 @@
+id: data-privacy-request-deadline-tracker
+version: 1
+name: Data Privacy Request (GDPR/CCPA) Deadline Tracker
+description: >
+  Flags open data subject access/deletion requests approaching their
+  statutory response deadline and drafts a status summary for whoever
+  owns the response. Use this if a GDPR or CCPA-style privacy request has
+  ever come uncomfortably close to its response window because tracking
+  it lived in someone's inbox instead of a real deadline list.
+category: legal
+tags: [legal, data-privacy, gdpr, ccpa, deadline]
+schedule: "0 8 * * *"
+timezone: "UTC"
+runner: hybrid
+command: >
+  awk -F',' -v days="{{warn_days_before}}" '
+    NR==1 {next}
+    $5 == "open" {
+      cmd = "date -d \"" $4 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $4 "\" +%s 2>/dev/null";
+      cmd | getline due_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      diff_days = (due_epoch - now_epoch) / 86400;
+      if (diff_days <= days) {
+        printf "PRIVACY REQUEST DUE: %s — %s request, due %s (%d days)\n", $1, $2, $4, diff_days;
+      }
+    }
+  ' "{{privacy_requests_csv_path}}"
+prompt: |
+  Here is the raw list of open data privacy requests approaching their
+  deadline (from the shell check): {{command_output}}. For each one:
+  1. Note the request type ({{request_types_hint}}) and which regulation's
+     clock applies (e.g. GDPR's ~30-day window, CCPA's 45-day window).
+  2. Flag anything with fewer than {{urgent_within_days}} days left as
+     urgent and needing an owner today.
+  3. Draft a short status update summarizing what's open, what's urgent,
+     and who should act next, suitable for pasting into a privacy/legal
+     ops channel.
+variables:
+  privacy_requests_csv_path:
+    default: "./data-privacy-requests.csv"
+    description: "Path to a CSV with columns: request_id,request_type (access/deletion/correction/opt-out),regulation (gdpr/ccpa/other),response_due_date (YYYY-MM-DD),status (open/closed)."
+  warn_days_before:
+    default: 7
+    description: Days before the statutory response deadline to start flagging.
+  urgent_within_days:
+    default: 2
+    description: Days left at which an open request becomes urgent in the drafted summary.
+  request_types_hint:
+    default: "access, deletion, correction, or opt-out of sale"
+    description: Short reminder of the request categories your intake form uses.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+script_note: >
+  The shell command gives a zero-token list of requests inside the warning
+  window from date math alone; the prompt adds regulation-specific
+  framing and a drafted, prioritized summary a non-lawyer can act on
+  without re-reading each row.
+notes: >
+  Actual statutory deadlines, extensions, and exceptions vary by
+  regulation and request type — confirm with privacy counsel. This is a
+  tracking and drafting aid, not a substitute for legal review of any
+  individual request.

package/jobs/legal/entity-authority-document-expiry-check.yaml

@@ -0,0 +1,37 @@
+id: entity-authority-document-expiry-check
+version: 1
+name: Entity Authority Document Expiry Check
+description: >
+  Warns before a power of attorney, corporate signing-authority
+  certificate, or other entity-authority document reaches its expiration
+  date. Use this if a bank, counterparty, or government office has ever
+  rejected a signature because the power of attorney or authority
+  certificate backing it had quietly expired.
+category: legal
+tags: [legal, power-of-attorney, corporate-authority, compliance]
+schedule: "0 9 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 "\" (" $2 ") expires in " days_left " days (" $3 ")";
+    }
+  ' {{authority_docs_csv}}
+variables:
+  authority_docs_csv:
+    default: "entity-authority-documents.csv"
+    description: "CSV with header row, columns: document_name,document_type (e.g. power-of-attorney, signing-authority-certificate),expiry_date(YYYY-MM-DD)."
+  warn_days:
+    default: 45
+    description: Days before expiry to start warning.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Distinct from `business-license-renewal-check` (operating licenses/permits)
+  — this tracks documents that grant someone authority to act or sign on
+  the entity's behalf. Update the CSV whenever an authority document is
+  issued, renewed, or revoked.

package/jobs/legal/legal-document-retention-purge-review.yaml

@@ -0,0 +1,39 @@
+id: legal-document-retention-purge-review
+version: 1
+name: Legal Document Retention Purge Review
+description: >
+  Checks contracts and legal documents against their retention schedule
+  and flags anything past its retention period as eligible for archival
+  or destruction review. Use this if signed contracts and legal files
+  have ever piled up indefinitely because nobody was checking them
+  against how long the business's own retention policy actually requires
+  keeping them.
+category: legal
+tags: [legal, records-retention, document-management, compliance]
+schedule: "0 8 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F',' -v today="$today" '
+    NR==1 {next}
+    $4 == "no" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline exp_epoch; close(cmd);
+      if (today >= exp_epoch) {
+        printf "RETENTION EXPIRED: %s (%s) — retention ended %s, check for holds before purging\n", $1, $2, $3;
+      }
+    }
+  ' "{{records_csv_path}}"
+variables:
+  records_csv_path:
+    default: "./legal-records-retention-schedule.csv"
+    description: "Path to a CSV with columns: document_id,document_type,retention_end_date (YYYY-MM-DD),reviewed (yes/no). One row per contract/legal document tracked under the retention policy."
+compatible_agents: [generic, claude, codex]
+notes: >
+  Business's own contract/legal-file retention schedule — distinct from
+  `public-records-retention-purge-check` in government (public-sector
+  records law) and from `litigation-hold-acknowledgment-tracker` in this
+  category. Always cross-check against any active litigation hold before
+  destroying anything this flags — a hold overrides the normal retention
+  schedule.

package/jobs/legal/litigation-hold-acknowledgment-tracker.yaml

@@ -0,0 +1,40 @@
+id: litigation-hold-acknowledgment-tracker
+version: 1
+name: Litigation Hold Acknowledgment Tracker
+description: >
+  Checks active litigation hold notices against the custodian list and
+  flags anyone who hasn't acknowledged receipt yet. Use this if a
+  litigation hold has ever gone out and nobody could later prove every
+  custodian actually got and confirmed it, which is exactly what gets
+  picked apart in a spoliation motion.
+category: legal
+tags: [legal, litigation, litigation-hold, ediscovery, compliance]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: shell
+command: >
+  awk -F',' -v days="{{escalate_after_days}}" '
+    NR==1 {next}
+    $5 == "active" && $4 == "" {
+      cmd = "date -d \"" $3 "\" +%s 2>/dev/null || date -j -f %Y-%m-%d \"" $3 "\" +%s 2>/dev/null";
+      cmd | getline sent_epoch; close(cmd);
+      "date +%s" | getline now_epoch; close("date +%s");
+      pending_days = (now_epoch - sent_epoch) / 86400;
+      if (pending_days >= days) {
+        printf "NOT ACKNOWLEDGED: %s — hold \"%s\" sent %s (%d days ago)\n", $1, $2, $3, pending_days;
+      }
+    }
+  ' "{{holds_csv_path}}"
+variables:
+  holds_csv_path:
+    default: "./litigation-holds.csv"
+    description: "Path to a CSV with columns: custodian_name,matter_name,notice_sent_date (YYYY-MM-DD),acknowledged_date (blank if not yet acknowledged),hold_status (active/released)."
+  escalate_after_days:
+    default: 5
+    description: Days a sent hold notice can go unacknowledged before it's flagged for follow-up.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Assumes counsel maintains the CSV whenever a hold is issued, released, or
+  a custodian confirms receipt. Distinct from court-deadline-reminder
+  (filing/response deadlines within a matter) — this tracks preservation
+  obligations and custodian acknowledgment instead.