github-project-triage

GitHub 项目分诊

除非请求明确针对非 GitHub 领域，否则用户输入 triage 时始终使用此技能。在仓库内时，默认使用当前 GitHub 项目。分诊意味着面向维护者的条目卡片：URL、每个 Issue/PR 的内容、重要性、作者可信度、契合度、风险、证据/测试状态、阻塞因素和后续操作。绝不能只返回队列编号或难以理解的引用。

输出以 URL 开头：每个列出的 Issue/PR/仓库条目都必须在该条目的第一行或第一句中包含其 GitHub URL。如果提供候选列表，每个条目单独列出一个 URL。

RepoBar 仅作为第一步，用于跨相关所有者/组织广泛发现队列。RepoBar 比手动编写 gh repo list 循环更快，也更了解用户配置文件，并且已能识别仓库活动、Issue 数量、PR 数量、本地项目、身份验证、缓存和筛选条件。

设置

如果已安装真正的 repobar 二进制文件，优先使用它。在此工作区中，它可能仅作为 SwiftPM 产品存在于 ~/Projects/RepoBar。

repobar_cmd() {
  if command -v repobar >/dev/null 2>&1; then
    repobar "$@"
  elif [ -x "$HOME/Projects/RepoBar/.build/debug/repobarcli" ]; then
    "$HOME/Projects/RepoBar/.build/debug/repobarcli" "$@"
  else
    swift run --package-path "$HOME/Projects/RepoBar" repobarcli "$@"
  fi
}

repobar_cmd status --json

广泛分诊的默认所有者：steipete、openclaw。对于广泛/默认队列分诊，即使 openclaw/openclaw 不是条目数量最多的仓库，也要对其进行详细检查，因为它是 ClawdBot/OpenClaw 的主要队列。除非用户点名 amantus-ai 或其他所有者、当前仓库已属于该所有者，或任务明确要求检查所有内容，否则不要纳入他们。对于指定所有者的精确任务，不要扩展到指定所有者以外。

本地仓库检查关卡

在任何本地项目中开始工作之前，先确认检出状态已就绪：

git status --short --branch
git branch --show-current
git pull --ff-only
git status --short --branch

只有当分支为 main、拉取成功且工作区干净时，才继续。如果分支不是 main、拉取失败，或 git status --short 显示存在更改，则停止并询问 Peter 如何处理。未经明确指示，不要切换分支、暂存、更改提交、重置、还原或清理。

范围规则

如果用户说 triage，且当前工作目录是带有 GitHub 远程仓库的 Git 仓库，则只对该项目进行分诊。除非用户说 broad、all、everything，点名多个所有者/组织，或要求跨仓库分诊，否则不要扩展到 Peter/组织的所有队列。

如果仓库中有 VISION.md，在判断哪些工作可自主处理之前先阅读它。将其作为产品契合度的事实依据，再应用此技能的风险/可测试性规则。如果没有 VISION.md，则使用以下自主处理契合度规则。

查找当前项目：

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"

当前项目分诊从以下内容开始：

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

对任何 Issue 或 PR 采取行动前，阅读所有评论，并将 Peter/所有者的评论视为权威的处理指示。如果 Peter 表示看起来不错、需要修改、已被取代、已获产品批准或不需要，则这些意见优先于机器人标签和常规分诊判断。如果没有 Peter/所有者的评论，则运用维护者判断，并说明这是你自己的判断。

随后检查足够的详细信息，以解释每个列出的条目。对于较小的队列（约 10 个或更少的开放条目），检查所有条目。对于较大的队列，检查优先级最高的一部分，并说明哪些条目未作深入检查。

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

只有在有充分证据时，才发表评论、关闭、合并、重新运行或打补丁。

分流输出

当用户说 triage 时，始终扫描当前仓库中未关闭的问题和未关闭的 PR。返回：

• Autonomous candidates：看起来无需更多产品输入即可修复或合并的条目，并提供 URL、符合条件的原因、所需验证和置信度。这是供审查的筛选结果；除非用户同时要求自主执行，否则不代表可以开始工作。
• Needs Peter：因需要 Peter／所有者决策、产品方向、缺少凭据／访问权限、无法获得实时服务商证明、安全／隐私判断，或 Peter 的权威评论要求修改而受阻的条目。
• Defer/close/supersede：过时、重复、质量较低或相互重叠，可能不需要新增代码的条目。

对于每个可能符合条件的自主候选项，如果工具支持，先使用可用的高推理能力子 Agent、oracle 或独立 Agent 审查可行性，再进行汇报。只向子 Agent 提供与任务直接相关的证据，并询问该条目能否自主完成、需要哪些验证，以及有哪些因素可能使其不安全。如果无法使用子 Agent，则自行进行同等深度的审查，并说明这一点。

自主工作模式

当用户说 do work autonomously、work you can do autonomously、keep going 或类似的话时，不要在队列摘要或一次本地补丁后就停止。将其视为授权，按顺序处理符合条件的问题／PR 队列，直到没有剩余的安全自主事项、每个事项都已合并／关闭／延期并提供证明，或遇到需要 Peter 处理的阻碍。

切勿同时处理多个工单。对于每个事项：

1. 阅读问题／PR、相关代码、文档、CI，以及存在时的 VISION.md；事实可能已过时或不明确时，通过 Google 查阅官方文档。
2. 判断该事项是否适合自主处理：
   • 可以处理：性能改进（除非复杂度增加过多）；有复现方式／根因和验证路径的缺陷修复；小型 UI／UX 调整；文档修复；范围明确的测试／内部修复；有 CI 通过证明的低风险依赖／CI 清理。
   • 先询问：新功能、产品／愿景决策、大范围行为变更、高风险依赖、缺乏充分证明的安全敏感变更、缺少可用凭据的实时服务商工作，以及任何无法进行端到端测试的事项。
   • 重构偏好：如果对于适合自主处理的事项而言，范围明确的整洁重构是更好的修复方式，就选择重构；不要默认采用会留下更差设计的“小补丁”。
3. 以最易维护的方式实现或修复 PR。若贡献者的 PR 可写入，优先更新该 PR；否则在本地重新创建，并注明贡献者。
4. 尽可能在本地和实时端到端验证。如果涉及 UI 行为，使用仓库预期的实时 UI 证明路径，例如 Peekaboo、browser-use、截图或虚拟机证明。如果涉及 API／服务商行为，在可用时通过预期的机密信息工作流使用真实且可用的密钥／账户。如果缺少访问权限，就在假装事项已完成之前停止，并向 Peter 求助。
5. 在提交／合并前运行 Codex Auto Review，除非改动极小、仅涉及文档或已明确跳过；处理已接受且可执行的发现。
6. 确保 CI 通过、PR 说明／变更日志内容完善，然后合并／关闭／评论并附上证据；接着返回 main，执行 pull --ff-only，并确认工作区干净后，再选择下一个自主事项。
7. 每个 PR 合并后，发布一条 PR 评论，准确说明测试方式：本地命令、实时／UI／API 证明、CI 运行／检查状态、已合并的提交，以及任何注意事项。如适用验证图片，则在可用时使用 gh image 上传／发布；如果上传工具不可用，应说明这一点，并附上截图路径或其他 GitHub 附件证明，不能默默省略图片。

自主模式结束时，不能留下脏文件或尚未推送的本地修复，除非遇到阻碍。如果受阻，应说明具体阻碍、当前分支／状态、已收集的证明，以及需要作出的下一步决策。

自主工作仍受范围限制：默认仅处理当前仓库；只有用户要求处理更广范围／所有事项，或点名所有者／组织时，才处理更广范围的队列。

信任信号

对于你建议采取行动的每个非维护者事项，都要说明作者／发起者的可信度。对于低风险的 Dependabot／内部事项，一行简短的机器人／内部信任说明即可。

优先使用内置辅助工具：

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

如果此技能的检出版本中没有该辅助工具，可使用以下替代方案：

~/Projects/clawdbot/.agents/skills/openclaw-pr-maintainer/scripts/github-activity.sh --repo <owner/repo> --global <login>

当 PR 需要更深入的信任判断时，也要使用 github-author-context，尤其是涉及 OpenClaw、安全敏感变更、大型 PR、新账号或作者行为异常时。优先查看现有贡献者备注：

~/Projects/maintainers/scripts/clawtributors find github <login>

信任说明必须基于事实：

Trust: @login; acct 2021-04-03; repo 2 PRs/1 issue/0 commits in 12mo; GitHub 9 PRs/3 issues/12 reviews; signal: known contributor / new drive-by / bot / unknown.

不要将信任视为证明。信任度会影响审查深度，而非正确性。

事项评估

对每个事项进行分类：

• bug：在可行的情况下，要求提供复现步骤／日志／失败测试／当前主分支证明；在建议修复或合并之前，先找出根本原因。
• feature：要求提供端到端测试计划。如果实时验证需要服务提供商密钥、账号、设备、服务、模型访问权限或付费 API，应明确说明工作完成还缺少哪些凭据／访问权限。
• dependency：说明软件包组、主／次版本风险、失败的检查、运行时／引擎变更，以及是否应拆分。
• security：提高优先级，要求仔细核实代码路径、测试和信任／背景信息；不能仅凭理由就合并。
• docs/internal：风险较低，但仍须说明对用户的影响以及内容过时／生成内容变更的风险。

判断以下各项：

• Fit：良好／一般／较差，并说明一个理由。
• Risk：低／中／高，并说明影响范围。
• Proof：当前 CI、本地复现、失败测试、实时 E2E，或缺少证明。
• Blocker：首次贡献者的 CI 审批、失败检查、缺少密钥、产品方向不明确、分支过时、不可信／范围过大的差异、无法复现、冲突。
• Next：批准 CI、运行测试、要求提供复现步骤、拆分 PR、本地修补、检查通过后合并、提供证明后关闭，或暂缓。

快速队列概览

仅当范围较广时使用此功能。从仓库级队列概览开始。它会查找存在未关闭 issue 和／或 PR 的仓库，并提供数量统计。

PR 队列，优先分流顺序：

repobar_cmd repos \
  --scope all \
  --only-with work \
  --owner steipete \
  --owner openclaw \
  --sort prs \
  --json

Issue 压力，在第二轮处理（当 issue 很重要时）：

repobar_cmd repos \
  --scope all \
  --only-with work \
  --owner steipete \
  --owner openclaw \
  --sort issues \
  --json

只有当用户说“全部”“所有内容”，或要求考古式排查时，才使用 --forks 和 --archived。默认分流应排除 fork 和已归档仓库，除非它们的队列确实相关。

简洁的终端视图：

repobar_cmd repos --scope all --only-with work --owner steipete --owner openclaw --sort prs --plain

实用的 jq 汇总：

repobar_cmd repos --scope all --only-with work --owner steipete --owner openclaw --sort prs --json |
  jq -r '.[] | [.fullName, .openIssues, .openPulls, .activityTitle, .activityActor] | @tsv'

汇总按 PR 数量排序的队列时，保留 RepoBar 的 PR 数量排序。对于同一所有者范围内的仓库，不要遗漏 PR 数量更多的仓库，却纳入 PR 数量更少的仓库。即使没有 issue，只要有未关闭的 PR，例如 openclaw/crabbox，也仍与分流相关。

详细检查

完成宽泛的队列概览后，只检查排名靠前的仓库，除非用户明确要求穷尽细节。

repobar_cmd issues <owner/name> --limit 50 --json
repobar_cmd pulls <owner/name> --limit 50 --json
repobar_cmd ci <owner/name> --limit 20 --json
repobar_cmd activity <owner/name> --limit 20 --json

对于看起来可合并或可疑的 PR，切换到 gh 查看维护者级别的状态：

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

对于可能已修复的 issue，切换到 gh issue view，然后检查当前源代码，再发表评论或关闭 issue。

对于 OpenClaw／ClawdBot 队列，必要时使用 OpenClaw 维护者检查流程：

• 如果有 gitcrawl，使用它搜索重复项／相关讨论串；
• 使用活动辅助工具核实发起者／作者身份；
• 除非用户要求处理维护者负责的工作，否则过滤掉顶级维护者产生的噪声；
• 优先处理外部／用户报告的 bug，以及有明确证明的 PR。

本地交叉检查

当任务提到本地项目状态、工作区有未提交更改，或询问“我在这里负责什么”时使用此功能。

repobar_cmd local --root "$HOME/Projects" --depth 1 --limit 200 --plain
repobar_cmd local --root "$HOME/Projects" --depth 1 --sync --limit 200 --json

除非用户明确要求，否则不要执行破坏性本地操作（local reset、删除分支、移动检出位置）。

分诊启发式

优先处理：

• CI 通过或接近通过、维护者近期有活动，或涉及低风险依赖项／文档／测试变更的 PR。
• 开放 PR 数量较多但近期仍有活动的仓库，因为其中往往藏有明显的清理机会。
• 可复现、近期报告或阻碍发布的问题。
• 优先处理安全、发布、身份验证、安装、CI 和数据丢失报告，再处理外观问题。
• 能在当前主分支上明确复现且负责人路径清晰的 Bug。
• 仅在可以进行实时验证或明确说明缺少的访问权限时，才处理功能请求。

降低优先级：

• 已归档的仓库，除非用户提出要求。
• 仅在 Fork 中排队等待的事项，除非 Peter 正在积极维护该 Fork。
• 缺少复现步骤或负责人线索的陈旧、宽泛功能请求。
• 远程仓库缺失或可移除的仓库，直到本地状态得到确认。
• 需要无法获取的 API 密钥或账号才能进行端到端验证的功能／提供方 PR。
• 缺少明确用户问题、测试计划或可信作者线索的宽泛生成式变更。

输出格式

对于当前项目分诊，请按以下格式回答：

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

Immediate:
- #123 PR: title
  What: one-line summary in plain words.
  Type/Fit/Risk: bug|feature|dependency; good|mixed|poor; low|medium|high because ...
  Trust: @login; acct date; repo/global activity; known/unknown/bot.
  Proof: CI/repro/test/e2e state.
  Blocker: none / missing key / first-time CI approval / failing lint / unclear direction.
  Next: exact maintainer action.

Needs judgment:
- #124 issue: ...

Defer/close:
- #125 issue: ...

Skipped:
- <why>

对于广泛扫描，请按以下格式回答：

Owners scanned: steipete, openclaw
Source: RepoBar <command summary>, plus gh for selected PRs/issues

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

Immediate actions:
- <small obvious merge/fix/comment/rerun, with item summary>

Needs judgment:
- <larger/ambiguous queues, with item summary>

Skipped:
- archived/forks/missing access/etc.

当用户要求采取行动时，继续执行：使用 gh 检查选定的 PR／问题，重新运行或修复 CI；只有在有证据时才发表评论、关闭或合并，并报告确切的命令和验证依据。