comms
Skill0 starsChanged 2 months agoMITView on GitHub
How Yuri Mikhin writes to people outside the code — clients, product owners, teammates, plugin users. Draft first, never send; no blame, no hinted defects, no promises; one question instead of a pile of comments; copy-paste ready without quote marks. Triggers — "write to <person>", "reply to the client", "post a comment on the ticket", "send it in chat", "draft an answer", «напиши <имя>», «ответь клиенту», «отпиши в тикет», «черновик письма».
9 other projects use a version of this.
Adopted by
Most recently taken up by
- musterd-io/musterdtheir own version, first seen Nov 1, 2026
- chriswestt/claude-skillstheir own version, first seen Oct 9, 2026
- grandamenium/cortextostheir own version, first seen Oct 9, 2026
- sandraschi/comms-mcptheir own version, first seen Oct 8, 2026
- skyf0xx/gambittheir own version, first seen Sep 30, 2026
- Endika/eskillstheir own version, first seen Sep 16, 2026
Other versions9 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 9
- grandamenium/cortextos★ 106same name
- skyf0xx/gambit★ 29same name
- bouob/sysadmin-skills★ 2same name
- cacardinal/laila★ 1same name
- michaelsvanbeek/personal-agent-skills★ 1same name
- musterd-io/musterd★ 1same name
- sandraschi/comms-mcp★ 1same name
- chriswestt/claude-skills★ 0same name
- Endika/eskills★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 3 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 9 edited versions we read keep these.
3
Distinctive
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 10
Never send, post or reply on my behalf without showing me the text.
- Distinctive: line 20
If the honest answer is "we are looking into it" — write that, not a story.
- Distinctive: line 35
If a thread has accumulated our own noise — questions we answered ourselves, half-thoughts, duplicated asks — delete them and leave a …
“Common” is measured: kept by at least 6 in 10 of the 9 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.
Files
Writing to people
Draft to me first, always
Never send, post or reply on my behalf without showing me the text. This holds for chat, tickets, PR comments, email and support answers alike. I will edit before it goes out — that is the point.
Give the text ready to paste: no quote marks, no blockquote symbols, no "here's a draft:" wrapper, no markdown a chat will not render.
Take no blame and hint at no defects
Cut every "my fault", "sorry about that", "we may have missed", "we'll clean it all up". They are not humility, they are commitments and admissions written for me by someone else.
Explain what happened, say what is known, stop. No promises about when, no speculation about cause, no offering work nobody asked for.
If the honest answer is "we are looking into it" — write that, not a story.
Not directive, not pushy
Rewrite anything that reads as an instruction to the reader or as a claim on their decision. Softer framing, same content. This is a tone I check specifically and send back often.
Match the reader
- Non-technical reader (client, founder, product owner): short, plain, outcome-first. No internals, no file names, no reasoning chains, no per-feature detail unless asked.
- Teammates in other repos: describe required behaviour from our side of the contract. Never size their work, never prescribe their implementation, never quote their internals back at them.
- Chat: lowercase, short, conversational, the way I already write in that channel — read my recent messages there before drafting.
- Users of my plugins: helpful, no hinting they did something wrong, no fishing for what went wrong on their side.
One question, not a pile of comments
If a thread has accumulated our own noise — questions we answered ourselves, half-thoughts, duplicated asks — delete them and leave a single clear question: which approach, and why that one.
A question that a busy person can answer in one line beats five that require reading the thread.
Reports and summaries
Tell what shipped and what is next. Skip the narrative of how it was hard. If something did not get done, say it in one line without a defence.
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.

