Heartbeat

${var} — Area to focus on. If empty, runs all checks.

If ${var} is set, focus checks on that specific area.

Read memory/MEMORY.md and the last 2 days of memory/logs/ for context.

Step 0: Compute today's day-of-week from the shell — do not infer it

Before checking any schedules, run:

date -u +%A          # full name, e.g. "Wednesday"
date -u +%u          # numeric, 1=Mon … 7=Sun
date -u +%d          # day-of-month, e.g. "30"

Use the shell-computed day-of-week as the source of truth in every "is this skill scheduled today?" comparison below. Do not infer the day-of-week from ${today} or the YYYY-MM-DD date — past heartbeat runs have hallucinated the wrong weekday from the date (Apr 29 2026 was logged as "Tuesday" when it was actually Wednesday, which then mis-classified memory-flush's on-schedule Wed run as "off-schedule" because the skill thought Wed wasn't a memory-flush day). The shell value is deterministic; the inferred value is not.

Anchor the heartbeat report header on the shell output: Date: <%A> <Mon DD>, <YYYY> — <HH:MM> UTC.

Translate cron expressions before checking schedules:

• Weekday (0 N D) — D is 0=Sun, 1=Mon, …, 6=Sat. Compare against date -u +%u (which is 1=Mon … 7=Sun — Sunday differs).
• Every-other-day (0 N /2 *) — when in doubt, ground-truth against the last 7 days of cron-state.json last_dispatch timestamps for that skill. Do not assume which parity (odd / even days-of-month) the cron resolves to without checking.

Checks

Check the following:

• [ ] Any open PRs stalled > 24h? (use gh pr list to check)
• [ ] Anything flagged in memory that needs follow-up?
• [ ] Check recent GitHub issues for anything labeled urgent (use gh issue list)
• [ ] Scan aeon.yml for enabled scheduled skills — cross-reference with today's log (memory/logs/${today}.md) to find any that haven't run when expected.

Matching skill names to log entries: Skills log under human-readable ## Headers, not their aeon.yml kebab-case names. To check if a skill ran, do a case-insensitive match against ## header lines only — grep -iE '^## …', not a free-text substring search of the full file. Header-only matching matters for short skill names: substring-searching the whole file for feature matches body text like "added a feature" in push-recap, falsely concluding the feature skill ran on a day it actually failed and masking the outage. Build the regex by replacing hyphens in the kebab-case name with [ -]? so both ## Feature Built and ## Self-Improve are accepted. Examples:

• token-report → ^## token[ -]?report (matches ## Token Report, ## Token Report (Update))
• push-recap → ^## push[ -]?recap (matches ## Push Recap, ## Push Recap (MiroShark))
• fetch-tweets → ^## fetch[ -]?tweets (matches ## Fetch Tweets — MIROSHARK)
• feature → ^## feature\b (matches ## Feature Built — ..., ## feature skill run — and does not match the bare word "feature" inside other sections' body text)
• hyperstitions-ideas → ^## hyperstitions (matches ## Hyperstitions Ideas)
• memory-flush → ^## memory[ -]?flush
• self-improve → ^## (self[ -]?improve|agent self-improvement) (matches ## Self-Improve — 2026-05-04, ## Agent Self-Improvement)
• repo-pulse → ^## repo[ -]?pulse
• repo-article → ^## repo[ -]?article
• repo-actions → ^## repo[ -]?actions
• project-lens → ^## project[ -]?lens
• tweet-allocator → ^## tweet[ -]?allocator
• weekly-shiplog → ^## weekly[ -]?shiplog
• skill-leaderboard → ^## skill[ -]?leaderboard

Timing rules (avoid false positives):

• GitHub Actions cron has ±10 min jitter and skills take 5-15 min to complete.
• Only flag a skill as missing if its scheduled time was more than 2 hours ago.
• Also check gh run list --workflow=aeon.yml --created=$(date -u +%Y-%m-%d) --json displayTitle,status,createdAt — if the skill is currently in_progress or queued and was created less than 2 hours ago, don't flag it.
• Stuck-run detection: If a run has been in_progress for more than 2 hours (compare createdAt against current time), treat it as stuck. Flag it in the report as "stuck (in_progress > 2h)" and allow auto-trigger of a fresh run. Do NOT cancel the stuck run — just dispatch a new one alongside it.
• For day-of-week schedules (e.g. 0 20 0 for Sundays), only check on the matching day.

Before sending any notification, grep the last 48h of logs for the same issue. If the same missing-skill or stalled-PR was already reported, skip it. Batch all findings into a single notification.

If nothing needs attention, log "HEARTBEAT_OK" and end your response.

If something needs attention:

1. Auto-trigger missing skills — for each skill confirmed missing (not just stalled PRs or issues), dispatch it if not already running:

Dedup guard — check before dispatching: Before firing gh workflow run for a skill, check whether a run for that skill is already queued or in_progress and was started less than 2 hours ago: ``bash gh run list --workflow=aeon.yml --json displayTitle,status,createdAt --jq \ '.[] | select((.status == "queued" or .status == "in_progress") and ((now - (.createdAt | fromdateiso8601)) < 7200)) | .displayTitle' ` If the output contains the skill name (case-insensitive), skip the dispatch — the skill is already pending. Runs older than 2 hours are considered stuck and ignored by this guard (a fresh dispatch is allowed). Only dispatch skills that have no active-and-recent or queued run: `bash gh workflow run aeon.yml -f skill="SKILL_NAME" ` Skip auto-trigger for: heartbeat itself, memory-flush, self-improve, reflect, self-review` (meta/housekeeping skills). For all other confirmed-missing daily or weekly skills that pass the dedup check, dispatch them.

1. Send a concise notification via ./notify listing what was flagged, what was auto-triggered, and what was skipped (already queued/in-progress).
2. Log the finding and action taken to memory/logs/${today}.md.