cook-auto-parallel

[IMPORTANT] 开始之前，请使用 TaskCreate 将所有工作拆分为小任务——包括为每个文件的读取创建任务。这样可以避免因长文件导致上下文丢失。对于简单任务，AI 必须主动询问用户是否要跳过。

批判性思维 — 运用批判性思维和顺序思维。每项断言都必须有可追溯的证据，置信度超过 80% 才能采取行动。 防止幻觉： 切勿把猜测当作事实陈述——为每项断言注明来源，坦然承认不确定性，自查输出是否有误，独立交叉验证，对自己的判断保持怀疑——没有证据的确信是所有幻觉的根源。

防止 AI 出错 — 每项任务都要避免以下失误：

• 删除前检查下游引用。 删除组件会导致文档和代码连锁过时。移除前应梳理所有引用该组件的文件。
• 根据实际代码核验 AI 生成的内容。 AI 会凭空编造 API、类名和方法签名。记录或引用之前，务必使用 grep 确认其确实存在。
• 编辑后追踪完整的依赖链。 修改定义时，容易遗漏由此派生的下游变量和使用方。务必追踪完整链路。
• 验证正确性时追踪所有代码路径。 确认代码存在，不代表确认代码会执行。务必追踪提前退出、错误分支和条件跳过的情况，而不只是顺利路径。
• 调试时，先问“问题该由哪一方负责？”。 追踪问题是出在调用方（数据错误）还是被调用方（处理错误）。在应负责的层级修复——切勿只修补症状出现的位置。
• 假定现有值是有意设定的——修改前先问“为什么？”。 修改任何常量、限制、标志或模式前：阅读注释、查看 git blame、检查周边代码。
• 核验所有受影响的输出，而不只是第一个。 涉及多个技术栈的改动需要核验每一项输出。一个检查通过不代表所有检查都通过。
• 先整体、后局部地调试——避免只关注最近注意到的问题。 调查任何故障时，先列出所有前置条件（配置、环境变量、数据库名称、端点、DI 注册、数据前置条件），再逐项根据证据核验，之后才能对代码层面的问题作出假设。
• 精准修改——执行差异检查。 修复错误时，每一处改动都必须能直接对应到该错误。不要顺便调整或改进相邻代码。增强任务：实现改进，并明确说明改进内容。
• 编码前先指出歧义——不要默默自行选择。 如果请求有多种解释，应列出每种解释及其工作量估算并询问用户。切勿擅自假设应处理所有记录、采用基于文件的方案或选择更复杂的路径。

先理解代码 — 严格门槛：在阅读现有代码之前，不得编写、规划或修复。

1. 搜索至少 3 个相似模式（grep/glob）——引用 file:line 作为证据
2. 阅读目标区域中的现有文件——理解其结构、基类和约定
3. 如果 .code-graph/graph.db 存在，则运行 python .claude/scripts/code_graph trace <file> --direction both --json
4. 通过 connections 或 callers_of 梳理依赖关系——了解哪些内容依赖目标
5. 对于非简单任务（涉及 3 个以上文件），将调查结果写入 .ai/workspace/analysis/
6. 实现前重新阅读分析文件——切勿只凭记忆开展工作
7. 现有模式可用时，绝不要另创模式——应严格遵循，或说明偏离的原因

解除阻塞条件： - [ ] 已阅读目标文件 - [ ] 已 grep 至少 3 个模式 - [ ] 已追踪代码图（如果存在 graph.db） - [ ] 已用证据核实假设

• docs/project-reference/domain-entities-reference.md — 领域实体目录、关系和跨服务同步（任务涉及业务实体/模型时阅读）（内容由钩子自动注入——阅读前检查是否有 [Injected: ...] 标头）
• docs/specs/ — 按模块划分的测试规范（阅读现有 TC；实现后通过 /tdd-spec 生成/更新测试规范）

计划质量 — 每个计划阶段都必须包含测试规范。

1. 在每个阶段文件中添加 ## Test Specifications 部分，并使用 TC-{FEAT}-{NNN} ID
2. 将每项功能需求映射到至少 1 个 TC（或填写明确的 TBD 并说明理由）
3. TC ID 遵循 TC-{FEATURE}-{NNN} 格式——按 ID 引用，绝不嵌入完整内容
4. 执行任何新工作流步骤前：调用 TaskList 并重新读取阶段文件
5. 上下文压缩时：首先调用 TaskList——绝不创建重复任务
6. 将阶段标记为完成前，验证 TC 是否满足（证据必须为 file:line，不能是 TBD）

模式： TDD 优先 → 使用 Evidence: TBD 引用现有 TC。实现优先 → 使用 TBD → /tdd-spec 完成后续填写。

防止合理化 — AI 会通过以下借口跳过步骤。识别并拒绝：

借口	反驳
“计划太简单了”	简单任务加上错误假设等于浪费时间。照样制定计划。
“我之后会测试”	先 RED 再 GREEN。先编写／验证测试。
“已经搜索过了”	用 file:line 给出 grep 证据。没有证明就等于没搜索。
“直接做就行”	仍然需要 TaskCreate。可以简化步骤，但绝不能跳过跟踪。
“只是个小修复”	在错误位置做小修复也会引发连锁问题。先用 file:line 核实。
“代码不言自明”	后续读者需要证据链。无论如何都要记录。
“合并步骤能节省时间”	合并步骤会分散重点。每个步骤都有独特目的。

红旗停止条件 — 出现以下情况时，停止并通过 AskUserQuestion 向用户升级处理：

1. 对任何关键决策的信心低于 60%
2. 变更会影响超过 20 个文件（影响范围过大）
3. 正在跨越服务边界
4. 涉及安全敏感代码（身份验证、加密、PII 处理）
5. 检测到破坏性变更（接口、API 契约、数据库架构）
6. 变更后测试覆盖率会降低
7. 方案需要使用项目中不存在的技术／模式

未经用户明确批准，绝不可越过红旗继续执行。

技能变体： /cook 的变体——由 fullstack-developer 子 Agent 并行自主执行。

快速摘要

目标： 规划可并行执行的阶段，并派遣 fullstack-developer 子 Agent 并发实施。

工作流：

1. 规划 — 制定包含可并行执行阶段的计划（严格限定文件所有权）
2. 派遣 — 按阶段启动 fullstack-developer 子 Agent
3. 合并 — 整合结果并验证

关键规则：

• 每个子 Agent 负责特定文件；不得跨边界编辑
• 自主模式：阶段之间无需用户确认
• 将工作拆分为待办任务；添加最终自我审查任务

超前思考，并行实施：$ARGUMENTS

重要： 激活所需技能。确保高效使用 token。为简洁起见，不必拘泥语法。

保持怀疑，运用批判性和顺序性思维。每项主张都需要可追溯的证明和信心百分比（Idea 应高于 80%）。

工作流

1. 研究（可选）

• 如果任务复杂，最多并行使用 2 个 researcher Agent
• 使用 /scout-ext 搜索代码库
• 报告不超过 150 行
• 外部记忆： 将研究内容写入 .ai/workspace/analysis/{task-name}.analysis.md。并行执行前重新阅读。

2. 并行规划

• 触发 /plan-parallel <detailed-instruction>
• 等待包含依赖关系图、执行策略和文件所有权矩阵的计划

3. 并行实现

• 阅读 plan.md，了解依赖关系图
• 针对可并行执行的阶段，同时启动多个 fullstack-developer Agent
  • 示例：“阶段 1-3 并行” → 同时启动 3 个 Agent
  • 传入阶段文件路径：{plan-dir}/phase-XX-*.md
  • 包含环境信息
• 等待所有并行阶段完成后，再执行依赖它们的阶段
• 顺序执行的阶段：每次启动一个 Agent

4. 测试

• 使用 tester 子 Agent 执行完整测试套件
• 不得使用伪造数据、模拟或作弊手段
• 如果失败：使用 debugger 修复，然后重复测试

5. 代码审查

• 对所有更改使用 code-reviewer
• 如果发现严重问题：修复并重新测试

6. 项目管理与文档

• 如果获批：同时使用 project-manager 和 docs-manager
• 更新计划文件、文档和路线图
• 如果被拒绝：修复并重复流程

7. 最终报告

• 总结所有并行阶段
• 提供入门指南
• 询问是否提交（如果同意，则使用 git-manager）

示例： 阶段 1-3 并行 → 启动 3 个 fullstack-developer Agent → 等待 → 顺序执行阶段 4

---

后续步骤（独立使用：必须使用 AskUserQuestion 询问用户。若在工作流内，则跳过。）

强制、重要、必须注意——无例外： 如果在工作流之外调用此技能，必须使用 AskUserQuestion 提供以下选项。即使任务看起来“简单”或“显而易见”，也不得跳过——由用户决定：

• “继续完整工作流（推荐）” — 我会从当前进度（功能已实现）开始，判断最合适的工作流并继续。这可确保不会跳过审查、测试和文档步骤。
• “/code-simplifier” — 简化并清理实现
• “/workflow-review-changes” — 在提交前审查更改
• “跳过，手动继续” — 由用户决定

如果已在工作流内，则跳过——工作流会处理后续步骤。

收尾提醒

• 强制、重要、必须注意：开始前使用 TaskCreate 将工作拆分为小型待办任务

• 强制、重要、必须注意：创建新代码前，在代码库中搜索 3 个或更多相似模式

• 强制、重要、必须注意：每项主张都要引用 file:line 作为依据（置信度 >80% 才能采取行动）

• 强制、重要、必须注意：添加最终审查待办任务，以验证工作质量

• 强制、重要、必须注意：使用 AskUserQuestion 与用户确认决策——不得自行决定

• 强制、重要、必须注意：任何修改之前，都要搜索 3 个或更多现有模式并阅读代码。如果存在 graph.db，则运行图追踪。

• 强制、重要、必须注意：每个阶段都要包含带 TC ID 的 ## Test Specifications。创建新任务前调用 TaskList。

• 强制、重要、必须注意：无论任务看起来多简单，都要遵循所有步骤。“太简单，不值得规划”不是理由，而是在规避要求。

• 强制、重要、必须注意：连续 3 次修复尝试失败后必须停止。报告所有尝试，并在继续前询问用户。

• 必须注意：运用批判性思维——每项主张都需要可追溯的证据，且置信度 >80% 才能采取行动。防止幻觉：绝不能把猜测说成事实。

• 必须注意：采取 AI 错误预防措施——优先从整体着手调试，在责任所在的层面修复，编写代码前先明确歧义，压缩上下文后重新阅读文件。

[TASK-PLANNING] 行动前，分析任务范围，并使用 TaskCreate 将任务系统地拆分为小型待办任务和子任务。