SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场implement-ticket

implement-ticket

编程与开发

查看项目

更新于 10-16 04:14

技能介绍

用途

implement-ticket 用于端到端实现一个 GitHub 工单（Issue）：在工单分支上完成实现，附带测试与运行时冒烟检查，确认应用仍可正常工作后再创建 PR。它既支持单人（solo）运行，也支持编排（orchestrated）模式：单人运行时主线程负责协调，worker 完成 Setup 及步骤 0 到 8；worker 无法调用仅限用户的技能，因此每次交接都会按路径指明该技能的根目录以及 worker 负责的步骤。worker 通过 open_questions 报告自动挑选、停止条件或问题，由协调者转达用户并派发答复。

主要能力

  • 解析工单编号：用户提供则直接使用；否则自动挑选编号最小的、标记为 ready-for-agent 的开放工单（排除 spec、未分配及带停止条件标签的工单），挑选前会先读取 references/auto-pick.md（该查询会先分页再选择）。若返回 null 则停止并询问，不直接实现 spec。
  • 读取并认领工单：通过 gh issue view <N> --comments 读取正文与评论，记录标题、验收标准、blocked-by 链接与范围标签。确认它是工单而非 spec；若已分配给他人需先说明。
  • 选择基础分支：默认使用仓库默认分支；检测 blocked-by（先查 GitHub 原生 issue-dependency 数据，再扫描正文中的 ## Blocked by 段落、Blocked by #12 / Depends on #12 等行、依赖段落中的任务列表引用或 blocked 标签）。若阻塞项已有分支，选择包含所有必需阻塞项 tip 的基础；若阻塞项尚无分支则停止并上报。记录不可变的 base_sha 与显式的 pr_base。
  • 创建工单分支：检查分支约定与 git status --porcelain，保留无关的脏工作，必要时使用隔离检出。从 SHA 而非移动的分支引用创建分支，名称保留 ticket-<N>-<slug>，并识别旧的 feat/ticket-<N>-* 与 feat/issue-<N>-* 分支。
  • 编辑前探索：搜索工单涉及的模块，阅读 AGENTS.md、CONTEXT.md 与 docs/adr/ 中的 ADR，匹配既有模式，不引入新基础设施。识别反馈循环命令（类型检查/静态检查、测试命令、运行命令），并在固定的干净 base_sha 上运行基线检查。
  • 实现：区分可测试的后端工作（采用 tracer bullets 红绿循环，一次一个测试）与其他工作（前端、探索性数据分析、notebook、一次性脚本等直接实现，依赖步骤 6 反馈循环与步骤 7 冒烟检查）。混合工单按部分拆分。单人运行在前 1–2 次提交内创建草稿 PR。
  • 反馈循环（标记 ready 前必需）：提交预期改动后运行类型检查/静态检查与测试套件，循环直到两者干净。基线通过的内容必须仍然通过；新增失败与类型错误由本次实现负责修复。
  • 运行时冒烟检查（标记 ready 前必需）：长运行应用（服务器/Web）后台启动、等待就绪信号、通过相关端点或 UI 验证改动行为、读取最后约 50 行日志、干净停止；CLI/库/脚本/管道运行入口点一次并确认退出码 0 且无新 traceback；文档或配置运行相关校验器并检查产物。
  • 审查与最终化 PR：阅读 git diff <base_sha>...HEAD，修复范围内问题（包括步骤 5 推迟的重构），提交修复并对受影响路径重跑步骤 6 和 7。单人运行遵循独立审查与单人最终化流程。
  • 工单生命周期评论：开始与停止工作时在工单上发布评论。开始评论在资格与工作区预检之后、实现之前发布；停止评论覆盖完成、阻塞、失败、暂停、取消与交接，包含 PR 或保留分支与 HEAD、剩余工作、失败检查或所需决策。使用 gh issue comment <N> --repo <owner/repo> --body-file <comment-file>，并记录返回的评论 URL。

使用方式

该技能以技能（skill）形式提供，通过技能运行环境调用。使用时提供工单编号与仓库；未提供编号时按自动挑选规则选择。单人运行会先以 standing 模式加载 orchestrator-mode。编排派发（feature dispatch）需先阅读 references/orchestrated.md，跳过步骤 0 到 3，用步骤 4 做本地探索，然后执行步骤 5 到 7 并在步骤 8 自审；协调者负责 PR、issue 操作与独立审查。

适用场景

适用于需要按工单范围实现 GitHub Issue 并产出带测试与冒烟验证的 PR 的开发流程，包括单人开发与多 worker 编排两种模式。

限制

遇到以下情况会停止并上报用户，不做即兴处理：工单带 needs-info、wontfix 或 needs-triage 标签，或已分配给他人；验收标准含糊或与代码库不变量矛盾；工单被尚无分支的工单/PR 阻塞；必需的非提交输入或重叠工作无法在无用户决策下安全使用；必需检查被阻塞且诊断或不同授权方式无法取得进一步有效进展。停止时保留工作并报告实际分支、HEAD、工作树路径、脏文件与推送结果。