Github Triage

by code-yeongyuf9181a90b5e2No license69K starsListed Oct 8, 2026Updated Oct 8, 2026Repository updated today

Read-only GitHub triage for issues AND PRs. 1 item = 1 background task (category: quick). Analyzes all open items and writes evidence-backed reports to /tmp/{datetime}/. Every claim requires a GitHub permalink as proof. NEVER takes any action on GitHub - no comments, no merges, no closes, no labels. Reports only. Triggers: 'triage', 'triage issues', 'triage PRs', 'github triage'.

Includes scriptsSoftware Development

AI-generated overview

Read-only GitHub triage that analyzes open issues and pull requests and writes evidence-backed reports.

What it does: This skill orchestrates a read-only triage of a GitHub repository's open issues and pull requests. It fetches open items, classifies each one by type, and spawns one background subagent per item to analyze it. Each subagent writes a Markdown report to a timestamped directory under /tmp, and a final summary report is produced. Every factual claim in a report is required to cite a GitHub permalink to a specific commit.
When to use it: Use it when you want a full backlog review of open issues and PRs without changing anything on GitHub. It fits maintainers who need per-item analysis, verdicts, and merge-readiness assessments backed by code evidence. It is not intended for acting on GitHub, such as commenting, labeling, merging, or closing.
Requirements: Requires the GitHub CLI (gh) authenticated for the target repository, git for commit history and SHA lookups, jq for JSON processing, and network access to GitHub. It ships an executable script at scripts/gh_fetch.py. Reports are written to a timestamped directory under /tmp.

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.

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

Find the relevant file and line(s) via Grep/Read.
Get the current commit SHA: git rev-parse HEAD
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)

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 neededif [ "$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')  donefi
# Same for PRsPRS_LIST=$(gh pr list --repo $REPO --state open --limit 500 \  --json number,title,labels,author,headRefName,baseRefName,isDraft,createdAt)PR_COUNT=$(echo "$PRS_LIST" | jq length)
if [ "$PR_COUNT" -eq 500 ]; then  LAST_DATE=$(echo "$PRS_LIST" | jq -r '.[-1].createdAt')  while true; do    PAGE=$(gh pr list --repo $REPO --state open --limit 500 \      --search "created:<$LAST_DATE" \      --json number,title,labels,author,headRefName,baseRefName,isDraft,createdAt)    PAGE_COUNT=$(echo "$PAGE" | jq length)    [ "$PAGE_COUNT" -eq 0 ] && break    PRS_LIST=$(echo "$PRS_LIST" "$PAGE" | jq -s '.[0] + .[1] | unique_by(.number)')    PR_COUNT=$(echo "$PRS_LIST" | jq length)    [ "$PAGE_COUNT" -lt 500 ] && break    LAST_DATE=$(echo "$PAGE" | jq -r '.[-1].createdAt')  donefi
echo "Total issues: $ISSUE_COUNT, Total PRs: $PR_COUNT"

# 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 neededif [ "$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')  donefi
# Same for PRsPRS_LIST=$(gh pr list --repo $REPO --state open --limit 500 \  --json number,title,labels,author,headRefName,baseRefName,isDraft,createdAt)PR_COUNT=$(echo "$PRS_LIST" | jq length)
if [ "$PR_COUNT" -eq 500 ]; then  LAST_DATE=$(echo "$PRS_LIST" | jq -r '.[-1].createdAt')  while true; do    PAGE=$(gh pr list --repo $REPO --state open --limit 500 \      --search "created:<$LAST_DATE" \      --json number,title,labels,author,headRefName,baseRefName,isDraft,createdAt)    PAGE_COUNT=$(echo "$PAGE" | jq length)    [ "$PAGE_COUNT" -eq 0 ] && break    PRS_LIST=$(echo "$PRS_LIST" "$PAGE" | jq -s '.[0] + .[1] | unique_by(.number)')    PR_COUNT=$(echo "$PRS_LIST" | jq length)    [ "$PAGE_COUNT" -lt 500 ] && break    LAST_DATE=$(echo "$PAGE" | jq -r '.[-1].createdAt')  donefi
echo "Total issues: $ISSUE_COUNT, Total PRs: $PR_COUNT"

LARGE REPOSITORY HANDLING: If total items exceeds 50, you MUST process ALL items. Use the pagination code above to fetch every single open issue and PR. DO NOT sample or limit to 50 items - process the entire backlog.

Example: If there are 500 open issues, spawn 500 subagents. If there are 1000 open PRs, spawn 1000 subagents.

Note: Background task system will queue excess tasks automatically.

Phase 2: Classify

Type	Detection
`ISSUE_QUESTION`	`[Question]`, `[Discussion]`, `?`, "how to" / "why does" / "is it possible"
`ISSUE_BUG`	`[Bug]`, `Bug:`, error messages, stack traces, unexpected behavior
`ISSUE_FEATURE`	`[Feature]`, `[RFE]`, `[Enhancement]`, `Feature Request`, `Proposal`
`ISSUE_OTHER`	Anything else
`PR_BUGFIX`	Title starts with `fix`, branch contains `fix/`/`bugfix/`, label `bug`
`PR_OTHER`	Everything else

Phase 3: Spawn Subagents (Individual Tool Calls)

CRITICAL: Create tasks ONE BY ONE using individual task_create tool calls. NEVER batch or script.

For each item, execute these steps sequentially:

Step 3.1: Create Task Record

typescript

task_create(  subject="Triage: #{number} {title}",  description="GitHub {issue|PR} triage analysis - {type}",  metadata={"type": "{ISSUE_QUESTION|ISSUE_BUG|ISSUE_FEATURE|ISSUE_OTHER|PR_BUGFIX|PR_OTHER}", "number": {number}})

task_create(  subject="Triage: #{number} {title}",  description="GitHub {issue|PR} triage analysis - {type}",  metadata={"type": "{ISSUE_QUESTION|ISSUE_BUG|ISSUE_FEATURE|ISSUE_OTHER|PR_BUGFIX|PR_OTHER}", "number": {number}})

Step 3.2: Spawn Analysis Subagent (Background)

ABSOLUTE RULES for Subagents:

ONLY ANALYZE - Never take action on GitHub (no comments, merges, closes)
READ-ONLY - Use tools only for reading code/GitHub data
WRITE REPORT ONLY - Output goes to {REPORT_DIR}/{issue|pr}-{number}.md via Write tool
EVIDENCE REQUIRED - Every claim must have GitHub permalink as proof

For each item:  1. task_create(subject="Triage: #{number} {title}")  2. task(category="quick", run_in_background=true, load_skills=[], prompt=SUBAGENT_PROMPT)  3. Store mapping: item_number -> { task_id, background_task_id }

For each item:  1. task_create(subject="Triage: #{number} {title}")  2. task(category="quick", run_in_background=true, load_skills=[], prompt=SUBAGENT_PROMPT)  3. Store mapping: item_number -> { task_id, background_task_id }

Subagent Prompts

Common Preamble (include in ALL subagent prompts)

CONTEXT:- Repository: {REPO}- Report directory: {REPORT_DIR}- Current commit SHA: {COMMIT_SHA}
PERMALINK FORMAT:Every factual claim MUST include a permalink: https://github.com/{REPO}/blob/{COMMIT_SHA}/{filepath}#L{start}-L{end}No permalink = no claim. Mark unverifiable claims as [UNVERIFIED].To get current SHA if needed: git rev-parse HEAD
ABSOLUTE RULES (violating ANY = critical failure):- NEVER run gh issue comment, gh issue close, gh issue edit- NEVER run gh pr comment, gh pr merge, gh pr review, gh pr edit- NEVER run any gh command with -X POST, -X PUT, -X PATCH, -X DELETE- NEVER run git checkout, git fetch, git pull, git switch, git worktree- Your ONLY writable output: {REPORT_DIR}/{issue|pr}-{number}.md via the Write tool

CONTEXT:- Repository: {REPO}- Report directory: {REPORT_DIR}- Current commit SHA: {COMMIT_SHA}
PERMALINK FORMAT:Every factual claim MUST include a permalink: https://github.com/{REPO}/blob/{COMMIT_SHA}/{filepath}#L{start}-L{end}No permalink = no claim. Mark unverifiable claims as [UNVERIFIED].To get current SHA if needed: git rev-parse HEAD
ABSOLUTE RULES (violating ANY = critical failure):- NEVER run gh issue comment, gh issue close, gh issue edit- NEVER run gh pr comment, gh pr merge, gh pr review, gh pr edit- NEVER run any gh command with -X POST, -X PUT, -X PATCH, -X DELETE- NEVER run git checkout, git fetch, git pull, git switch, git worktree- Your ONLY writable output: {REPORT_DIR}/{issue|pr}-{number}.md via the Write tool

ISSUE_QUESTION

You are analyzing issue #{number} for {REPO}.
ITEM:- Issue #{number}: {title}- Author: {author}- Body: {body}- Comments: {comments_summary}
TASK:1. Understand the question.2. Search the codebase (Grep, Read) for the answer.3. For every finding, construct a permalink: https://github.com/{REPO}/blob/{COMMIT_SHA}/{path}#L{N}4. Write report to {REPORT_DIR}/issue-{number}.md
REPORT FORMAT (write this as the file content):
# Issue #{number}: {title}**Type:** Question | **Author:** {author} | **Created:** {createdAt}
## Question[1-2 sentence summary]
## Findings[Each finding with permalink proof. Example:]- The config is parsed in [`src/config/loader.ts#L42-L58`](https://github.com/{REPO}/blob/{SHA}/src/config/loader.ts#L42-L58)
## Suggested Answer[Draft answer with code references and permalinks]
## Confidence: [HIGH | MEDIUM | LOW][Reason. If LOW: what's missing]
## Recommended Action[What maintainer should do]
---REMEMBER: No permalink = no claim. Every code reference needs a permalink.

You are analyzing issue #{number} for {REPO}.
ITEM:- Issue #{number}: {title}- Author: {author}- Body: {body}- Comments: {comments_summary}
TASK:1. Understand the question.2. Search the codebase (Grep, Read) for the answer.3. For every finding, construct a permalink: https://github.com/{REPO}/blob/{COMMIT_SHA}/{path}#L{N}4. Write report to {REPORT_DIR}/issue-{number}.md
REPORT FORMAT (write this as the file content):
# Issue #{number}: {title}**Type:** Question | **Author:** {author} | **Created:** {createdAt}
## Question[1-2 sentence summary]
## Findings[Each finding with permalink proof. Example:]- The config is parsed in [`src/config/loader.ts#L42-L58`](https://github.com/{REPO}/blob/{SHA}/src/config/loader.ts#L42-L58)
## Suggested Answer[Draft answer with code references and permalinks]
## Confidence: [HIGH | MEDIUM | LOW][Reason. If LOW: what's missing]
## Recommended Action[What maintainer should do]
---REMEMBER: No permalink = no claim. Every code reference needs a permalink.

ISSUE_BUG

You are analyzing bug report #{number} for {REPO}.
ITEM:- Issue #{number}: {title}- Author: {author}- Body: {body}- Comments: {comments_summary}
TASK:1. Understand: expected behavior, actual behavior, reproduction steps.2. Search the codebase for relevant code. Trace the logic.3. Determine verdict: CONFIRMED_BUG, NOT_A_BUG, ALREADY_FIXED, or UNCLEAR.4. For ALREADY_FIXED: find the fixing commit using git log/git blame. Include the commit SHA and what changed.5. For every finding, construct a permalink.6. Write report to {REPORT_DIR}/issue-{number}.md
FINDING "ALREADY_FIXED" COMMITS:- Use `git log --all --oneline -- {file}` to find recent changes to relevant files- Use `git log --all --grep="fix" --grep="{keyword}" --all-match --oneline` to search commit messages- Use `git blame {file}` to find who last changed the relevant lines- Use `git show {commit_sha}` to verify the fix- Construct commit permalink: https://github.com/{REPO}/commit/{fix_commit_sha}
REPORT FORMAT (write this as the file content):
# Issue #{number}: {title}**Type:** Bug Report | **Author:** {author} | **Created:** {createdAt}
## Bug Summary**Expected:** [what user expects]**Actual:** [what actually happens]**Reproduction:** [steps if provided]
## Verdict: [CONFIRMED_BUG | NOT_A_BUG | ALREADY_FIXED | UNCLEAR]
## Analysis
### Evidence[Each piece of evidence with permalink. No permalink = mark [UNVERIFIED]]
### Root Cause (if CONFIRMED_BUG)[Which file, which function, what goes wrong]- Problematic code: [`{path}#L{N}`](permalink)
### Why Not A Bug (if NOT_A_BUG)[Rigorous proof with permalinks that current behavior is correct]
### Fix Details (if ALREADY_FIXED)- **Fixed in commit:** [`{short_sha}`](https://github.com/{REPO}/commit/{full_sha})- **Fixed date:** {date}- **What changed:** [description with diff permalink]- **Fixed by:** {author}
### Blockers (if UNCLEAR)[What prevents determination, what to investigate next]
## Severity: [LOW | MEDIUM | HIGH | CRITICAL]
## Affected Files[List with permalinks]
## Suggested Fix (if CONFIRMED_BUG)[Specific approach: "In {file}#L{N}, change X to Y because Z"]
## Recommended Action[What maintainer should do]
---CRITICAL: Claims without permalinks are worthless. If you cannot find evidence, say so explicitly rather than making unverified claims.

You are analyzing bug report #{number} for {REPO}.
ITEM:- Issue #{number}: {title}- Author: {author}- Body: {body}- Comments: {comments_summary}
TASK:1. Understand: expected behavior, actual behavior, reproduction steps.2. Search the codebase for relevant code. Trace the logic.3. Determine verdict: CONFIRMED_BUG, NOT_A_BUG, ALREADY_FIXED, or UNCLEAR.4. For ALREADY_FIXED: find the fixing commit using git log/git blame. Include the commit SHA and what changed.5. For every finding, construct a permalink.6. Write report to {REPORT_DIR}/issue-{number}.md
FINDING "ALREADY_FIXED" COMMITS:- Use `git log --all --oneline -- {file}` to find recent changes to relevant files- Use `git log --all --grep="fix" --grep="{keyword}" --all-match --oneline` to search commit messages- Use `git blame {file}` to find who last changed the relevant lines- Use `git show {commit_sha}` to verify the fix- Construct commit permalink: https://github.com/{REPO}/commit/{fix_commit_sha}
REPORT FORMAT (write this as the file content):
# Issue #{number}: {title}**Type:** Bug Report | **Author:** {author} | **Created:** {createdAt}
## Bug Summary**Expected:** [what user expects]**Actual:** [what actually happens]**Reproduction:** [steps if provided]
## Verdict: [CONFIRMED_BUG | NOT_A_BUG | ALREADY_FIXED | UNCLEAR]
## Analysis
### Evidence[Each piece of evidence with permalink. No permalink = mark [UNVERIFIED]]
### Root Cause (if CONFIRMED_BUG)[Which file, which function, what goes wrong]- Problematic code: [`{path}#L{N}`](permalink)
### Why Not A Bug (if NOT_A_BUG)[Rigorous proof with permalinks that current behavior is correct]
### Fix Details (if ALREADY_FIXED)- **Fixed in commit:** [`{short_sha}`](https://github.com/{REPO}/commit/{full_sha})- **Fixed date:** {date}- **What changed:** [description with diff permalink]- **Fixed by:** {author}
### Blockers (if UNCLEAR)[What prevents determination, what to investigate next]
## Severity: [LOW | MEDIUM | HIGH | CRITICAL]
## Affected Files[List with permalinks]
## Suggested Fix (if CONFIRMED_BUG)[Specific approach: "In {file}#L{N}, change X to Y because Z"]
## Recommended Action[What maintainer should do]
---CRITICAL: Claims without permalinks are worthless. If you cannot find evidence, say so explicitly rather than making unverified claims.

ISSUE_FEATURE

You are analyzing feature request #{number} for {REPO}.
ITEM:- Issue #{number}: {title}- Author: {author}- Body: {body}- Comments: {comments_summary}
TASK:1. Understand the request.2. Search codebase for existing (partial/full) implementations.3. Assess feasibility.4. Write report to {REPORT_DIR}/issue-{number}.md
REPORT FORMAT (write this as the file content):
# Issue #{number}: {title}**Type:** Feature Request | **Author:** {author} | **Created:** {createdAt}
## Request Summary[What the user wants]
## Existing Implementation: [YES_FULLY | YES_PARTIALLY | NO][If exists: where, with permalinks to the implementation]
## Feasibility: [EASY | MODERATE | HARD | ARCHITECTURAL_CHANGE]
## Relevant Files[With permalinks]
## Implementation Notes[Approach, pitfalls, dependencies]
## Recommended Action[What maintainer should do]

You are analyzing feature request #{number} for {REPO}.
ITEM:- Issue #{number}: {title}- Author: {author}- Body: {body}- Comments: {comments_summary}
TASK:1. Understand the request.2. Search codebase for existing (partial/full) implementations.3. Assess feasibility.4. Write report to {REPORT_DIR}/issue-{number}.md
REPORT FORMAT (write this as the file content):
# Issue #{number}: {title}**Type:** Feature Request | **Author:** {author} | **Created:** {createdAt}
## Request Summary[What the user wants]
## Existing Implementation: [YES_FULLY | YES_PARTIALLY | NO][If exists: where, with permalinks to the implementation]
## Feasibility: [EASY | MODERATE | HARD | ARCHITECTURAL_CHANGE]
## Relevant Files[With permalinks]
## Implementation Notes[Approach, pitfalls, dependencies]
## Recommended Action[What maintainer should do]

ISSUE_OTHER

You are analyzing issue #{number} for {REPO}.
ITEM:- Issue #{number}: {title}- Author: {author}- Body: {body}- Comments: {comments_summary}
TASK: Assess and write report to {REPORT_DIR}/issue-{number}.md
REPORT FORMAT (write this as the file content):
# Issue #{number}: {title}**Type:** [QUESTION | BUG | FEATURE | DISCUSSION | META | STALE]**Author:** {author} | **Created:** {createdAt}
## Summary[1-2 sentences]
## Needs Attention: [YES | NO]## Suggested Label: [if any]## Recommended Action: [what maintainer should do]

You are analyzing issue #{number} for {REPO}.
ITEM:- Issue #{number}: {title}- Author: {author}- Body: {body}- Comments: {comments_summary}
TASK: Assess and write report to {REPORT_DIR}/issue-{number}.md
REPORT FORMAT (write this as the file content):
# Issue #{number}: {title}**Type:** [QUESTION | BUG | FEATURE | DISCUSSION | META | STALE]**Author:** {author} | **Created:** {createdAt}
## Summary[1-2 sentences]
## Needs Attention: [YES | NO]## Suggested Label: [if any]## Recommended Action: [what maintainer should do]

PR_BUGFIX

You are reviewing PR #{number} for {REPO}.
ITEM:- PR #{number}: {title}- Author: {author}- Base: {baseRefName} <- Head: {headRefName}- Draft: {isDraft} | Mergeable: {mergeable}- Review: {reviewDecision} | CI: {statusCheckRollup_summary}- Body: {body}
TASK:1. Fetch PR details (READ-ONLY): gh pr view {number} --repo {REPO} --json files,reviews,comments,statusCheckRollup,reviewDecision2. Read diff: gh api repos/{REPO}/pulls/{number}/files3. Search codebase to verify fix correctness.4. Write report to {REPORT_DIR}/pr-{number}.md
REPORT FORMAT (write this as the file content):
# PR #{number}: {title}**Type:** Bugfix | **Author:** {author}**Base:** {baseRefName} <- {headRefName} | **Draft:** {isDraft}
## Fix Summary[What bug, how fixed - with permalinks to changed code]
## Code Review
### Correctness[Is fix correct? Root cause addressed? Evidence with permalinks]
### Side Effects[Risky changes, breaking changes - with permalinks if any]
### Code Quality[Style, patterns, test coverage]
## Merge Readiness
| Check | Status ||-------|--------|| CI | [PASS / FAIL / PENDING] || Review | [APPROVED / CHANGES_REQUESTED / PENDING / NONE] || Mergeable | [YES / NO / CONFLICTED] || Draft | [YES / NO] || Correctness | [VERIFIED / CONCERNS / UNCLEAR] || Risk | [NONE / LOW / MEDIUM / HIGH] |
## Files Changed[List with brief descriptions]
## Recommended Action: [MERGE | REQUEST_CHANGES | NEEDS_REVIEW | WAIT][Reasoning with evidence]
---NEVER merge. NEVER comment. NEVER review. Write to file ONLY.

You are reviewing PR #{number} for {REPO}.
ITEM:- PR #{number}: {title}- Author: {author}- Base: {baseRefName} <- Head: {headRefName}- Draft: {isDraft} | Mergeable: {mergeable}- Review: {reviewDecision} | CI: {statusCheckRollup_summary}- Body: {body}
TASK:1. Fetch PR details (READ-ONLY): gh pr view {number} --repo {REPO} --json files,reviews,comments,statusCheckRollup,reviewDecision2. Read diff: gh api repos/{REPO}/pulls/{number}/files3. Search codebase to verify fix correctness.4. Write report to {REPORT_DIR}/pr-{number}.md
REPORT FORMAT (write this as the file content):
# PR #{number}: {title}**Type:** Bugfix | **Author:** {author}**Base:** {baseRefName} <- {headRefName} | **Draft:** {isDraft}
## Fix Summary[What bug, how fixed - with permalinks to changed code]
## Code Review
### Correctness[Is fix correct? Root cause addressed? Evidence with permalinks]
### Side Effects[Risky changes, breaking changes - with permalinks if any]
### Code Quality[Style, patterns, test coverage]
## Merge Readiness
| Check | Status ||-------|--------|| CI | [PASS / FAIL / PENDING] || Review | [APPROVED / CHANGES_REQUESTED / PENDING / NONE] || Mergeable | [YES / NO / CONFLICTED] || Draft | [YES / NO] || Correctness | [VERIFIED / CONCERNS / UNCLEAR] || Risk | [NONE / LOW / MEDIUM / HIGH] |
## Files Changed[List with brief descriptions]
## Recommended Action: [MERGE | REQUEST_CHANGES | NEEDS_REVIEW | WAIT][Reasoning with evidence]
---NEVER merge. NEVER comment. NEVER review. Write to file ONLY.

PR_OTHER

You are reviewing PR #{number} for {REPO}.
ITEM:- PR #{number}: {title}- Author: {author}- Base: {baseRefName} <- Head: {headRefName}- Draft: {isDraft} | Mergeable: {mergeable}- Review: {reviewDecision} | CI: {statusCheckRollup_summary}- Body: {body}
TASK:1. Fetch PR details (READ-ONLY): gh pr view {number} --repo {REPO} --json files,reviews,comments,statusCheckRollup,reviewDecision2. Read diff: gh api repos/{REPO}/pulls/{number}/files3. Write report to {REPORT_DIR}/pr-{number}.md
REPORT FORMAT (write this as the file content):
# PR #{number}: {title}**Type:** [FEATURE | REFACTOR | DOCS | CHORE | TEST | OTHER]**Author:** {author}**Base:** {baseRefName} <- {headRefName} | **Draft:** {isDraft}
## Summary[2-3 sentences with permalinks to key changes]
## Status
| Check | Status ||-------|--------|| CI | [PASS / FAIL / PENDING] || Review | [APPROVED / CHANGES_REQUESTED / PENDING / NONE] || Mergeable | [YES / NO / CONFLICTED] || Risk | [LOW / MEDIUM / HIGH] || Alignment | [YES / NO / UNCLEAR] |
## Files Changed[Count and key files]
## Blockers[If any]
## Recommended Action: [MERGE | REQUEST_CHANGES | NEEDS_REVIEW | CLOSE | WAIT][Reasoning]
---NEVER merge. NEVER comment. NEVER review. Write to file ONLY.

You are reviewing PR #{number} for {REPO}.
ITEM:- PR #{number}: {title}- Author: {author}- Base: {baseRefName} <- Head: {headRefName}- Draft: {isDraft} | Mergeable: {mergeable}- Review: {reviewDecision} | CI: {statusCheckRollup_summary}- Body: {body}
TASK:1. Fetch PR details (READ-ONLY): gh pr view {number} --repo {REPO} --json files,reviews,comments,statusCheckRollup,reviewDecision2. Read diff: gh api repos/{REPO}/pulls/{number}/files3. Write report to {REPORT_DIR}/pr-{number}.md
REPORT FORMAT (write this as the file content):
# PR #{number}: {title}**Type:** [FEATURE | REFACTOR | DOCS | CHORE | TEST | OTHER]**Author:** {author}**Base:** {baseRefName} <- {headRefName} | **Draft:** {isDraft}
## Summary[2-3 sentences with permalinks to key changes]
## Status
| Check | Status ||-------|--------|| CI | [PASS / FAIL / PENDING] || Review | [APPROVED / CHANGES_REQUESTED / PENDING / NONE] || Mergeable | [YES / NO / CONFLICTED] || Risk | [LOW / MEDIUM / HIGH] || Alignment | [YES / NO / UNCLEAR] |
## Files Changed[Count and key files]
## Blockers[If any]
## Recommended Action: [MERGE | REQUEST_CHANGES | NEEDS_REVIEW | CLOSE | WAIT][Reasoning]
---NEVER merge. NEVER comment. NEVER review. Write to file ONLY.

Phase 4: Collect & Update

Poll background_output() per task. As each completes:

Parse report.
task_update(id=task_id, status="completed", description=REPORT_SUMMARY)
Stream to user immediately.

Phase 5: Final Summary

Write to {REPORT_DIR}/SUMMARY.md AND display to user:

markdown

# GitHub Triage Report - {REPO}
**Date:** {date} | **Commit:** {COMMIT_SHA}**Items Processed:** {total}**Report Directory:** {REPORT_DIR}
## Issues ({issue_count})| Category | Count ||----------|-------|| Bug Confirmed | {n} || Bug Already Fixed | {n} || Not A Bug | {n} || Needs Investigation | {n} || Question Analyzed | {n} || Feature Assessed | {n} || Other | {n} |
## PRs ({pr_count})| Category | Count ||----------|-------|| Bugfix Reviewed | {n} || Other PR Reviewed | {n} |
## Items Requiring Attention[Each item: number, title, verdict, 1-line summary, link to report file]
## Report Files[All generated files with paths]

# GitHub Triage Report - {REPO}
**Date:** {date} | **Commit:** {COMMIT_SHA}**Items Processed:** {total}**Report Directory:** {REPORT_DIR}
## Issues ({issue_count})| Category | Count ||----------|-------|| Bug Confirmed | {n} || Bug Already Fixed | {n} || Not A Bug | {n} || Needs Investigation | {n} || Question Analyzed | {n} || Feature Assessed | {n} || Other | {n} |
## PRs ({pr_count})| Category | Count ||----------|-------|| Bugfix Reviewed | {n} || Other PR Reviewed | {n} |
## Items Requiring Attention[Each item: number, title, verdict, 1-line summary, link to report file]
## Report Files[All generated files with paths]

Anti-Patterns

Violation	Severity
ANY GitHub mutation (comment/close/merge/review/label/edit)	CRITICAL
Claim without permalink	CRITICAL
Using category other than `quick`	CRITICAL
Batching multiple items into one task	CRITICAL
`run_in_background=false`	CRITICAL
`git checkout` on PR branch	CRITICAL
Guessing without codebase evidence	HIGH
Not writing report to `{REPORT_DIR}`	HIGH
Using branch name instead of commit SHA in permalink	HIGH

Source and attribution

Source:code-yeongyu/oh-my-openagentin.agents/skills/github-triageat commitf9181a9

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal

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`

Github Triage

GitHub Triage - Read-Only Analyzer

Architecture

Zero-Action Policy (ABSOLUTE)

Evidence Rule (MANDATORY)

How to generate permalinks

Rules

Phase 0: Setup

Phase 1: Fetch All Open Items (CORRECTED)

Phase 2: Classify

Phase 3: Spawn Subagents (Individual Tool Calls)

Step 3.1: Create Task Record

Step 3.2: Spawn Analysis Subagent (Background)

Subagent Prompts

Common Preamble (include in ALL subagent prompts)

ISSUE_QUESTION

ISSUE_BUG

ISSUE_FEATURE

ISSUE_OTHER

PR_BUGFIX

PR_OTHER

Phase 4: Collect & Update

Phase 5: Final Summary

Anti-Patterns

Source and attribution

More from code-yeongyu/oh-my-openagent

Work With Pr

Remove Deadcode

Security Research

Publish

Pre Publish Review

Get Unpublished Changes

More in Software Development

Playground

M5 Onboard

Cardputer Buddy

Web Design Guidelines

Vercel React Native Skills

Vercel React Best Practices