plan-ci

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 入手，然后仅打开与任务相关的文件。

快速摘要

目标： 分析 GitHub Actions CI 日志，并制定修复已发现问题的计划。

工作流：

1. 获取 — 从 GitHub Actions 下载 CI 日志
2. 分析 — 找出构建／测试失败的根本原因
3. 规划 — 制定修复 CI 问题的实施计划

关键规则：

• 仅限规划：不要实施，只制定修复计划
• 聚焦 CI 特有问题（构建、测试、环境、Docker、依赖项）
• 制定计划后，务必提出使用 $plan-review

保持审慎，运用批判性思维和顺序思维。每项论断都必须有可追溯的证据和置信度百分比（想法的置信度应高于 80%）。

激活 planning 技能。

仅限规划——需要协作

不要使用手动计划模式切换工具——你已经处于规划工作流中。 不要实施或执行任何代码变更。 与用户协作：提出决策问题，展示选项并给出建议。 制定计划后，务必运行 $plan-review 以验证计划。 在进行任何后续步骤之前，先请用户确认计划。

Github Actions URL

$ARGUMENTS

使用 planner 子代理读取 github actions 日志，分析并找出问题根因，然后提供详细的修复实施计划。

计划文件规范：

• 每个 plan.md 都 MUST ATTENTION 以 YAML frontmatter 开头：

  ---
  title: '{简短标题}'
  description: '{用于卡片预览的一句话描述}'
  status: pending
  priority: P1
  effort: { 预估修复时间 }
  branch: { 当前 git 分支 }
  tags: [ci, bugfix]
  created: { YYYY-MM-DD }
  ---
  

输出： 至少提供 2 种实施方案，明确说明各自的权衡，并解释每种方案的优缺点，同时给出推荐方案。

重要的任务规划说明（MUST ATTENTION FOLLOW）

• 始终使用任务跟踪，将工作规划并拆分为许多小型待办任务
• 始终添加最终审核待办任务，以验证工作质量并找出修复项／改进项
• 强制最终任务： 创建所有规划待办任务后，始终添加以下最终任务：
  1. 任务：“为每个阶段编写测试规范”——为每个阶段文件添加 ## Test Specifications，并使用 TC-{FEATURE}-{NNN} ID。如果存在功能文档，则使用 $tdd-spec。TDD-first 模式下使用 Evidence: TBD。
  2. 任务：“运行 $plan-validate”——触发 $plan-validate 技能，通过关键问题访谈用户并验证计划假设
  3. 任务：“运行 $plan-review”——触发 $plan-review 技能，自动审核计划的有效性、正确性和最佳实践
  4. 任务：“根据最终计划重新评估估算”——完成前的估算以范围猜测为依据；最终阶段会揭示实际成本。在阶段／TC／决策确定后：(a) 根据最终阶段文件重新推导 bottom_up_hours = Σ phase_hours；(b) 按 SYNC:estimation-framework 重新计算 likely_days、risk_margin_pct 和 min-max range；(c) 与当前 frontmatter 中的 man_days_traditional／story_points 对比。如果 |delta| > 20% → 更新 frontmatter，添加 reestimate_delta_pct: <signed> 和一行 reestimate_reason。如果 |delta| > 50% → 标记 SHOULD-RESCOPE，并在实施前直接向用户提问。

重要说明

重要： 分析技能目录，并在过程中启用任务所需技能。 重要： 撰写输出时，宁可牺牲语法，也要保持简洁。

提醒——仅限规划的命令

不要使用手动切换计划模式的工具。 不要开始实施。 计划创建后，始终使用 $plan-review 进行验证。 实施开始前，务必让用户确认计划。 存在多种方案时，务必询问用户的决策，并提供推荐意见。

---

[IMPORTANT] 开始前，使用任务跟踪将所有工作拆分为小任务——包括读取每个文件的任务。这可以防止处理长文件时丢失上下文。对于简单任务，AI MUST ATTENTION 询问用户是否跳过。

• docs/specs/ — 按模块划分的测试规范（读取现有 TC，将测试策略纳入计划）

技能变体： $plan 的变体，专用于 CI/GitHub Actions 失败分析。 AI 错误预防 — 每项任务都要避免的失败模式：

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

嵌套任务展开约定 — 对工作流步骤的调用而言，[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. Thought N/M: [aspect] — 每条思考只讨论一个方面，并说明假设／不确定性
2. Thought N/M [REVISION of Thought K]: ... — 先前推理被推翻时使用；说明原内容／修订原因／影响
3. Thought N/M [BRANCH A from Thought K]: ... — 探索替代方案；说明决策依据并得出结论
4. Thought N/M [HYPOTHESIS]: ... 然后是 [VERIFICATION]: ... — 行动前先进行验证
5. Thought N/N [FINAL] — 仅在完成验证、涵盖所有关键方面且置信度 >80% 时使用

必须包含的结尾内容： 说明置信度 % · 列出假设 · 提出未解决的问题 · 明确下一步行动。

停止条件： 任何关键决策的置信度 <80% → 直接向用户询问并升级处理 · 同一条思考修订 ≥3 次 → 重新定义问题 · 分支数量 >3 → 拆分为子任务。

隐式模式： 当添加标记会使回复显得冗杂时（例如有助于提高准确性的常规任务），在内部应用此方法，不显示标记。

深入了解： 查看 $sequential-thinking 技能（.claude/skills/sequential-thinking/SKILL.md），了解示例（API 设计、调试、架构）、高级技巧（螺旋式完善、假设测试、收敛）和元策略（不确定性处理、修订级联）。

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

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. 每项主张都要引用 file:line、grep 结果或框架文档
2. 声明置信度：>80% 可直接行动，60-80% 先验证，<60% 不得提出建议
3. 架构变更必须进行跨服务验证
4. “证据不足”是合理且符合预期的输出

满足以下条件前，禁止继续： - [ ] 提供证据文件路径（file:line）- [ ] 已执行 grep 搜索 - [ ] 已找到 3 个以上的相似模式 - [ ] 已说明置信度

未经证实不得使用： “显而易见”“我认为”“应该是”“可能是”“这是因为” 若信息不完整 → 输出："Insufficient evidence. Verified: [...]. Not verified: [...]." 估算框架 — 优先自下而上；故事点（SP）为推导值；预计用时可能 ≥3d 时，输出最小值至最大值范围。与技术栈无关。基准：3-5 年经验的开发者，每天 6 个有效工作小时。AI 估算假设使用 Claude Code + 项目上下文。

方法：

1. 影响范围检查（见下文）——决定代码和测试成本
2. 分解阶段 → 每阶段小时数 → bottom_up_hours = Σ phase_hours
3. likely_days = ceil(bottom_up_hours / 6) × productivity_factor
4. 累加风险余量（基础值 + 附加值）→ max_days = likely_days × (1 + margin)
5. min_days = likely_days × 0.9
6. 当 likely_days ≥3 时输出范围；<3 时可用单点值（仍须记录余量）
7. man_days_ai = 相同范围 × AI 加速比
8. story_points 根据 likely_days 通过 SP-Days 推导——绝不作为估算驱动因素。偏差 >50% → 以自下而上估算为准

效率系数： 0.8 脚手架、代码生成和 AI 钩子完善 · 1.0 成熟默认值 · 1.2 模式薄弱 · 1.5 从零开始

成本驱动因素启发式规则（在选择工作类型行之前应用）：

• UI 占主导：CRUD/业务应用中通常如此——成本为后端的 1.5-3 倍（状态、验证、响应式、无障碍、打磨）
• 仅以下情况由后端占主导： 多聚合不变量、跨服务契约、架构迁移、复杂查询/性能、新事件流

复用与创建轴（首要杠杆，按层计算）：

UI 层级	成本
复用现有屏幕上的组件	0.1-0.3d
在现有屏幕上添加控件/列	0.3-0.8d
将组件组合成新屏幕	1-2d
新屏幕，含自定义布局/状态/验证	2-4d
新建共享/通用组件（含主题、测试）	3-6d+

后端层级	成本
在新位置复用查询/处理程序	0.1-0.3d
小幅更新现有处理程序/实体	0.3-0.8d
在现有仓库/模型上新增查询	0.5-1d
在现有聚合上新增命令/处理程序（增量式）	1-2d
新建聚合/实体（仓库、验证、事件）	2-4d
新建跨服务契约或架构迁移	各 2-4d
多聚合不变量/复杂领域规则	3-5d

规则： 将 UI、后端和测试各层级成本相加，再应用效率系数。复用可直接跳过对应层级——请注明。

测试范围驱动因素（明确计算 test_count——用“+测试”含糊带过是首要失败原因）：

驱动因素	数量
顺利路径用户旅程	每个用户故事/验收标准主流程 1 项
状态机转换	可达转换数 × 允许的操作者数
多实体状态组合	state(A) × state(B)——仅计算可达组合，不计算笛卡尔积
授权矩阵	（所有者、非所有者、较高权限、未认证）× 每种变更操作
验证规则	每个必填字段/边界/格式/跨字段规则 1 项
UI 状态（每个新屏幕/对话框）	顺利、加载中、空状态、错误、部分状态——仅计算实际存在的状态
负向路径/不变量	每条可违反的业务规则 1 项

测试层级（传统方式，含设置、断言和偶发失败处理）	成本
1-5 个用例，复用测试夹具	0.3-0.5d
6-12 个用例，新增 1 个测试夹具	0.5-1d
13-25 个用例，多实体设置	1-2d
26-50 个用例，或新增状态机覆盖	2-3d
>50 个用例，或完整端到端旅程	3-5d

测试乘数： 新增测试夹具/种子数据框架 +0.5d · 每个跨服务/总线断言 +0.3d · UI 端到端测试 ×1.5 · 每新增一个角色 +1-2 个用例

影响范围（强制预检查——影响代码和测试）：

1. 直接修改的文件/组件——计数
2. 其中的“复杂”项（>500 LOC、多处理程序、核心、频繁修改）——计数
3. 下游使用方（调用方、事件订阅者、跨服务）——列出
4. 是否改动共享/通用代码（影响多个应用）——是/否
5. 回归范围——需要重新测试的区域

规则： 改动复杂项 → 添加 risk_factors。每个下游使用方 → +1-3 个回归用例。影响范围 >5 个区域或 >2 个复杂项 → 估算前重新评估是否应拆分。

风险余量（决定最大值上限）：

预计天数	基础余量
<1d 微小	+10%
1-2d 小型增量	+20%
3-4d 实际功能	+35%
5-7d 大型	+50%
8-10d 特大型	+75%
>10d	+100% 并标记为应拆分

风险因素附加值（累加——在 risk_factors 中逐项列出）：

因素	+余量
touches-complex-existing-feature（>500 LOC、多处理程序、核心）	+20%
cross-service-contract 变更	+25%
schema-migration-on-populated-data	+25%
new-tech-or-unfamiliar-pattern	+30%
regression-fan-out（≥3 个下游区域需重新测试）	+20%
performance-or-latency-critical	+20%
concurrency-race-event-ordering	+25%
shared-common-code（多个使用方/多个应用）	+25%
unclear-requirements-or-design	+30%

合并规则： 总余量 >100% → 停止并拆分（缓冲超过 2 倍就是不诚实）。likely_days ≥5 时余量 <15% → 估算偏低，应扩大范围。

工作类型上限（likely_days 的硬性上限）：

工作类型	最大 SP	最大预计天数
单个字段/配置标记/样式修复	1	0.5d
在现有模型中添加属性并绑定到现有 UI	2	1d
新增端点 + 轻量 UI 控件（按钮/菜单/列），复用测试夹具	3	2-3d
新增端点 + 新 UI 界面，或增量式多层变更 + 新领域规则 + 2 个以上测试文件	5	3-5d
新模型/聚合，或迁移，或跨模块契约，或复杂测试（>1.5d），或新 UI + 非简单后端	8	5-7d
新 UI 界面 +（新聚合或迁移或跨服务契约）	13	应拆分
跨服务契约 + 迁移组合	13	应拆分
超出以上范围	21	必须拆分

SP→天数（仅用于验证）： 1=0.5d/0.25d · 2=1d/0.35d · 3=2d/0.65d · 5=4d/1.0d · 8=6d/1.5d · 13=10d/2.0d（传统/AI 预计天数） AI 加速比： SP 1≈2x · 2-3≈3x · 5-8≈4x · 13+≈5x。AI 成本 = (code_gen × 1.3) + (test_gen × 1.3)（30% 审查开销）。

强制前置元数据：

story_points: <n>
complexity: low | medium | high | critical
man_days_traditional: '<min>-<max>d' # likely ≥3d 时用范围；<3d 时用 '<N>d'
man_days_ai: '<min>-<max>d'
risk_margin_pct: <n> # 基础值 + 附加值
risk_factors: [touches-complex-existing-feature, regression-fan-out] # 来自附加值的封闭列表；没有则为 []
blast_radius:
    touched_areas: <n>
    complex_touched: <n>
    downstream_consumers: [列表或数量]
    shared_common_code: yes | no
estimate_scope_included: [代码，集成测试，前端，i18n，文档]
estimate_scope_excluded: [单元测试，端到端测试，性能测试，部署，代码审查轮次]
estimate_reasoning: |
    用 5-7 行说明：
    (a) UI 层级——应用的行
    (b) 后端层级——应用的行
    (c) 测试范围——按驱动因素拆分用例数、文件数、测试夹具、层级行
    (d) 成本驱动因素——占主导的层级及原因
    (e) 影响范围——改动项、复杂项、回归范围
    (f) 风险因素——导致余量的因素；说明为何余量不更大/更小
    示例："UI：组合 Form/Table/Dialog → 新屏幕（约 1.5d）。后端：在现有聚合上新增命令，
    复用验证和仓库（约 1d）。测试：4 个转换 × 2 个操作者 + 3 个验证规则 + 2 个 UI 状态 = 13 个用例，
    新增 1 个测试夹具 → 13-25 个用例层级，约 1.5d。驱动因素：UI 组合 + 新状态。影响范围：4 个区域，1 个复杂项。
    风险：基础值 35% + 复杂项改动 20% = 55% → 最大值 3.9d → 范围 2.5-4d。"

合理性自检：

• likely_days ≥3d 却给出单点值？→ 拒绝，必须给出范围

• likely_days ≥5d 时余量 <15%？→ 估算偏低，应扩大范围

• 余量 >100%？→ 停止，改为拆分，而不是增加缓冲

• 改动了现有复杂功能，但 (c) 中没有回归预算？→ 拒绝

• 影响范围 >5 个区域或 >2 个复杂项，却没有讨论拆分？→ 拒绝

• 仅在现有模型和现有 UI 上做增量修改？→ SP 上限为 3，除非测试 >1.5d

• 新 UI 界面（页面/复杂表单/仪表板）？→ 即使后端只有一个端点，SP 也至少为 5

• 后端涉及跨服务/迁移/多聚合？→ 无论 UI 如何，SP 至少为 8

• bottom_up_hours / 6 与 SP-Days 的偏差 >50%？→ 以自下而上估算为准，调低 SP

• 去掉测试后，SP 是否至少下降一个档位？→ 测试占主导；请明确说明

• 推理是否说明了 UI 与后端的差异、影响范围和风险因素？→ 缺少则补充 计划质量 — 每个计划阶段都必须 ATTENTION 包含测试规范。

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 优先 → 使用 Evidence: TBD 引用现有 TC。实现优先 → 使用 TBD → $tdd-spec 后续补全。

迭代阶段质量 — 规划前先评估复杂度。

复杂度信号： >5 个文件 +2，跨服务 +3，新模式 +2，数据库迁移 +2 得分 >=6 → 必须 ATTENTION 拆分为多个阶段。每个阶段：

• 修改文件不超过 5 个
• 工作量不超过 3 小时
• 遵循以下周期：规划 → 实现 → 评审 → 修复 → 验证
• 仅当第 N 阶段通过 VERIFY 后，才开始第 N+1 阶段——原因：在未经验证的阶段上继续构建，会导致下游错误层层累积

阶段成功 = 所有 TC 均通过 + code-reviewer agent 批准 + 没有 CRITICAL 发现。

• 强制 IMPORTANT 必须 ATTENTION 为每个阶段添加含 TC ID 的 ## Test Specifications。创建新任务前，调用当前任务列表。

• 强制 IMPORTANT 必须 ATTENTION 为每项声明引用 file:line 证据。置信度 >80% 才采取行动，<60% = 不得给出建议。

• 强制必须 ATTENTION 进行估算：自下而上估算的阶段工时决定 man_days_traditional（Σh/6 × productivity_factor）；SP 为推导值。UI 成本通常占主导——如果新增 UI 界面（页面/复杂表单/仪表板），SP 上调一个档位。Frontmatter 必须包含 story_points、complexity、man_days_traditional、man_days_ai、estimate_scope_included、estimate_scope_excluded、estimate_reasoning（UI 与后端成本驱动因素）。若在现有模型和现有 UI 上进行增量修改，SP 上限为 3，除非测试范围超过 1.5 天。SP 为 13 时应拆分，SP 为 21 时必须拆分。

• 强制 IMPORTANT 必须 ATTENTION 先评估复杂度。得分 >=6 → 拆分。每个阶段：规划 → 实现 → 评审 → 修复 → 验证。不得跳过。

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

必须 ATTENTION 运用 sequential-thinking——对多步骤过程使用 Thought N/M、REVISION/BRANCH/HYPOTHESIS 标记，并尽量注明置信度百分比；参见 $sequential-thinking 技能。

必须 ATTENTION 运用 AI 错误预防措施——优先整体排查，在负责的层面修复，在编码前明确歧义，并在上下文压缩后重新读取文件。

• 强制 在处理目标工作前启动任务跟踪；一次只推进一个任务。

• 强制 将计划和评审发现逐步保存到 plans/reports/，并基于磁盘中的内容进行综合。

• 强制 在启动任务跟踪后、处理目标或源代码前，阅读必需的项目参考文档，并注明 Reference docs read: ...。

• 强制 始终包含 lessons.md；项目约定优先于通用默认值。

• 强制 父工作流条目不能替代子阶段跟踪；嵌套时展开各阶段并链接父项。

• 强制 编排器在调用前预先展开子技能阶段；使用 [N.M] $skill-name — phase 前缀，并确保同一时间只有一个任务处于 in_progress 状态。

收尾提醒

• 必须、重要、务必注意：开始前，使用任务跟踪将工作拆分为小型待办任务
• 必须、重要、务必注意：编写新代码前，在代码库中搜索至少 3 个类似模式
• 必须、重要、务必注意：每项论断都要引用 file:line 证据（置信度 >80% 才可采取行动）
• 必须、重要、务必注意：添加最终审查待办任务，以验证工作质量
• 必须、重要、务必注意：在计划 frontmatter 中加入 Test Specifications 部分和 story_points

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

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

来源：.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] 执行任何工作流或技能步骤之前，先为所有计划步骤创建或更新任务跟踪，然后在每个步骤开始和完成时保持任务跟踪同步。