parallel

仅当用户要求时，才并行处理任务。否则，在本次会话中逐个执行任务。任务彼此独立，才有并行的保障。并行执行只是更省力的方式。

1. 选择模式。默认模式是 Partition：任务彼此独立，且不共享文件或状态；每项任务分配一个子 Agent。Race 是针对同一项任务进行多次完整尝试，详见 race.md。Coverage 是将一项工作拆分成多个部分，并进行完成情况检查，详见 coverage.md。相互关联的问题不适合任何一种模式。先一起调查这些问题。
2. 对于 Race 或 Coverage，先说明成本：需要多少个子 Agent，以及需要进行多少次完整尝试。只有用户同意后才能启动。
3. 对于 Partition，为每位执行者提供简要说明，写明其范围、背景、约束和预期返回内容。范围应限于一个文件、一个子系统或一个问题。“修复所有测试”对单个 Agent 来说范围太大。将背景信息写入说明：错误消息、测试名称和相关路径。Agent 无法获取本次会话中的任何内容。约束应说明哪些内容不得更改，例如“仅修改测试”或“不要改动生产代码”。预期返回内容应包括根本原因摘要和所做的更改，以便你审查整合结果。
4. 同时启动所有子 Agent。每位需要编辑文件的执行者都应在自己的 git worktree 中工作，避免多个执行者共用同一检出目录。新的 worktree 只包含已提交的文件，因此应从干净的检出目录启动执行者。
5. 收到结果后整合。worktree 中的执行者应通过补丁或分支提交更改，而不是直接修改此检出目录。阅读每份摘要。使用 git apply --3way 应用补丁，或合并相应分支。根据意图解决冲突。确认批次完成前，先运行 verify 技能。完整门禁会覆盖整个测试套件。

规则：

• 以下三种情况不适合 Partition：问题彼此相关，修复其中一个可能解决其他问题；问题原因尚不明确；或者各 Agent 会修改相同文件。
• Race 不会对不同设计取平均。当各次尝试的方案形态不同时，说明说明写得不够明确。重写说明。Coverage 必须先定义完成情况检查，才能启动。
• 执行者的 worktree 和分支会在任务结束后保留，以便执行者继续工作。批次通过 verify 后，可提出清理这些目录。只有用户同意后才能清理。