trim

trim

Every byte in an always-on file is paid on every session, forever. This skill measures that cost, removes what is provably dead, and then makes the judgment calls one at a time in front of the person whose rules they are.

Adapted from the Trim skill in LifeOS by Daniel Miessler (https://github.com/danielmiessler/LifeOS), MIT.

Procedure

Copy this checklist and track progress:

- [ ] 1. Measure
- [ ] 2. Make the edit reversible
- [ ] 3. Remove what is provably dead
- [ ] 4. Propose the semantic moves, one at a time
- [ ] 5. Run the safety gate
- [ ] 6. Re-measure and report

1 — Measure. Never start from an impression of which file is too big.

bun scripts/measure-context.ts --root "$PWD"

It resolves the always-on set — ~/.claude/CLAUDE.md, the project CLAUDE.md and AGENTS.md, every @-import they pull in, and the memory index for this project — and reports bytes, an approximate token count, the largest sections, dead pointers and directives duplicated across two always-on files. Show the totals to the user before proposing anything. Without a target size, "smaller" has no end.

2 — Make it reversible. Before the first edit:

• The file is in a git repository — check git status --short on that path. Clean means the repository is the undo. Dirty means say so and ask before touching it; a trim mixed into somebody else's uncommitted work cannot be reverted on its own.
• The file is not in a repository — this is the normal case for ~/.claude/CLAUDE.md. Copy it to <file>.bak-<UTC timestamp> and print the exact cp command that restores it. Do this once, before the first edit, not per move.

3 — Remove what is provably dead. These need no judgment, so they are free. Take them all before proposing anything that costs attention:

• Dead pointers. A rule that points at a file which no longer exists has no reader. Delete the rule, or repair the pointer when the file merely moved — say which, and how you checked.
• Duplicated directives. A line loaded by two always-on files is paid twice. Keep the copy in the narrower scope, delete the other, and say which one survived.
• Rules about things that no longer exist. A tool, a path, a service, a workflow that is gone. Check before claiming it: ls, the repository, the deployment ledger. An unverified "this looks obsolete" is not a deterministic removal, it is a semantic one, and it belongs in step 4.