Run a quality, sanity and efficiency audit of Ane's MEL/SRHR system (Ann/Vi/Li/Researcher team, wiki, harness, three-repo architecture): surfaces drift, inconsistencies, hygiene issues and architectural ceilings, categorised by severity, as a Tier 1 working brief with sequencing. Does NOT auto-execu

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; report the count it prints, never a remembered one) 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. Compare check NAMES, not totals, and simulate the cloud before diagnosing. Run the harness with HOME , USERPROFILE and PERSONAL SKILLS CLONE pointed at an empty folder and CLAUDE CODE REMOTE=true , collect Suite.results names from both runs, and diff the sets. On 2026 10 07 the 417 vs 358 gap was mostly duplicate names (the per agent checks run once per agents dir locally), and only 13 checks were truly absent remotely. The same simulation reproduced a cloud red that the last fix had not touched. Ignore git identity failures in the simulation: they come from the empty home folder. 3. 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. Compare with diff q strip trailing cr , not cmp : on Windows the installed root holds CRLF copies of LF sources, and a byte compare reported 21 false drifts on 2026 10 07. 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 — read it as a case register, not a rate meter (its header withdrew rate trending on 2026 09 09; rates wait for 20+ trend eligible rows). Only Ann/Vi orchestrated runs write it, via /wrap up check 4b. So before calling a quiet log a telemetry gap, count orchestrated runs in cost calibration log.md over the same window: no runs means an empty log is correct, and the finding is a usage observation, not a defect (2026 10 07: zero orchestrations in 140 rows since the last entry). 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. claude.ai mirror size — the mirror is now two files, mel framework reference.md (core: standing rules, quick reference table, lenses, ECA calibration) plus mel framework appendix.md (numbered framework entries), split 2026 07 30 at 194KB. Do not re raise a combined size threshold. The threshold moved three times (117KB baseline 2026 04 28, 174.7KB 2026 05 10, 200KB) and each raise bought about a week, because size was never the cost: the cost is that claude.ai has no file API, so any edit forces a manual re paste of everything in the edited file. The split addresses that directly, since a standing rule edit now re pastes 30KB rather than 194KB. The size question is no longer yours to judge: /test enforces it on every pass via claude ai:framework core ≤ 50KB , which fails when framework entries drift back out of the appendix, and via claude ai:framework mirror build stamp current in both halves , which fails when the two halves fall out of step. A judgement check here only fired when Ane invoked the audit; the harness fires always. What remains yours: run python scripts/check desktop sync.py and report whether either half is stale against claude.ai, since no script can see what actually landed in project knowledge. Em dash discipline across wiki body prose. Raw grep c "—" over counts: it catches section headers, the title: frontmatter, table rows, list item term — definition separators, and em dashes inside verbatim citation titles, none of which are violations. Filter the structural noise first: grep rnE "—" mel wiki/wiki/ include=" .md" grep vE ":[0 9]+: title: \ \[\[" . Compare the filtered count to the most recent audit drift baseline; trend matters more than absolute count. Inspect survivors by eye, since list definition dashes and citation titles still pass through; apposition where a comma causes genuine ambiguity is allowed. Step 6 — Recent audit drift carry forward If agent improvements/audit drift .md exists: 1. Read the most recent (sort by filename date). 2. For each previously flagged item, check whether it has been resolved. 3. Carry forward unresolved items into your findings, marked [carry forward from audit drift YYYY MM DD] . 4. Verify numeric budgets against their authoritative source before re flagging. When a carried item's finding cites a numeric budget (a line cap, file size cap, token cap), locate the cap's authoritative definition first: SKILL BUDGETS or P1 SECTION TOKEN CAP in tests/run tests.py , or the named config the finding cites. Confirm the metric still exists and still uses that number. If the cap was retired or changed, downgrade the finding to [stale heuristic, not a live breach] , name the real governing metric, and do not re flag the old number. Motivating case: an "index.md 200 lines" breach was carried forward as live although the harness replaced total line caps with a per section token cap ( P1 SECTION TOKEN CAP ) on 2026 04 30. This sub step does not re implement the harness: /test enforces the budgets; the audit only stops re flagging retired ones. This prevents the same issue from getting re flagged as new each audit and from being silently dropped between audits. Step 7 — Skill trigger and steering integrity (skill quality) Apply the four part skill rubric: trigger, structure, steering, pruning. Three of the four are already covered elsewhere. Trigger quality is checked by skill creator evals; structure by superpowers:writing skills; pruning by Steps 3 to 4 and the harness budgets. This step adds the axis those miss: steerin

system-audit