elim
Skill2 starsChanged 43 days agoMITView on GitHub
Explain the last message like I am a manager. Plain English, no code names and no shop talk.
In this repository16 other files it gives its agents.
- audit-backendSkill
- audit-frontendSkill
- audit-securitySkill
- ralph-loopSkill
- ralph-planSkill
- againSkill
- huhSkill
- ughSkill
- code-audit-jevSkill
- jev-email-analysisSkill
- prompt-injection-evalSkill
- resume-mirror-evalSkill
- run-jevSkill
- traffic-triage-evalSkill
- built-withSkill
- github-remediate-vulnsSkill
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 26
When you are not sure, keep the word the source used.
- Distinctive: line 31
Use short common words. Long words cost the reader more than long sentences do.
- Distinctive: line 32
Use, not utilize. Start, not initiate.
- Distinctive: line 41
Keep every number the source gave and say what it means.
- Distinctive: line 43
If the source asks for a decision, put it as a business choice.
- Distinctive: line 46
Keep the hedge. If the source said no problems were found, do not promote that to correct.
- Distinctive: line 49
Add nothing. If the source never said why it matters, say what happened and stop.
- Distinctive: line 58
If the message was already plain, say so and leave it alone.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Say your last message again for a manager. Someone senior who does not work in the tools: a director, an executive, a non-technical lead. They are smart. They just do not know the words.
Lead with the answer in one sentence: what happened, or what you need from them.
Drop the names. No file paths, function or variable names, commands, error text, tool or library names, version numbers, ticket numbers. Say what the thing does instead of what it is called.
Then judge every word that is left by one test: would this reader say it themselves? A manager says the website, the app, billing, staging, production, release, outage. A manager does not say backfill, cut over, canary, smoke test, drain, ramp, repoint, or green for passing. Those are examples of the two kinds, not a list to check against. Run the test on every word, including ones nobody has named here.
When you are not sure, keep the word the source used. A vaguer word is not a plainer one. A reader can ask about a term they do not know, but they cannot ask for a detail you deleted. Spell out any acronym they would not use, and prefer the full word to the shop short form: production, not prod.
Use short common words. Long words cost the reader more than long sentences do. Use, not utilize. Start, not initiate. Wrong, not incorrect. Left out, not omitted.
Split done from not done. Say what you already handled in a line or two. Spend the rest on what still needs them.
Then, only if the source says it: what works now, what is broken, what it costs, what happens if nobody acts.
Keep every number the source gave and say what it means.
If the source asks for a decision, put it as a business choice. Two options at most, what each one costs, and your pick.
Keep the hedge. If the source said no problems were found, do not promote that to correct. If the source said something is unproven, it stays unproven.
Add nothing. If the source never said why it matters, say what happened and stop. Never invent risk, money, urgency, severity, or a recommendation.
Short sentences, under twelve words where you can. One idea each. No tables, no code blocks, no headings.
Plainness is the goal, not brevity. Cut what a manager cannot use, keep every word they need, and never pad to fill space.
If the message was already plain, say so and leave it alone.
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
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.

