Agent skill

Triage GitHub

by TanStack in TanStack/ai

Triage all open GitHub issues, PRs, and discussions in the current repository by fanning out up to 100 parallel subagents (one per item), then produce a single prioritized report ranking which PRs…

MITAuto-check passedAgent Workflows

Install Triage GitHub

skills CLI
$ npx skills add TanStack/ai --skill triage-github -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install TanStack/ai triage-github --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/TanStack/ai.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.grok/skills/triage-github .claude/skills/triage-github && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
triage-github
GitHub stars
3.2k
Token cost
~5.2k tokens
SKILL.md length
1,552 words
Files
1
Skills in repo
24
Repo updated
First seen
Licence
MIT

At a glance

Triage all open GitHub issues, PRs, and discussions in the current repository by fanning out up to 100 parallel subagents (one per item), then produce a single prioritized report ranking which PRs…

  • Works in 7 steps: Fetch open work → Decide the parallel split → Fan out subagents → …
  • The user asks to triage open issues/PRs
  • SKILL.md covers When to use, Prerequisites, Procedure and Notes
  • Calls gh

What it does

Triage GitHub is an agent skill from TanStack/ai. Triage all open GitHub issues, PRs, and discussions in the current repository by fanning out up to 100 parallel subagents (one per item), then produce a single prioritized report ranking which PRs to review first, which issues to address first, and which discussions need maintainer attention. Use when the user asks to "triage open issues/PRs", "triage discussions", "prioritize the backlog", "what should I review first", "sweep the repo", or any request to bulk-evaluate open GitHub work and recommend an order.

Its SKILL.md is about 5.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Agent Workflows, covering Subagents. It works with GitHub. The repository describes itself as: 🤖 Type-safe, provider-agnostic TypeScript AI SDK for streaming chat, tool calling, agents, and multimodal apps across OpenAI, Anthropic, Gemini, React, Vue, Svelte, and Solid. The licence is MIT.

When your agent uses it

  • The user asks to triage open issues/PRs
  • Triage discussions
  • Prioritize the backlog
  • What should I review first

Example prompts

  • “triage open issues/PRs”
  • “triage discussions”
  • “prioritize the backlog”
  • “/triage-github”

Workflow steps

7 steps, taken from the step headings in SKILL.md.

  1. Fetch open work
  2. Decide the parallel split
  3. Fan out subagents
  4. Aggregate
  5. Write the snapshot, then the report
  6. Summarize for the user
  7. Offer to publish as a secret gist (opt-in)

What it can do on your machine

Read from SKILL.md and the folder at commit 68aeada. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • gh

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Triage GitHub loads about 5.2k tokens when it runs. Until then it costs about 132 tokens; SKILL.md has 1,552 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~132
When it runs · the whole SKILL.md, loaded when a task matches
~5.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from TanStack/ai at commit 68aeada, republished under its MIT licence (© TanStack). 1,552 words, ~5,210 tokens.

Download SKILL.mdSave it as .claude/skills/triage-github/SKILL.md (or your agent's skills folder).
name
triage-github
description
Triage all open GitHub issues, PRs, and discussions in the current repository by fanning out up to 100 parallel subagents (one per item), then produce a single prioritized report ranking which PRs to review first, which issues to address first, and which discussions need maintainer attention. Use when the user asks to "triage open issues/PRs", "triage discussions", "prioritize the backlog", "what should I review first", "sweep the repo", or any request to bulk-evaluate open GitHub work and recommend an order.

Triage GitHub Issues, PRs & Discussions in Parallel

When to use

The user wants a prioritized view of everything open on the current repo's GitHub: which PRs to merge/review first, which issues to fix first, and which discussions need maintainer engagement. Trigger phrases include "triage the backlog", "what should I look at first", "prioritize open PRs and issues", "sweep open work", "triage discussions".

Do not invoke for single-item review (just look at it directly) or when the user wants ongoing automation (use /schedule instead).

Prerequisites

  • gh CLI is authenticated (gh auth status). If not, stop and ask the user to authenticate — do not attempt to fix auth automatically.
  • Run from inside a git repo whose origin points at the GitHub repo to triage. Confirm with gh repo view --json nameWithOwner,hasDiscussionsEnabled.
  • If hasDiscussionsEnabled is false, skip the discussions section entirely (don't fetch, don't include in budget, note in report that discussions are disabled).

Procedure

1. Fetch open work

Run these gh calls in parallel. Use JSON so the downstream agent prompts are self-contained. The discussions call is a GraphQL query because gh has no built-in discussion list command.

bash
gh pr list --state open --limit 200 --json number,title,url,author,assignees,createdAt,updatedAt,isDraft,mergeable,reviewDecision,labels,additions,deletions,changedFiles,statusCheckRollup

gh issue list --state open --limit 200 --json number,title,url,author,createdAt,updatedAt,labels,comments,reactionGroups

gh api graphql -f query='
query($owner: String!, $name: String!) {
  repository(owner: $owner, name: $name) {
    discussions(first: 100, orderBy: {field: UPDATED_AT, direction: DESC}, states: OPEN) {
      totalCount
      nodes {
        number
        title
        url
        createdAt
        updatedAt
        upvoteCount
        isAnswered
        locked
        category { name }
        author { login }
        labels(first: 5) { nodes { name } }
        comments(first: 0) { totalCount }
        reactions { totalCount }
      }
    }
  }
}' -F owner=<OWNER> -F name=<REPO>

Substitute <OWNER> and <REPO> from gh repo view --json nameWithOwner.

If the combined total exceeds 100 items, tell the user the counts (PRs / issues / discussions) and ask whether to cap at 100 most-recently-updated or split into batches. The agent cap is 100 total across all three categories.

2. Decide the parallel split
  • Count nPRs, nIssues, nDiscussions.
  • If nPRs + nIssues + nDiscussions <= 100: spawn one agent per item.
  • Otherwise: prioritize PRs first (they block contributors), then issues by most-recently-updated, then discussions by most-recently-updated, up to the 100 budget. Note in the final report which items were skipped.
3. Fan out subagents

Dispatch all agents in a single message using multiple Agent tool calls (Claude Code parallelizes when they're in one block). Use subagent_type: "general-purpose" and run_in_background: false — you need the results synchronously to write the report.

Per-PR prompt template (substitute the bracketed values):

Triage GitHub PR [URL]. You have read-only access via `gh` and web tools.

Gather:
- `gh pr view [NUMBER] --json title,body,author,assignees,createdAt,updatedAt,isDraft,mergeable,mergeStateStatus,reviewDecision,labels,additions,deletions,changedFiles,statusCheckRollup,comments,closingIssuesReferences`
- `gh pr diff [NUMBER]` (skim — don't dump it)
- Recent review comments if any

`closingIssuesReferences` is GitHub's authoritative "this PR closes #X" linkage (populated by closing keywords like `Closes #123`). Put those issue numbers in `closesIssues`. Also scan the PR body/title for issue references that use closing keywords but weren't auto-linked (cross-repo, typos) and include those too. `assignees` is the array of assigned logins (may be empty).

Return ONLY a JSON object on a single line (no prose, no fences), matching:
{"kind":"pr","number":N,"title":"...","url":"...","author":"...","assignees":["login",...],"closesIssues":[N,...],"ageDays":N,"sizeLOC":N,"ciStatus":"passing|failing|pending|none","mergeable":true|false,"reviewState":"approved|changes_requested|review_required|none","draft":true|false,"priority":"P0|P1|P2|P3","reason":"<=140 chars","blockedBy":"<=80 chars or empty","recommendedAction":"merge|review|request-changes|close|wait"}

Priority rubric:
- P0: ready-to-merge (approved + green CI + mergeable + non-draft), or fixes broken main
- P1: small/focused, passing CI, needs review; or bug fix with clear reproduction
- P2: feature work, larger diff, no blockers
- P3: draft, stale (>30 days no activity), or has unresolved conflicts/failures

Be terse. One JSON object. No commentary.

Per-issue prompt template:

Triage GitHub issue [URL]. Read-only access via `gh`.

Gather:
- `gh issue view [NUMBER] --json title,body,author,createdAt,updatedAt,labels,comments,reactionGroups,assignees`
- Cross-referenced/linked PRs from the timeline: `gh api "repos/<OWNER>/<REPO>/issues/[NUMBER]/timeline" --jq '[.[] | select(.event=="cross-referenced" and .source.issue.pull_request != null) | .source.issue.html_url] | unique'` (substitute `<OWNER>`/`<REPO>`). Any URL returned is a PR that references this issue — capture it in `linkedPR`.
- Skim comments for repro steps, workarounds, and any "fixed by #NNN" / PR links

Set `linkedPR` to the URL of an open PR that addresses this issue if one exists (from the timeline query or comments), else empty. This is used to dedup: issues with a linked PR are folded under that PR in the report. `assignees` is the array of assigned logins (may be empty).

Return ONLY a JSON object on one line:
{"kind":"issue","number":N,"title":"...","url":"...","author":"...","assignees":["login",...],"ageDays":N,"reactions":N,"comments":N,"hasRepro":true|false,"linkedPR":"<url or empty>","category":"bug|feature|docs|question|chore","priority":"P0|P1|P2|P3","reason":"<=140 chars","recommendedAction":"fix|investigate|answer|close|wait-for-info"}

Priority rubric:
- P0: regression / data loss / security / blocks many users (high reactions + recent activity)
- P1: confirmed bug with reproduction, or high-engagement feature request
- P2: feature requests, minor bugs, docs gaps
- P3: questions, unreproducible, no activity in 60+ days

One JSON object. No commentary.

Per-discussion prompt template:

Triage GitHub discussion [URL]. Read-only access via `gh api graphql`.

Gather:
- `gh api graphql -f query='{ repository(owner:"<OWNER>", name:"<REPO>") { discussion(number: [NUMBER]) { title body url createdAt updatedAt upvoteCount isAnswered locked category { name } author { login } labels(first: 10) { nodes { name } } comments(first: 30) { totalCount nodes { author { login } body createdAt isAnswer upvoteCount } } reactions { totalCount } } } }'`
- Skim body + comments for: maintainer engagement, repro steps that suggest a real bug, and any links to issues/PRs (`#NNN` or full github.com/.../issues|pull/NNN URLs)

If the discussion body or comments reference an existing issue or PR that tracks it (or it was converted to an issue), capture that URL in `linkedIssueOrPR`, else empty. This is used to dedup: discussions already tracked by an issue or PR are folded away and only surface if unlinked.

Return ONLY a JSON object on one line:
{"kind":"discussion","number":N,"title":"...","url":"...","author":"...","linkedIssueOrPR":"<url or empty>","category":"Q&A|Ideas|General|Show and tell|Announcements|Polls|other","ageDays":N,"updatedDaysAgo":N,"upvotes":N,"comments":N,"reactions":N,"isAnswered":true|false|null,"maintainerEngaged":true|false,"looksLikeBug":true|false,"priority":"P0|P1|P2|P3","reason":"<=140 chars","recommendedAction":"answer|convert-to-issue|engage|mark-answered|close|wait"}

Priority rubric (category-aware):
- Q&A:
  - P0: unanswered AND (looksLikeBug OR upvotes>=5 OR ageDays>=7 with no maintainer reply)
  - P1: unanswered with clear question, some engagement, recent
  - P2: recently asked, no engagement yet, awaiting community signal
  - P3: effectively answered but not marked, stale (60+ days), or low-effort
- Ideas:
  - P0: upvotes>=10 AND updatedDaysAgo<=14 — strong roadmap demand
  - P1: upvotes>=3 with clear scope, or moderate engagement
  - P2: legitimate idea, low engagement so far
  - P3: stale, duplicate, off-roadmap, or off-topic
- General / Show and tell / Announcements / Polls / other:
  - P1: high engagement (upvotes+comments>=10) and recent — surfaces trends
  - P2: normal engagement
  - P3: low engagement, off-topic, or stale (60+ days)

Notes for recommendedAction:
- "convert-to-issue" if looksLikeBug is true and no linked issue exists
- "answer" for unanswered Q&A
- "mark-answered" for Q&A where a comment clearly answers but isAnswered is false
- "engage" for high-signal Ideas needing maintainer feedback
- "close" for off-topic, duplicate, or out-of-scope
- "wait" if community signal is still forming

One JSON object. No commentary.
4. Aggregate

Collect every agent's JSON line. If an agent returned prose instead of JSON (rare), extract what you can or mark priority: "P3", reason: "agent parse failed".

4a. Build the linkage/dedup map (do this BEFORE sorting)

The report is a strict hierarchy — PRs > issues > discussions. Each unit of work appears once, in the highest tier that covers it. A PR outranks the issue it closes; an issue outranks the discussion that spawned it.

  1. coveredIssues = the union of every PR's closesIssues, PLUS every issue whose own linkedPR is non-empty. These issues are represented by a PR, so they are removed from the Issues section.
  2. For each PR, attach the human-readable closes #X[, #Y] list from its closesIssues. Pull each closed issue's title from the issue results (if that issue was triaged) so the PR line can name what it closes.
  3. coveredDiscussions = every discussion whose linkedIssueOrPR is non-empty. These are tracked elsewhere, so they are removed from the Discussions section.
  4. Keep a short "Folded away" tally (counts only) so the report can note how many issues/discussions were hidden because a PR/issue already covers them.

Edge cases:

  • A PR closing an issue that is itself closed/not in the open set — still list closes #X on the PR (it's informative), just don't try to fetch a title.
  • An issue with a linkedPR pointing at a PR that is not open (already merged/closed) — treat the issue as still open work: keep it in the Issues section, but note the merged PR in its reason. Only fold an issue away when the linked PR is open.
  • Two PRs closing the same issue (competing fixes) — list the issue under both PRs; fold the issue once.
4b. Sort
  1. PRs by priority (P0→P3), then by ageDays ascending within each tier (newer first for P0/P1 to capture momentum; for P3 by oldest first — those are stalest).
  2. Issues (after removing coveredIssues) by priority, then by reactions + comments desc within each tier.
  3. Discussions (after removing coveredDiscussions) by priority, then by upvotes * 2 + comments + reactions desc within each tier. Inside the same tier, surface Q&A above Ideas above other categories (response latency matters most for Q&A).
4c. Compute deltas vs the previous run

Triage data dir. Machine-readable snapshots live in a stable directory so runs can be compared: use .agent/triage/ if the repo has a .agent/ directory, else .triage/ at the repo root (create it, and add /.triage/ to .gitignore if not already ignored). These snapshots are local working data — never commit them.

Find the most recent snapshot triage-*.json in that dir whose date is before today (ignore any from today so a same-day re-run doesn't diff against itself). If none exists, skip deltas and note "first tracked run — no prior snapshot to compare" in the report.

Otherwise load it. Each snapshot is { "date", "repo", "items": [ <agent JSON> + "highStreak": N ] }. Match items across runs by kind + number and compute:

  • New — in current, not in prior.
  • Resolved — in prior, not in current (merged / closed / answered since last run).
  • Escalated — priority increased (e.g. P2 → P0). Record old → new.
  • De-escalated — priority decreased.
  • Recurring high priority — highStreak >= 2 (see below): P0/P1 now and also high-priority last run. A P0 that recurs across runs is being ignored despite "act today" — the single most actionable delta signal.

highStreak propagates the streak so you don't need full history: when building the current snapshot, for each item look up its prior entry. If the item is P0/P1 and its prior entry was P0/P1, set highStreak = priorHighStreak + 1; otherwise highStreak = 1. Store it on each current item.

Deltas are additive — they never change an item's score or its placement in the sections below. If the prior snapshot is missing or unparseable, skip the delta section entirely rather than guessing; do not fabricate a comparison.

Show full SKILL.md (589 more words)Show less
5. Write the snapshot, then the report

First write the machine-readable snapshot to <triage data dir>/triage-YYYY-MM-DD.json (the dir from 4c) — { "date", "repo", "items": [...] }, one entry per triaged item (the agent's JSON verbatim plus the computed highStreak). This is the source of truth the next run diffs against; the markdown report is human-facing only. Overwrite today's snapshot if re-running.

Then save the human report to TRIAGE_REPORT.md at the repo root (or .agent/triage/TRIAGE_REPORT-YYYY-MM-DD.md if the repo has a .agent/ directory). Ask before overwriting an existing report from today.

Report skeleton:

markdown
# Triage Report — <repo nameWithOwner> — <YYYY-MM-DD>

Scanned **N PRs**, **M issues**, and **D discussions**. Folded away **X issues** covered by an open PR and **Y discussions** already tracked by an issue/PR (they appear under the covering item, not in their own section). Skipped K items over the 100-agent budget (listed at bottom).

PR lines carry the metadata format: **by @author** · **assigned @assignee1, @assignee2** (or _unassigned_) · **closes #X** (when the PR closes an issue).

## What changed since <prior date>

_Diffed against the previous snapshot (<prior date>). Omit this whole section on the first tracked run._

- **New (<count>):** [#NUM Title](url) _(pr/issue/discussion, P0)_, …
- **Resolved (<count>):** [#NUM Title](url), … — open last run, now merged/closed/answered.
- **Escalated (<count>):** [#NUM Title](url) **P2 → P0**, … — priority rose; look here first.
- **De-escalated (<count>):** [#NUM Title](url) **P0 → P2**, …
- **Recurring high priority (<count>):** [#NUM Title](url) — **P0 for 3 consecutive runs**, still _<action>_, … — keeps surfacing without resolution.

## PRs to review first

### P0 — merge/fix today

- [#NUM Title](url) — by @author · assigned @assignee (or _unassigned_) · closes #X — <reason>. _Action: <recommendedAction>_

### P1 — review this week

- [#NUM Title](url) — by @author · assigned @assignee · closes #X — <reason>. _Action: <recommendedAction>_

### P2 — when time permits

<one-line per item, same by/assigned/closes prefix>

### P3 — needs author input or close

<one-line per item, same by/assigned/closes prefix>

## Issues to address first

_Only issues with **no open PR** addressing them. Issues that a PR already closes are folded under that PR above._

### P0 — fix now

- [#NUM Title](url) — assigned @assignee (or _unassigned_) — <reason>. _Action: <recommendedAction>_

### P1 — schedule this sprint

- [#NUM Title](url) — assigned @assignee — <reason>. _Action: <recommendedAction>_

### P2 — backlog

<one-line per item, with assignee>

### P3 — close or ask for info

<one-line per item, with assignee>

## Discussions to engage with

_Only discussions **not already tracked** by an issue or PR._

### P0 — respond today

- [#NUM Title](url) _(<category>)_ — <reason>. _Action: <recommendedAction>_

### P1 — respond this week

- [#NUM Title](url) _(<category>)_ — <reason>. _Action: <recommendedAction>_

### P2 — when time permits

<one-line per item, prefix with category>

### P3 — close, mark answered, or let community drive

<one-line per item, prefix with category>

## Skipped (over budget)

<list any items not triaged>

## How this was generated

N parallel triage agents ran via the `triage-github` skill on <date>. Each agent independently scored its item; this report aggregates and ranks them, then applies a PR > issue > discussion linkage pass so each unit of work appears once under the highest tier that covers it (a PR's `closesIssues` and each issue's `linkedPR` drive the folding). A machine-readable snapshot was written to `<triage data dir>/triage-<date>.json`; the "What changed" section above diffs this run against the most recent prior snapshot. Priorities are heuristic — sanity-check P0s before acting, especially `convert-to-issue` and `close` recommendations on discussions.

If discussions are disabled on the repo, omit the "Discussions to engage with" section and add a one-liner near the top noting they're disabled.

6. Summarize for the user

After writing the file, give the user a 3–5 line summary: total counts (plus how many issues/discussions were folded under a covering PR/issue), top 3 PRs to review, top 3 issues to fix, top 3 discussions to engage with, and the report path. Do not paste the full report into chat.

7. Offer to publish as a secret gist (opt-in)

The report stays local by default. After the summary, offer once:

Report saved to <path>. Want me to publish it as a secret gist to share? Note: a secret gist is unlisted, not private — anyone with the link can read it, and the report names contributors next to candid verdicts (close, low-effort, etc.).

Only if the user says yes that run, publish the markdown report (never the JSON snapshot):

bash
gh gist create <report-path> --desc "Triage report — <repo nameWithOwner> — <YYYY-MM-DD>"

Secret is the gh gist create default — do not pass --public. Print the returned URL back to the user. If the call fails with a scope error, tell the user to run gh auth refresh -s gist and re-run; don't try to work around it.

Do not create the gist pre-emptively, on a schedule, or without an explicit yes — it is the one outward-facing action this skill can take, and it must be user-initiated on each run.

Notes

  • Cost: 100 agents is expensive. If the combined open-item total is small (say <20), just triage them yourself in the main thread instead of fanning out — mention this and proceed.
  • Rate limits: gh shares one auth token; 100 concurrent gh calls usually fits inside GitHub's per-hour quota for authenticated users, but if the user has run heavy gh traffic recently, batch the agents in two waves of 50. Discussion GraphQL queries cost more rate-limit points per call than REST — factor that in.
  • Failed agents: if an agent times out or returns garbage, include it in the report under a "Triage failures" subsection rather than silently dropping it.
  • Snapshots & deltas: each run writes a triage-<date>.json snapshot to the triage data dir (.agent/triage/ or .triage/); the next run diffs against the latest prior one to produce the "What changed" section. Snapshots are local-only working data — gitignore them, and delete freely (deleting just disables deltas for the next run). If no prior snapshot exists or it won't parse, the run proceeds without a delta section rather than guessing.
  • Don't take actions: this skill is read-only. Do not close issues, request changes, merge PRs, comment on discussions, convert discussions to issues, or post any reply. The report is for the human to act on. The only exception is the opt-in secret gist in step 7 — an explicit, user-initiated publish of the report itself; it never happens automatically.
  • Discussion category names vary per repo. The common GitHub defaults are Q&A, Ideas, General, Show and tell, Announcements, Polls. Unknown categories should be tagged as "other" and ranked under the General rubric.

© TanStack, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .grok/skills/triage-github of TanStack/ai.

Open the folder on GitHubat commit 68aeada

Compare with similar skills

Triage GitHub next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Triage GitHub compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Triage GitHub this skillTanStack/ai3.2k—~5.2kAutomated safety check: PassMIT
Load PR CommentsNeoLabHQ/context-engineering-kit1.7k—~2.1kAutomated safety check: PassGPL-3.0
Gh Issuestrpc-group/trpc-agent-go1.8k8 repos~8.7kAutomated safety check: PassApache-2.0
Analyze Ossteam-attention/hoyeon173—~2kAutomated safety check: PassMIT
Threadsmajiayu000/spellbook286—~8.7kAutomated safety check: PassMIT
GitHub Review Iterationprisma/orm48k—~2.2kAutomated safety check: PassApache-2.0

Similar skills

  • Load PR Comments

    NeoLabHQ/context-engineering-kit

    A skill your agent uses to load open/unresolved PR review comments then aggregate them as tasks in .specs/comments/.md for parallel agents to fix.

    1.7k GitHub stars~2.1k tokensUpdated 1 mo ago
    Agent WorkflowsAuto-check passed
  • Gh Issues

    trpc-group/trpc-agent-go

    Fetch GitHub issues, spawn sub-agents to implement fixes and open PRs, then monitor and address PR review comments.

    1.8k GitHub starsUsed in 8 repos~8.7k tokens
    Agent WorkflowsAuto-check passed
  • Analyze Oss

    team-attention/hoyeon

    Analyze an open-source project from What/Why perspective (not how-it's-implemented).

    173 GitHub stars~2k tokensUpdated 4 mo ago
    Agent WorkflowsAuto-check passed
  • Threads

    majiayu000/spellbook

    A skill your agent uses when the user explicitly asks for $threads, Codex-native subagents, 开几个子 agent, or a GitHub issue/PR queue needing parallel lanes, worktrees, review/merge gates, and closure…

    286 GitHub stars~8.7k tokensUpdated today
    Agent WorkflowsAuto-check passed
  • Official

    Runs a loop on a GitHub pull request: fetch review state, triage comments into actions, implement them and resolve threads, repeating until nothing actionable is left.

    48k GitHub stars~2.2k tokensUpdated today
    DevelopmentAuto-check passed
  • Runs a spec-driven workflow from PRD to epic to GitHub issues to parallel agents, with status, standup and blocked-work reports from bundled scripts.

    8.4k GitHub stars~1.1k tokensUpdated 6 mo ago
    Product & Project ManagementAuto-check passed

More from TanStack/ai

All 24 skills in this repo
  • I Have Adhd

    TanStack/ai

    A skill your agent uses when the user invokes /i-have-adhd, says they have ADHD, or asks for ADHD-friendly output.

    3.2k GitHub starsUsed in 5 repos~1.8k tokens
    Auto-check passed
  • PR Sweep

    TanStack/ai

    Sweep open (or listed) PRs with up to 100 parallel agents: security-scan outside contributors, rebase onto main when behind (push --force-with-lease), approve pending first-time-contributor CI when…

    3.2k GitHub stars~4.6k tokensUpdated today
    Auto-check passed
  • A skill your agent uses when wiring honcho() from @tanstack/ai-memory/honcho — a hosted memory adapter where recall is a dialectic answer over the user's representation (no discrete fragments).

    3.2k GitHub starsUsed in 1 repo~457 tokens
    Auto-check passed
  • A skill your agent uses when wiring inMemory() from @tanstack/ai-memory/in-memory — explains setup, options (embedder, extract, topK/minScore), when to pick it (dev/tests/single-process demos), and…

    3.2k GitHub starsUsed in 1 repo~448 tokens
    Auto-check passed
  • A skill your agent uses when wiring redis() from @tanstack/ai-memory/redis in production — covers client setup (ioredis or node-redis via fromNodeRedis), the storage model, client-side ranking…

    3.2k GitHub starsUsed in 1 repo~840 tokens
    Auto-check passed
  • A skill your agent uses when adding a public teaching example or a docs tutorial.

    3.2k GitHub stars~1.4k tokensUpdated today
    Auto-check passed

Works with

Questions about Triage GitHub

What does Triage GitHub do?

Triage all open GitHub issues, PRs, and discussions in the current repository by fanning out up to 100 parallel subagents (one per item), then produce a single prioritized report ranking which PRs…. Triage GitHub is an agent skill from TanStack/ai. Triage all open GitHub issues, PRs, and discussions in the current repository by fanning out up to 100 parallel subagents (one per item), then produce a single prioritized report ranking which PRs to review first, which issues to address first, and which discussions need maintainer attention.

When should I use Triage GitHub?

Triage GitHub fits situations like: the user asks to triage open issues/PRs; triage discussions; prioritize the backlog; what should I review first.

How do I install Triage GitHub in Claude Code?

Run `npx skills add TanStack/ai --skill triage-github -a claude-code`. Or copy the skill folder (.grok/skills/triage-github in TanStack/ai) into .claude/skills/triage-github in your project. Claude Code loads it when a task matches its description.

How do I install Triage GitHub in Codex?

Run `npx skills add TanStack/ai --skill triage-github -a codex`. Or copy the skill folder (.grok/skills/triage-github in TanStack/ai) into .agents/skills/triage-github in your project. Codex loads it when a task matches its description.

Can I use Triage GitHub in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add TanStack/ai --skill triage-github -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/triage-github, .gemini/skills/triage-github, .github/skills/triage-github and .opencode/skills/triage-github in your project.

What does Triage GitHub need to run?

Going by SKILL.md and its folder, Triage GitHub needs the command-line tools its instructions call (gh).

Does Triage GitHub access the network?

SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Triage GitHub safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Triage GitHub use?

Triage GitHub is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Triage GitHub use?

About 5.2k tokens (SKILL.md is roughly 21k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Triage GitHub?

Skills that share tags, products or a category with Triage GitHub: Load PR Comments (NeoLabHQ/context-engineering-kit, 1.7k stars), Gh Issues (trpc-group/trpc-agent-go, 1.8k stars), Analyze Oss (team-attention/hoyeon, 173 stars) and Threads (majiayu000/spellbook, 286 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Triage GitHub?

TanStack (a GitHub organization) maintains it in TanStack/ai, which has 3,172 GitHub stars. The repository holds 24 skills in this directory. The repository was last updated on October 8, 2026.

Source: TanStack/ai on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.