القائمة
Fork Overlay：ce:work 意图分类门控。在执行前识别任务意图（实现/修复/重构/探索），设定对应的执行策略。使用时机：ce:work Phase 0（环境扫描）之后、Phase 1（Quick Start）之前。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Fork Overlay：Task Bundle 持久化 + Failure FSM 集成。在 ce:work 基础上增加 state.md 读写和状态机转换。使用时机：执行 ce:work 时，如果任务有对应的 Task Bundle（docs/tasks/<id>/），加载此 skill 以启用持久化和状态追踪。
Fork Overlay：Codex-first 外部执行器策略。按任务特征路由到 Claude 或 Codex，Codex-first（非品牌路由）。使用时机：需要决定是否将当前任务派发给 Codex 时加载此 skill。
Fork Overlay：经验分层沉淀升级阶梯。检测是否值得将 solution 升级为 pattern 或 skill。使用时机：ce:compound 完成后手动调用，分析 docs/solutions/ 中的重复模式。（不会自动触发，需主动加载此 skill）
Fork Overlay：外部模型调用前置检查门控。调用 Codex/Gemini 之前运行五项检查，防止调用失败浪费时间。使用时机：任何调用外部模型（Codex [C]、Gemini [G]）之前自动运行。
Fork Overlay：Codex Patch Approval 咨询版。当 Codex 返回 patch 时，Claude 审批后才写入文件。使用时机：Codex 以 patch/diff 格式返回代码变更时，由 Claude 作为审批层。
Fork Overlay：Review Contract 三档 Tier 分类 + Anti-Leniency 注入。在 ce:review 基础上增加 Blocking/Analytical/Advisory 分层和结论类型系统。使用时机：运行 ce:review 前阅读此协议以理解审查标准。
| name | intent-gate |
| description | Fork Overlay：ce:work 意图分类门控。在执行前识别任务意图（实现/修复/重构/探索），设定对应的执行策略。使用时机：ce:work Phase 0（环境扫描）之后、Phase 1（Quick Start）之前。 |
参考：oh-my-openagent 的 Intent Classification 思路，适配本仓库 ce:work 流程。
目的：避免 ce:work 对所有任务一刀切处理；不同意图需要不同的执行策略。
| 意图 | 英文 | 触发信号 | 执行策略 |
|---|---|---|---|
| 实现新功能 | implement | "新增"、"添加"、"实现"、"create"、"add"、"implement" | TDD 优先，先写测试再实现 |
| 修复问题 | fix | "修复"、"修复 bug"、"fix"、"broken"、"error" | 先定位根因（systematic-debugging），再修复 |
| 重构 | refactor | "重构"、"优化"、"清理"、"refactor"、"cleanup" | 确保有测试覆盖，小步骤重构 |
| 探索/分析 | explore | "分析"、"研究"、"了解"、"explore"、"investigate" | 只读模式，不改代码，生成报告 |
| 配置/文档 | configure | "配置"、"文档"、"设置"、"config"、"docs" | 轻量执行，无需 TDD |
| 混合 | mixed | 多种意图混合 | 拆分为独立子任务，逐一处理 |
在 ce:work Phase 0 完成后，执行意图分类：
分析输入文档（plan 或 bare prompt）中的关键词，得出初始分类：
输入分析 → 关键词匹配 → 初始意图
| 置信度 | 行为 |
|---|---|
| ≥ 0.80 | 直接设定执行策略，不询问 |
| 0.60-0.79 | 展示分类结果，询问确认（单问） |
| < 0.60 | 明确询问用户意图 |
使用 AskUserQuestion 询问：
检测到此任务可能是：
A. 实现新功能（test-first）
B. 修复问题（debug-first）
C. 重构（refactor-safe）
D. 其他：___
选择最准确的意图 (A/B/C/D)：
1. 加载 test-driven-development skill
2. 先写失败测试
3. 实现使测试通过
4. 重构（可选）
5. 验证完整测试套件
1. 加载 systematic-debugging skill
2. 定位根因（不猜测）
3. 写复现测试（证明 bug 存在）
4. 修复使测试通过
5. 验证无回归
1. 确认现有测试覆盖率
2. 如覆盖率不足 → 先补测试
3. 小步骤重构（每步运行测试）
4. 最终效果：行为不变，代码更清晰
1. 设置只读模式（不改代码）
2. 使用 repo-research-analyst + learnings-researcher
3. 生成分析报告到 docs/plans/ 或标准输出
4. 明确告知用户：探索模式，不执行任何修改
1. 轻量执行，无需 TDD 周期
2. 修改相关配置文件或文档
3. 验证格式正确性（lint/yaml validate 等）
Intent Gate 在 ce:work Phase 0（环境扫描）完成后、Phase 1（Quick Start）开始前执行：
Phase 0: 环境扫描（原有）
↓
[Intent Gate 插入点 — 本 overlay 在此插入]
├── 自动分类意图
├── 设定执行策略
└── 加载对应 skill（TDD / systematic-debugging 等）
↓
Phase 1: Quick Start（原有，但按策略执行）
注意：不使用分数相命名（如 Phase 0.5），以避免与 ce:work 原有整数相编号冲突。
不修改 ce:work SKILL.md。在调用 ce:work 前先加载 intent-gate skill，按其指导调整执行方式。
在 state.md 中记录意图分类结果（如有 Task Bundle）：
# state.md 新增字段
intent:
detected: fix
confidence: 0.85
strategy: "systematic-debugging → write reproduction test → fix → verify"
intent_gate_at: "2026-04-08T10:00:00+08:00"
| 场景 | 正确处理 |
|---|---|
| 用户说"修复这个 bug"但实际是新功能 | Intent Gate 检测为 implement，提示用户确认 |
| 混合意图（既修复又重构） | 拆分为两个子任务，分别处理 |
| 用户明确说"直接实现，不要 TDD" | 尊重用户意图，跳过 TDD 要求 |