cook-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 生成/更新测试规范）

计划质量 — 每个计划阶段 MUST ATTENTION 包含测试规范。

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 的变体——通过子 Agent 并行实现多项任务。

快速摘要

目标： 使用并行的 fullstack-developer 子 Agent 同时实现多项独立任务。

工作流：

1. 计划 — 制定包含并行阶段和严格文件归属的计划
2. 分派 — 按阶段启动 fullstack-developer 子 Agent
3. 合并 — 集成所有变更并进行验证
4. 审查 — 运行 code-simplifier 并审查变更

关键规则：

• 各阶段的文件归属不得重叠
• 分派子 Agent 前必须获得用户批准
• 将工作拆分为待办任务；添加最终自我审查任务

保持怀疑。运用批判性思维和顺序思维。每项主张都必须有可追溯的证据和信心百分比（Idea 应超过 80%）。

并行执行以下任务以实现最高效率： $ARGUMENTS

模式： 并行 — 多个子 Agent 同时工作。

工作流

1. 任务分解

• 分析任务之间的独立性
• 将任务分组为可并行处理的工作单元
• 识别各单元之间的依赖关系
• 创建依赖关系图
• 外部记忆： 将任务分析写入 .ai/workspace/analysis/{task-name}.analysis.md。并行分派前重新读取。

2. 并行研究（如有需要）

同时启动多个 researcher 子 Agent：

Task A research ──┐
Task B research ──┼──► Synthesis
Task C research ──┘

3. 并行规划

• 使用 planner 子 Agent 整合研究结果
• 制定各阶段可安全并行执行的计划
• 标记文件归属边界（防止冲突）

4. 并行实现

启动多个 fullstack-developer 子 Agent：

Phase 1 (Backend API) ──┐
Phase 2 (Frontend UI) ──┼──► Integration
Phase 3 (Tests)       ──┘

关键： 每个子 Agent 必须遵守文件归属边界。

5. 集成与测试

• 合并并行输出
• 使用 tester 子代理进行集成测试
• 如果发现集成问题，使用 debugger

6. 审查与报告

• 使用 code-reviewer 进行最终审查
• 汇总所有更改
• 向用户报告

并行化规则

规则	描述
文件所有权	每个子代理负责特定文件，不得重叠
依赖顺序	遵循依赖关系图
最大并发数	最多 3 个子代理，以避免冲突
同步点	在各阶段之间设置集成检查点

适用场景

• 多组件功能（后端 + 前端）
• 跨独立模块的大型重构
• 并行编写测试
• 同步更新文档与代码

任务拆分示例

"Add user authentication with login UI"
├── Backend API (subagent 1)
│   ├── auth-controller.ts
│   └── auth-service.ts
├── Frontend UI (subagent 2)
│   ├── login-page.component.ts
│   └── login-form.component.ts
└── Tests (subagent 3)
    ├── auth.spec.ts
    └── login.e2e.ts

权衡

方面	并行	顺序
速度	快约 2-3 倍	基准
协调	复杂度较高	简单
冲突	存在合并问题的风险	无
上下文	在各 Agent 之间拆分	统一

---

后续步骤（独立调用：必须通过 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 系统地将其拆分为小型待办任务和子任务。