| name | team-issue-batch-implement |
| description | 按依赖顺序批量编排多个工程 issue 的实现与验证，并保留失败即停和可恢复续跑边界。Batch orchestrate multiple engineering issues in dependency order with verification, fail-fast behavior, and resumable boundaries. |
| license | MIT |
| metadata | {"author":"coolbeevip","version":"1.0"} |
| triggers | ["批量实现 issue","连续处理多个 issue","批量跑工程任务","一次实现多个 AFK issue","批量最小改动实现","批量不要过度设计","不要扩大 issue 范围","batch implement issues","implement multiple issues","run issue queue","process AFK issues in bulk","lean batch implementation","avoid batch over-engineering","keep issue scope minimal"] |
Issue 批量实现编排
这个技能用于在 team-prd-to-issues 或 team-tech-debt-to-issues 产出多个工程 issue 后，恢复批量处理能力。它只做队列编排、依赖排序、停机条件和进度汇总；单个 issue 的实现仍必须交给 team-issue-implement，验证仍必须交给 team-issue-verify。
核心原则：批量选择，单个执行，逐个验证，失败即停，可恢复继续。
当用户说“批量最小改动实现”“批量不要过度设计”“不要扩大 issue 范围”“lean batch implementation”等表达时，批量编排仍只负责排队和停机条件；每个 issue 必须按 team-issue-implement 的最小实现模式独立执行，不得因为批量处理而合并 scope、引入无关重构或提前实现后续 issue。
触发边界
- 适合触发：用户要按依赖顺序连续处理多个可执行 issue，并需要失败即停、逐个验证和可恢复进度。
- 不适合触发：用户只指定一个 issue 时，转交
team-issue-implement；用户只是要验证已完成实现时，转交 team-issue-verify。
运行时配置
在读取 issue 目录、PRD、评审或代码前，先读取目标项目根目录的 team-spec/config.yml。如果存在 access_policy，必须先应用目录访问边界，再进入任何批量执行或写入流程。
language: zh-CN
version_control:
system: git
trunk_branch: main
contribution_model: fork-pull
source_remote: origin
target_remote: upstream
access_policy:
mode: default-readonly
directory_file: team-spec/access_policy/default.md
user_file_template: team-spec/access_policy/{user_name}.md
language：批量计划、对话回复和输出汇总的统一语言。version_control：仅在需要衔接发布技能或判断主干分支时使用。access_policy：目录访问策略索引。缺失时默认只读；如果本次任务必须写入目标项目而配置又缺失，先询问是否创建最小配置。
输入物
主输入必须能唯一定位一组 issue：
team-spec/active/{slug}/issues/- 或用户显式提供的多个本地 issue 文件路径。
参考输入可以包括：
team-spec/config.yml，用于确定语言、版本管理系统、主干分支和贡献方式。team-spec/active/{slug}/prd/prd.md，用于确认父 PRD 与需求边界。team-spec/active/{slug}/spec/reviews.md，用于识别风险、HITL 决策点和 blocker。team-spec/CONTEXT.md、team-spec/decisions/、team-spec/active/{slug}/spec/CONTEXT.md、team-spec/active/{slug}/spec/decisions/。- 当前代码库、测试、ADR、验证命令和现有实现。
必须先确定唯一 slug、issue 目录或明确的 issue 文件列表。如果无法唯一判断，要停止并要求用户提供 slug、目录或文件列表，不要扫描 team-spec/archive/ 猜测。
输出物
- 批量执行计划：可执行队列、跳过项、阻塞项、依赖顺序和批量上限。
- 每个已处理 issue 的实现和验证结果，仍回写原 issue 文件。
- 可选批量汇总报告：
team-spec/active/{slug}/issues/batch-implementation.md，用于记录本轮队列、完成项、停止原因、验证命令和剩余队列。
本技能不直接修改 PRD、规格评审或产品决策。发现需求问题时，应停止并反馈给上游技能或人工决策。
固定脚本
批量执行前，优先使用本技能目录下的固定脚本生成队列计划，不要临时手写依赖排序：
./scripts/plan_issue_batch.py
脚本能力：
- 读取
team-spec/active/{slug}/issues/ 或显式 --issues-dir。
- 解析 issue 标题、
Type、Status、Blocked by 和文件名前缀。
- 按
Blocked by 做依赖排序，识别循环依赖、缺失依赖、HITL issue 和已完成 issue。
- 输出可批量处理的 AFK 队列；默认只生成计划，不执行代码变更。
- 支持
--limit N 限制本轮最多处理的 issue 数量。
- 支持
--json 输出机器可读计划。
推荐用法：
python3 {skill_dir}/scripts/plan_issue_batch.py --slug {slug}
python3 {skill_dir}/scripts/plan_issue_batch.py --slug {slug} --limit 3 --json
其中 {skill_dir} 是当前技能目录。技能内部定位脚本时应使用相对 SKILL.md 的路径 ./scripts/plan_issue_batch.py，执行命令时再解析成实际文件路径。
批量边界
默认只处理 AFK（可独立执行，无需人工决策） issue。以下 issue 必须跳过：
HITL（需要人工介入） issue。- 缺少验收标准的 issue。
Blocked by 指向未完成、缺失、循环或 HITL issue 的任务。- 已经处于
verified、pr-created、mr-created 或等价完成状态的 issue。兼容读取旧值 ready for PR、PR created、MR created、done、completed。
- 实现范围明显跨出父 PRD 或当前 slug 的 issue。
默认批量上限为 3 个 issue。用户明确要求“全部可执行 issue”时可以处理更多，但仍必须逐个验证，且任何失败都立即停止。
最小实现模式
- 批量编排不得改变单个 issue 的验收边界。
- 每个 issue 执行前都要确认最小实现路径、可复用代码和被拒绝的复杂方案。
- 不要把多个小 issue 合并成一次跨模块重构。
- 不要为后续 issue 提前新增抽象、配置层、通用框架或依赖。
- 如果某个 issue 的最小正确实现需要扩大范围，应停止批量执行并说明证据。
- 批量实现不能把“相邻 issue 可能也会用到”作为提前抽象的理由；只有当前 issue 的验收标准需要时才允许扩展。
- 每个 issue 的最终记录必须独立说明复用了什么、跳过了什么复杂方案、何时才需要升级为更复杂方案。
工作流
- 确定 slug、issue 目录或用户指定的 issue 文件列表。
- 读取
team-spec/config.yml、父 PRD、评审报告和必要上下文。
- 检查工作区状态。若存在与本轮无关的未提交变更，先说明风险并停止，除非用户明确要求在当前工作区继续。
- 运行
./scripts/plan_issue_batch.py 生成执行队列。
- 向用户展示批量计划：本轮将处理哪些 issue、跳过哪些 issue、为什么跳过、批量上限是多少。
- 如果用户已明确要求批量执行且队列规模不超过默认上限，可以继续；否则先等待用户确认。
- 按队列顺序对每个 issue 执行
team-issue-implement 的完整工作流，并保留最小实现模式的复用、跳过复杂方案和验证记录。
- 每个 issue 实现结束后，立即执行
team-issue-verify。
- 只有当前 issue 达到
verified 或用户明确接受的完成状态，才继续下一个 issue。
- 记录本轮完成项、验证命令、停止原因、未处理队列和需要人工介入的事项。
停止条件
遇到以下任一情况，必须停止批量执行：
- 当前 issue 验证结果不是
verified。
- 测试失败、验证命令缺失且无法从项目文档推断。
- 发现未解决的 HITL 决策点。
- 依赖关系变化、循环依赖、缺失 blocker 或 blocker 未完成。
- 当前实现需要修改 PRD、规格评审或产品决策。
- 代码变更范围明显超出当前 issue 或混入无关重构。
- 工作区出现无法归因到本轮 issue 的新变更。
- 当前 issue 的实现开始依赖后续 issue 的假设、提前抽象或跨 issue 合并改动。
停止不是失败。停止后输出已完成进度、停止原因和下一步可选动作，确保用户可以修正后继续批量执行。
执行约束
- 不要把多个 issue 合并成一个实现说明；每个 issue 都必须保留独立实现记录和验证记录。
- 不要跳过
team-issue-verify。
- 不要自动执行
git commit、git push、创建 PR/MR 或发布 issue。
- 不要自动修改
team-spec/archive/。
- 不要为了跑完整批量而降低测试或验收标准。
- 如果批量过程中发现拆分过薄或依赖设计错误，应停止并建议回到
team-prd-to-issues 合并或重排。
完成标准
最终回复必须包含：
- 本轮批量范围和实际处理数量。
- 已完成 issue 列表及各自验证状态。
- 跳过或阻塞的 issue 及原因。
- 每个已完成 issue 是否保持单独最小路径，是否复用现有实现并拒绝无关复杂方案。
- 运行过的关键验证命令和结果。
- 是否保留未提交本地变更，以及没有执行
git commit / git push。
- 有序号的“下一步可选”，例如继续下一批、处理 HITL、回到拆解合并过薄 issue、进入 PR/MR 创建。
推荐“下一步可选”：
## 下一步可选
1. `team-issue-batch-implement`：继续处理下一批可执行 AFK issue。
2. 完成人工决策：先处理被 HITL 或 blocker 卡住的 issue。
3. `team-prd-to-issues`：如果发现 issue 过薄或依赖不合理，回到拆解阶段合并或重排。
4. `team-issue-create-pr-github` / `team-issue-create-mr-gitlab`：当前批次已验证完成后，按项目平台创建 PR/MR。
最终回复
必须包含：
- 本批次计划处理、已完成、失败和被阻塞的 issue。
- 每个已处理 issue 的最终生命周期状态和验证结论。
- 执行停止原因；正常完成时说明是否仍有可执行 issue。
- 未解决的 HITL、外部 blocker 和恢复入口。
- 有序号的“下一步可选”列表。
