/guijios-reply

name: guijios-reply
description: >
  Cross-platform reply and comment drafting. Auto-routes to platform-specific rules
  (GitHub/Reddit/Twitter/HN/general). Use when the user mentions: reply to issue,
  reply to PR, github reply, draft a reply, write a comment, comment on issue,
  reddit reply, analyze comments, twitter reply, help me respond.

Cross-platform reply/comment drafting. Auto-routes to the correct platform ruleset based on input.

Routing

| Input | Mode | |-------|------| | GitHub Issue/PR number or link | GitHub mode | | Reddit comment text/screenshot | Reddit mode | | Twitter/X content | Twitter mode | | Other platforms or unspecified | General mode (applies universal principles) |

---

Part 1: Universal Principles (Shared Across All Platforms)

Context Assessment (Judge Before Writing)

| Context | Definition | Core Strategy | |---------|-----------|---------------| | **Your turf** | You are the maintainer / OP / author | Deliver information | | **Someone else's turf** | You are a visitor | Contribute experience first, then ask; no self-promotion | | **Cold DM** | Zero prior relationship, you're reaching out | Reference their specific content to build trust |

Rules for Someone Else's Turf

• **Contribute before asking.** Share a similar problem or experience, then naturally lead into one question
• **One question per comment.** Multiple questions = interrogation vibes
• **Every question must have clear information value.** Before posting, articulate "what will this answer tell me?" If you can't, rewrite
• **Your profile is your introduction.** No need to introduce yourself in the body text
• **Don't reveal research intent.** Look like "someone who ran into the same problem," not "competing founder mining for intel"

Rules for Cold DMs

• **Quote their specific words.** Vague references = low reply rate
• **Make it clear you're not selling anything**
• **Give them an easy out.** "No worries if not"
• **Async over calls.** Higher reply rate

Pre-Send Checklist (5 Steps, Required Every Time)

1. **Intent check:** What information does this comment aim to get? What's the concrete use for us? If you can't answer, rewrite 2. **Fact check:** Verify your own project's technical claims against code; verify quotes against originals 3. **Smell check:** Re-read from the recipient's perspective. Does it read like competitive research? Like AI? Or like someone who naturally ran into the same problem? 4. **Style check:** Run through the blocklist 5. **Compression check:** Can you cut an entire paragraph? Can bullets collapse into prose? Did you restate something the other person already said clearly? When in doubt, cut

Cross-Platform Blocklist

• Em dashes in body text
• "Thanks for your contribution" / "Thank you for reporting this"
• "Great catch" / "Great question" / "Appreciate the detailed report"
• "the clearest/strongest/best [X] I've seen" (superlative praise)
• "Feel free to..." / "Don't hesitate to..."
• "Happy to discuss further" / "Let me know if you have questions"
• "I'd love to hear your thoughts"
• "I maintain [project name]" as an opener
• @-mentioning multiple people with separate questions in one comment
• "Curious about..." / "I'd be interested to know..." (reveals research intent)
• Any three-part structure. Not just Thank → Answer → Invite, but also: Confirm problem → Restate solution → List asks, Acknowledge → Explain → Close. More than 2 paragraphs in a single comment is a red flag
• Using a bullet list for 2-3 short asks. Real people inline them into a sentence of prose. Bullets only make sense for 4+ independent complex items
• Restating what the other person already said clearly. If they wrote out a solution, don't come back with "you're right, the approach is..." Just move to the next step

Cross-Platform Dos

• High information density, no filler sentences
• Have an opinion, don't just describe
• Lead with the conclusion, no preamble
• Use contractions (doesn't, won't, btw, iirc, tbh)
• Keep it short. Default is 1-2 sentences. Past 3 sentences, ask yourself: can I cut a paragraph? Past 2 bullets, ask yourself: can these collapse into prose? Only open up the length budget for deep technical discussion

Strategic Principles

1. **Silence is a weapon** -- not replying ≠ losing 2. **Technical credibility is the only moat** 3. **Convert > Defend** -- spend energy on people who might use your product 4. **Don't explain motives** -- only answer people who genuinely want to know 5. **Don't engage in legal discussions**

---

Part 2: GitHub Mode

Input

• Issue/PR number (e.g. #72) or link
• Pasted comment content
• Screenshot

After receiving a number/link, use `gh` commands to read the Issue/PR body and existing comments to understand the full context.

Workflow

Step 1: Understand Context

• Issue or PR? Open / Closed / Merged?
• Is the author an external user or yourself?
• How many comments exist? What does the last one say?
• What is the other person's core ask?
• **Assess context: your repo or external repo?**

Step 2: Draft Reply

Output sendable text. Put strategic reasoning after the reply.

GitHub Tone Guide

• **Like coworkers chatting on Slack**
• Drop subjects. "Fixed in #77." not "This has been fixed in #77."
• Answer technical questions with technical language, don't dumb it down

Tone Examples

**Closing an Issue:** `Fixed in #77.`

**Confirming a Bug:** `Yeah this is real. Will add a per-agent semaphore.`

**Feature Request:** `Makes sense. Tracking in #XX.`

**Asking About Use Case:** `What's the use case driving this?`

**Code Review:** `Left a few comments. Main thing is [specific issue].`

**Merging a PR:** `LGTM, merged.`

GitHub Context Strategies

Your Repo

| Scenario | Strategy | |----------|----------| | External bug report | Confirm the issue + fix plan/status, optionally ask about use case | | External PR (good quality) | Substantive technical feedback, can ask about us