Talking to humans
Texts that sound like you, explanations you understand
The agent writes two kinds of text for people. Some go out under your name, like a PR comment or a commit message, so they should sound like you. The rest is the agent explaining things: to you in the session, or to a teammate who reads its ticket review or test steps. Those should be clear on the first read, even for someone who reads English as a second language.
One skill for each, and opt-in rules that apply them without being asked.
Texts that go out under your name
We often ask AI to help draft texts that other people will read: chat replies, PR comments, commit messages. The agent is great at drafting them quickly, but not at matching the tone to the context: a chat reply doesn't want the polish of a README, yet everything comes out in the same overly formal, fancy prose that readers recognize as AI at a glance.
use-conversational-language
Tells the agent to write in simple, human language instead of sophisticated AI prose full of — em dashes — and fancy terms. It adapts the voice to the kind of text (a PR comment, a chat reply, a commit message, a code comment) and changes the wording only, never the content.
Other skills use it too: /handover writes your PR description with it, and review skills like /review-code-assistant and /refine-pr-review word the comments and replies they draft for you with it.
Read the SKILL.md → Read more about the conversational voice →
write-realistic-texts
Opt-in rule that applies the skill automatically whenever the agent writes something other people will read as if you wrote it, like a commit message, a PR comment or a chat message, even when writing wasn't the task you gave it. Before it posts a comment, a PR description or a chat message for you, it shows you the exact wording and waits for your go-ahead. Asking it to approve a PR or close a ticket doesn't approve the comment that goes with it.
no-nonsense-comments
Opt-in rule for code comments: the agent writes one only when a future reader with no idea of your session still needs it, like a non-obvious why or an easily missed edge case. No notes about the session ("as discussed", "now also handles X") and no lines that restate the code. The comments it keeps go through the skill above, so they read like a colleague jotted them down.
Explanations written to be understood
The agent explains things to someone who did not see the files and tool output it just read. It tends to write in its own shorthand, so an answer can be correct and still hard to follow.
Not a native English speaker? One more rule makes your agent talk to you in your own language, while everything it writes into the project stays in English. Get the use-my-mothertongue rule →
explain-in-simple-language
Rewords answers, recaps and questions to you, and documents a teammate reads, like a TICKET-REVIEW.md or test steps, so they are understood on the first read. Ask with /explain-in-simple-language, or let the agent use it on its own. It changes the wording only, never the content, without dumbing it down or hiding that an agent wrote it.
Most skills in the toolkit use it when it's installed, from the questions /refine-ticket and /create-implementation-plan ask you to the TICKET-REVIEW.md that /review-ticket writes.
write-simple-explanations
Opt-in rule that applies the skill every time the agent asks you something, explains a decision, how something works or why something failed, gives you a recap, or writes a document a person reads, like a ticket review or test steps. It also kicks in when you ask for an explanation or say you didn't get it. Short status lines ("done, tests pass") and documents written for other agents, like plans, stay as they are, except the questions in them meant for you. Questions and messages to you need no go-ahead.