用途
Parallel Execution Optimizer 适用于“速度来自同时执行相互独立工作”的场景，例如仓库检查、文件读取、API 检查、浏览器检查、构建/测试通道、部署回读，以及多 worktree 的实现过程。它的目标是把紧迫感转化为行动前的依赖图，而不是盲目并发。
核心模式
技能给出的核心流程是：
- 定义目标与完成信号。
- 把工作拆分为多个通道（lane）。
- 将每个通道标记为并行、串行或受门控（gated）。
- 把相互独立的读取/检查放在一起运行。
- 写入按文件、worktree、分支、服务或数据集隔离。
- 只有在证据表明各通道兼容后才合并。
- 以验证表收尾，而不是给出含糊的提速声明。
通道矩阵
在大型推进之前，先写一个紧凑的矩阵，包含以下列：通道、能否并行、写入面、风险、验证方式。资料给出的示例包括：
- 仓库扫描：可并行，无写入面，低风险，验证为 rg/git status 输出。
- 后端补丁：也许可并行，写入面 src/api，中风险，验证为单元测试。
- 前端补丁：也许可并行，写入面 app/components，中风险，验证为浏览器截图。
- 部署回读：构建后执行，写入面为远程服务，高风险，验证为线上 URL 加日志。
只有当各通道的写入面不冲突时，才并行运行它们。
执行规则
- 批量执行文件读取、搜索、状态检查和元数据查询。
- 对大型且互不相关的实现通道，使用隔离的 worktree。
- 把长时间运行的测试、构建、回填和部署放到独立会话中启动，然后有意识地轮询它们。
- 如果某个通道发现会改变计划的阻塞点，暂停依赖它的通道并更新矩阵。
- 除非用户明确要求持续运行的服务，否则不要让后台进程存活超过本轮对话。
- 不要并行化破坏性命令、迁移、对同一张表的写入，或影响线上客户的部署，除非有明确的门控。
输出形态
报告时使用如下结构：
并行执行结果：
- 运行的通道数：5
- 完成的通道数：4
- 被阻塞的通道：部署回读，等待 DNS 传播
- 发现的快速路径：批量仓库扫描 + 聚焦测试
- 验证：lint 通过、单元测试通过、线上冒烟通过
失败模式
资料列出的失败模式包括：
- 并发过多导致编辑冲突。
- 对工具做基准测试，而不是对任务做基准测试。
- 在正确性被证明之前就把“快”当作完成。
- 忘记轮询正在运行的会话。
- 把被跳过的检查隐藏在成功总结背后。
适用场景与限制
该技能适合需要同时推进多个独立工作流的任务，尤其是读取、检查、构建、测试和部署回读等可分离的环节。限制方面，资料明确要求：写入面冲突时不得并行；破坏性命令、迁移、同表写入和影响线上客户的部署在没有明确门控时不得并行；后台进程不应超出本轮对话存活。关于收费、价格、平台支持等具体信息，资料暂未提供。