用途：仅当用户希望并行实现时使用。它把请求拆成多个可独立交付的部分，并行构建后合并到一个分支并验证，不执行 polish，也不打开 pull request；之后应运行 polish，再运行 ready-pr。请求可包含 issue、书面指令或两者，书面指令决定构建内容，working-on-issue 负责查找 issue 及其分支。
必要工具与技能：使用前需确认 Claude Workflow 工具、working-on-issue、new-branch、implement、tdd、code-review、resolving-merge-conflicts、to-tickets、polish、ready-pr、codebase-design 均可用；缺失时停止并指出，提供其当前来源的项目本地安装命令。
主要步骤：先运行 working-on-issue；若无 issue，提示后续提交和 PR 可能需要 issue 引用，然后继续在当前分支工作。用 to-tickets 作为规划指南，把请求拆成能贯穿各受影响层、各自可验证的部分，记录每部分构建内容、验证方式和依赖，不创建跟踪 issue。对重命名共享符号等大范围机械改动，改用三阶段：新增形式与旧形式并存、分批迁移调用方、全部迁移后删除旧形式。将拆分结果以编号列表展示给用户，包含标题、依赖、实现和检查，询问部分大小与依赖，用户批准后才开始实现。统计可并行启动的部分，若少于两个可同时运行，则用 implement 在当前分支继续。按依赖顺序分组，每组用 Claude Workflow 工具以 isolation: 'worktree' 为每个独立部分启动一个 agent，只给该部分的工作与检查，每个 agent 使用 implement 和 tdd。每组完成后用 resolving-merge-conflicts 合并到同一分支，运行仓库文档中的检查；涉及产品或设计决策的冲突需询问用户。依赖部分从合并后的分支开始。全部部分合并且检查通过后结束。
最终报告：分支及合并的部分、部分数与依赖组数、是否并行或仅一次 implement、已解决冲突与需用户决策的冲突、验证结果、后续步骤 polish 和 ready-pr。