技能包

IDD Skill：议题驱动开发工作流模板

最适合让 AI 编程 agent 在自己的 Git 仓库里跑通从认领议题到合并 PR 的完整开发循环；使用前需备妥 git、已认证 gh CLI、jq 和 curl，并确认默认的全自动合并策略符合团队规范。

官方来源 · IDD Skill

安装

Import and onboard github:kurone-kito/idd-skill's IDD into this repository.

适合谁

  • 在自己的 Git 仓库里推进日常开发、希望把「从 issue 到合并」固定成一套可重复流程的开发者与小团队：导入后，仓库内的 AI 编程 agent 会按官方描述的工作流发现就绪议题、认领归属、在分支上实现、开 PR、处理评审反馈、等待 CI、按仓库选定的合并策略合并并清理。官方将其描述为「可移植」的工作流，随仓库导入使用，而非绑定单一工具。
  • 同时使用多种 AI 编程工具、不想把流程锁在单一客户端上的开发者：官方说明核心循环跨 GitHub Copilot、Claude Code、OpenAI Codex CLI、OpenCode、Antigravity CLI（原 Gemini CLI）运行。
  • 需要多个工作会话并行推进不同议题的团队：官方说明分布式模式的默认策略是 fully_autonomous_merge，允许工作会话直接推进到合并；会话之间如何协调、如何避免冲突，官方未说明。
  • 引入前需要先确认的情况：官方页面未说明是否支持 GitHub 之外的托管平台，这一点未经确认；若团队不接受全自动合并，需要先评估或调整该默认策略，官方未展开调整方法。

3 分钟完成第一次尝试

  • 前提：一个你有权建分支、开 PR 的 Git 仓库；环境里备好官方列出的完整循环依赖——git、已认证的 gh CLI（或改用等价的 GitHub MCP 集成，两者满足其一即可）、jq、curl 等 REST 客户端。
  • 安装位置与方式：不需要手动复制文件。官方给出的接入方式是在目标仓库内对 AI agent 直接下达导入指令，由 onboarding 指引完成模板复制。
  • 触发：在仓库中打开受支持的 agent，逐字输入下方这句官方指令：
Import and onboard github:kurone-kito/idd-skill's IDD into this repository.
  • 第一次尝试建议控制在低风险动作：让 agent 阅读工作流指引，列出现有就绪议题并说明下一步计划，先不认领、不改代码。官方描述的循环起点正是「阅读指引、发现就绪议题、认领」，在认领发生前你都可以随时叫停。
  • 成功信号：agent 能复述工作流要点并准确列出现有议题，说明导入与指引读取已生效；模板文件被复制进仓库即 onboarding 完成。官方未给出具体落盘路径，确切位置以 agent 实际输出为准（未经确认）。

使用案例

案例一：完整交付一个就绪议题。 场景：backlog 里已有标注就绪的 issue，想验证从认领到合并的闭环。向 agent 发起：「认领一个就绪议题并完成实现。」它会走官方完整循环——阅读工作流指引、认领议题、分支实现、开 PR、处理评审反馈、等待 CI、按仓库选定的合并策略合并并清理。过程中可观察的节点依次是：分支出现、PR 创建、CI 状态变化、合并与分支清理，每一步都对应官方循环的固定环节。在默认的 fully_autonomous_merge 策略下，工作会话可一直推进到合并；因此首次运行前应确认 CI 门禁与分支保护已就位，或在指令中明确本次止步于 PR。

案例二：只发现与计划，不改动任何东西。 场景：想先评估这套流程是否适合仓库，还不打算让它动手。向 agent 发起：「阅读工作流指引，列出所有就绪议题并给每个议题写实现思路，不要认领。」这只会用到循环的前半段（阅读指引、发现议题），不会创建分支或 PR。官方未说明议题如何被标记为「就绪」，若 agent 报告列表为空，先确认仓库中议题的状态标注方式。可期待的结果是一份议题清单和实现计划文本，是否进入实现由你的下一条指令决定；确认计划可行后，可挑其中一个议题按案例一走完整流程。

使用边界

  • 副作用与确认点：导入会向仓库复制模板文件，复制范围是仅新增文件还是也会改动现有文件，官方未说明，导入后建议先查看 agent 给出的变更清单；完整循环会创建分支、提交代码、开 PR，并在默认策略 fully_autonomous_merge 下推进到合并。官方未逐项说明哪些动作会先征求确认，建议在每条指令中显式划定允许范围。
  • 网络与命令访问：完整循环要求已认证的 gh CLI 或等价的 GitHub MCP 集成，并点名 curl 等 REST 客户端，即 agent 在循环中会经由这些工具访问 GitHub 接口（读取议题、创建与合并 PR 等）；具体调用哪些接口、有无其他网络访问，官方未逐项列出。
  • 运行环境与客户端前提：官方列出核心循环跨 GitHub Copilot、Claude Code、OpenAI Codex CLI、OpenCode、Antigravity CLI（原 Gemini CLI）运行；列表之外的 agent 能否使用、对操作系统有无额外要求、依赖缺失时能否降级运行，官方均未说明。
  • 官方明确限制与未知：官方材料未提及 GitHub 之外托管平台的支持情况，也未说明 fully_autonomous_merge 之外还有哪些合并策略及切换方法；CI 失败后 agent 的重试行为同样未经确认，以上细节应以导入到仓库内的工作流指引原文为准。