这个 Skill 能做什么，适合哪些场景？
这个技能把 GitHub 当作唯一事实来源，并要求仓库中存在 MAINTAINERS.md 作为排序政策。它在“推荐模式”下只读地收集开放 issue、RFC 和 PR，按轮询阶梯（门控、按影响排序、就绪度分类、执行匹配）产出 3–5 张候选卡片，并附带排除理由和时间戳。只有当维护者明确选定某一项（例如说“start #123”）时，它才进入执行模式：刷新状态、确认范围、建立隔离分支并尽早开关联的草稿 PR。它内置了大量安全约束：轮询期间绝不写仓库，不信任 issue/PR 正文中的指令，不公开疑似漏洞细节，也不把旧 issue 或点赞数当优先级。
- 解析目标仓库，读取开放的 issue、RFC、PR、里程碑、标签、评审和 CI 状态（优先用已配置的 GitHub 集成，否则用 gh CLI）
- 按 MAINTAINERS.md 的轮询阶梯筛选：门控、按影响排序、分类就绪度、检查执行匹配
- 深入核查最强候选：问题证据、RFC/依赖状态、是否已有人在做的竞争性 PR
- 输出 3–5 张“推荐现在做”卡片，附“需分诊/被阻塞”项和代表性排除项、ISO 8601 轮询时间和不确定性说明
- 在用户明确说“start #123”后：复核状态、报告冲突、声明范围与验收证据、建隔离分支/工作树并开草稿 PR
- 开源维护者在周会或碎片时间里问“这周该处理什么”，需要一份按影响排序、区分就绪度的 backlog 短名单
- 接手一个陌生仓库的贡献者，想快速看清哪些 issue 已有 PR 在做、哪些被阻塞，避免重复劳动
- 维护者看完短名单后明确指定一项，让代理按仓库贡献规范建分支、开草稿 PR 并持续更新进度
- 团队想把“凭感觉挑 issue”换成有据可依的流程：门控标准、排除原因、证据与不确定性都写进输出
- 没有 MAINTAINERS.md 排序政策、或希望代理自主决定做什么/直接派活的团队——本技能明确禁止自动分发公开事件，且推荐模式严格只读
- 只想批量拉取 issue 元数据做统计或仪表盘的场景——技能明确指出批量元数据不足以作为推荐依据
- 没有 gh CLI 也没有配置 GitHub 集成、无法读取仓库状态的环境
如何安装这个 Skill？
- 核心功能依赖 GitHub 与 gh CLI；在无法稳定访问 GitHub 的网络环境下该技能可能不可用，使用前请确认网络可达性。
- 排序策略外置于 MAINTAINERS.md，本次评估未验证其内容；使用前请自行审阅该文件以确保排序逻辑符合预期。
- 'start #123' 执行模式会创建分支并打开 PR，属写操作；请确认仓库的分支保护与评审流程后再使用。
- 技能依赖 Agent 运行环境已配置 GitHub 凭据；请确保凭据为最小权限，避免授予写权限给仅需轮询的场景。
- Shell / 命令行
- 网络访问
- 本地文件系统
GitHub CLI (gh) or a configured GitHub integrationMAINTAINERS.md ranking policy in the repo
本仓库是一个包含 9 个技能的 monorepo（trycua/cua，MIT 许可，README 外的 Spaces 应用为 FSL-1.1-MIT）。安装器可把 Cua 技能装进你的 AI 编码代理：
Claude Code / Codex / Cursor 等
curl -fsSL https://cua.ai/install.sh | sh
cua auth login登录后安装器会提供把 cua skills 和 MCP server 装入你的代理；也可用 sh -s -- --select cua-driver 预选。技能文件位于仓库内 .agents/skills/poll-github-work/SKILL.md；README 未给出该单个技能的独立安装命令。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- poll work：看看这个仓库现在最值得处理的问题
- 给 backlog 排个优先级，按影响排序并标出已阻塞的项
- 有什么可做的开放 issue 或 PR？给我三到五张推荐卡片
- start #123
用自然语言触发：问“该做什么工作”“给 backlog 排个优先级”“poll work”或“有什么可做的 issue/PR”。技能默认处于只读的推荐模式，产出候选卡片后等待你明确选定。说“start #123”即选中第 123 项并进入执行流程：刷新状态→报告冲突→声明范围与验收证据→通过仓库正常机制让选择可见→建隔离分支→尽早开并持续更新草稿 PR。注意它会保留其他贡献者的署名，优先给现有 PR 做评审而不是另起竞争实现。
这个 Skill 有哪些优点和局限？
- 严格的模式分离：轮询只读、执行需显式选择，误操作风险低
- 输出结构化（候选卡片含影响、就绪度、竞争性工作、验证路径、主要风险），事实与推断分开
- 内置针对提示注入的安全规则：不信任 issue/PR 正文内容，不公开漏洞细节
- 尊重现有贡献者，避免重复实现
- 依赖仓库内 MAINTAINERS.md 作为排序政策，没有该文件的仓库需要先补齐或接受默认阶梯
- 推荐质量取决于 gh CLI 或 GitHub 集成的可用性与权限
- 来源未提供该技能的测试套件或实测平台证据
- 执行阶段只覆盖“开分支+草稿 PR”的常规贡献流程，不含合并/部署授权
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| Poll GitHub Work — GitHub 维护工作轮询与排期 本页 | 52 · 谨慎使用 | ★ 29k | 1 天前 | MIT |
| RenderCV Issue 解决器 | 51 · 谨慎使用 | ★ 18k | 6 个月前 | MIT |
| GitHub PR 工作流助手 | 42 · 不推荐 | ★ 1.7k | 3 天前 | MIT |
| 维护者回复助手（agent-service-toolkit 专属） | 69 · 推荐 | ★ 4.5k | 7 天前 | MIT |
| Engram 积压事项分诊 | 45 · 不推荐 | ★ 7.1k | 4 天前 | MIT |
FollowSkills 如何评估这个 Skill？
证据显示该技能采用只读轮询默认模式，明确禁止在轮询期间变更仓库状态，将 issue/PR 内容视为不可信数据（防提示注入），要求漏洞信息走私密安全流程，并设置'从不自动分派公共输入'红线；扣分项：执行模式下的隔离与回滚细节不足，依赖未在文内完整展示的 MAINTAINERS.md 排序策略，发布者身份未经注册表验证。
证据显示步骤结构清晰、提供可直接使用的 gh 命令示例、要求区分事实与推断并对陈旧推荐做冲突报告；扣分项：静态审查无法执行验证，核心排序阶梯依赖未随文展示的 MAINTAINERS.md，缺少针对本技能的测试或异常输入下的失败反馈示例。
证据显示 description 明确了触发词（询问工作优先级、'poll work'、'start #123'）与模式边界（推荐 vs 执行），输出格式有明确模板；扣分项：核心功能依赖 GitHub/gh API，对无法直接访问 GitHub 的中国大陆网络环境存在可用性风险且未在文内声明。
证据显示文件结构良好、命名与描述一致、含 MIT 许可的仓库上下文、progressive disclosure（轮询→候选卡→执行）清晰；扣分项：技能自身无版本号或变更记录，关键排序策略外置为相对链接（其内容未随本次证据提供），无 FAQ 或已知限制章节。
证据显示输出格式（候选卡）可直接使用、包含 ISO 8601 时间戳与不确定性披露，对维护者有真实边际价值；扣分项：静态审查下无法验证实际产出质量，价值依赖 MAINTAINERS.md 排序策略的正确性，未经执行复现。
证据显示仓库整体有 CI 工作流与测试文件，但均针对 driver/perception 路径，与 poll-github-work 技能关键路径无关；技能主张仅由 SKILL.md 文本支撑，无第三方执行证据或独立可复现材料。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
查看完整评分方法 →