github-maintainer
Handle GitHub project queues from a maintainer perspective: triage issues and pull requests, judge fit and risk, check CI/proof/trust signals, and recommend next maintainer actions. Use for GitHub project maintenance, triage, PR queues, issue queues, contributor handling, and selecting safe next work.
What this skill does
GitHub Maintainer
Use this when the user wants maintainer-grade judgment over a GitHub project queue. The goal is not just to list issues or pull requests; it is to decide what each item means, what evidence exists, what is risky, and what should happen next.
Scope
- Default to the current repository when the working directory is a GitHub checkout.
- Broaden to multiple repositories only when the user asks for broad, all, everything, a named owner, or a named organization.
- Read local project guidance first when available:
CONTRIBUTING.md,README.md, maintainer notes, roadmap, project policy files, or equivalent docs. - Use live GitHub data through
ghwhen queue state matters. - Only comment, close, merge, rerun CI, or push changes after explicit user approval.
Workflow
- Identify the repository and confirm access.
- Collect open issues and pull requests.
- Inspect enough detail to explain each surfaced item.
- Classify each item by type, fit, risk, proof, blocker, and next action.
- Include trust signals for non-maintainer contributors when recommending action.
- If the user asks to act, work one item at a time and verify before moving on.
References
- Read
references/issue-pr-triage.mdfor queue discovery, item evaluation, trust signals, and output structure. - Read
references/permissions-and-safety.mdbefore any write action or autonomous project-maintenance work. - Use
scripts/github-activity.shwhenghandjqare available and contributor trust history is useful.
Default Output
For current-repository triage:
Repo: owner/name
Source: gh commands and local files inspected
Immediate:
- #123 PR: title
What: one-line plain-language summary.
Type/Fit/Risk: bug|feature|dependency|docs|internal; good|mixed|poor; low|medium|high because ...
Trust: factual contributor signal, or unavailable.
Proof: CI, tests, reproduction, diff review, or missing proof.
Blocker: none, missing access, failing check, unclear product direction, stale branch, no repro, etc.
Next: exact maintainer action.
Needs judgment:
- #124 issue: ...
Defer/close:
- #125 issue: ...
Skipped:
- Reason and scope limitation.For broad scans:
Owners scanned: owner/org list
Source: repo discovery method and selected gh inspections
Top queues:
- owner/repo: issue count, PR count, why it matters, next action
Immediate actions:
- Specific low-risk item with evidence.
Needs judgment:
- Ambiguous or high-risk item with decision needed.
Skipped:
- Archived, forks, missing access, or out-of-scope repositories.Files in this skill
- references/issue-pr-triage.md
- references/permissions-and-safety.md
- scripts/github-activity.sh
- SKILL.md
How to use in Orkas
Open the Orkas desktop app, go to the marketplace, and install this item with one click. Don't have Orkas yet? Download Orkas.
从维护者视角处理 GitHub 项目队列：分诊 issue/PR、判断适配度与风险、核对 CI/证据/信任信号，并给出下一步维护动作；适合 GitHub 项目维护、triage、PR 队列、issue 队列、贡献者处理和可安全推进项筛选。
该技能的功能
GitHub Maintainer
Use this when the user wants maintainer-grade judgment over a GitHub project queue. The goal is not just to list issues or pull requests; it is to decide what each item means, what evidence exists, what is risky, and what should happen next.
Scope
- Default to the current repository when the working directory is a GitHub checkout.
- Broaden to multiple repositories only when the user asks for broad, all, everything, a named owner, or a named organization.
- Read local project guidance first when available:
CONTRIBUTING.md,README.md, maintainer notes, roadmap, project policy files, or equivalent docs. - Use live GitHub data through
ghwhen queue state matters. - Only comment, close, merge, rerun CI, or push changes after explicit user approval.
Workflow
- Identify the repository and confirm access.
- Collect open issues and pull requests.
- Inspect enough detail to explain each surfaced item.
- Classify each item by type, fit, risk, proof, blocker, and next action.
- Include trust signals for non-maintainer contributors when recommending action.
- If the user asks to act, work one item at a time and verify before moving on.
References
- Read
references/issue-pr-triage.mdfor queue discovery, item evaluation, trust signals, and output structure. - Read
references/permissions-and-safety.mdbefore any write action or autonomous project-maintenance work. - Use
scripts/github-activity.shwhenghandjqare available and contributor trust history is useful.
Default Output
For current-repository triage:
Repo: owner/name
Source: gh commands and local files inspected
Immediate:
- #123 PR: title
What: one-line plain-language summary.
Type/Fit/Risk: bug|feature|dependency|docs|internal; good|mixed|poor; low|medium|high because ...
Trust: factual contributor signal, or unavailable.
Proof: CI, tests, reproduction, diff review, or missing proof.
Blocker: none, missing access, failing check, unclear product direction, stale branch, no repro, etc.
Next: exact maintainer action.
Needs judgment:
- #124 issue: ...
Defer/close:
- #125 issue: ...
Skipped:
- Reason and scope limitation.For broad scans:
Owners scanned: owner/org list
Source: repo discovery method and selected gh inspections
Top queues:
- owner/repo: issue count, PR count, why it matters, next action
Immediate actions:
- Specific low-risk item with evidence.
Needs judgment:
- Ambiguous or high-risk item with decision needed.
Skipped:
- Archived, forks, missing access, or out-of-scope repositories.技能包含的文件
- references/issue-pr-triage.md
- references/permissions-and-safety.md
- scripts/github-activity.sh
- SKILL.md
如何在 Orkas 中使用
打开 Orkas 桌面应用，进入市场，一键安装此项。还没有 Orkas？ 下载 Orkas.