# Comms > 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 ", "reply to the client", "post a comment on the ticket", "send it in chat", "draft an answer", «напиши <имя>», «ответь клиенту», «отпиши в тикет», «черновик письма». - Skill: `mikhin/comms` (Agent Skill) - Install (CLI): `npx skillmds@latest add mikhin/comms` - Raw SKILL.md: https://api.skillmd.com/api/skills/mikhin/comms/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: mikhin (https://skillmd.com/u/mikhin) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/mikhin/comms --- # 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.