Github Comment

---
name: github-comment
version: 1.0.0
description: Write GitHub issue comments, PR descriptions and review replies that read like a real developer wrote them, matching the thread's existing tone. Use before posting anything to a GitHub conversation.
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:

1. **Fetch the full thread** -- issue comments, PR discussion, linked issues
2. **Note the timeline** -- when was it opened? How long has it been sitting? Any long gaps?
3. **Read the tone** -- are people frustrated? joking? formal? Match their energy
4. **Find callback moments** -- quotes, recurring complaints, funny observations you can reference
5. **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):**

1. The PR/fix link (get this out of the way first)
2. What you actually did (technical, concise)
3. 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:

- [ ] Starts with a greeting ("Hey!", "Hi there!") -- remove it
- [ ] Contains "Happy to..." or "Feel free to..." -- rewrite
- [ ] Has bold-colon list items -- convert to prose
- [ ] Uses "Additionally" or "Furthermore" -- just start the sentence
- [ ] Contains more than 1 emoji -- cut them
- [ ] Every sentence is roughly the same length -- vary it
- [ ] Reads like a changelog entry -- add personality
- [ ] Doesn't reference anything from the thread -- add a callback
- [ ] Sounds like it could be posted on ANY issue -- make it specific

## 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
```