agentleFS
mikhinmikhin/claude-skills/skills/comms/SKILL.md

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

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
  1. Distinctive:

    Never send, post or reply on my behalf without showing me the text.

    line 10
  2. Distinctive:

    If the honest answer is "we are looking into it" — write that, not a story.

    line 20
  3. Distinctive:

    If a thread has accumulated our own noise — questions we answered ourselves, half-thoughts, duplicated asks — delete them and leave a …

    line 35

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.