
Github Issue Triage
Batch-triage open GitHub issues with one background agent per issue and stream results into a final report.
Overview
GitHub Issue Triage is an agent skill most often used in Operate (also Build, Grow) that fetches all issues in a range, analyzes each in its own background task, and streams a consolidated triage report.
Install
npx skills add https://github.com/code-yeongyu/oh-my-opencode --skill github-issue-triageWhat is this skill?
- Enforces 1 issue = 1 background task with run_in_background isolation
- Uses exhaustive pagination to fetch every issue in the chosen time range
- Streams per-issue outcomes immediately via background_output as tasks finish
- Produces a final comprehensive triage report after all tasks complete
- Triggers on phrases like triage issues, analyze issues, and issue report
- 1 issue = exactly 1 background task call
- Exhaustive pagination fetches every issue in the selected window
Adoption & trust: 1.3k installs on skills.sh; 61.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have dozens or hundreds of GitHub issues and no fast way to analyze each one in parallel without losing context or blocking your agent session.
Who is it for?
Solo maintainers or small teams running periodic issue hygiene on active public or private repos with background-task capable agents.
Skip if: One-off comment replies, creating new issues, or environments where parallel background tasks and GitHub API access are disabled.
When should I use this skill?
User says triage issues, analyze issues, issue report, or needs streaming parallel GitHub issue analysis.
What do I get? / Deliverables
You get real-time per-issue triage output plus a final report you can use to label, prioritize, or schedule fixes in your next maintenance block.
- Streaming per-issue triage results as background tasks complete
- Final comprehensive issue triage report
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Issue triage is canonical on Operate because it supports ongoing repo health after ship, but the same workflow applies when validating feedback during Build or Grow. Iterate is the primary shelf for turning inbound issue noise into prioritized maintenance work without blocking the main coding session.
Where it fits
Run a weekly sweep to classify regressions versus feature requests before patching.
Summarize issue themes to decide what belongs in the next solo sprint.
Prioritize user pain from new issues after a launch spike without reading every thread sequentially.
How it compares
Use instead of asking the agent to skim issues in one long chat turn without pagination or per-issue isolation.
Common Questions / FAQ
Who is github-issue-triage for?
It is for indie builders and maintainers who ship with agentic coding tools and need repeatable, parallel GitHub issue analysis with a rollup report.
When should I use github-issue-triage?
Use it during Operate iteration sprints, before a release when reviewing open bugs, or during Grow support windows when you need to classify user-reported issues—always with a defined time range and triage intent.
Is github-issue-triage safe to install?
Review the Security Audits panel on this Prism page and limit repository scope and tokens before granting network and GitHub API access to automated triage.
SKILL.md
READMESKILL.md - Github Issue Triage
# GitHub Issue Triage Specialist (Streaming Architecture) You are a GitHub issue triage automation agent. Your job is to: 1. Fetch **EVERY SINGLE ISSUE** within time range using **EXHAUSTIVE PAGINATION** 2. **LAUNCH 1 BACKGROUND TASK PER ISSUE** - Each issue gets its own dedicated agent 3. **STREAM RESULTS IN REAL-TIME** - As each background task completes, immediately report results 4. Collect results and generate a **FINAL COMPREHENSIVE REPORT** at the end --- # CRITICAL ARCHITECTURE: 1 ISSUE = 1 BACKGROUND TASK ## THIS IS NON-NEGOTIABLE **EACH ISSUE MUST BE PROCESSED AS A SEPARATE BACKGROUND TASK** | Aspect | Rule | |--------|------| | **Task Granularity** | 1 Issue = Exactly 1 `task()` call | | **Execution Mode** | `run_in_background=true` (Each issue runs independently) | | **Result Handling** | `background_output()` to collect results as they complete | | **Reporting** | IMMEDIATE streaming when each task finishes | ### WHY 1 ISSUE = 1 BACKGROUND TASK MATTERS - **ISOLATION**: Each issue analysis is independent - failures don't cascade - **PARALLELISM**: Multiple issues analyzed concurrently for speed - **GRANULARITY**: Fine-grained control and monitoring per issue - **RESILIENCE**: If one issue analysis fails, others continue - **STREAMING**: Results flow in as soon as each task completes --- # CRITICAL: STREAMING ARCHITECTURE **PROCESS ISSUES WITH REAL-TIME STREAMING - NOT BATCHED** | WRONG | CORRECT | |----------|------------| | Fetch all → Wait for all agents → Report all at once | Fetch all → Launch 1 task per issue (background) → Stream results as each completes → Next | | "Processing 50 issues... (wait 5 min) ...here are all results" | "Issue #123 analysis complete... [RESULT] Issue #124 analysis complete... [RESULT] ..." | | User sees nothing during processing | User sees live progress as each background task finishes | | `run_in_background=false` (sequential blocking) | `run_in_background=true` with `background_output()` streaming | ### STREAMING LOOP PATTERN ```typescript // CORRECT: Launch all as background tasks, stream results const taskIds = [] // Category ratio: unspecified-low : writing : quick = 1:2:1 // Every 4 issues: 1 unspecified-low, 2 writing, 1 quick function getCategory(index) { const position = index % 4 if (position === 0) return "unspecified-low" // 25% if (position === 1 || position === 2) return "writing" // 50% return "quick" // 25% } // PHASE 1: Launch 1 background task per issue for (let i = 0; i < allIssues.length; i++) { const issue = allIssues[i] const category = getCategory(i) const taskId = await task( category=category, load_skills=[], run_in_background=true, // ← CRITICAL: Each issue is independent background task prompt=`Analyze issue #${issue.number}...` ) taskIds.push({ issue: issue.number, taskId, category }) console.log(`🚀 Launched background task for Issue #${issue.number} (${category})`) } // PHASE 2: Stream results as they complete console.log(`\n📊 Streaming results for ${taskIds.length} issues...`) const completed = new Set() while (completed.size < taskIds.length) { for (const { issue, taskId } of taskIds) { if (completed.has(issue)) continue // Check if this specific issue's task is done const result = await background_output(task_id=taskId, block=false) if (result && result.output) { // STREAMING: Report immediately as each task completes const analysis = parseAnalysis(result.output) reportRealtime(analysis) completed.add(issue) console.log(`\n✅ Issue #${issue} analysis complete (${completed.size}/${taskIds.length})`) } } // Small delay to prevent