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; 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. 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. 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. 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: steering , whether a skill that fires actually constrains what the agent does. Read the first party skills under the personal skills skills/ tree plus the {ann,vi,li,researcher} team skills. For each, check three things: Trigger collision. Two model invocable skills whose description trigger phrases overlap without either naming the other as a deferral. Grep the description: frontmatter lines for shared trigger verbs (grill, review, plan, debate, design) and inspect the overlapping pairs by eye. A skill with disable model invocation: true is user invoked only and cannot collide, so exclude it. A collision is resolved when the more specific skill names its lane and routes the neighbours away in its description (see grill mel as the worked example). Steering strength. Does the body give the agent concrete, ordered actions, a numbered workflow, decision rules, an output template, or a "what NOT to do" list? Or does it only name a topic and leave the agent to improvise? A skill that fires but does not constrain behaviour is a steering failure. Flag any skill whose body has no imperative

system-audit