cook

Codex 兼容性说明：

• 在 Codex 中使用 $skill-name 调用仓库技能；此镜像副本会将旧版 Claude /skill-name 引用改写为此形式。
• 任务跟踪要求：在执行任何工作流或技能步骤之前，先为所有步骤创建或更新任务跟踪，并随着进度变化保持同步。
• 需要向用户提问时，表示要在 Codex 中直接询问用户。
• 出现 Claude 专属的模式切换指示时，请忽略。
• 严格执行约定：用户明确调用某项技能时，必须按原样执行该技能协议。
• 子 Agent 授权：用户调用或 AI 检测到某项技能，且其协议要求使用子 Agent 时，激活该技能即表示授权为该任务调用所需的 spawn_agent 子 Agent。
• 除非用户事先明确批准偏离，否则不得跳过、重排或合并协议步骤。
• 对于工作流技能，须明确执行列出的每个子技能步骤，并逐步报告证据。
• 如果在此环境中无法运行某个必需步骤或工具，请停止并询问用户，然后再调整方案。

Codex 项目参考文档加载（无钩子）

Codex 不会通过 Claude 钩子注入文档。 编码、规划、调试、测试或审查时，请按照以下路径显式打开项目文档。

始终阅读：

• docs/project-config.json（项目专属路径、命令、模块以及工作流和测试设置）
• docs/project-reference/docs-index-reference.md（提供完整 docs/project-reference/* 目录的索引）
• docs/project-reference/lessons.md（始终适用的防护措施和反模式）

根据情况阅读文档：

• 后端/CQRS/API/领域/实体变更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• 前端/UI/样式/设计系统：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 规范/测试用例规划或 TC 映射：feature-docs-reference.md
• 集成测试实现/审查：integration-test-reference.md
• E2E 测试实现/审查：e2e-test-reference.md
• 代码审查/审计工作：code-review-rules.md，以及根据变更文件选择的领域文档

不要不加区分地阅读所有文档。请从 docs-index-reference.md 开始，然后只打开与任务相关的文件。

[BLOCKING] 按声明顺序执行技能步骤。未经用户明确批准，绝不跳过、重排或合并步骤。 [BLOCKING] 在每个步骤或子技能调用之前，更新任务跟踪：开始时标记为 in_progress，结束时标记为 completed。 [BLOCKING] 每个已完成或跳过的步骤都必须附上证据或明确的跳过原因。 [BLOCKING] 如果无法使用任务工具，请维护具有相同状态转换的等效逐步计划跟踪。

快速摘要

目标： 通过深入研究、全面规划和最高质量的验证来实现功能。

工作流：

1. 研究 — 深入调查，使用多个研究员子 Agent
2. 规划 — 通过 $plan 制定详细计划；须经用户批准
3. 实现 — 执行并进行完整的代码审查和 SRE 审查
4. 验证 — 运行所有测试、审查变更并更新文档

关键规则：

• 尽可能全面：研究 → 规划 → 实现 → 审查 → 测试 → 文档
• 规划阶段必须获得用户批准
• 将工作拆分为待办任务；添加最终自审任务

第一原则——易于更改

每个编码决策的成功指标都是_未来更改成本_。 DRY、SRP、抽象、设计模式、命名、分层、测试——每种 技术都服务于一个目标：降低下一次更改的成本。

评估代码、重构、测试或抽象时，请问： 这会让下一次更改成本更低还是更高？

• 拒绝会提高更改成本的“最佳实践”（过早抽象、 推测性通用设计、泄漏的间接层、没有收益的繁文缛节）。
• 在发现中指出真正的敌人：耦合、隐藏状态、重复的 知识、意图不明确、过早暴露且不可逆的决策。
• 易于更改的简单设计，胜过难以更改的复杂设计。

在应用以下任何具体规则、模式或清单之前，先用这一视角审视——如果后续规则会提高更改成本，以此原则为准。

---

默认模式策略

默认模式为 HARD（全面严格）。 默认情况下，以下每个部分都适用——深入研究、强制执行 $plan、完整的 code-reviewer 审查、强制测试、强制执行 $docs-update。

仅当以下条件全部满足时，才可选择快速模式（任务确实非常简单）：

• 单文件编辑，更改不超过 30 行
• 无设计选择（只有一种合理方案）
• 无跨服务影响、无契约更改、无新增依赖
• 无新模式——遵循现有代码库模式
• 现有测试覆盖更改，或更改不影响功能（拼写错误、注释、日志消息）

任何一项条件不满足 → 使用以下完整流程。 如有疑问，默认采用 HARD 模式。对非简单更改跳过审查或测试会导致缺陷上线。

**快速模式仅跳过以下内容：**研究员子代理阶段（改为直接使用 grep）、强制的 code-reviewer 审查（仅自我审查）、单独的测试阶段（在过程中验证）。不会跳过 $plan 步骤、测试执行、$docs-update 分类。

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

当任务涉及前端或 UI 更改时：

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

深入思考这些任务的规划与实施，并进行最大限度的验证：

保持怀疑。运用批判性思维和顺序思维。每项主张都必须有可追溯的证据，置信度须 >80% 才能采取行动。

$ARGUMENTS

**模式：**额外研究、详细规划、强制审查。

工作流

1. 深入研究阶段

• 并行启动 2-3 个 researcher 子代理，分别覆盖：
  • 技术方案验证
  • 边缘情况、故障模式
  • 安全影响
  • 性能考量
• 使用 $scout-ext 全面分析代码库
• 每份研究报告最多 150 行
• **外部记忆：**将所有研究内容写入 .ai/workspace/analysis/{task-name}.analysis.md。规划前重新阅读整个文件。
• **实施前追踪门槛：**对于缺陷修复、验证失败、最终输出过时或错误、回归，或会改变行为的修复计划，必须特别确认计划/引用的分析包含 Debugger Trace: End -> Start、所有馈入路径、假设矩阵、负责修复的层，以及前向收敛证明。若缺少其中任何一项，立即停止，并在编辑前列出缺失的追踪内容。

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

实施前的图追踪

图数据库可用时，在编写代码之前追踪影响范围：

• python .claude/scripts/code_graph trace <file> --direction both --json — 哪些代码会调用此代码，以及此代码会触发什么
• python .claude/scripts/code_graph trace <file> --direction downstream --json — 所有下游使用方
• 防止破坏隐式依赖（总线消息使用方、事件处理器）

2. 全面规划

• 使用 planner 子 Agent，并提供所有研究报告
• 创建完整的计划目录：
  • plan.md — 概述及风险评估
  • phase-XX-*.md — 详细的阶段文件
  • 每个阶段的成功标准
  • 回滚策略

3. 经验证的实现

• 一次实现一个阶段
• 每个阶段完成后：
  • 运行类型检查和编译
  • 运行相关测试
  • 继续之前进行自我审查

批次检查点（大型计划）

对于包含 10 个或更多任务的计划，分批执行并由人工审查：

1. 执行批次 — 完成接下来的 3 个任务（或用户指定的数量）
2. 报告 — 展示实现内容、验证输出及任何顾虑
3. 等待 — 说“准备好接收反馈”，然后停止。不要自动继续。
4. 应用反馈 — 纳入修改，执行下一批
5. 重复，直到完成所有任务

包含 10 个或更多任务的计划——不得不间断地连续执行所有任务而不设置检查点。 每批执行完毕后都要停止，等待人工审查。这样可以防止早期错误在后续任务中不断累积。

4. 强制测试

• 使用 tester 子 Agent 进行全面测试
• 为以下场景编写测试：
  • 正常流程场景
  • 研究中发现的边缘情况
  • 错误处理路径
• 不得使用模拟对象或伪造数据
• 重复测试，直到全部通过

5. 强制代码审查

• 使用 code-reviewer 子 Agent
• 解决所有严重和重大问题
• 修复后重新运行测试
• 重复审查，直到通过

6. 更新文档

• 使用 docs-manager 更新相关文档
• 使用 project-manager 更新项目状态
• 记录架构决策

7. 最终报告

• 总结所有更改
• 测试覆盖率指标
• 已处理的安全事项
• 尚未解决的问题（如有）
• 请用户审查并批准

适用场景

• 关键生产功能
• 安全敏感的更改
• 公共 API 修改
• 数据库架构更改
• 跨服务集成

质量门禁

门禁	标准
研究	至少 2 份研究报告
规划	完整的计划目录
测试	全部通过，不使用模拟对象
审查	严重/重大问题为 0
文档	如有需要则更新

---

后续步骤（独立执行：必须通过直接提问询问用户。若处于工作流中则跳过。）

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

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

如果已经处于工作流中，则跳过——由工作流负责安排顺序。

[IMPORTANT] 使用任务跟踪，将所有工作拆分为小任务后再开始——包括为每个文件的阅读创建任务。这样可以防止因长文件导致上下文丢失。对于简单任务，必须询问用户是否跳过。

• docs/project-reference/domain-entities-reference.md — 领域实体目录、关系及跨服务同步（任务涉及业务实体/模型时阅读）（相关时直接阅读；不要依赖钩子注入的对话文本）
• docs/specs/ — 按模块划分的测试规范（阅读现有测试用例；实现后通过 $tdd-spec 生成/更新）

从终点到起点的调试追踪 — 对于复杂 Bug、验证失败、回归修复、行为变更代码或代码流向不明确的情况，请从观察到的最终状态出发，反向追踪后再提出修复方案。

1. 帧 0：观察到的最终状态 — 指明确切的用户可见输出、失败断言、日志行、持久化值、API 响应、渲染的 UI 或聚合分桶。记录生成该结果的读取器／查询／渲染器，并提供 file:line 证据。
2. 每次向后追溯一跳 — 追踪最终读取器 -> 投影／缓存／存储 -> 写入器 -> 消费者／处理器／作业 -> 生产者／调用方 -> 原始触发。在每一跳记录：输入、转换、输出、负责人和证据。
3. 列出所有输入路径 — 找出所有可能写入最终路径的上游生产者／调用方／事件／作业，包括重试、异步、缓存、后台任务以及其他 UI／API 路径。将每条路径标记为已验证、已排除或仍未知。
4. 建立假设矩阵 — 对每个合理原因，列出支持证据、反对证据、复现／验证方法、影响范围和状态（primary、contributing、ruled out、latent）。在明确排除或限定其他竞争原因之前，不要修复。
5. 选择负责修复的层级 — 找出不变量的责任方，以及能够保护所有下游消费者的最低共享层。除非症状出现的层级负责该不变量，否则不得在症状出现处修复。
6. 正向证明收敛 — 选定修复方案后，再次从起点追踪到终点，说明修正后的状态如何到达观察到的最终输出。将每个根本原因对应到一项修复，并将每项修复对应到一个测试／证明。

满足以下条件前不得继续： 已指明最终状态 · 已撰写反向追踪 · 已列出所有输入路径 · 已完成假设矩阵 · 已论证负责修复的层级 · 已将正向收敛证明对应到测试。

切勿： 从第一个可疑代码路径开始。将多个生产者合并为一条“流程”。未经证明读取模型就把重复症状视为重复记录。跳过已排除的假设。

源代码／测试偏移检查。 对于编码、修复、调试、调查、测试或审查工作：当源代码行为发生变化时，检查受影响的单元／集成／E2E 测试，并依据证据判断测试应调整以符合预期行为，还是源代码变更本身是需要修复的意外 Bug。不要为迁移代码编写测试；架构／数据迁移是一次性执行路径，而非核心应用逻辑。 AI 错误预防 — 每项任务都应避免的失败模式：

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

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。

图辅助调查 — 当 .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 查看详情。 嵌套任务展开约定 — 对于工作流步骤调用，[Workflow] ... 行仅为父容器；子技能仍需创建可见的阶段任务。

1. 首先调用当前任务列表。如果存在匹配的活动父工作流行，则设置 nested=true 并记录 parentTaskId；否则独立运行。
2. 在阶段工作开始前，为每个已声明阶段创建一个任务。嵌套时，主题前缀使用 [N.M] $skill-name — phase。
3. 嵌套时，使用 TaskUpdate(parentTaskId, addBlockedBy: [childIds]) 将父任务与子任务关联。
4. 编排器必须先展开子技能的阶段列表，并关联工作流行，然后才能调用该子技能或子 Agent。
5. 开始工作前，恰好将一个子任务标记为 in_progress；证据写入后立即将其标记为 completed。
6. 只有在所有子任务均已完成或明确取消并说明原因后，才能完成父任务。

**解除阻塞条件：**当前任务列表已完成、子阶段已创建、嵌套时父任务已关联、第一个子任务已标记为 in_progress。

项目参考文档门禁 — 在任务跟踪初始化之后、读取目标文件/源文件、执行 grep、编辑或分析之前运行。项目文档优先于通用框架假设。

1. 确定范围：文件类型、领域和操作。
2. 按触发条件查阅所需文档：始终查阅 docs/project-reference/lessons.md；文档查找查阅 docs-index-reference.md；审查查阅 code-review-rules.md；后端/CQRS/API 查阅 backend-patterns-reference.md；领域/实体查阅 domain-entities-reference.md；前端/UI 查阅 frontend-patterns-reference.md；样式/设计查阅 scss-styling-guide.md + design-system/design-system-canonical.md；集成测试查阅 integration-test-reference.md；E2E 查阅 e2e-test-reference.md；功能文档/规格查阅 feature-docs-reference.md；架构/新领域查阅 project-structure-reference.md。
3. 阅读每份存在的必需文档；缺失的文档视为不适用并跳过。不要将对话文本（如 [Injected: <path>]）视为当前上下文中包含该文档的证明。
4. 开始目标工作前，声明：Reference docs read: ... | Missing/not applicable: ...。

**解除阻塞条件：**已评估范围、已检查/阅读所需文档、已确认 lessons.md、已给出引用。

任务跟踪与外部报告持久化 — 执行前先完成初始化；然后在处理目标/源文件前，预先查阅项目参考文档。

1. 在读取目标文件、执行 grep、编辑或分析前，创建简明的任务拆分。上下文丢失时，先检查当前任务列表。
2. 工作前将一个任务标记为 in_progress；证据生成后立即将其标记为 completed；不得批量转换状态。
3. 对计划/审查工作，在记录第一个发现前创建 plans/reports/{skill}-{YYMMDD}-{HHmm}-{slug}.md。
4. 每处理完一个文件/章节/决策后，追加发现；最后根据报告文件汇总。
5. 最终输出引用 Full report: plans/reports/{filename}。

**解除阻塞条件：**任务拆分已创建；计划/审查工作已声明报告路径；第一个发现已持久化，之后才能记录下一个发现。

批判性思维准则 — 运用批判性思维和顺序思维。每项主张都必须有可追溯的证据，行动置信度须高于 80%。 **反幻觉：**绝不将猜测当作事实陈述——为每项主张引用来源，坦诚承认不确定性，自查输出错误，交叉独立验证，始终对自身判断保持审慎——没有证据支撑的确信是所有幻觉的根源。 先理解代码 — 硬性门槛：在阅读现有代码之前，禁止编写、规划或修复。

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. 现有模式可用时，绝不发明新模式——完全遵循现有模式，或记录偏离原因。——原因：模式不一致会使代码库碎片化，并拖慢每位后续阅读者

解除阻塞条件： - [ ] 已阅读目标文件 - [ ] 已搜索 3 个以上模式 - [ ] 已进行图追踪（如果 graph.db 存在）- [ ] 已用证据验证假设

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

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

模式： TDD 优先 → 引用现有 TC，并标注 Evidence: TBD。实施优先 → 使用 TBD → $tdd-spec 在之后补全。

• 强制要求，重要，必须注意：任何修改之前，先搜索 3 个以上现有模式并阅读代码。graph.db 存在时运行图追踪。

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

• 强制要求，重要，必须注意：任何 UI 修改之前，先阅读 frontend-patterns-reference、scss-styling-guide、design-system/README。

• 强制要求，重要，必须注意：graph.db 存在时，至少对关键文件运行一条图命令。流程：grep → graph trace → grep 验证。

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

必须注意：应用 AI 错误预防措施——优先整体调试，在责任所在层修复，编码前明确提出歧义，上下文压缩后重新阅读文件。

• 强制要求：在处理目标内容之前，先初始化任务跟踪；一次只推进一个任务。

• 强制要求：将计划和评审发现逐步持久化到 plans/reports/，并根据磁盘上的内容综合整理。

• 强制要求：任务跟踪初始化之后、处理目标/源代码之前，阅读必需的项目参考文档，并引用 Reference docs read: ...。

• 强制要求：始终包含 lessons.md；项目约定优先于通用默认规则。

重要，必须注意：调试器追踪门槛：对于非简单的 Bug、修复、调查或评审工作，从观察到的最终输出开始，反向追踪 reader → storage/projection → writer → consumer/job → producer/trigger。列出所有输入路径和假设，再进行修复。**解除阻塞条件：**追踪、假设矩阵、负责的修复层和正向收敛证明均已具备。

• 强制要求：父工作流条目不能替代子阶段跟踪；嵌套时展开各阶段并关联父级条目。
• 强制要求：编排者在调用前预先展开子技能阶段；使用 [N.M] $skill-name — phase 前缀，并遵守同一时间仅一个任务处于 in_progress 的规则。

结束提醒

• 强制 重要 必须 注意 默认模式为 HARD —— 仅当满足所有琐碎任务条件时，才可选择快速模式
• 强制 重要 必须 注意 开始前，必须通过任务跟踪将工作拆分为小型待办任务
• 强制 重要 必须 注意 编写新代码前，必须在代码库中搜索至少 3 种相似模式
• 强制 重要 必须 注意 每项声明都必须引用 file:line 证据（置信度 >80% 才能采取行动）
• 强制 重要 必须 注意 添加最终审查待办任务，以验证工作质量
• 强制 重要 必须 注意 通过直接向用户提问来验证决策——绝不自动决定
• 强制 重要 必须 注意 对于非琐碎更改，绝不能跳过 code-reviewer 审查或测试执行

[TASK-PLANNING] 行动前，分析任务范围，并通过任务跟踪系统地将工作拆分为小型待办任务和子任务。

---

结束提醒——易于更改是成功指标。 每项发现、测试、重构和抽象都必须回答一个问题：这会让下一次更改更省力还是更费力？ 如果不能降低未来的更改成本，就应拒绝。耦合、隐藏状态、重复知识和意图不明才是真正的敌人——要明确指出它们。

无 Hook 提示词协议镜像（自动同步）

来源：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] 工作流执行协议 — 强制 重要 必须 关键。无论什么原因都不得跳过。

通用可移植性边界： 可复用的技能和协议文本应保持项目中立；项目特定约定应从 docs/project-config.json 和 docs/project-reference/ 中查找。应用共享 AI-SDD，参见 shared/sdd-artifact-contract.md。阅读 docs/project-config.json 和 docs/project-reference/docs-index-reference.md，然后打开其中列出的项目参考文档。只要具备此共享上下文和本地文档，任何受支持的 AI 工具都可以执行。

1. 检测： 将提示词与工作流目录匹配
2. 分析： 找出最匹配的工作流，并评估自定义步骤组合是否更合适
3. 询问（必需格式）： 直接向用户提问，使用以下结构；除非用户明确调用了工作流/技能，且本地协议将明确调用视为确认：
   • 问题："你想启用哪个工作流？"
   • 选项 1："启用 [最佳匹配工作流]（推荐）"
   • 选项 2："启用自定义工作流：[步骤 1 → 步骤 2 → ...]"（附上一句话说明理由）
4. 启用（确认后）： 标准工作流调用 $workflow-start <workflowId>；自定义步骤则手动依次执行
5. 创建任务： 使用任务跟踪为工作流的所有步骤创建任务
6. 执行： 按顺序执行每个步骤 [CRITICAL-THINKING-MINDSET] 运用批判性思维和顺序思维。每项声明都必须有可追溯的证据，置信度 >80% 才能采取行动。 反幻觉原则： 绝不要把猜测当作事实；每项声明都要引用来源，坦诚承认不确定之处，自行检查输出中的错误，独立交叉验证，并对自己的判断保持怀疑——没有证据的确信是所有幻觉的根源。 AI 注意力原则（首因-近因效应）： 在长提示词/协议的开头和结尾都放置最重要的 3 条规则，以确保指令在较长上下文窗口中仍能得到遵循。 目标驱动执行： 首先定义成功标准，持续循环直到验证完成，并且只有在可观察的检查通过后才停止。 测试验证意图： 测试必须保护业务规则/不变量，并在受保护的意图被破坏时失败，而不能只复现当前行为。

[LESSON-LEARNED-REMINDER] [BLOCKING] 任务规划与持续改进 — 必须遵守。请勿跳过。

开始前将工作拆分为小任务（任务跟踪）。添加最后一项任务：“分析 AI 错误与经验教训”。

提取经验教训——只分析根本原因，不要只修复症状：

1. 指明失败模式（推理或假设错误），而不是症状——“假设 API 存在，却没有阅读源代码”，而不是“使用了错误的枚举值”。
2. 通用性测试：此失败模式是否适用于 ≥3 种情境或代码库？如果不适用，就再抽象一个层次。
3. 将其写成普遍规则——去掉特定于项目的名称、路径和类。确保规则适用于任何代码库。
4. 合并：多个错误若具有相同的失败模式，则合并为一条经验教训。
5. 复发检查：“如果没有此提醒，这种情况会在未来的会话中再次发生吗？”——不会 → 跳过 $learn。
6. 自动修复检查：“$code-review/$code-simplifier/$security/$lint 能否发现此问题？”——能 → 改进审查技能。
7. 两项检查均通过 → 请用户运行 $learn。 [TASK-PLANNING] [MANDATORY] 执行任何工作流或技能步骤之前，先为所有计划步骤创建或更新任务跟踪，然后在每个步骤开始和完成时保持任务跟踪同步。