cook-fast

[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 的变体——跳过研究、采用最少规划的快速实现。

快速摘要

目标： 以最少的研究和精简的规划快速实现功能。

工作流：

1. 侦察 — 快速扫描代码库以了解模式
2. 计划 — 制定轻量级实现计划
3. 实现 — 执行并进行代码简化审查

关键规则：

• 跳过深入研究；依赖代码库中的模式
• 实现前仍需获得用户批准
• 将工作拆分为待办任务；添加最终自我审查任务

前端/UI 上下文（如适用）

当任务涉及前端或 UI 变更时，

UI 系统上下文 — 对于任何涉及 .ts、.html、.scss 或 .css 文件的任务：

实现前必须特别注意阅读：

1. docs/project-reference/frontend-patterns-reference.md — 组件基类、存储、表单
2. docs/project-reference/scss-styling-guide.md — BEM 方法、SCSS 变量、混入、响应式设计
3. docs/project-reference/design-system/README.md — 设计令牌、组件清单、图标

项目专属路径请参考 docs/project-config.json。

• 组件模式：docs/project-reference/frontend-patterns-reference.md
• 样式/BEM 指南：docs/project-reference/scss-styling-guide.md
• 设计系统令牌：docs/project-reference/design-system/README.md

保持怀疑，运用批判性思维和顺序思维。每项断言都需要可追溯的证据和置信度百分比（Idea 应超过 80%）。

立即开始处理以下任务，尽量减少规划： $ARGUMENTS

模式： FAST——跳过研究，尽量减少规划，相信你的知识。

工作流

1. 快速规划（跳过研究阶段）
   • 直接分析任务要求
   • 使用 TaskCreate 创建最精简的待办列表
   • 不使用研究员子 Agent，不运行 scout 命令
   • 对于非简单任务：在实施前，将简要分析写入 .ai/workspace/analysis/{task-name}.analysis.md。

图谱辅助调查——当 .code-graph/graph.db 存在时，必须执行。

**硬性门槛：**调查结束前，必须注意在关键文件上至少运行一条图谱命令。

**模式：**Grep 查找文件 → trace --direction both 揭示完整系统流程 → Grep 验证细节

任务	最低图谱操作
调查/侦察	对 2-3 个入口文件运行 trace --direction both
修复/调试	对有问题的函数运行 callers_of 和 tests_for
功能/增强	对要修改的文件运行 connections
代码审查	对已更改的函数运行 tests_for
影响范围	运行 trace --direction downstream

CLI：python .claude/scripts/code_graph {command} --json。先使用 --node-mode file（噪声减少 10-30 倍），再使用 --node-mode function 查看细节。

实施后，对已修改的文件运行 python .claude/scripts/code_graph connections <file> --json，以确认无需更新相关文件。

图谱追踪快速检查

当图谱数据库可用时，实施前运行一次快速下游追踪：

• python .claude/scripts/code_graph trace <file-to-modify> --direction downstream --json — 快速检查下游影响

2. 快速实施

   • 直接对任务使用 /code
   • 跳过多步骤规划文档
   • 优先编写可运行的代码，而非文档

3. 快速验证

   • 运行类型检查和编译
   • 手动抽查，代替完整测试套件
   • 跳过代码审查员子 Agent

4. 提交（可选）

   • 通过 AskUserQuestion 询问用户是否准备好提交
   • 如果准备好了，使用 /commit

适用场景

• 需求明确的简单功能
• 有已知解决方案的 Bug 修复
• 重构任务
• 用户说“直接做吧”时

权衡

方面	快速模式	完整模式
研究	跳过	多个 Agent
规划	最简	完整规划文档
测试	快速检查	完整测试套件
审查	跳过	代码审查员
速度	快约 2 倍	全面

---

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

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

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

如果已经处于工作流内，则跳过——工作流会处理步骤安排。

收尾提醒

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

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

• 强制重要必须注意 每项论断都要引用 file:line 证据（置信度 >80% 才能采取行动）

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

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

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

• 强制重要必须注意 按阶段添加带有 TC ID 的 ## 测试规范。创建新任务前调用 TaskList。

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

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

• 强制重要必须注意 进行任何 UI 更改前，阅读 frontend-patterns-reference、scss-styling-guide、design-system/README。

• 强制重要必须注意 若 graph.db 存在，至少对关键文件运行一条图命令。模式：grep → 图追踪 → grep 验证。

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

• 必须注意 落实 AI 错误预防措施——优先整体排查，在责任所在层修复，编码前明确说明模糊之处，压缩上下文后重新阅读文件。

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