
Github Triage
Batch-analyze every open GitHub issue and PR in parallel and get permalink-backed read-only reports without changing repo state.
Overview
github-triage is an agent skill most often used in Ship (also Operate and Grow) that runs read-only parallel analysis of open GitHub issues and PRs and writes evidence-backed reports with zero GitHub mutations.
Install
npx skills add https://github.com/code-yeongyu/oh-my-opencode --skill github-triageWhat is this skill?
- Strict 1 issue/PR = 1 background quick subagent with full parallel execution
- Absolute zero-action policy: no comments, merges, closes, labels, or mutating gh API calls
- Every claim must cite a GitHub permalink as proof in per-item markdown under /tmp/{datetime}/
- Orchestrator uses task_create tracking; triggers include triage, triage issues, triage PRs, github triage
- 1 issue/PR = 1 background quick subagent with zero GitHub mutations
Adoption & trust: 1.1k installs on skills.sh; 61.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your issue and PR queue is too large to scan manually, but you cannot trust an agent that might comment, merge, or close items.
Who is it for?
Maintainers who want a fast, auditable inbox snapshot using gh and local codebase reads only.
Skip if: Anyone who needs auto-labeling, auto-merge, bot replies, or any write action on GitHub.
When should I use this skill?
User says triage, triage issues, triage PRs, or github triage; need read-only analysis of all open issues and PRs with reports only.
What do I get? / Deliverables
You receive parallel markdown reports per item with permalink proof in /tmp, with no changes made on GitHub.
- /tmp/{datetime}/issue-{N}.md reports
- /tmp/{datetime}/pr-{N}.md reports
- task_create tracking per item
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Ship is the canonical shelf because triage supports pre-merge review, release readiness, and understanding open work before you ship. Review subphase fits evidence-backed classification of issues and PRs—the output informs human review decisions, not automated merges.
Where it fits
Generate cited summaries for all open PRs before a Friday release cut.
Audit contributor-facing issues to prioritize docs and onboarding fixes.
How it compares
Read-only report generator—not an auto-triage bot or PR merge workflow skill.
Common Questions / FAQ
Who is github-triage for?
Solo builders and indie maintainers who need structured, cited summaries of open issues and PRs without granting the agent permission to act on GitHub.
When should I use github-triage?
Before Ship review or release prep, during Operate support backlog reviews, or when Grow-facing open-source hygiene needs a dated audit trail.
Is github-triage safe to install?
It is designed for read-only GitHub access; still review the Security Audits panel on this page and ensure gh credentials are scoped and subagents cannot run forbidden mutating commands.
SKILL.md
READMESKILL.md - Github Triage
# GitHub Triage - Read-Only Analyzer <role> Read-only GitHub triage orchestrator. Fetch open issues/PRs, classify, spawn 1 background `quick` subagent per item. Each subagent analyzes and writes a report file. ZERO GitHub mutations. </role> ## Architecture **1 ISSUE/PR = 1 `task_create` = 1 `quick` SUBAGENT (background). NO EXCEPTIONS.** | Rule | Value | |------|-------| | Category | `quick` | | Execution | `run_in_background=true` | | Parallelism | ALL items simultaneously | | Tracking | `task_create` per item | | Output | `/tmp/{YYYYMMDD-HHmmss}/issue-{N}.md` or `pr-{N}.md` | --- ## Zero-Action Policy (ABSOLUTE) <zero_action> Subagents MUST NEVER run ANY command that writes or mutates GitHub state. **FORBIDDEN** (non-exhaustive): `gh issue comment`, `gh issue close`, `gh issue edit`, `gh pr comment`, `gh pr merge`, `gh pr review`, `gh pr edit`, `gh api -X POST`, `gh api -X PUT`, `gh api -X PATCH`, `gh api -X DELETE` **ALLOWED**: - `gh issue view`, `gh pr view`, `gh api` (GET only) - read GitHub data - `Grep`, `Read`, `Glob` - read codebase - `Write` - write report files to `/tmp/` ONLY - `git log`, `git show`, `git blame` - read git history (for finding fix commits) **ANY GitHub mutation = CRITICAL violation.** </zero_action> --- ## Evidence Rule (MANDATORY) <evidence> **Every factual claim in a report MUST include a GitHub permalink as proof.** A permalink is a URL pointing to a specific line/range in a specific commit, e.g.: `https://github.com/{owner}/{repo}/blob/{commit_sha}/{path}#L{start}-L{end}` ### How to generate permalinks 1. Find the relevant file and line(s) via Grep/Read. 2. Get the current commit SHA: `git rev-parse HEAD` 3. Construct: `https://github.com/{REPO}/blob/{SHA}/{filepath}#L{line}` (or `#L{start}-L{end}` for ranges) ### Rules - **No permalink = no claim.** If you cannot back a statement with a permalink, state "No evidence found" instead. - Claims without permalinks are explicitly marked `[UNVERIFIED]` and carry zero weight. - Permalinks to `main`/`master`/`dev` branches are NOT acceptable - use commit SHAs only. - For bug analysis: permalink to the problematic code. For fix verification: permalink to the fixing commit diff. </evidence> --- ## Phase 0: Setup ```bash REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner) REPORT_DIR="/tmp/$(date +%Y%m%d-%H%M%S)" mkdir -p "$REPORT_DIR" COMMIT_SHA=$(git rev-parse HEAD) ``` Pass `REPO`, `REPORT_DIR`, and `COMMIT_SHA` to every subagent. --- --- ## Phase 1: Fetch All Open Items (CORRECTED) **IMPORTANT:** `body` and `comments` fields may contain control characters that break jq parsing. Fetch basic metadata first, then fetch full details per-item in subagents. ```bash # Step 1: Fetch basic metadata (without body/comments to avoid JSON parsing issues) ISSUES_LIST=$(gh issue list --repo $REPO --state open --limit 500 \ --json number,title,labels,author,createdAt) ISSUE_COUNT=$(echo "$ISSUES_LIST" | jq length) # Paginate if needed if [ "$ISSUE_COUNT" -eq 500 ]; then LAST_DATE=$(echo "$ISSUES_LIST" | jq -r '.[-1].createdAt') while true; do PAGE=$(gh issue list --repo $REPO --state open --limit 500 \ --search "created:<$LAST_DATE" \ --json number,title,labels,author,createdAt) PAGE_COUNT=$(echo "$PAGE" | jq length) [ "$PAGE_COUNT" -eq 0 ] && break ISSUES_LIST=$(echo "$ISSUES_LIST" "$PAGE" | jq -s '.[0] + .[1] | unique_by(.number)') ISSUE_COUNT=$(echo "$ISSUES_LIST" | jq length) [ "$PAGE_COUNT" -lt 500 ] && break LAST_DATE=$(echo "$PAGE" | jq -r '.[-1].createdAt') d