SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场keep-the-pool-full

keep-the-pool-full

办公与效率

查看项目

更新于 10-29 05:29

技能介绍

keep-the-pool-full 是一个“待办池管家”技能：当实施、评审和合并已经自动化之后，瓶颈转移到上游的“工作供给”。智能体若没有定义清晰的任务可接，要么空转，要么自行发明工作。该技能的目标是维持一个池子，里面的 issue 都是真实的、可独立合并的、小型的、可验收的且不重复的，让智能体可以自行领取、完成并合入。人的职责从“构建 X”转变为设定池子目标与来源。

何时使用：就绪 issue 数量低于目标，或按当前吞吐量将在一天内低于目标；交付循环或多个工作自动化反复报告 NOOP（无合格工作）；按计划运行（每日，或活跃运行期间每几小时一次）。

何时不使用：没有人或自动化在消费池子（提交没人领取的 issue 只是噪音）；工作需要尚未做出的产品决策（此时应为人提交一个决策 issue）；仓库维护者尚未同意由智能体提交 issue（先询问一次；在他人仓库默认使用 DRY_RUN）。

运行步骤：

  1. 测量池子：按 POOL_QUERY（默认 is:open is:issue label:ready no:assignee）统计开放 issue 数量；统计最近 7 天每日关闭或分配的就绪 issue 作为消耗量；覆盖率 = 池子规模 / 日消耗量，单位为天。
  2. 决定是否提交：若覆盖天数 ≥ TARGET_DAYS，则结束并输出 NOOP(pool healthy: N issues, C days)，不发布任何内容；否则缺口为 ceil(TARGET_DAYS × 消耗量) − 池子规模，并受 MAX_FILED_PER_RUN 上限约束。
  3. 按 SOURCES 顺序挖掘来源，每个候选须引用读者可核查的证据：失败或被隔离的测试及 flake 跟踪 issue；带无主、局部修复的 TODO/FIXME；规范、文档或参考实现与代码之间的差距；仓库或其 issue 中已有的审计与报告输出（性能、可访问性、安全、依赖）；已确认但缺少可执行任务的用户报告；已合并 PR 描述或评审回复中承诺的后续事项。
  4. 按检查清单将候选塑造成 issue；超过 SIZE_CAP 的须拆分为独立 issue，而非依赖链；无法做到可独立合并的候选应丢弃或转为一个人工决策 issue。
  5. 去重：在开放及近期关闭的 issue 和开放 PR 中搜索相同文件、符号、测试名或错误字符串；在正文嵌入来源指纹（<!-- pool-source: <kind>:<path-or-test>:<hash> -->）并在提交前搜索；若已有匹配，则在该 issue 上评论一次新证据（若允许），而不是新提交。
  6. 提交并打标签：用 READY_LABEL 和区域标签创建 issue；永远不分配；消费者通过分配或关联 PR 领取工作。
  7. 报告：每次运行一行：pool: before → after (target T, coverage C days), filed n, skipped-duplicate d, dropped k；未提交任何内容时保持静默。

Issue 质量检查清单：标题说明变更而非症状；Why 一句话加来源证据链接；Done when 为可观测的验收检查（理想是现在失败、改后通过的命令或测试，写不出则说明 issue 未就绪）；Loop 说明实施者如何验证；Scope hint 指出可能改动的文件或区域及范围外内容；Size 预期 diff 小于 SIZE_CAP、一个 PR、不依赖其他开放 issue 的顺序；Safety 不复制来源中的密钥、凭据、内部链接或个人数据。

可调参数：POOL_QUERY（默认 is:open is:issue label:ready no:assignee）、TARGET_DAYS（默认 2 天消耗量）、MAX_FILED_PER_RUN（默认 5，在无效率未知前保持较低）、SIZE_CAP（默认一个 PR、约 200 行改动）、SOURCES（默认 tests、todos、gaps、audits、reports、follow-ups，可按优先级取子集）、READY_LABEL（默认 ready）、Mode（自有仓库 file，其他仓库 dry_run）、Autonomy（L0，仅 issue，本技能从不写代码）。

作为自动化运行：使用 automate-it，触发间隔 daily（或活跃交付期间每小时）；所需工具包括 github/search_issues、github/search_pull_requests、github/issue_read、github/get_file_contents、github/search_code、github/actions_list、github/get_job_logs、github/list_label、github/create_issue、github/update_issue_labels，去重评论开启时还需 github/add_issue_comment；write_scope 为 repository。建议先以暂停状态创建并 dry-run 一次，阅读候选清单后再启用。

输出：带 ready 标签的新 issue，每个含证据、验收检查、验证循环和规模；运行摘要或账本中的每次运行记录。

自反馈循环：按来源每周跟踪领取率（在 TARGET_DAYS 内被领取）、已合并/已提交比、无效率（以未计划、重复或无效关闭；某来源超过 20% 则收紧或放弃该来源）、池覆盖率随时间变化；若池子每天清零则调高 TARGET_DAYS 或 MAX_FILED_PER_RUN，若 issue 超过 14 天无人领取则调低。

它预防的失败模式：工人空转或自行发明工作；过大且耦合的 issue 拖住评审与 CI；多个智能体挖掘同一故障产生的重复 issue；无法判断何时完成的“就绪”issue。