GitHub Project Triage 是一个面向 GitHub 仓库维护者的分诊技能，来源于 steipete/agent-scripts。它的核心用途是把仓库中开放的 issue 和 PR 整理成维护者可判断的条目卡片，而不是只给出队列编号或难以理解的引用。每条被呈现的事项都需要包含 GitHub URL，且 URL 要出现在该条目所在的第一行或第一句话中；如果给出候选清单，则每条打印一个 URL。
主要能力方面，该技能覆盖分诊的多项要素：URL、每个 issue/PR 的内容、为什么重要、作者可信度、适配度、风险、证明/测试状态、阻塞项以及下一步动作。它要求在采取任何评论、关闭、合并、重跑或打补丁动作前，必须拥有强证据。分诊输出通常分为三类：可自主处理候选（看似无需更多产品输入即可修复或落地，需给出 URL、符合条件的理由、所需验证与信心度）、需要 Peter（因产品方向、缺少凭据、无法取得的实时提供方证明、安全隐私判断或负责人评论要求修改而阻塞的事项）、以及延后/关闭/取代（过期、重复、质量较低或重叠、且可能动作不是新代码的事项）。
使用方式上，技能区分当前项目分诊与宽泛队列扫描。若用户输入 triage 且当前工作目录是带有 GitHub 远程仓库的 Git 仓库，则只分诊该项目；除非用户明确说 broad、all、everything，点名多个 owner/org，或要求跨仓库分诊。当前项目分诊从 gh issue list 与 gh pr list 开始，对约 10 个开放条目以内的小队列检查全部，对更大的队列只检查优先级最高的切片并说明未展开的部分。宽泛扫描使用 RepoBar 做第一轮队列发现，默认 owner 为 steipete 与 openclaw，对 openclaw/openclaw 需要做细节检查；它要求保留 RepoBar 的 PR 数量排序，不遗漏同 owner 范围内 PR 更多的仓库。
技能还定义了自主工作模式。当用户说 do work autonomously、keep going 等类似指令时，技能会把它视为逐个处理符合条件的 issue/PR 队列的许可，直到没有安全的自主条目、每个条目都以证据落地/关闭/延后，或出现需要 Peter 的阻塞。它明确要求不得同时处理多个工单，并对每个条目的处理流程、本地验证、实时/UI/API 证明、Codex Auto Review、CI 绿灯、落地证据与返回 main 分支后的清洁工作树核对作了规定。对于可信度，技能要求对每个建议行动的非维护者条目给出作者可信度，且可信度输出须保持事实性，不能把可信度当作正确性证明。
适用场景包括：在某个仓库内进行常规 issue/PR 分诊；跨多个 owner/org 的宽泛队列扫描；在局部项目中做核对，例如查看本地项目状态、脏仓库或“我在这里拥有什么”。技能还给出了条目评估分类（bug、feature、dependency、security、docs/internal）、评分维度（Fit、Risk、Proof、Blocker、Next）、分诊启发式与优先级规则，以及当前项目分诊和宽泛扫描两种输出形态。
限制方面：技能要求在本地项目开始工作前先做 Local Repo Gate 检查，只有分支为 main、pull 成功且工作树干净时才能继续，否则停止并询问，不得擅自切换分支、stash、commit、reset、restore 或 clean。对于新功能、产品/愿景选择、宽泛行为变更、有风险的依赖、无强证明的安全敏感变更、无可用凭据的实时提供方工作、无法端到端测试的事项，必须先询问。技能不包含收费、价格、平台或效果等事实信息，相关细节暂未提供。