System Audit

System Audit

You are running a quality / sanity / efficiency audit on Ane's MEL/SRHR system. Output is a Tier 1 working brief listing issues with file paths and a sequencing recommendation. You do NOT execute fixes. Ane reviews and confirms each.

When to use this

• Ane types /system-audit, /audit, /system-check, or asks for a system health read
• Before any /li curate (audit surfaces issues curate should consolidate)
• After substantive agent-improvement work to verify nothing drifted
• Periodically as a backstop against silent drift

This skill complements rather than duplicates /test (harness only) and /li lint (wiki only). It is the broader pass that catches inconsistencies between layers.

Workflow

Step 1 — Harness state (fast, mechanical)

Run in this order:

1. python tests/run_tests.py (static; expect 78/78 or higher as system grows)
2. python tests/run_tests.py --output (fixture mode; some fixtures may be deliberately uncaptured)

Parse failures. Each [FAIL] line goes into the findings list with file:line as shown. Do NOT re-run the failures or attempt fixes; just record.

*A green local harness does not mean a green harness. Read the newest `routine-reports/weekly-health-check-.md and diff its harness line against the run you just did.** The weekly cloud routine runs the same commit in an environment that provisions differently, and a check whose inputs depend on the environment fails there while passing here. Report BOTH numbers and treat any difference, in the count or in the verdict, as a finding rather than as cloud flakiness. Two distinct failures hide in that gap and neither is visible from a local run: a check that FAILS remotely because half its vocabulary lives in a file the remote does not install, and a check count that is LOWER remotely because the glob sweeps walked an empty root and reported an aggregate pass over zero files. The second is the more dangerous, because it reads as success. Motivating case (2026-09-09 post-migration audit): local ran 380/380 clean while the cloud routine had reported 318/319 with a hard FAIL since at least 2026-08-31, ten days unnoticed, because workflow-drift:qa_block fields resolve builds its field vocabulary from qa-block-schema.md PLUS vi/SKILL.md` and two fields were documented only in the skill. Nothing in a local pass could surface it. When the counts differ, diagnose which inputs the remote lacks before touching the check itself; the usual answer is that a canonical source is incomplete and a skill file has been silently covering for it.

1. Resolve `SKILLS_DIR` before measuring anything against it, and report which root it returned. Run python -c "import sys; sys.path.insert(0,'tests'); import run_tests as rt; print(rt.SKILLS_DIR, len(list(rt.SKILLS_DIR.glob('*/SKILL.md'))))". Several install roots hold SKILL.md copies and they drift from each other, so a line count, a budget check, or a coverage claim measured against the wrong root is simply wrong. Never infer the root from a path written in CLAUDE.md or in this skill; ask the harness. A flat check count across two runs does NOT prove a skills change had no effect, because the glob-based sweeps report one aggregate check each regardless of how many files they cover.

Then compare that root against the personal-skills clone, listing skills absent from the root as well as skills whose content differs. On 2026-07-29 the resolved root was missing 7 first-party skills outright and held stale copies of 6 more while the harness reported green, and the audit brief initially named the wrong directory because it assumed rather than resolved. When the two differ, diagnose which side is older before copying anything (compare line counts and diff direction): the newer side is not always the installed one, and the copy overwrites whichever side you point it at.

Step 2 — Documentation consistency (medium severity, high impact)

Read in parallel:

• ~/.claude/CLAUDE.md — scan for self-contradictions. Common patterns: specialist count drift ("16" vs "20" in same file), version-number drift, layer-table drift.
• <work folder>/CLAUDE.md — scan for stale numbers (specialist count, harness check count, page count, agent-team member count).
• {ann,vi,li,researcher}/SKILL.md under the `SKILLS_DIR` you resolved in Step 1, not a hardcoded path — line counts vs budgets (read the current numbers from SKILL_BUDGETS in tests/run_tests.py, which is the authoritative source; do not trust any figure quoted here, they go stale). Report headroom, not just pass or fail: a skill within 5 lines of its budget is a finding, because the next edit fails the harness on arithmetic rather than on substance. Em-dash counts in body prose (per CLAUDE.md voice rule, which carves out list-item separators and frontmatter in skill files).
• agent-improvements/agent_registry.md — count ### entries. Cross-reference with Vi taxonomy table for completeness. Cross-reference each name with ~/.claude/agents/<name>.md existence.

For each finding, capture: file path, line number where shown, what's wrong, suggested fix from the failure-fix table below.

Step 3 — Overlay and CURATE state (medium severity)

Read in parallel:

• agent-improvements/{ann,vi,li,researcher,community}-overlay.md — file sizes (cap 35KB) and Active-entries count (cap 10). If either breaches: flag for compression CURATE, not just archive-only CURATE. The community-overlay.md (claimed-space feedback log, created 2026-05-06) is monitored for the same caps.
• agent-improvements/coordination-log.md — count entries with STATUS: OPEN.
• agent-improvements/_pending-ingest.md — count rows with Status: PENDING. Surface to Ane for action.
• agent-improvements/PROPOSED-*.md — Status: field on each. Flag any AWAITING APPROVAL older than 7 days.

Step 4 — Hygiene (low severity, visible clutter)

Check:

• agent-improvements/_temp_*.md — any files older than 7 days are stale candidates. Use ls -la to get dates.
• agent-improvements/proposed-agents/*.md — for each .md (excluding README), check whether ~/.claude/agents/<same-name>.md exists. If yes, the staging copy should have been removed when deployed. Use diff -q to confirm divergence.
• agent-improvements/SESSION-STATE-*.md — read each; check for internal contradictions (table cells contradicting bullet points, or progress-status fields disagreeing).
• mel_wiki/wiki/raw/ size — should not be empty (the immutability rule says Li reads but never modifies; if it's empty, ingestion has stopped).

Step 5 — Architectural ceilings (decisions, not bugs)

Read:

• agent-improvements/qa-rejection-log.md — count data rows and trend the verdicts; this is the live QA telemetry signal. An empty table means the improvement loop steers on anecdote: flag it as a risk. qa-disagreement-log.md is historical only, retired as a live counter 2026-07-30 with its Vi/Li elevation watch-trigger withdrawn as unmeasurable; do not count its rows as a watch (the 2026-08-05 audit did, inherited from a stale grade-system copy, and reported a retired ceiling as "monitored").
• agent-improvements/cost-calibration-log.md — count rows with observed actuals vs not observed. If less than 30% have actuals, observability remains weak.