Batch Task Executor 是一个实验性的工作流技能，用于协调和编排来自任意来源的大量相关任务。它的定位是规划和编排模式，而不是固定的 CLI 契约，不同运行环境下的并行分发工具可能有所不同。
用途 该技能适用于需要批量处理相似任务的场景，例如逐项审计文件、组件、包、服务、事件、PR、工单、迁移目标或客户记录，将同一套审查标准应用到多个输入，为待办列表或跟踪器生成结构化摘要，执行多个边界清晰的独立修复或调查，以及并行化重复性的研究、验证或代码库探索。文档明确列出不适用的情况：只有一个任务、任务之间紧耦合且需要统一编辑计划、并行执行可能破坏共享状态、或用户需要对每个任务做实时交互决策。
核心机制 技能强调输入不定义工作流。CSV、Markdown 清单、Jira 看板、文件夹、粘贴的列表、测试矩阵、包列表或直接的用户提示，都只是获取工作项集合的方式。稳定的契约包括：确定如何读取任务源；确定如何用状态和可选注释更新任务源，包括如何标记进行中；把任务规范化为带稳定 ID 和来源引用的工作项；探查足够的上下文以判断范围、风险、顺序、依赖和冲突；把清晰简单的任务与阻塞、模糊、危险或互斥的任务分开。在交互模式下，只询问会实质性影响安全或正确性的澄清问题；在非交互模式下，标记困难、阻塞或不明确的项目并继续处理安全的项目。
执行计划与运行模式 技能要求为每个批次建立执行计划，分离顺序前置任务与安全的并行分组，在安全与写入策略约束下执行，并在把跟踪器项目标记为完成前验证所报告的结果。文档提供四种运行模式：plan-only 模式只构建批次计划、项目模式、worker 提示和结果模式而不执行；execute 模式使用最佳的本地运行环境或子代理机制运行批次；resume 模式从持久化的项目或结果状态继续部分完成的批次；reduce-only 模式合并、验证或汇总已完成 worker 的输出。如果缺少运行环境支持或存在不安全因素，则回退到 plan-only 模式并给用户确切的命令或后续步骤。
所需批次计划字段 每个批次应包含 batch_goal（整体目标）、source（项目来源）、read_method（读取任务列表的方式）、update_method（回写状态和注释的方式）、in_progress_method（标记进行中的方式，如支持）、items（带稳定 item_id 的规范化记录）、dependency_map（必要顺序、互斥项、冲突和失效风险）、execution_groups（可一起委派的逻辑分组）、worker_instruction（单个任务的模板）、result_schema（每个 worker 结果的预期字段）、max_concurrency（保守选择的有界并行度）、write_policy（worker 是否可编辑文件或仅报告发现）、merge_policy（结果如何成为最终答案或产物）、verification_policy（如何确认覆盖、质量和失败）。
Worker 契约与结果字段 每个 worker 通常只获得一个项目，除非所选运行环境需要分块。当一组项目比一 worker 一项更安全或更高效时，也可以获得一小组一致的项目，例如同一组件中三项相关 UI 修复。不应仅为减少任务数而把无关项目分组，也不应把紧耦合的变更拆到会争抢同一代码的并行 worker 中。最小结果字段包括 item_id、status（completed、skipped、blocked、failed、pending 或 stale）、summary、evidence、next_action。当运行环境提供正式的结果报告工具时，worker 必须恰好使用该工具一次；没有此类工具时，要求 worker 的最终消息包含一个符合结果模式的 JSON 对象。
安全规则 技能列出多条安全规则：除非用户明确要求变更，优先使用只读 worker；绝不让多个 worker 编辑同一文件、数据库行、工单或外部对象；使用稳定的项目 ID，避免依赖行号；执行前确定每个项目应如何标记为完成、阻塞、失败或跳过；在跟踪器支持且不会造成噪音时，把项目或分组标记为进行中；不要盲目地把所有任务并行派出，先决定顺序、并行还是分组执行；按逻辑归属、涉及文件、子系统、依赖链和验证需求分组；先执行前置任务再执行依赖任务，尤其是测试或 UI 变更依赖后端或 API 变更时；除非用户明确说不验证，否则假定相关测试和检查是隐含的；在把跟踪器项目标记为完成前验证 worker 的说法；只有协调器或编排器写最终的跟踪器注释；只在失败与任务本身无关（如瞬态环境、工具或网络问题）时重试未完成的工作；遇到硬性任务阻塞时，标记为阻塞或待处理并用简洁说明代替盲目重试；优先更新用户现有的任务跟踪器而不是创建独立的状态系统；对阻塞、失败、有风险或有明显注意事项的已完成项目添加简洁注释；对平淡无奇的成功项目保持注释为空或最少，除非跟踪器或团队约定另有要求；默认保持适度的并发，仅当任务只读或用户要求速度时才增加；对长时间批次尽可能持久化项目列表和部分结果；如果任何 worker 未能报告，把该项目标记为失败并附上最后观察到的错误；摘要必须区分已完成工作与跳过、阻塞和失败的项目。
示例请求与输出预期 文档给出的示例请求包括：用该技能审查 components.md 中列出的每个组件；批量审计 Jira 工单并返回风险、负责人和下一步行动；给出 40 个迁移目标并分发，指出哪些有风险；检查此单仓库中每个包的已弃用 API；处理一个 CSV，但不要让工作流专门依赖 CSV。最终响应应包含：项目总数、完成、跳过、阻塞、失败的数量，如果产生了输出产物则给出其路径，主要发现或分组结果，未解决项目及其原因，以及建议的下一批次或后续行动。
限制 该技能自身标注为实验性，应首先视为规划和编排模式，而非固定 CLI 契约；不同运行环境下的并行分发工具可能不同。文档强调「如果缺少运行环境支持或存在不安全因素，则回退到 plan-only 模式」。关于收费、价格和具体平台支持，资料中暂未提供。