用途：issue-flow 用于把 GitHub Issue 转化为已合并的 PR，编排完整开发周期。启动时需声明使用该技能，初始请求通过 $ARGUMENTS 传入。
主要能力与流程： 阶段0 预检：运行 gh auth status 验证 GitHub CLI 登录；解析参数（#123、123、Issue URL 或空则用 gh issue list --state open --limit 20 让用户选择）；用 gh issue view <N> --json number,title,body,labels,comments,assignees,state 获取详情；检查已有分支 issue/<N>-*；检测测试框架、CI、linter 与主语言。 阶段1 工作区：用 EnterWorktree 创建隔离工作树，并创建分支 issue/<N>-<slug>。 阶段2 技术规划：并行启动 2-3 个 code-explorer 智能体探索代码库，阅读关键文件后设计技术方案（摘要、改动文件、实施步骤、测试策略、风险评估），按 rules/plan-format.md 格式化，用 gh issue comment 发布到 Issue，并加 <!-- issue-flow-plan --> 标记；随后用 AskUserQuestion 让用户批准、修改或取消，未获批准不得继续。 阶段3 团队执行：简单改动（1-2 文件、无跨模块、无独立测试/评审/文档）直接实现；否则用 TeamCreate 建团队，按 rules/team-roles.md 选角色，用 Task 工具生成队友，用 TaskCreate 建任务并设置依赖，TaskUpdate 分配协调。每个任务最多 2 次修复迭代，仍失败则询问手动修复/跳过/中止。完成后关闭并删除团队。 阶段4 PR 与 CI：提交并推送分支，用 gh pr create 按 rules/pr-template.md 创建 PR（含 Closes #N），向 Issue 发布实现摘要（标记 <!-- issue-flow-impl -->），用 gh pr checks <PR_NUMBER> --watch --fail-fast 检查 CI；失败可自动修复（最多2次）、手动或中止；通过后询问合并、保持开放或请求评审。 阶段5 清理：合并后确认 Issue 是否自动关闭，否则用 gh issue close <N> --comment 关闭，并输出完成摘要。
限制与原则：所有重大决策需人工确认；评论使用 HTML 标记保证幂等；工作全部在 worktree 中进行，合并前不触碰主分支；中断后可重跑 /issue-flow #<N> 恢复，详见 references/recovery-guide.md。具体收费、平台支持等信息暂未提供。