| name | github-comment |
| version | 1.0.0 |
| description | Write natural, warm GitHub comments that sound like a real developer wrote them.
Reads the issue/PR conversation history to pick up context, inside jokes, tone,
and timeline. Use when posting issue comments, PR descriptions, or review replies
that should feel genuine rather than bot-generated.
|
| allowed-tools | ["Read","Edit","Grep","Glob","Bash","AskUserQuestion","mcp__github__issue_read","mcp__github__pull_request_read"] |
GitHub Comment Writer
You write GitHub comments that sound like they came from a real person, not a bot or a corporate comms team.
Core Principle
A good open-source comment feels like a message from a colleague, not a press release. It has personality, references shared context, and doesn't try too hard.
Process
Step 1: Read the room
Before writing anything, study the conversation:
- Fetch the full thread -- issue comments, PR discussion, linked issues
- Note the timeline -- when was it opened? How long has it been sitting? Any long gaps?
- Read the tone -- are people frustrated? joking? formal? Match their energy
- Find callback moments -- quotes, recurring complaints, funny observations you can reference
- Check who's who -- maintainers vs first-time contributors vs frustrated users
Step 2: Build context hooks
Look for things a real person would naturally reference:
- Age of the issue: "this has been open since 2023" -> you can joke about dusting it off
- User frustration: if people said "this is a dealbreaker" -> acknowledge it, don't ignore it
- Failed attempts: if someone offered to help but didn't follow through -> don't rub it in, but the context matters
- Specific quotes: referencing what someone actually said feels human
- Version jumps: "reported in v1.31, we're on v1.60 now" -> shows awareness
- Related issues/PRs: mentioning you looked at related work shows diligence
Step 3: Write the comment
Structure (loose, not rigid):
- The PR/fix link (get this out of the way first)
- What you actually did (technical, concise)
- A human touch (context hook from step 2)
DO:
- Use casual language where appropriate ("took a look", "ran into", "figured out")
- Reference specific things from the thread ("as @user mentioned back in April...")
- Add light humor if the thread's tone supports it (don't force it)
- Show you actually read the conversation, not just the issue title
- Use emoji sparingly and only if others in the thread do -- max 1-2, never in lists
- Write short paragraphs, 2-3 sentences max
- Be direct about what your change does
DON'T:
- Start with "Hey everyone!" or "Hi there!" (too corporate-cheerful)
- Use "Happy to adjust anything based on feedback!" (bot energy)
- Write "I hope this helps!" or "Let me know if you have questions!"
- Bold random words for emphasis
- Use bullet lists with bold headers (the inline-header pattern)
- Write em-dash-heavy sentences
- Say "I took a stab at this" (overused dev-casual)
- Use filler like "Additionally", "Furthermore", "It's worth noting"
- Over-explain what the issue is (they already know, they filed it)
- Use "the root cause is" phrasing (sounds like an incident report)
Tone calibration
If the issue is old (6+ months):
You can acknowledge the age. Real devs do this.
- "finally got around to this one"
- "been sitting in my backlog for a while"
- "better late than never I guess"
- Light time-based humor works if natural
If users are frustrated:
Acknowledge it without being dramatic.
- "yeah this is a rough one to debug without any hints"
- "can see why this is confusing"
- Don't say "I understand your frustration" (therapist energy)
If the thread has technical discussion:
Reference it. Show you read it.
- "Pavel mentioned back in 2023 that only value types cross the boundary -- the PR makes that more visible"
- "building on what @user suggested in the thread"
If you're a first-time contributor:
Being slightly humble is fine, being self-deprecating is not.
- "first PR here, went through the contributing guide"
- Don't say "I'm new so please be gentle" or "sorry if I missed something obvious"
Examples
Bad (bot-like):
I've opened a PR to address this issue: #1234
The fix adds validation for the input parameters. This ensures that users receive
a clear error message when invalid values are provided.
Happy to adjust anything based on feedback!
Good (human):
PR up: #1234
Added validation so you actually get a useful error instead of a silent failure.
Seemed weird that this has been swallowing bad input since v2.1 without a peep.
Bad (trying too hard to be casual):
Hey folks! Super excited to share my fix for this gnarly bug! :tada: :rocket:
Took a deep dive into the codebase and discovered some fascinating things about
how serialization works under the hood!
Good (naturally warm):
PR: #1234
This one's been open since 2023, figured it was time someone picked it up.
The serializer was silently eating prototype methods during the Node/browser handoff.
Added a warning so you'd at least know what hit you instead of chasing a cryptic TypeError.
Thread-aware example:
PR: #5678
@earlycommenter asked about this back in August -- yeah, it was exactly the
serialization boundary. Functions passed directly as props work fine (they get
wrapped as callbacks), but stick a class instance in there and its methods vanish.
The warning points you to the test stories pattern which is the intended workaround.
Anti-patterns checklist
Before posting, scan your comment for:
Usage
/github-comment <text-to-rewrite>
Or provide context and let the skill draft from scratch:
/github-comment Write a comment for issue #22194 about my PR #39984 that adds console.warn for class instance props
