agentleFS
Sanexxxx777Sanexxxx777/curated-claude-code/skills/system-health/SKILL.md

system-health

Skill16 starsChanged 5 months agoMITView on GitHub

Preventive hygiene audit of your own Claude Code configuration — memory files, project context (CLAUDE.md), rules, permissions, skills — a deterministic scan of sizes / broken links / stale entries / excessive permissions / junk + interpretation + targeted fixes by agreement. Keeps the setup from rotting before it breaks. Triggers — "check the system", "system health", "workflow hygiene", "what to clean up", "audit memory", "optimize the system".

6 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

3 rules. 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 6 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    After a large session with heavy writes to memory.

    line 13
  2. Distinctive:

    When a built-in hook warns "memory index over limit" (that's the signal it's time).

    line 14
  3. Very specific:

    Read the report. Focus on ⚠️WARN lines.

    line 29

“Common” is measured: kept by at least 6 in 10 of the 6 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

/system-health — Claude Code config hygiene

Keeps the setup "in an optimization flow": a cheap regular measurement catches degradation (bloated memory/context files, broken links, stale entries, excessive permissions, junk) BEFORE it breaks. Like a server health check, but for your Claude Code configuration rather than servers.

When to use

  • On command or the trigger phrases above.
  • Once a week (can be scheduled).
  • After a large session with heavy writes to memory.
  • When a built-in hook warns "memory index over limit" (that's the signal it's time).

Process

Step 1 — deterministic measurement (0 LLM tokens)

A read-only shell pass that changes nothing and emits metrics with ✓OK / ⚠️WARN flags. Measure:

  • Size of the memory index and each topic file vs the model's read limit.
  • Broken [[wiki-links]] / pointers in the active index (a link to a non-existent file is a distractor).
  • Stale "next-session" / TODO carryovers that are actually finished.
  • Orphan files (referenced by no index — invisible to recall, dead weight).
  • Project context file size vs target.
  • Excessive permission entries (specific grants subsumed by a wildcard).
  • .bak/junk files lying around.

Step 2 — interpretation (LLM)

Read the report. Focus on ⚠️WARN lines. Translate each into a concrete diagnosis: what grew/went stale and why it hurts (recall / tokens / security).

Step 3 — targeted fixes BY AGREEMENT

Propose minimal surgical fixes per WARN. Don't act silently (except pure junk). ROI order:

  • broken links in the active index (CRITICAL) → fix/remove immediately (distractors hurt recall).
  • index over target → compress reactively: longest lines first; then move on-demand references out of the "active" section into an on-demand index; finished/dormant → an archive file. Don't cut live facts for a metric.
  • stale "next-session" carryovers → read status, move finished/dormant to archive.
  • orphan files (no pointer in any index) → either wire a pointer into the right index, or archive/delete (user decides). A file with no pointer is invisible to recall.
  • consolidation candidates (a topic spread across many files) → read the group, distinguish DUPLICATES (one fact in N files → merge into one, the rest a link) from FACETS (different triggers → leave alone). Only merge real duplicates, by agreement.
  • project context file over target → move dated patch-history into topic memory, keep state + ⚠️ invariants + pointers.
  • excessive permissions → remove specific grants subsumed by a wildcard, keeping MCP/Skill/deny entries.
  • .bak junk → move to a backups dir (pure junk — fine without asking).

Discipline (the "change accounting" rule)

Back up BEFORE any mutation (snapshot memory + rules to a backups dir) → surgical edit → verify by checking (size + a diff of preserved entries/invariants against the backup, not on faith) → record in one place.

Anti-actions

  • ❌ Don't squeeze to a target blindly, losing facts — the read limit matters more than a cosmetic target; if the index loads fully, further squeezing is optional.
  • ❌ Don't mass-merge topic files — "many files on a topic" ≠ duplicates; they're facets with different triggers, merging loses recall.
  • ❌ Don't delete skills/files without agreement — they're the user's data/tools; show the finding, the user decides.
  • ❌ Don't touch passwords/credentials in memory silently — move to a secrets store only on command.
  • ❌ Don't measure size in bytes — the built-in memory hook measures in Unicode CHARACTERS (non-Latin scripts can be 2 bytes/char).

Principle

Hygiene is preventive and cheap. A weekly deterministic scan is a few seconds; the LLM only interprets the WARN lines and proposes surgical, reversible fixes by agreement.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.