heartbeat

name	Heartbeat
description	Proactive ambient check — surface anything worth attention
var
tags	["meta"]

${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:

   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:

   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.

2. Send a concise notification via ./notify listing what was flagged, what was auto-triggered, and what was skipped (already queued/in-progress).

3. Log the finding and action taken to memory/logs/${today}.md.