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.
1---2name: comms3description: 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", «напиши <имя>», «ответь клиенту», «отпиши в тикет», «черновик письма».4---56# Writing to people78## Draft to me first, always910Never 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.1112Give the text ready to paste: no quote marks, no blockquote symbols, no "here's a draft:" wrapper, no markdown a chat will not render.1314## Take no blame and hint at no defects1516Cut 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.1718Explain what happened, say what is known, stop. No promises about when, no speculation about cause, no offering work nobody asked for.1920If the honest answer is "we are looking into it" — write that, not a story.2122## Not directive, not pushy2324Rewrite 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.2526## Match the reader2728- **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.29- **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.30- **Chat**: lowercase, short, conversational, the way I already write in that channel — read my recent messages there before drafting.31- **Users of my plugins**: helpful, no hinting they did something wrong, no fishing for what went wrong on their side.3233## One question, not a pile of comments3435If 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.3637A question that a busy person can answer in one line beats five that require reading the thread.3839## Reports and summaries4041Tell 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.
mikhin