Willow System Health

Audit the Willow local AI stack for subsystem failures, drift, and resource bloat. Use when a user asks to check Willow health, diagnose a slow or broken Wil...

Security Scan

The skill's code, instructions, and requirements are coherent with an on‑host Willow health auditor; it performs local checks and offers cleanup actions and requests no external credentials.

Purpose & Capability

Name and description claim a local Willow system audit; the included script explicitly checks Postgres, Ollama, the MCP server, git worktrees, Willow CLI tasks, and store sizes — all directly relevant to the stated purpose. No unrelated cloud credentials or remote service keys are requested.

Instruction Scope

SKILL.md instructs the agent to run the included Python script and, optionally, append an entry to the user's memory. The script performs network probes to localhost services, runs local subprocesses (git, pg_isready, python -m willow.cli, psycopg2 via python -c), and reads repository and Willow store paths (default ~/.willow and ~/github/willow-1.9). These actions are within the audit scope but do access local files, sockets, and run commands with potentially elevated read access to local data; the SKILL.md requires explicit user confirmation before destructive actions.

Install Mechanism

No install spec is present; the skill is instruction-only with an included script. Nothing is downloaded from external URLs and no archives are extracted. This lowers install-time risk.

Credentials

The skill declares no required environment variables or credentials which is appropriate. The script uses an embedded default Postgres DSN (postgresql://willow:willow@localhost:5432/willow) and attempts to import/use psycopg2 and system binaries (git, pg_isready, willow CLI) if present. That is proportionate for a local Willow health check, but it does assume access to local DB credentials and filesystem paths (~/github/willow-1.9, ~/.willow) — users should be aware it will probe those locations.

Persistence & Privilege

always is false and model invocation is allowed (normal). SKILL.md says memory writes are conditional on the user's memory opt-in and are append-only to memory/YYYY-MM-DD.md. The skill does not request permanent always-on privilege or modification of other skills' configs.

Assessment

This skill appears to do exactly what it says: local health checks and guided cleanup for a Willow stack. Before installing or running it, note that it will: (1) probe local TCP ports and make HTTP requests to localhost (Ollama/MCP), (2) attempt Postgres connections using the default Willow DSN and may call pg_isready or import psycopg2, (3) run local commands like git and `python -m willow.cli`, and (4) can append entries to your agent memory if you have memory writes enabled. None of these actions contact remote endpoints outside the host, and destructive operations (git worktree remove, ollama rm, VACUUM) are gated by explicit confirmation in the SKILL.md. If you plan to run this skill, review the script (scripts/system_health.py), ensure you trust the local environment, and confirm any cleanup actions before proceeding.

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.

Tier	When to run	Focus
boot	Every new session	Core services up, orphaned forks, open tasks
daily	Once per day	KB growth, session bloat, store bloat, dead Ollama models
weekly	Sunday or first session of the week	Fork 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 phrase	Tier
"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

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.

Flag	Suggested action
Postgres CRITICAL	Check systemctl status postgresql or pg_lsclusters
Ollama CRITICAL	Run ollama serve or check systemctl status ollama
MCP CRITICAL	Run willow restart or check ~/.willow/server.log
Orphaned forks WARN	Show fork list, ask user which to merge or delete
Sessions WARN (>500)	Run willow jeles cleanup --dry-run then confirm
Store collections WARN (>150)	Run python3 scripts/system_health.py --check daily --json for detail
Dead Ollama models WARN	Run ollama rm <model> after confirmation
Postgres bloat WARN	Run 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:

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