code

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. 计划检测 — 查找最新计划或使用提供的路径，选择下一个未完成阶段
2. 分析与任务 — 从阶段文件中提取任务并纳入任务跟踪
3. 实施 — 逐步实施并运行类型检查
4. 测试 — 调用测试子 Agent；必须达到 100% 通过才能继续
5. 代码审查 — 调用代码审查子 Agent；关键问题必须为 0
6. 用户审批 — 阻塞关卡：等待用户明确批准
7. 最终处理 — 更新状态和文档，并自动提交

关键规则：

• 测试必须 100% 通过（第 3 步关卡）
• 关键问题必须为 0（第 4 步关卡）
• 最终处理前，用户必须明确批准（第 5 步关卡）
• 每次命令运行只处理一个计划阶段

务必阅读 CLAUDE.md，然后深入思考，开始处理以下计划：

保持怀疑并运用批判性、顺序性思维。每项结论都必须提供可追溯的依据和置信度百分比（设想的置信度应高于 80%）。

$ARGUMENTS

---

实施前粒度关卡（MANDATORY）

如果任一检查未通过 → 停止。向用户询问："Phase 需要更多细节才能开始实施。使用 $plan 进行完善？[Y/n]" 仅实施包含已命名文件、具体操作且已解决决策的阶段 — 不要实施包含规划动词、未命名文件或未解决决策的阶段。

---

步骤 0：计划检测与阶段选择

如果 $ARGUMENTS 为空：

1. 在 ./plans 中查找最新的 plan.md
2. 解析计划中的阶段和状态，自动选择下一个未完成的阶段（优先选择 IN_PROGRESS 或最早的 Planned 阶段）

如果提供了 $ARGUMENTS： 使用该计划并检测要处理的阶段。

输出： ✓ Step 0: [Plan Name] - [Phase Name]

---

工作流顺序

规则： 按顺序执行步骤 1-6。每个步骤都必须输出标记 ✓ Step N:。继续之前，在任务跟踪中将每一步标记为已完成。不要跳过步骤。

---

步骤 1：分析与任务提取

完整阅读计划文件。梳理依赖关系。列出模糊之处。识别所需技能并从目录中启用。如果计划引用了 .ai/workspace/analysis/ 中的分析文件，则在实施前重新阅读这些文件。

实施前追踪关卡： 如果计划针对 Bug 修复、验证失败、过时/错误的最终输出、回归问题或改变行为的修复，MUST ATTENTION 验证计划或引用的分析是否包含 Debugger Trace: End -> Start、所有馈入路径、假设矩阵、负责修复的层，以及正向收敛证明。如果缺少其中任何一项，停止并报告缺失的追踪链接，而不是实施。

任务跟踪初始化：

• 使用 Step 0: [Plan Name] - [Phase Name] 初始化任务跟踪，并包含所有步骤（1-6）
• 阅读阶段文件，查找任务/步骤/阶段/章节/编号列表/项目符号列表
• 将其转换为具有唯一名称的任务以进行跟踪：
  • 阶段实施任务 → Step 2.X（Step 2.1、Step 2.2 等）
  • 阶段测试任务 → Step 3.X
  • 阶段代码审查任务 → Step 4.X

输出： ✓ Step 1: Found [N] tasks across [M] phases - Ambiguities: [list or "none"]

---

步骤 2：实施

按照提取的任务逐步实施所选计划阶段。完成任务后将其标记为已完成。对于 UI 工作，调用 ui-ux-designer 子 Agent。运行类型检查和编译以进行验证。

输出： ✓ Step 2: Implemented [N] files - [X/Y] tasks complete, compilation passed

---

步骤 3：测试

调用 tester 子 Agent。如果任一测试失败：停止，调用 debugger 子 Agent，修复问题并重新运行。重复此过程，直至全部通过。

测试标准： 单元测试可以使用 mock。集成测试使用测试环境。禁止：注释掉测试、修改断言以使测试通过、使用 TODO/FIXME 延后修复。

输出： ✓ Step 3: Tests [X/X passed] - All requirements met

验证： 如果 X ≠ 总数，则步骤 3 未完成 — 不要继续。

---

步骤 4：代码审查

调用 code-reviewer 子 Agent。如果发现严重问题：停止，修复问题，重新运行 tester，再重新运行 code-reviewer。重复此过程，直至不再有严重问题。

输出： ✓ Step 4: Code reviewed - [0] critical issues

验证： 如果严重问题 > 0，则步骤 4 未完成 — 不要继续。

---

步骤 5：用户批准 ⏸ 阻塞关卡

提交摘要（3-5 条要点）：实施内容、通过的测试、代码审查结果。

明确询问用户： "阶段实施已完成。所有测试均已通过，代码已审查。是否批准这些更改？"

停止并等待 — 在用户回复之前不要继续。

输出： ✓ Step 5: User approved - Ready to complete

---

步骤 6：完成

前提条件： 用户已在步骤 5 批准。

1. 状态更新（并行）：

   • 调用 project-manager 子 Agent 更新计划状态
   • 调用 docs-manager 子 Agent 更新文档

2. 入门检查： 检测入门要求并生成摘要。

3. 自动提交： 调用 git-manager 子 Agent。仅当步骤 1-2 成功、用户已批准且测试通过时才运行。

输出： ✓ Step 6: Finalize - Status updated - Git committed

---

第一原则——易于变更

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

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

• 拒绝会增加变更成本的“最佳实践”（过早抽象、推测性通用设计、泄漏的间接层、没有收益的仪式）。
• 在评审结果中指出真正的敌人：耦合、隐藏状态、重复知识、意图不明、过早暴露的不可逆决策。
• 易于变更的简单设计，胜过难以变更的复杂设计。

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

---

关键执行规则

步骤输出格式： ✓ Step [N]: [Brief status] - [Key metrics]

必须跟踪任务： 在 Step 0 初始化，并在进入下一步之前将当前步骤标记为完成。

必须调用子 Agent： Step 3：tester | Step 4：code-reviewer | Step 6：project-manager AND docs-manager AND git-manager

阻塞关卡：

• Step 3：测试必须 100% 通过
• Step 4：严重问题必须为 0
• Step 5：用户必须明确批准

按声明的顺序执行每一步；只有验证通过且用户已批准后才能继续；每条命令只运行一个计划阶段。不得跳过步骤、在验证失败时继续，也不得在用户未回应时假定已获批准。

---

工作流建议

必须注意，非常重要，必须遵守——无例外： 如果你当前尚未处于工作流中，必须注意通过直接提问询问用户。不要判断任务复杂度，也不要自行决定任务“足够简单，可以跳过”——是否使用工作流由用户决定，而不是你：

1. 启用 refactor 工作流（推荐）——侦察 → 调查 → 计划 → 编码 → 评审 → SRE 评审 → 测试 → 文档
2. 直接执行 $code——单独运行此技能

---

后续步骤（单独运行：必须注意通过直接提问询问用户。若在工作流中则跳过。）

必须注意，非常重要，必须遵守——无例外 完成本技能后，必须注意通过直接提问向用户提供以下选项。不要因为任务看起来“简单”或“明显”而跳过——由用户决定：

• “继续完整工作流（推荐）”——我会从此处（代码已实现）开始，判断最适合继续的工作流。这可以确保不跳过评审、测试和文档步骤。
• $code-simplifier——简化实现
• $integration-test——根据测试规范生成或更新集成测试
• $workflow-review-changes——提交前评审变更
• “跳过，手动继续”——由用户决定

单独评审关卡（仅限非工作流场景）

必须注意，非常重要，必须遵守： 如果在工作流之外调用此技能（单独运行 $code），必须注意在任务列表的最后一项创建 $review-changes 的任务跟踪待办任务。这样即使没有工作流强制执行，也能确保在提交前评审所有变更。

如果当前已在工作流中运行（例如 feature、refactor），则跳过此项——工作流会在适当步骤安排 $review-changes。

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

前置条件： 执行前必须注意阅读：

• docs/project-reference/frontend-patterns-reference.md（相关时直接阅读；不要依赖钩子注入的对话文本）
• docs/project-reference/scss-styling-guide.md — 样式/BEM 指南（任务涉及前端/UI 时阅读）
• docs/project-reference/design-system/README.md — 设计系统令牌（任务涉及前端/UI 时阅读）
• docs/project-reference/domain-entities-reference.md — 领域实体目录、关系、跨服务同步（任务涉及业务实体/模型时阅读）

外部记忆： 对于复杂或耗时较长的工作（研究、分析、扫描、审查），将中间发现和最终结果写入 plans/reports/ 下的报告文件，避免上下文丢失，并作为交付物。

证据门槛： 强制要求、重要、必须关注——每项主张、发现和建议都需要 file:line 证据或可追溯证据，并注明置信度百分比（>80% 才可采取行动，<80% 必须先核实）。

从结果到起点的调试追踪 — 对于非简单的 Bug、验证失败、回归修复、行为变更代码或不明确的代码流程，先从观察到的最终状态开始向前追溯，再提出修复方案。

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

以下内容完成前一律阻塞： 明确最终状态 · 写出反向追踪 · 枚举所有供给路径 · 完成假设矩阵 · 论证负责修复的层 · 将正向收敛证明对应到测试。

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

计划粒度 — 实施前，每个阶段都必须通过 5 项检查：

1. 列出要修改的确切文件路径（不能笼统地写“实现 X”）
2. 不得使用规划类动词（研究、调查、分析、确定、弄清楚）
3. 每个步骤 ≤30 分钟，每个阶段总计 ≤3 小时
4. 每个阶段 ≤5 个文件
5. 方案中不得有未解决的决策或待定事项

未通过的阶段 → 创建子计划。重复此过程，直到所有叶阶段均通过（最大深度：3）。 自问：“我现在能立刻开始编码吗？如果任何步骤需要‘弄清楚’，就将其拆分为子计划。” 嵌套任务扩展约定 — 对于工作流步骤调用，[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。

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

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、已给出引用。

批判性思维原则 — 运用批判性思维和顺序思维。每项断言都必须有可追溯的证据，行动所需置信度须高于 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 存在） - [ ] 已用证据验证假设 源代码／测试漂移检查。 对于编码、修复、调试、调查、测试或审查工作：当源代码行为发生变化时，检查受影响的单元／集成／E2E 测试，并根据证据判断应修改测试以匹配预期行为，还是源代码变更本身是需要修复的意外错误。不要为迁移代码编写测试；架构／数据迁移是一次性执行路径，不属于核心应用逻辑。

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

重要，务必注意 确认所有阶段都通过 5 点粒度检查。未通过的阶段 → 制定子计划。“我现在可以立刻开始编码吗？”

重要，务必注意 任何修改前，搜索至少 3 种现有模式并阅读代码。存在 graph.db 时，运行图追踪。

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

务必注意 落实 AI 防错措施——整体优先地调试、在负责的层级修复、编码前明确歧义，并在压缩上下文后重新阅读文件。

• 强制要求 完成任务跟踪初始化后、开始处理目标／源代码前，阅读必需的项目参考文档，并注明 Reference docs read: ...。
• 强制要求 始终包含 lessons.md；项目约定优先于通用默认规则。

重要，务必注意 调试器追踪门槛：对于非简单的 Bug／修复／调查／审查工作，从观察到的最终输出开始反向追踪：读取方 -> 存储／投影 -> 写入方 -> 使用方／任务 -> 生产方／触发器。列出所有供给路径和假设后再修复。在追踪、假设矩阵、负责的修复层级和正向收敛证明均具备之前，禁止继续。

• 强制要求 父级工作流条目不能取代子阶段跟踪；嵌套时，展开各阶段并关联父级。
• 强制要求 编排器须在调用前预先展开子技能阶段；使用 [N.M] $skill-name — phase 前缀，并遵循单一 in_progress 纪律。

Prompt-Enhance 结束锚点

重要：必须注意，遵循此技能声明的步骤顺序；未经用户明确批准，绝不跳过、调整顺序或合并步骤 重要：必须注意，每次执行步骤／子技能调用时：执行前设为 in_progress，执行后设为 completed 重要：必须注意，每个跳过的步骤都必须注明明确原因；每个已完成的步骤都必须提供简要证据 重要：必须注意，如果 Task 工具不可用，则维护一个状态同步的等效逐步计划跟踪器

结束提醒

强制：重要：必须注意，开始前使用任务跟踪将工作拆分成小型待办任务。 强制：重要：必须注意，通过直接向用户提问来验证决策——绝不自行决定。 强制：重要：必须注意，添加最终审查待办任务，以验证工作质量。 强制：重要：必须注意，开始前阅读以下文件：

重要：必须注意，开始前阅读 CLAUDE.md

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

[IMPORTANT] 分析任务规模，并在开始前系统地将其拆分为许多小型待办任务——这非常重要。

---

结束提醒——易于更改是成功指标。 每个发现、 测试、重构和抽象都必须回答一个问题：这会让下一次更改更容易 还是更困难？ 如果无法降低未来更改的成本，就应舍弃。耦合、 隐藏状态、重复的知识和模糊的意图才是真正的敌人——请明确指出它们。

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

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

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

通用可移植性边界： 可复用的技能和协议文本应与项目无关；从 docs/project-config.json 和 docs/project-reference/ 中查找项目特定约定。应用 shared/sdd-artifact-contract.md 中的共享 AI-SDD。阅读 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] 在执行任何工作流或技能步骤之前，先为所有计划步骤创建／更新任务跟踪；然后随着每个步骤开始／完成，持续同步任务状态。