Willow System Health

Audit the Willow local AI stack across three cadenced tiers. Each tier adds depth — boot checks are instant, daily checks catch drift, weekly checks catch structural rot.

Trigger

Use this skill when the user:

• Asks to check, audit, or verify Willow health
• Reports Willow is slow, unresponsive, or giving stale answers
• Wants to know if Postgres, Ollama, or MCP are running
• Asks about open forks, open tasks, or store bloat
• Wants a weekly deep diagnostic

Step 1 — Determine the tier

Ask or infer from context. Default to boot if the user just wants a quick check.

Step 2 — Run the diagnostic script

python3 {baseDir}/scripts/system_health.py --check boot
python3 {baseDir}/scripts/system_health.py --check daily
python3 {baseDir}/scripts/system_health.py --check weekly
python3 {baseDir}/scripts/system_health.py --check all

Optional flags:

• --willow-dir PATH — override default ~/.willow/ store path
• --repo PATH — override default Willow git repo path (for fork audit)
• --json — machine-readable output

Step 3 — Interpret the report

The script prints a per-subsystem table followed by a summary:

WILLOW SYSTEM HEALTH — boot (2026-04-24 09:15)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SUBSYSTEM          STATUS     DETAIL
Postgres           HEALTHY    connection ok
Ollama             HEALTHY    3 models loaded
MCP server         HEALTHY    responding at 127.0.0.1:7337
Orphaned forks     WARN       2 worktrees unmerged >7d
Open tasks         HEALTHY    4 open tasks
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SUMMARY
  Tier checked  : boot
  HEALTHY       : 3
  WARN          : 1
  CRITICAL      : 0

HEALTHY — no action needed.

WARN — review recommended. Suggest specific next action (see table below).

CRITICAL — service is down or threshold severely exceeded. Block-level recommendation.

Step 4 — Enforce config drift (boot tier)

The boot check includes a drift watchdog. If any of these fail, flag CRITICAL:

• Ollama reachable at 127.0.0.1:11434
• MCP server socket alive (default 127.0.0.1:7337)
• Postgres connection succeeds with default Willow credentials

Drift means something changed the environment — not the code. Check recent git log, system updates, or port conflicts first before spelunking source.

Step 5 — Offer cleanup actions

After reporting, offer numbered actions the user can pick:

1. Merge or delete orphaned forks (show list first)
2. Archive old Jeles sessions (willow jeles cleanup)
3. Remove dead Ollama models (ollama rm <model>)
4. Run Postgres VACUUM ANALYZE
5. Skip — report only, no changes

Always confirm before any destructive action.

Step 6 — Execute with confirmation

For each cleanup action:

• Show exactly what will be changed
• Confirm before proceeding
• Report what was done

After cleanup, offer to re-run the diagnostic to confirm health improved.

Memory writes

If the user has opted into memory writes, append a dated summary to memory/YYYY-MM-DD.md:

## Willow system health — {timestamp}
- Tier: boot/daily/weekly
- CRITICAL: N subsystems
- WARN: N subsystems
- Actions taken: (list or "none")

Append-only. Do not overwrite existing entries.

Notes

• Boot checks are safe to run at any time — read-only, no side effects.
• Daily and weekly checks may be slow (Postgres queries, git commands). Warn the user if running in a latency-sensitive session.
• Fork audit uses git worktree list in the Willow repo. Default path is ~/github/willow-1.9 — override with --repo.
• Ollama dead-model detection uses ollama list and compares to last-access timestamps if available; falls back to listing all models as WARN.
• This skill does not modify the Postgres schema or Willow config directly — it reports and suggests; the user confirms all changes.