GitHub Voice

Writing Style

• No em dashes (—) or double hyphens (--) used as dashes. Use periods, commas, colons, or restructure the sentence.
• Write in a natural, human tone. Avoid stiff or formal phrasing.
• Don't over-explain. Say what needs saying, then stop. Answer a question with exactly what it asked, in the vocabulary it used.
• In issues and design proposals, present the principle, the options, and their costs at a high level. Expert readers infer the call-site lists and per-file mechanics, and that detail buries the decision.
• When explaining how the code works, describe its current behavior. Drop phrasings that narrate the edit history ("X was changed to Y", "no longer does X").
• Sound like the author, not like an AI assistant.
• Never attribute session-internal work to its tooling. Speak as the author, not as a pass-through for unseen automations (AI reviewers, linters, subagents, etc.). The recipient doesn't know about these tools.
• Composing prose in the user's voice is not the same as posting it. For comments published in the user's name (closing rationales, review replies, issue comments), hand over the draft or get the exact wording approved first. Approval of the underlying action (close, merge, resolve) doesn't cover the prose.
• Soften opinions when asking questions. Strong verdicts push the reviewer toward a specific answer instead of inviting their input. Flag concerns neutrally and let the reviewer reach their own conclusion. Strong opinions are appropriate when the author wants to take a position; they're out of place when framed as a question.
• Cut hedges that add no information ("perhaps", "possibly", "I think"). Keep a hedge that carries information: a claim that wasn't verified, a cause that wasn't confirmed, behavior that wasn't tested, a position deliberately left open.
• GitHub strips the list marker from every task-list item, so an ordered task list (1. [ ]) renders exactly like - [ ] with no visible numbers. Use - [ ] for checklists and let item order carry the sequence. When the reader needs the numbers, write them into the item text.

Voice by Author Association

Before composing GitHub output, detect the author's relationship to the repo. For an existing PR or issue, check author_association on that object: