gh-triage-ru
Made by JeffGitHub issue/PR triage via ru and gh. Use when processing issues, closing PRs (no-contributions policy), or bulk triage. Independent verification required.
Works With
Quality and Utility come from canonical skill metadata. Community ratings appear separately as stars when subscriber reviews exist.
Subscribe to download
Public previews are available, but downloads, CLI sync, and premium content require an active subscription.
Sign In to Subscribe- Full skill content with deterministic versioning
- CLI sync + local search index
- Access to Jeffrey’s premium library
Save to your account
Saved skills live in your cloud list. Run jsm sync on each machine to pull them locally.
What's New with this Skill
1Updates, enhancements, and release notes for this skill.
New: GitHub Triage with ru, independent verification under a no-contributions policy
User reports are hints, not facts. Every bug report, feature request, and PR has to be independently verified: never trust the suggested fix; always implement your own based on your own analysis. ru and gh together are the engine; this skill is the discipline. The contribution policy is explicit and disclosed in every project README.
- Independent verification rule: a bug report is a hint. The fix is implemented from the agent's own reading of the code, not from the reporter's diff. Suggested patches are reference material
- The policy is disclosed up front: outside contributions are not merged directly because the maintainer carries the risk-reward asymmetry alone. PRs are useful illustration, not source
- Multi-repo triage via ru: ru review --dry-run --json enumerates open items across every project; the agent works through them systematically
- PR-close template: thank the contributor, state the policy, name the outcome (implemented independently, noted for later, or intentional behavior). Reusable across repos
- Verification before any fix: reproduce the report yourself, check commits since the issue date for an existing fix, read the actual code. The reporter may be wrong; verify
- Decision matrix per item type: fix, close as already fixed, request info, close pre-2025 as stale, implement, decline scope creep, or surface complex features for a human decision
The contribution policy is explicit and disclosed in every project README: outside contributions are not merged directly. PRs are useful as illustration of a proposed fix, but the actual fix is implemented independently after review. The reason is risk management: the maintainer's name is on the project, so the maintainer is responsible for any problems a merged change causes, and the risk-reward is highly asymmetric.