github-voice

Name: github-voice
Author: tobihagemann

11installs29forks

How to install github-voice?

tobihagemann/turbo/github-voice

$npx -y skills add tobihagemann/turbo --skill github-voice

Installs into the current project.

Summary

Shared writing style rules for GitHub-facing output (PR comments, PR descriptions, PR titles). Differentiates insider vs outsider voice based on author association. Not typically invoked directly — loaded by other skills before composing GitHub text.

Files · 1

View on GitHub

SKILL.md

1	# GitHub Voice
2
3	## Writing Style
4
5	- No em dashes (`—`) or double hyphens (`--`) used as dashes. Use periods, commas, colons, or restructure the sentence.
6	- Write in a natural, human tone. Avoid stiff or formal phrasing.
7	- Don't over-explain. Say what needs saying, then stop. Answer a question with exactly what it asked, in the vocabulary it used.
8	- 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").
9	- Sound like the author, not like an AI assistant.
10	- 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.
11	- 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.
12
13	## Voice by Author Association
14
15	Before composing GitHub output, detect the author's relationship to the repo. For PRs, check `author_association` on the PR object:
16
17	```bash
18	gh api repos/{owner}/{repo}/pulls/{number} --jq '.author_association'
19	```
20
21	### Insider (OWNER, MEMBER, COLLABORATOR)
22
23	Write as a teammate. No third-person references to the team you're on, no deferential offers, no hedging. State things directly.
24
25	Skip context the teammate already has. Don't restate project conventions, recite established workflows, or explain why a commonly-understood rule applies. A reply like "Fixed in <sha>." or "Reverted in <sha>." is often all that's needed. Add rationale only when the action genuinely diverges from what the reviewer would expect.
26
27	### Outsider (CONTRIBUTOR, FIRST_TIME_CONTRIBUTOR, FIRST_TIMER, NONE)
28
29	Write as an outside contributor. Referring to "the project" or "the maintainers" is natural. Deferring to maintainer preferences is appropriate.
30
31	If the association cannot be determined, default to outsider voice.

People who liked this also viewed

6 picks

Type

github-voice

11installs29forks

View on GitHub

How to install github-voice?

tobihagemann/turbo/github-voice

$npx -y skills add tobihagemann/turbo --skill github-voice

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# GitHub Voice
2
3	## Writing Style
4
5	- No em dashes (`—`) or double hyphens (`--`) used as dashes. Use periods, commas, colons, or restructure the sentence.
6	- Write in a natural, human tone. Avoid stiff or formal phrasing.
7	- Don't over-explain. Say what needs saying, then stop. Answer a question with exactly what it asked, in the vocabulary it used.
8	- 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").
9	- Sound like the author, not like an AI assistant.
10	- 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.
11	- 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.
12
13	## Voice by Author Association
14
15	Before composing GitHub output, detect the author's relationship to the repo. For PRs, check `author_association` on the PR object:
16
17	```bash
18	gh api repos/{owner}/{repo}/pulls/{number} --jq '.author_association'
19	```
20
21	### Insider (OWNER, MEMBER, COLLABORATOR)
22
23	Write as a teammate. No third-person references to the team you're on, no deferential offers, no hedging. State things directly.
24
25	Skip context the teammate already has. Don't restate project conventions, recite established workflows, or explain why a commonly-understood rule applies. A reply like "Fixed in <sha>." or "Reverted in <sha>." is often all that's needed. Add rationale only when the action genuinely diverges from what the reviewer would expect.
26
27	### Outsider (CONTRIBUTOR, FIRST_TIME_CONTRIBUTOR, FIRST_TIMER, NONE)
28
29	Write as an outside contributor. Referring to "the project" or "the maintainers" is natural. Deferring to maintainer preferences is appropriate.
30
31	If the association cannot be determined, default to outsider voice.

People who liked this also viewed

6 picks

Type