@wonsukchoi/crondex 0.7.0 → 0.9.0

package/jobs/marketing/seo-rank-drop-watch.yaml

@@ -0,0 +1,38 @@
+id: seo-rank-drop-watch
+version: 1
+name: SEO Keyword Rank Drop Watch
+description: >
+  Checks a tracked keyword's search ranking and flags a real drop. Use
+  this if a page has ever slipped off page one and nobody noticed until
+  organic traffic was already down for weeks.
+category: marketing
+tags: [seo, rankings, marketing]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check the current search ranking for the keyword "{{keyword}}" targeting
+  {{target_url}}, via {{rank_source_hint}}.
+  1. Compare the current position to the baseline position of
+     {{baseline_position}}.
+  2. Flag a drop of {{drop_threshold_positions}} positions or more.
+  3. If dropped, note which competing URLs now outrank {{target_url}}, if
+     visible.
+variables:
+  keyword:
+    default: "your target keyword"
+    description: Keyword to track.
+  target_url:
+    default: "https://example.com/page"
+    description: URL you're tracking rank for.
+  rank_source_hint:
+    default: "a rank tracker (Ahrefs, SEMrush, Search Console) or a manual SERP check"
+    description: Where to check current rank.
+  baseline_position:
+    default: 5
+    description: Baseline ranking position to compare against.
+  drop_threshold_positions:
+    default: 5
+    description: Position drop that counts as a real regression.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: No generic script mode — SERP position checking needs a rank-tracking API or live search, both of which vary by provider/region.

package/jobs/nonprofit/volunteer-hours-shortfall-check.yaml

@@ -0,0 +1,30 @@
+id: volunteer-hours-shortfall-check
+version: 1
+name: Volunteer Hours Shortfall Check
+description: >
+  Compares logged volunteer hours against a program's target and flags a
+  shortfall. Use this if a program has ever fallen behind on a grant's
+  volunteer-hour commitment without anyone noticing until the report was
+  due.
+category: nonprofit
+tags: [nonprofit, volunteers, programs]
+schedule: "0 9 1 * *"
+timezone: "UTC"
+runner: shell
+command: >
+  logged=$(awk -F, -v month="$(date +%Y-%m)" -v program="{{program_name}}" '$1 ~ month && $2 == program {sum += $3} END {print sum+0}' {{volunteer_hours_csv}});
+  target={{monthly_target_hours}};
+  if awk "BEGIN{exit !($logged < $target)}"; then echo "WARNING: {{program_name}} logged $logged of $target target hours this month"; exit 1;
+  else echo "OK: {{program_name}} logged $logged of $target target hours"; fi
+variables:
+  volunteer_hours_csv:
+    default: "volunteer-hours.csv"
+    description: "CSV with columns: month(YYYY-MM),program,hours."
+  program_name:
+    default: "your program"
+    description: Program name to check.
+  monthly_target_hours:
+    default: 100
+    description: Target volunteer hours for the program this month.
+compatible_agents: [generic, claude, codex]
+notes: Keep volunteer-hours.csv updated from your volunteer management system's export before each run.

package/jobs/personal/end-of-day-wrap-message.yaml

@@ -0,0 +1,32 @@
+id: end-of-day-wrap-message
+version: 1
+name: End-of-Day Wrap Message
+description: >
+  Fires around the end of your work calendar and drafts a short wrap-up:
+  what got done today, what's carrying over to tomorrow. Use this if you
+  close your laptop most days without a clear sense of what actually
+  happened or what's still pending.
+category: personal
+tags: [reflection, end-of-day, productivity, wrap-up]
+schedule: "0 18 * * 1-5"
+timezone: "America/Los_Angeles"
+runner: agent-prompt
+prompt: |
+  Look at today's completed calendar events, closed tasks/tickets, and
+  commits (whatever of {{activity_sources}} is available) for
+  {{lookback_hours}} hours.
+  1. Summarize in 2-3 bullets what got meaningfully done today.
+  2. List anything left open that was expected to close today, as
+     "carrying over to tomorrow."
+  3. End with one line acknowledging the day plainly — no forced
+     positivity, just an honest close.
+  Keep the whole thing short enough to read in 15 seconds.
+variables:
+  activity_sources:
+    default: "your calendar, task tracker, and git commits"
+    description: Comma-separated list of sources to check for today's activity.
+  lookback_hours:
+    default: 10
+    description: Rough length of the workday to look back over.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Schedule this against your actual calendar end time, not a fixed hour, if your agent can read "last event ends at" dynamically.

package/jobs/personal/new-restaurant-roundup.yaml

@@ -0,0 +1,35 @@
+id: new-restaurant-roundup
+version: 1
+name: New Restaurant Roundup
+description: >
+  Checks for restaurants that newly opened near you in the last week and
+  gives you a short list to consider. Use this if you like trying new
+  places but never remember to actually go looking for what just opened.
+category: personal
+tags: [restaurants, local, discovery, weekly]
+schedule: "0 17 * * 5"
+timezone: "America/Los_Angeles"
+runner: agent-prompt
+prompt: |
+  Check for restaurants that newly opened within {{radius_miles}} miles of
+  {{location}} in the last {{lookback_days}} days (via Yelp, Google Maps,
+  local news, or whatever local-discovery source is available).
+  1. List each new place: name, cuisine, and distance.
+  2. Note anything getting early buzz (a write-up, strong early reviews).
+  3. Keep it to the top {{max_results}} most promising — this is a quick
+     Friday-evening list, not a research report.
+variables:
+  location:
+    default: "your city/neighborhood"
+    description: Location to search around.
+  radius_miles:
+    default: 5
+    description: Search radius in miles.
+  lookback_days:
+    default: 14
+    description: How recently a restaurant must have opened to count as "new."
+  max_results:
+    default: 5
+    description: Max number of places to list.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Quality depends on local coverage in whatever source the agent can reach — sparser in small towns than big cities.

package/jobs/podcast/guest-followup-reminder.yaml

@@ -0,0 +1,31 @@
+id: guest-followup-reminder
+version: 1
+name: Podcast Guest Follow-up Reminder
+description: >
+  Flags recorded guest episodes that haven't been published or thanked
+  yet. Use this if a guest has ever had to awkwardly ask when their
+  episode was coming out because nobody followed up after recording.
+category: podcast
+tags: [podcast, guests, followup]
+schedule: "0 9 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  today=$(date +%s);
+  awk -F, -v today="$today" -v warn={{warn_days}} '
+    NR>1 && $3 == "unpublished" {
+      cmd="date -d \"" $2 "\" +%s 2>/dev/null || date -jf \"%Y-%m-%d\" \"" $2 "\" +%s";
+      cmd | getline recorded_ts; close(cmd);
+      days_since = int((today - recorded_ts) / 86400);
+      if (days_since >= warn) print "WARNING: episode with " $1 " recorded " days_since " days ago, still unpublished";
+    }
+  ' {{guest_episodes_csv}}
+variables:
+  guest_episodes_csv:
+    default: "guest-episodes.csv"
+    description: "CSV with header row, columns: guest_name,recorded_date(YYYY-MM-DD),status(unpublished/published)."
+  warn_days:
+    default: 14
+    description: Days since recording before an unpublished episode is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Keep guest-episodes.csv updated as episodes are recorded and published — one row per guest episode.

package/jobs/productivity/morning-briefing-digest.yaml

@@ -0,0 +1,42 @@
+id: morning-briefing-digest
+version: 1
+name: Morning Briefing Digest
+description: >
+  Pulls together overnight email, today's calendar, and any connected
+  analytics/monitoring dashboards into one short digest waiting for you at
+  the start of the day. Use this if you start your morning tab-hopping
+  across five dashboards before you've even had coffee.
+category: productivity
+tags: [briefing, digest, morning, calendar, email]
+schedule: "0 7 * * 1-5"
+timezone: "America/Los_Angeles"
+runner: agent-prompt
+prompt: |
+  Build a short morning briefing covering:
+  1. Calendar: today's meetings from {{calendar_source}}, flagging any
+     back-to-back blocks with no prep time.
+  2. Email: unread messages from {{email_source}} in the last
+     {{lookback_hours}} hours that look like they need a same-day reply —
+     skip newsletters/notifications.
+  3. Metrics: anything notable from {{dashboard_sources}} (traffic spike or
+     drop, error rate change, ranking movement) — only report real changes,
+     not routine noise.
+  4. End with a single "top 3 things to do today" list synthesized from the
+     above.
+  Keep the whole digest to one screen — this replaces tab-hopping, it
+  shouldn't become its own chore to read.
+variables:
+  calendar_source:
+    default: "your calendar (e.g. Google Calendar)"
+    description: Calendar to pull today's meetings from.
+  email_source:
+    default: "your inbox (e.g. Gmail)"
+    description: Inbox to scan for messages needing a same-day reply.
+  dashboard_sources:
+    default: "analytics/search console/uptime monitoring, whatever you have connected"
+    description: Comma-separated list of dashboards/metrics sources to check.
+  lookback_hours:
+    default: 16
+    description: How far back to scan email (covers overnight since last workday).
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Value scales with how many sources you connect — start with just calendar+email and add dashboards as they're available.

package/jobs/productivity/recurring-task-queue-reset.yaml

@@ -0,0 +1,37 @@
+id: recurring-task-queue-reset
+version: 1
+name: Recurring Task Queue Reset
+description: >
+  Clears out last week's completed recurring-task checklist and creates a
+  fresh one from your template, so every cycle starts with the same
+  predefined owners and checklist instead of a copy-pasted mess. Use this
+  if your recurring weekly checklist has ever quietly drifted because
+  someone edited last week's copy instead of starting clean.
+category: productivity
+tags: [productivity, checklist, recurring, template]
+schedule: "0 6 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  if [ ! -f "{{template_path}}" ]; then
+    echo "template not found at {{template_path}} — nothing to reset from.";
+    exit 1;
+  fi
+  week_label=$(date +%G-W%V);
+  dest="{{output_dir}}/${week_label}.md";
+  mkdir -p "{{output_dir}}";
+  if [ -f "$dest" ]; then
+    echo "$dest already exists — not overwriting this week's checklist.";
+  else
+    cp "{{template_path}}" "$dest";
+    echo "created fresh checklist: $dest";
+  fi
+variables:
+  template_path:
+    default: "./templates/weekly-checklist.md"
+    description: Path to the checklist template with predefined owners/items.
+  output_dir:
+    default: "./weekly-checklists"
+    description: Directory where each week's fresh checklist file is written.
+compatible_agents: [generic, claude, codex]
+notes: File-based by default for portability — swap `cp` for your task tool's API call (Notion, Asana, ClickUp) if you want it created there instead of as a local file.

package/jobs/realestate/rent-payment-late-check.yaml

@@ -0,0 +1,23 @@
+id: rent-payment-late-check
+version: 1
+name: Rent Payment Late Check
+description: >
+  Flags tenants whose rent is overdue past the grace period. Use this if
+  a late payment has ever gone unnoticed for weeks because nobody was
+  cross-checking the rent roll against the bank deposits.
+category: realestate
+tags: [realestate, rent, payments]
+schedule: "0 9 * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  psql "{{database_url}}" -t -c "select tenant_name, unit, amount_due, due_date from rent_ledger where paid = false and due_date < current_date - interval '{{grace_days}} days';"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the property management database.
+  grace_days:
+    default: 5
+    description: Days past due_date before a late payment is flagged.
+compatible_agents: [generic, claude, codex]
+notes: Assumes a `rent_ledger` table with `paid`, `due_date`, and `amount_due` columns — adjust the query to your property management system's schema.

package/jobs/restaurant/health-inspection-prep-reminder.yaml

@@ -0,0 +1,29 @@
+id: health-inspection-prep-reminder
+version: 1
+name: Health Inspection Prep Reminder
+description: >
+  Reminds the team of the standard health-inspection checklist on a
+  recurring basis, not just when an inspection is imminent. Use this if
+  you've ever scrambled the morning an inspector showed up unannounced.
+category: restaurant
+tags: [compliance, health-inspection, checklist, kitchen]
+schedule: "0 7 * * 1"
+timezone: "America/New_York"
+runner: shell
+command: >
+  echo "Weekly health-inspection self-check ({{checklist_path}}):";
+  if [ -f "{{checklist_path}}" ]; then cat "{{checklist_path}}"; else
+  echo "- Fridge/freezer temps logged and in range";
+  echo "- Handwashing stations stocked (soap, towels, signage)";
+  echo "- Food storage labeled with dates, FIFO followed";
+  echo "- No bare-hand contact with ready-to-eat food";
+  echo "- Pest control log up to date";
+  echo "- Cleaning/sanitizing log current";
+  echo "- Employee health/illness policy posted";
+  fi
+variables:
+  checklist_path:
+    default: "./health-inspection-checklist.txt"
+    description: Optional path to your own custom checklist file; falls back to a standard baseline if not found.
+compatible_agents: [generic, claude, codex]
+notes: This is a recurring self-audit reminder, not a substitute for your local health department's actual requirements — adapt the checklist to your jurisdiction.

package/jobs/restaurant/inventory-waste-log-review.yaml

@@ -0,0 +1,32 @@
+id: inventory-waste-log-review
+version: 1
+name: Inventory Waste Log Review
+description: >
+  Reviews the kitchen's waste log for the week and flags which items are
+  being tossed most, in case it's an over-ordering or portioning problem.
+  Use this if food cost keeps creeping up and nobody's sure why.
+category: restaurant
+tags: [inventory, waste, food-cost, kitchen]
+schedule: "0 10 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Read the waste log for the past {{lookback_days}} days from
+  {{waste_log_source}}.
+  1. Total waste by item (quantity and estimated cost if given).
+  2. Rank the top 5 items by wasted cost.
+  3. For each top item, note the most common waste reason logged (spoilage,
+     over-prep, returned order, etc.) if that field exists.
+  4. Flag any item where waste looks like it's trending up week over week,
+     not just a one-off bad night.
+  5. Suggest one concrete action per top item (reduce par level, tighten
+     portioning, adjust prep timing).
+variables:
+  waste_log_source:
+    default: "your POS/inventory system's waste log"
+    description: Where the waste log lives (e.g. "Toast waste tracking", "a shared spreadsheet").
+  lookback_days:
+    default: 7
+    description: How many days of waste log to review.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Quality of the report depends entirely on how consistently staff logs waste — garbage in, garbage out.

package/jobs/restaurant/reservation-noshow-deposit-check.yaml

@@ -0,0 +1,32 @@
+id: reservation-noshow-deposit-check
+version: 1
+name: Reservation No-Show Pattern Check
+description: >
+  Reviews recent reservation no-shows and flags parties/times where
+  no-shows cluster, so you know whether a deposit or confirmation-call
+  policy would help. Use this if a certain night or party size keeps
+  costing you empty tables.
+category: restaurant
+tags: [reservations, no-show, hospitality]
+schedule: "0 11 * * 1"
+timezone: "America/New_York"
+runner: agent-prompt
+prompt: |
+  Pull reservation data from {{reservation_system}} for the past
+  {{lookback_days}} days.
+  1. Calculate the overall no-show rate.
+  2. Break it down by day of week, time slot, and party size — flag any
+     segment with a no-show rate meaningfully above the overall average.
+  3. List repeat no-show guests (2+ in the window) by name/phone if
+     available.
+  4. Recommend whether a deposit or confirmation-text policy is warranted
+     for the flagged segments specifically, rather than restaurant-wide.
+variables:
+  reservation_system:
+    default: "your reservation platform"
+    description: Name of the reservation system (e.g. "OpenTable", "Resy", "Tock").
+  lookback_days:
+    default: 30
+    description: Window of reservation history to analyze.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Read-only analysis — any policy change (deposits, blocklisting repeat no-shows) is a business decision for a human to make.

package/jobs/sales/newly-funded-leads-scout.yaml

@@ -0,0 +1,44 @@
+id: newly-funded-leads-scout
+version: 1
+name: Newly Funded Companies Lead Scout
+description: >
+  Checks funding-announcement sources for companies that just raised in
+  your target market and drafts a first-outreach message for each. Use
+  this if you sell to companies that spend differently right after a
+  funding round and you want to reach them before every other vendor does.
+category: sales
+tags: [sales, leads, funding, outreach, prospecting]
+schedule: "0 8 * * 1-5"
+timezone: "UTC"
+runner: agent-prompt
+prompt: |
+  Check {{funding_sources}} for companies that announced a funding round in
+  the last {{lookback_days}} days matching: industry "{{target_industry}}",
+  stage "{{target_stage}}".
+  1. List each company: name, round size/stage, and a one-line note on why
+     they fit the target profile.
+  2. For each, note the most relevant contact if discoverable (founder,
+     head of the department your product serves).
+  3. Draft a short, non-generic first-touch outreach message per company
+     that references the funding news and ties it to a concrete reason
+     they'd need {{your_product}} now.
+  4. Skip companies already in {{existing_crm_note}} to avoid duplicate
+     outreach.
+variables:
+  funding_sources:
+    default: "Crunchbase, TechCrunch funding news, or your preferred funding-news feed"
+    description: Sources to check for funding announcements.
+  target_industry:
+    default: "SaaS"
+    description: Industry/vertical to filter for.
+  target_stage:
+    default: "Seed or Series A"
+    description: Funding stage(s) worth prospecting.
+  your_product:
+    default: "your product"
+    description: One-line description of what you sell, for the outreach draft to reference.
+  existing_crm_note:
+    default: "no CRM connected — skip duplicate check"
+    description: Where to check for companies already in your pipeline, to avoid re-outreaching.
+compatible_agents: [claude, codex, hermes, openclaw, generic]
+notes: Draft-only — review before sending, and check the funding source's terms of use before scraping instead of using an official API/RSS feed.

package/jobs/sales/quota-attainment-check.yaml

@@ -0,0 +1,33 @@
+id: quota-attainment-check
+version: 1
+name: Quota Attainment Check
+description: >
+  Compares a rep's closed-won revenue this period against their quota
+  pace and flags whether they're on track. Use this if a rep has ever
+  found out they missed quota only at the end of the quarter, instead of
+  with enough runway left to fix it.
+category: sales
+tags: [sales, quota, pipeline]
+schedule: "0 8 * * 1"
+timezone: "UTC"
+runner: shell
+command: >
+  closed=$(psql "{{database_url}}" -t -c "select coalesce(sum(amount),0) from deals where owner = '{{rep_name}}' and stage = 'closed_won' and closed_at >= date_trunc('quarter', current_date);");
+  quota={{quarterly_quota}};
+  pct=$(awk "BEGIN{printf \"%.0f\", ($closed/$quota)*100}");
+  echo "quota check for {{rep_name}}: closed \$$closed of \$$quota quarterly quota (${pct}%) so far"
+variables:
+  database_url:
+    default: "postgres://user:pass@host:5432/db"
+    description: Connection string for the CRM/deals database.
+  rep_name:
+    default: "rep-name"
+    description: Sales rep owner field to check.
+  quarterly_quota:
+    default: 100000
+    description: Quarterly quota amount for this rep.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Prints closed-won revenue vs. quota for the current quarter; the pacing
+  math (days elapsed vs. days in quarter) is left for you or your agent to
+  interpret since exact quarter boundaries vary by fiscal calendar.

package/jobs/support/sla-breach-warning.yaml

@@ -0,0 +1,31 @@
+id: sla-breach-warning
+version: 1
+name: SLA Breach Warning
+description: >
+  Flags open tickets that are about to breach their SLA, before they
+  actually do. Use this if a ticket has ever blown past its SLA with zero
+  warning because the only check was after the fact.
+category: support
+tags: [support, sla, tickets]
+schedule: "*/15 * * * *"
+timezone: "UTC"
+runner: shell
+command: >
+  count=$(curl -s -H "Authorization: Bearer {{api_token}}" "{{api_url}}" | grep -o '"status":"open"' | wc -l | tr -d ' ');
+  if [ -z "$count" ] || [ "$count" -eq 0 ]; then echo "OK: no tickets approaching SLA breach"; exit 0;
+  else echo "WARNING: $count ticket(s) within {{warn_minutes}} minutes of SLA breach at {{api_url}}"; exit 1; fi
+variables:
+  api_url:
+    default: "https://api.example-helpdesk.com/tickets?status=open&sla_remaining_lt_minutes=30"
+    description: Helpdesk API endpoint pre-filtered to tickets close to breaching SLA.
+  api_token:
+    default: "your-api-token"
+    description: Bearer token for the helpdesk API.
+  warn_minutes:
+    default: 30
+    description: Minutes of SLA time remaining that counts as "about to breach", for labeling output.
+compatible_agents: [generic, claude, codex]
+notes: >
+  Proactive counterpart to `ticket-backlog-aging-check` (which flags
+  tickets already past SLA) — point api_url at your helpdesk's filtered
+  search for tickets still within SLA but running low on time.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wonsukchoi/crondex",
-  "version": "0.7.0",
+  "version": "0.9.0",
   "description": "A public directory of pre-made, agent-editable cron jobs.",
   "type": "module",
   "license": "MIT",