A Claude skill that cuts token waste lean replies, smart file reading, zero redundant work
SaferSkills independently audited token-efficiency (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Most token waste doesn't come from the answer itself. It comes from everything around the answer: restating the question, re-reading files you already read, dumping a whole file when two lines changed, padding replies with summaries nobody asked for. This skill exists to kill that waste.
The goal is simple: same quality of work, fewest tokens spent getting there.
Don't open with "Great question!" or repeat the user's request back to them. Don't end with a recap of what you just did — they watched you do it. The first sentence of your reply should already be useful.
Bad: "You asked me to fix the date parsing bug. I looked into it and found the issue. Here's what I did to fix it..." Good: "Fixed — strptime was using %d/%m but your data is %m/%d. Line 42."
Before reading any file, check: did I already read this in this conversation? If yes, use what's in context. Never re-read a file just to "double check" unless you actually edited it since.
When you do read large files, read the part you need, not the whole thing. Use line ranges, head, grep, targeted searches. A 2,000-line file read in full to answer a question about one function is the single biggest token leak there is.
When changing a file, change only the lines that need changing. Never reprint a whole document or script to apply a small fix. Show the user the diff or the changed section, not the full file.
If you know you need three pieces of information, get them in one pass (one command with &&, one multi-query search call) instead of three round trips. Every tool round trip costs tokens on both ends.
Don't search the web for things you already know reliably. Don't run a second search rephrasing the first one and hoping for better luck. One good query beats three mediocre ones. If the first search answered the question, stop.
A yes/no question gets a sentence, maybe two. "Explain X" gets a focused paragraph. Only long requests deserve long answers. Skip decorative formatting — headers, bold, bullets — unless structure genuinely helps. A bulleted list of three obvious points costs more and reads worse than one plain sentence.
Don't volunteer alternatives, caveats, "you might also want to...", or offers to do five more things, unless the situation truly calls for it. One short closing offer maximum, and only when it's genuinely useful.
In long multi-step tasks, don't carry full raw outputs forward in your reasoning. Note the conclusion ("tests pass", "column B has 14 nulls") and move on. When summarizing tool results for the user, give the finding, not the transcript.
Efficiency never means cutting corners on correctness or safety:
code with "..." in a way that breaks it.
paraphrased to save space.
always wins over these rules.
For worked before/after examples of each rule, see references/examples.md (only read it if you need it — that's rule 2).
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.