gh-triage-ru

name	gh-triage-ru
description	GitHub issue/PR triage via ru and gh. Use when processing issues, closing PRs (no-contributions policy), or bulk triage. Independent verification required.

gh-triage-ru — GitHub Issues/PRs with ru

Core Insight: User reports are hints, not facts. Every bug report, feature request, and PR must be independently verified. Never trust suggested fixes—implement your own solution based on your own analysis.

The Full Contribution Policy

This is the official policy disclosed to users in READMEs:

About Contributions: Please don't take this the wrong way, but I do not accept outside contributions for any of my projects. I simply don't have the mental bandwidth to review anything, and it's my name on the thing, so I'm responsible for any problems it causes; thus, the risk-reward is highly asymmetric from my perspective. I'd also have to worry about other "stakeholders," which seems unwise for tools I mostly make for myself for free. Feel free to submit issues, and even PRs if you want to illustrate a proposed fix, but know I won't merge them directly. Instead, I'll have Claude or Codex review submissions via gh and independently decide whether and how to address them. Bug reports in particular are welcome. Sorry if this offends, but I want to avoid wasted time and hurt feelings. I understand this isn't in sync with the prevailing open-source ethos that seeks community contributions, but it's the only way I can move at this velocity and keep my sanity.

Translation for agents: We NEVER merge PRs. Ever. PRs are intel, not contributions. Mine them for ideas, implement yourself, close with explanation.

---

Quick Start

# 1. Health check
ru doctor && gh auth status

# 2. Discover open items (2025+ only)
ru review --dry-run --json 2>/dev/null | \
  jq '[.items[] | select(.created_at >= "2025-01-01")]'

# 3. Review each item
gh issue view NUMBER -R owner/repo
gh pr diff NUMBER -R owner/repo  # THE INTEL for PRs

# 4. Verify independently (NEVER trust user claims)
cd /data/projects/REPO
git log --oneline --since="ISSUE_DATE" | head -20  # Already fixed?
grep -r "relevant_function" src/                    # Find the code

# 5. Take action
gh issue close N -R owner/repo -c "Fixed in abc123"
gh pr close N -R owner/repo -c "Thanks! Implemented independently in abc123"

---

Decision Matrix

Type	Status	Action	Response
Bug, confirmed unfixed	Verified	Fix it	gh issue close N -c "Fixed in SHA"
Bug, already fixed	Verified	Close	gh issue close N -c "Fixed in SHA from DATE"
Bug, can't reproduce	Unknown	Ask	Use REQUEST-INFO.md
Bug, pre-2025	Stale	Close	gh issue close N -c "Closing as stale"
Feature, simple	Fits scope	Implement	gh issue close N -c "Implemented in SHA"
Feature, complex	Needs judgment	SURFACE	Use SURFACE-FORMAT.md
Feature, scope creep	Doesn't fit	Decline	Use DECLINE-TEMPLATES.md
PR, any	N/A	NEVER MERGE	Close + mine for ideas

---

The Independent Verification Protocol

This is non-negotiable. Every claim must be verified.

DO NOT:

• Trust that the bug exists as described
• Trust that the suggested fix is correct
• Trust that reproduction steps work
• Assume the issue is still relevant
• Copy-paste user-provided code fixes

DO:

• Reproduce bugs yourself
• Check commits since issue date
• Read the actual code
• Verify against official docs
• Test empirically
• Write your OWN fix

Verification Questions

Claim Type	How to Verify
"X crashes"	Reproduce the crash yourself
"X doesn't work"	Define "work", test actual behavior
"X should do Y"	Check docs, is this intended?
"X is slow"	Benchmark, compare to baseline
"X has security issue"	Analyze code path, test exploit
"This PR fixes it"	Read diff, understand approach, implement yourself

Verification Commands

cd /data/projects/REPO_NAME

# Check if commits since issue might have fixed it
git log --oneline --since="ISSUE_DATE" | head -20

# Search codebase for relevant code
grep -r "relevant_function" src/

# Read the actual implementation
cat src/relevant_file.rs

# Check current behavior
./target/debug/tool --help

# For API claims, verify against official docs
# (Use WebFetch for official documentation)

Deep dive: VERIFICATION.md

---

PR Handling: Mine, Never Merge

PRs contain intel, not contributions. The workflow:

1. Read the diff — This is THE INTEL
2. Understand their approach — What problem are they solving? How?
3. Write YOUR OWN implementation — Never copy their code
4. Commit — No attribution needed for ideas
5. Close PR with explanation — Be kind, explain policy

# View the diff (THE INTEL)
gh pr diff NUMBER -R owner/repo

# Read their approach
gh pr view NUMBER -R owner/repo --comments

# If idea is good:
# 1. Understand their approach
# 2. Write YOUR OWN implementation
# 3. Commit (no attribution needed for ideas)
# 4. Close PR with explanation

PR Close Template

gh pr close NUMBER -R owner/repo -c "$(cat <<'EOF'
Thanks for the contribution! Per project policy, I don't merge outside PRs, but I reviewed your approach.

[One of:]
- I've implemented a similar fix in abc123
- Noted the idea—may address differently later
- Current behavior is intentional because [reason]

Appreciate you taking the time!
EOF
)"

---

Response Templates

Bug Fixed

gh issue close N -R owner/repo -c "$(cat <<'EOF'
Fixed in abc123.

The issue was [brief explanation]. [Any additional context.]
EOF
)"

Bug Already Fixed

gh issue close N -R owner/repo -c "$(cat <<'EOF'
This was fixed in abc123 (from DATE).

Please update to the latest version. If issue persists after updating, reopen with details.
EOF
)"

Cannot Reproduce

gh issue comment N -R owner/repo -b "$(cat <<'EOF'
I tried to reproduce this but couldn't. Could you provide:

- Exact steps to reproduce
- OS and version
- Full error output
- Tool version (`tool --version`)

Happy to investigate with more details.
EOF
)"

Stale Issue (Pre-2025)

gh issue close N -R owner/repo -c "$(cat <<'EOF'
Closing as stale—the codebase has changed significantly.

If this is still relevant with current versions, please open a new issue with fresh reproduction steps.
EOF
)"

Feature Implemented

gh issue close N -R owner/repo -c "$(cat <<'EOF'
Implemented in abc123.

[Brief description of what was added and how to use it.]
EOF
)"

Feature Declined (Scope Creep)

gh issue close N -R owner/repo -c "$(cat <<'EOF'
Thanks for the suggestion! After consideration, this would add scope I'm trying to avoid.

[Optional: brief explanation or workaround]

Feel free to fork if you need this functionality.
EOF
)"

More templates: DECLINE-TEMPLATES.md | REQUEST-INFO.md

---

Surface Format: When Judgment Required

For complex features, ambiguous issues, or security-related items—surface to user for decision.

When to Surface

Situation	Surface?	Why
Simple bug, clear fix	No	Just fix it
Feature fits, low effort	No	Just do it
Complex feature request	Yes	Scope implications
Interesting PR ideas	Yes	Need approval to integrate
Ambiguous intended behavior	Yes	Could break things
Security-related	Yes	High stakes
Multiple valid approaches	Yes	Design decision
Breaking changes	Yes	User impact

Surface Format

FEATURE REQUEST REQUIRING JUDGMENT: owner/repo#42

**Request:** "[Title from issue]"

**User's Problem:** [What they're trying to accomplish]

**Analysis:**
+ [Benefit 1]
+ [Benefit 2]
- [Drawback 1]
- [Drawback 2]
- Scope Risk: [What this might lead to]

**Implementation Options:**
1. Full implementation: [What it would take]
2. Simplified version: [Reduced scope alternative]
3. Decline: [Polite response]

**My recommendation:** Option [X] because [reasoning]

**If approved:** I'll implement and close with: "[proposed response]"

More formats: SURFACE-FORMAT.md

---

Scope Creep Detection

Signal	Why It's Scope Creep
"Also add X while you're at it"	Bundled unrelated request
"Support format Y too"	Opens floodgate for formats
Requires new dependencies	Maintenance burden
Changes core architecture	Risk outweighs benefit
"Make it configurable"	Complexity for edge cases
"Would be nice if..."	Vague, unbounded request
"What if we also..."	Feature creep in disguise
"Full parity with X"	Massive scope expansion

---

Bulk Processing

# Get all 2025+ issues
gh issue list -R owner/repo --state open --json number,title,createdAt | \
  jq '.[] | select(.createdAt >= "2025-01-01")'

# Count by repo
ru review --dry-run --json 2>/dev/null | \
  jq 'group_by(.repo) | map({repo: .[0].repo, count: length})'

# Process systematically
for num in $(gh issue list -R owner/repo --state open --json number -q '.[].number'); do
  echo "=== Issue #$num ==="
  gh issue view $num -R owner/repo
  # Analyze, verify, act
done

---

Validation

After triage session:

# Verify no 2025+ issues remain unaddressed
ru review --dry-run --json 2>/dev/null | \
  jq '[.items[] | select(.created_at >= "2025-01-01" and .state == "open")] | length'
# Should be 0 (or only surfaced items awaiting judgment)

# Verify commits reference issues
git log --oneline --grep="Closes #" -10
git log --oneline --grep="Fixed #" -10

---

References

Topic	Resource
Request info templates	REQUEST-INFO.md
Decline templates	DECLINE-TEMPLATES.md
Surface formats	SURFACE-FORMAT.md
gh command reference	GH-COMMANDS.md
Verification deep dive	VERIFICATION.md
Real-world examples	REAL-EXAMPLES.md

---

Anti-Patterns

Don't	Why	Do Instead
Merge PRs	Policy violation	Close with explanation
Trust user diagnosis	Often wrong	Verify independently
Close without response	Bad UX	Always explain why
Batch-close stale issues	Loses context	Review each briefly
Implement user's exact code	Could be wrong	Write your own version
Ignore old issues	May contain valid bugs	Triage by date, close if stale
Skip verification	Miss bugs or break things	Always verify empirically
Copy PR code	Violates policy spirit	Understand approach, reimplement