# Blitz：并行工作树 + 代理工作流程通过在隔离的 git 工作树中运行独立的 Claude 代理来并行化多问题冲刺。每个代理创建一个 PR，自我审查至 10/10，问题覆盖率为 100%，然后按顺序合并 PR 以避免冲突。放牧🐲。 ## ⚠️ 强制：每个代理 100% 的问题覆盖率 **每个代理必须 100% 实施其指定问题的要求，然后才能合并其 PR。** * 每个代理都会收到完整的问题要求（摘自 GitHub 问题） * 审核必须验证所有要求均已实施 * 覆盖率 < 100% = 代理被送回完成工作 * 在解决问题的所有要求之前，不会合并 PR ## 先决条件 **所需工具：** * `gh` CLI（已验证） * 支持工作树的 Git (2.5+) * 带有代理生成的 Claude 代码（任务工具） **所需技能：** * `4-step-program` \- 指导代理完成修复-审查-迭代-呈现循环 * `code-reviewer` \- 自我审查至 10/10 质量门 * `delphi` \- 用于分类决策的并行预言机（可选，用于不明确的分类） ## 工作流程阶段 ### 第 1 阶段：问题分类对于要解决的问题的模糊决定，请使用“delphi”技能：调用 Delphi：“审核这些未解决的问题。对于每个问题，建议：关闭（完成）、修复（可操作）或推迟（阻止）。” **解释德尔福结果：** * 一致同意 → 根据建议采取行动 * 2/3同意 → 倾向于多数人，调查少数人的观点 * 完全分歧 → 需要更多背景；手动调查 **立即关闭完整问题：** gh 问题关闭 1 2 3 --comment“根据 Delphi 审核完成” 对于明确的问题列表，请跳过 Delphi 并直接进入第 2 阶段。 ### 第 2 阶段：工作树设置从 main 中为每个可修复问题创建一个工作树： git worktree add .worktrees/ -b fix/ main **分支命名：** `fix/` 或 `feat/` **4 个问题的示例设置：** git worktree add .worktrees/test-isolation -b 修复/test-isolation main git worktree add .worktrees/config-theater -b 修复/config-theater main git worktree add .worktrees/wire-salience -b 修复/wire-salience main git worktree add .worktrees/testing-quality -b 修复/testing-quality main **为什么选择工作树：** * 每个代理的完整文件系统隔离 * 没有存储/结帐冲突 * 代理真正并行工作 * 每个都有独立的node_modules，构建工件 ### 第 3 阶段：委托给并行代理使用带有结构化提示的任务工具生成代理。每个代理需要： 1. **工作目录**（工作树的绝对路径） 2. **问题背景**（数量、描述、验收标准） 3. **问题中所有要求的完整列表**（通过“gh问题视图”提取） 4. **使用四步编程技巧的明确说明** **关键：在委派之前，从每个问题中提取所有要求：** gh 问题视图在代理提示中列出每个要求、接受标准和边缘情况。 **代理提示模板：** 工作目录：/absolute/path/to/.worktrees/ 问题：#<编号> - <标题> **发布的所有要求（必须 100% 得到实施）：** 1. [问题要求1] 2. [问题要求2] 3. [问题要求3] ...（列出所有）使用四步计划技巧可以： 1. 实施上述所有要求（要求覆盖率100%） 2. 运行测试，验证是否通过 3. 使用“gh pr create”创建 PR - **必须在正文中包含“Closes #”** 4. 使用代码审查员技能进行自我审查（将验证 100% 覆盖率） 5. 使用“gh api”将评论发布到 GitHub **公关必须包括：** - `Closes #` 在合并时自动关闭问题 - 公关正文中的“相关问题”部分 - 使用“gh pr view --json openingIssuesReferences”进行验证在您达到 10/10 审核分数且 100% 已实施问题要求且问题已正确链接之前，请勿返回。 **重要：** 代理必须将评论发布到 GitHub，而不仅仅是打印它们： gh api repos/OWNER/REPO/pulls/NUMBER/reviews \ -f 正文 =“...” -f 事件 =“评论” **在一条消息中使用多个任务工具调用并行启动代理。 ### 第 4 阶段：回顾迭代循环监控每个 PR 的审核状态： gh pr 视图 --json 评论 --jq '.reviews[-1].body' **每个 PR 必须通过两个大门：** **GATE 1：100% 问题覆盖率** * 验证原始问题的所有要求均已实施 * 如果缺少任何要求 → 恢复缺少要求的代理 **GATE 2：10/10 审查质量** * 审核中零建议 * 所有验证命令通过 **如果覆盖率 < 100%：** 恢复具有特定缺失要求的代理： PR # 覆盖率：80%（5 项要求中的 4 项）。缺少要求：[问题中的要求 5 - 具体文本] 执行此要求并重新审查。 **如果分数 < 10/10（但覆盖率 100%）：** 恢复代理并提供具体反馈： PR # 覆盖率为 100%，但得分为 8/10。问题： - <具体问题1> - <具体问题2> 修复这些问题并重新审查。 **10/10 + 100% 覆盖标准：** * **原始问题的所有要求均已实施** * 所有功能均正常工作 * 测试通过 * 没有明显的错误或安全问题 * 代码遵循项目约定 * 如果需要更新文档 ### 阶段 4.5：最终覆盖门（合并前） **强制**：在合并任何 PR 之前，请执行逐行要求验证。对于准备合并的每个 PR： #### 第 1 步：提取所有要求 # 获取问题中的所有清单项目 gh 问题视图 <问题编号> --json body --jq '.body' | grep -E "^\- \[" # 还可以获得完整的散文要求 gh 问题视图 <问题编号> #### 步骤 2：创建逐行表每个 PR 的 **强制**： ## 问题 #X - 完整要求检查 |要求|公关状态 |证据| |------------|------------|----------| | [问题的确切文本] | ✅ | `file.cs:line` - [实现] | | [问题的确切文本] | ❌ 失踪 |公关中未找到 | | [问题的确切文本] | ⚠️ 部分 | `file.cs:line` - [缺少什么] | | [问题的确切文本] | ⚠️ 手册 |需要 Unity 编辑器 | #### 第 3 步：诚实评估 **诚实的评估**： - 覆盖率：X%（Z 要求中的 Y 完全实施） - 缺失：[列出具体项目] - 部分：[列出项目和缺少的内容] - 手册：[列出需要编辑器/运行时的项目] **最终门决定：** 覆盖范围|行动 ---|--- **100%** | ✅ 进入第 5 阶段（合并） **< 100%** | ❌ **请勿合并** \- 恢复代理 **如果最终覆盖率 < 100%：** 恢复代理：“PR # 的最终覆盖门失败。问题 #X - 完整要求检查： |要求|状态 |证据| |-------------|--------|----------| | MeshDeformer 组件已创建 | ✅ | MeshDeformer.cs | |创建场景游戏对象 | ❌ 失踪 |无场景修改| |缓存命中率>90% | ⚠️ 手册 |需要运行时分析器 | 诚实评价： - 覆盖率：85%（13 项要求中的 11 项） - 缺少：场景游戏对象创建 - 部分：无 - 手动：缓存命中率验证实施标记为❌的所有项目。可以通过 mcp-unity 自动化的标记为 ⚠️ MANUAL 的项目必须自动化。在覆盖率达到 100% 之前请勿返回。” **→ 循环回到第 4 阶段（审核迭代）** ### 第 5 阶段：顺序挤压合并 + 变基一次合并一个 PR。按依赖关系排序（基础设施优先）。 **合并之前，验证问题链接：** # 验证 PR 将关闭问题 gh pr view --json openingIssuesReferences --jq '.endingIssuesReferences[].number' # 如果为空，则 PR 缺少问题链接 - 发送代理回来修复！ **对于每个 PR：** # 1. Squash 合并（保持历史记录干净）- 合并时问题自动关闭 gh pr 合并 --squash --delete-branch # 2.更新本地main git checkout 主要 && git pull # 3. 将下一个 PR 重新设置为更新后的 main cd .worktrees/ git fetch origin 主要 git rebase 起源/主要 git push --force-with-lease git push --force-with-lease # 4. 为下一个 PR 重复合并 **为什么这个订单：** * 挤压合并保持主要历史线性 * 合并前变基可防止冲突 * 顺序合并尽早发现集成问题 * `--force-with-lease` 防止覆盖其他人的工作 **处理冲突：** git rebase 起源/主要 # 如果发生冲突： # 1.修复受影响文件中的冲突 # 2. git add <固定文件> # 3. git rebase --继续 # 4. git push --force-with-lease ### 第 6 阶段：清理所有 PR 合并后： # 删除工作树 git worktree remove .worktrees/ # 对每个重复 # 删除本地分支（远程已经被--delete-branch删除） gitbranch -D fix/ # 对每个重复 # 同步主线 git checkout 主要 && git pull # 验证干净状态 git worktree list # 应该只显示 main gitbranch # 应该只显示 main ## 快速参考请参阅“references/commands.md”以获取完整的命令参考。有关常见问题和解决方案，请参阅“references/pitfalls.md”。 ## Blitz PR 中的美人鱼图 **当变更需要可视化时，每个代理的公关应该包括美人鱼图。** ### 代理何时应添加图表更改类型 |图解 ---|--- 流量变化|之前/之后的“流程图” API修改 | `序列图` 状态处理| `状态图-v2` 架构变更 |带有子图的“流程图” ### 代理委托应包括委托给代理时，添加到提示中：如果您的更改涉及流程修改、状态更改或 API 交互，在公关正文中包含显示新行为的美人鱼图。 ### 带图表的 PR 示例 ## 总结修复了 WebSocket 重新连接中的竞争条件。 ### 之前/之后 ````美人鱼流程图LR 之前的子图 A1[断开连接] --> B1[重新连接] B1 --> C1[重复处理程序] 结束子图之后 A2[断开连接] --> B2[清理处理程序] B2 --> C2[重新连接] C2 --> D2[单个处理程序] 结束 ```` ## 相关问题 - 关闭 #45 - WebSocket 重新连接错误 ** ** ## 清单摘要 1. 分类问题（如果不明确，请使用“delphi”） 2. **从每个问题中提取所有需求**（`gh问题视图`） 3. 为每个可修复的问题创建工作树 4. 通过 4 步程序启动并行代理 **包括完整的要求列表** 5. 监控和迭代，直到所有 PR 达到 **100% 问题覆盖率和 10/10** 6. **FINAL COVERAGE GATE** ：每次合并前重新验证 100% 覆盖率 7. 顺序挤压合并，并在其间进行变基（仅在通过门之后） 8. 清理工作树和分支 9. PR 包括有帮助的美人鱼图

闪电战

包含技能