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.

TierWhen to runFocusbootEvery new sessionCore services up, orphaned forks, open tasksdailyOnce per dayKB growth, session bloat, store bloat, dead Ollama modelsweeklySunday or first session of the weekFork audit, Postgres vacuum estimate, full diagnostics

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.

User phraseTier"quick check", "is Willow up"boot"daily check", "how's the KB growing"daily"weekly", "deep check", "full diagnostic"weekly"all", "everything"all

Step 2 — Run the diagnostic script#

bash

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:

text

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.

FlagSuggested actionPostgres CRITICALCheck systemctl status postgresql or pg_lsclustersOllama CRITICALRun ollama serve or check systemctl status ollamaMCP CRITICALRun willow restart or check ~/.willow/server.logOrphaned forks WARNShow fork list, ask user which to merge or deleteSessions WARN (>500)Run willow jeles cleanup --dry-run then confirmStore collections WARN (>150)Run python3 scripts/system_health.py --check daily --json for detailDead Ollama models WARNRun ollama rm <model> after confirmationPostgres bloat WARNRun VACUUM ANALYZE in psql; schedule during off-hours

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:

text

## 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.