agentsclimarketplace

Github triage

Skill TonkaToyXL/cursor-agent-skills/github-triage

Curated agent skills for Cursor — diagnose, triage, commits, workflows.

Install
npx -y skills add TonkaToyXL/cursor-agent-skills --skill github-triage

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when the user types triage or asks to triage GitHub issues, PRs, queues, CI, blockers, risk, proof, next actions, or autonomous GitHub maintainer work.

SKILL.md

11.5 KB, ~2.8k tokens by cl100k_base, as published. Nobody here has run it

GitHub Triage

Use this skill when the user types triage, asks about GitHub issues/PRs/queues, or says do work autonomously, keep going, or fix what you can on GitHub.

Triage means maintainer-facing item cards: URL, what each issue/PR is about, why it matters, author trust, fit, risk, proof/test state, blockers, and next action. Never return only queue numbers or opaque refs.

Output is URL-first: every surfaced issue/PR/repo item must include its full GitHub URL in the first line or first sentence for that item.

Adapted from steipete/agent-scripts; gh-only triage workflow.

Modes

ModeTriggersPermission
Triagetriage, queue summary, next actionsRead-only analysis; no edits
Autonomousdo work autonomously, keep going, fix what you can on GitHubImplement + verify locally; push/merge/close only when explicitly authorized

Triage alone is not permission to mutate GitHub or local repos.

Scope

Default (current repo): If cwd is a git repo with a GitHub remote, triage only that project unless the user says broad, all, everything, or names multiple repos.

Broad: Scan all repos visible to gh (owned, collaborator, org — including private when token allows).

No remote: If the local project has no GitHub remote, say triage is N/A and offer to create/push a repo first.

Setup

Verify gh auth:

gh auth status

Resolve current repo:

repo=$(gh repo view --json nameWithOwner --jq .nameWithOwner 2>/dev/null || true)
if [ -z "$repo" ]; then
  url=$(git remote get-url origin 2>/dev/null || true)
  repo=$(printf '%s\n' "$url" |
    sed -E 's#^[email protected]:##; s#^https://github.com/##; s#\.git$##')
fi
printf '%s\n' "$repo"

Local Repo Gate

Before starting work inside any local project:

git status --short --branch
git branch --show-current

Proceed only when the worktree is clean. If dirty, stop and ask the user what to do. Do not stash, commit, reset, restore, or clean without explicit direction.

If not on the default branch (main or repo default), stop and ask unless the user already authorized work on that branch.

For autonomous work that needs latest main:

git pull --ff-only

If pull fails, stop and report.

Product Fit

Read in order when present:

  1. VISION.md
  2. README.md
  3. AGENTS.md / CLAUDE.md

Use these as product-fit source of truth before judging autonomous fit.

Current-Project Triage

gh issue list --repo "$repo" --state open --limit 50 \
  --json number,title,author,labels,createdAt,updatedAt,url
gh pr list --repo "$repo" --state open --limit 50 \
  --json number,title,author,isDraft,reviewDecision,mergeStateStatus,createdAt,updatedAt,url

Before acting on any item, read all comments. Maintainer comments are authoritative — they override bot labels and ordinary triage judgment. If the maintainer says it looks good, needs changes, is superseded, or is not wanted, follow that.

For small queues (about 10 open items or fewer), inspect all items. For larger queues, inspect the top priority slice and say what was not expanded.

gh issue view <n> --repo "$repo" \
  --json number,title,author,body,comments,labels,createdAt,updatedAt,url
gh pr view <n> --repo "$repo" \
  --json number,title,author,body,comments,files,commits,isDraft,reviewDecision,mergeStateStatus,statusCheckRollup,createdAt,updatedAt,url
gh pr diff <n> --repo "$repo" --patch

Only comment, close, merge, rerun, or patch with strong evidence.

Broad Queue Scan (gh-only)

List repos with open work, sorted by PR count then issues:

gh repo list --limit 200 --json nameWithOwner,issues,pullRequests,isPrivate,updatedAt \
  --jq '[.[] | select(.issues.totalCount > 0 or .pullRequests.totalCount > 0)]
        | sort_by(-.pullRequests.totalCount, -.issues.totalCount)
        | .[] | {repo: .nameWithOwner, issues: .issues.totalCount, prs: .pullRequests.totalCount, private: .isPrivate}'

Detail pass for top repos:

gh issue list --repo <owner/name> --state open --limit 50 --json number,title,author,url,updatedAt
gh pr list --repo <owner/name> --state open --limit 50 --json number,title,author,isDraft,url,updatedAt
gh run list --repo <owner/name> --limit 10

For mergeable or suspicious PRs:

gh pr view <n> --repo <owner/name> --json number,title,state,author,isDraft,mergeStateStatus,reviewDecision,statusCheckRollup,updatedAt,url
gh pr diff <n> --repo <owner/name> --patch
gh run list --repo <owner/name> --branch <branch> --limit 10

Triage Output

Return three buckets:

  • Autonomous candidates: fixable/landable without more product input — URL, why it qualifies, required verification, confidence. Selection for review, not permission to start unless the user also asked for autonomous execution.
  • Needs maintainer: blocked on product direction, credentials/access, live proof unavailable, security/privacy judgment, or maintainer comment requesting changes.
  • Defer/close/supersede: stale, duplicate, lower-quality, or overlapping items.

For plausible autonomous candidates on risky PRs (security, broad diff, new account), optionally spawn a Task subagent for trust/feasibility review before presenting.

Item Evaluation

Classify each item:

TypeRequirements
bugRepro/log/failing test/current-main proof; root cause before fix
featureE2E test plan; state missing creds/access explicitly
dependencyPackage group, semver risk, failing checks, split recommendation
securityHigh priority; careful code-path proof; no merge on rationale alone
docs/internalLower risk; note user-visible relevance

Judge: Fit (good/mixed/poor), Risk (low/medium/high), Proof (CI/repro/E2E/missing), Blocker, Next action.

Trust Signals

For non-maintainer items you recommend acting on, include author trust:

./scripts/github-activity.sh --repo <owner/repo> --global <login>

Trust changes review depth, not correctness. Do not treat trust as proof.

Permission Ladder

Separate permissions explicitly:

PermissionWhat it allows
Triage / monitorRead queue, CI, diffs — no edits
Autonomous implementLocal changes, tests, live proof
PushPush branch / update PR
CI fixRerun workflows, repair CI failures
Merge/closeMerge PR, close issue, comment as land proof
ReleaseVersion bump, tag, publish

Without required permission, stop at the last authorized boundary and report the exact next action needed.

The user saying land it, merge, or push counts as explicit authorization for that action.

Autonomous Work Mode

When the user authorizes autonomous work, do not stop after a queue summary or one local patch. Process the eligible queue sequentially, one item at a time, until no safe autonomous item remains, each item is landed/closed/deferred with proof, or a blocker requires the user.

For each item:

  1. Read issue/PR, related code, docs, CI, and product-fit files; use official docs when facts may be stale.
  2. Decide autonomous fit:
    • Go: performance (unless complexity spikes); bugfixes with repro; small UI/docs; narrow test/CI fixes; low-risk deps.
    • Ask first: new features, product choices, broad behavior changes, security without proof, live-provider work without creds, anything not E2E testable.
    • Refactor: prefer clean bounded refactor when it is the better fix.
  3. Implement or fix PR in the best maintainable way. Prefer updating contributor PR when writable; preserve credit.
  4. Live proof on the real boundary (device/audio, browser, API with real creds when available). If access missing, stop before claiming done.
  5. Run review: Bugbot or security-review subagent for non-trivial changes; address actionable findings.
  6. Ensure CI green; good PR description/changelog. If push authorized, push. If merge authorized, land with proof comment.
  7. Post PR comment with exactly how it was tested: commands, live proof, CI state, landed commit, caveats.
  8. Return to default branch, git pull --ff-only, verify clean worktree, then next item.

Do not end with dirty files or unpushed fixes unless blocked. If blocked, state exact blocker, branch/status, proof gathered, and decision needed.

Integrate — do not duplicate:

  • PR merge-ready loop → a PR babysit automation (see agent-loop-runner)
  • CI failures → gh-fix-ci when available
  • Done claims → verification-before-completion
  • Commits → your commit message conventions

Live Proof Gate

Live proof is required before merge/close, not optional polish.

  • Test the final candidate through the changed user path with real built artifact and real service/device/OS as applicable.
  • Mocks, fixtures, and CI supplement but do not replace live proof for runtime changes.
  • Redact secrets; keep concrete evidence (command, behavior, response class, state transition).
  • If creds/hardware unavailable, finish code/tests/CI, then stop and ask with a decision brief.
  • Docs/CI/test-only changes: use closest built-artifact or workflow proof; state why no external boundary applies.

Owner Decision Brief

Never ask the maintainer to land/delete/approve with only a URL.

Every decision request must include:

  • Full canonical clickable URL and title
  • Plain-language what changes and who benefits
  • Why the decision is needed now
  • Completed proof: repro, live test, tests, review, CI, mergeability
  • Tradeoffs, residual risks, scope concerns
  • Recommendation and rationale
  • Exact choices and what each does

If autonomous work remains, do that first — report as active, not premature decision.

Triage Heuristics

Prioritize: green/near-green CI PRs; reproducible bugs; security/release/auth/CI/data-loss; dependency/docs with clear path.

Deprioritize: archived repos (unless asked); old broad features without repro; provider PRs needing unavailable API keys; generated churn without user problem.

Output Shape

Current-project triage:

Repo: owner/name
Source: gh list/view/diff/checks, local source/tests where inspected

Autonomous candidates:
- https://github.com/owner/repo/pull/123 — title
  What: one-line summary.
  Type/Fit/Risk: bug; good; low because ...
  Trust: @login; acct date; repo/global activity; known/unknown/bot.
  Proof: CI/repro/test/e2e state.
  Blocker: none / ...
  Next: exact action.

Needs maintainer:
- https://github.com/owner/repo/issues/124 — ...

Defer/close:
- https://github.com/owner/repo/issues/125 — ...

Skipped:
- <why>

Broad scan:

Owners/repos scanned: <summary>
Source: gh repo list + gh detail for selected repos

Top queues:
- owner/repo: X issues, Y PRs; why it matters; next action

Autonomous candidates:
- <URL-first items>

Needs maintainer:
- <URL-first items>

Skipped:
- archived/no access/etc.

When the user asks to act, inspect selected items with gh, rerun/fix CI when authorized, comment/close/merge only with evidence, and report exact commands/proof.

Credential Access

  1. Check only the exact expected environment variable; use only when already exported.
  2. Never broadly enumerate secrets or print values.
  3. Ask the user only after targeted env check fails or interactive unlock is required.
  4. Report presence, access path, and exact missing approval — never send credentials between threads.

What ships with it: 1 file

2.0 KB alongside SKILL.md, 1 of them executable

scripts/

Keep looking

Skills are one crate of 327,132. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.