vulgarize
Skill2 starsChanged 3 months agoMITView on GitHub
Turn the technical changes in the working tree into a short, casual, jargon-free message you can send straight to the client (en/fr)
In this repository12 other files it gives its agents.
- battle-testSkill
- choicesSkill
- commitSkill
- frontend-verifySkill
- init-agentsSkill
- loopableSkill
- loopitSkill
- review-deepSkill
- reviewSkill
- security-auditSkill
- sessionsSkill
- thermo-nuclear-code-quality-reviewSkill
The file
We split this skill into the rules it gives an agent
2 rules. About 0 are common, 2 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
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 21
Read the changes: look at the git diff (staged + unstaged) and recent commits to understand what actually changed.
- Distinctive: line 31
No technical jargon: no file names, function names, variable names, component names.
≈ “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
Vulgarize — plain-language summary of what changed
Produce a simple message for a non-technical client summarising the code changes. It reads like the developer texting the client directly, not like a release note.
Language: en by default. If $ARGUMENTS starts with fr, write it in French, casual and
informal (tutoiement, no polite formulas). Everything else below is identical.
Sibling skill:
/explain-devproduces a structured WhatsApp update (bold numbered points + a numbered "How to test" section). This one produces a flowing, casual text message. Pick by how formal the recipient is.
Steps
- Read the changes: look at the git diff (staged + unstaged) and recent commits to understand what actually changed.
- Find the "why": for each change, identify the concrete impact for the user or the business.
- Write the message following the rules below.
Writing rules
- First person, speaking directly to them: "I did…", "I added…" — as if you are the developer talking TO the client. Never refer to the client in the third person ("the client asked…"). Say "you mentioned that…" when referencing feedback you got.
- No technical jargon: no file names, function names, variable names, component names. Ever.
- Casual tone: like a WhatsApp/Slack message. No formal salutations, no sign-off boilerplate.
- Explain the WHY, not just the what: e.g. "that way the numbers are frozen at the moment the order is accepted, so they can't drift afterwards".
- Group logically: merge related changes into one flowing explanation rather than listing them file by file.
- If a technical concept is unavoidable, explain it in parentheses: "a snapshot (a frozen copy)".
- No bullet lists, no markdown: plain text, it's a message not a document.
- Short and direct: no "here's what I did" preamble. Get straight to it.
- NEVER use an em dash (—), en dash (–) or arrow (→) — they read as AI-written. Use a comma, a period, parentheses, or the word "to" instead.
Output format
Two paragraphs:
- What changed and why (rules above).
- How to test: one or two plain sentences on how they can check it themselves, no jargon. E.g. "to check it, log in and open any order, the total should stay the same after you refresh".
Output ONLY the message, ready to copy-paste and send. No commentary, no "here's the message:".
Example
Technical changes (input)
- Clear the tax-number field when the company country changes
- Store a snapshot of the buyer and seller details when the order is created
- Refresh those snapshots on payment retry
- Build the invoice from the stored snapshot instead of re-reading live data
Client message (expected output)
ok so here's what I did: when the company country changes I now clear the tax number, since it doesn't apply anymore I save a copy of the buyer and seller details the moment the order is created (a snapshot) and the invoice is now built from that copy instead of re-reading everything later that way the details are frozen at the moment the price is accepted and can't shift afterwards if a payment is retried I refresh that copy once the payment goes through, because the amount is recalculated at that point
to check it, create an order then change the company details afterwards, the invoice should still show the details as they were when the order was placed
$ARGUMENTS
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.

