skill-fix-logs

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

快速摘要

目标： 根据技能 logs.txt 文件中的错误分析修复技能。

工作流：

1. 阅读 — 分析技能的 logs.txt，查找错误和失败
2. 诊断 — 确定技能故障的根本原因
3. 修复 — 修正 SKILL.md、脚本或参考资料
4. 验证 SYNC 合规性 — 确保修复不会破坏 SYNC 标签配对或移除内联协议
5. 增强 — 如果修改了结构，则对修复后的 SKILL.md 调用 $prompt-enhance
6. 测试 — 再次运行技能以验证修复

关键规则：

• 聚焦于日志中报告的具体错误
• 修复 SKILL.md 结构时：保持 SYNC 标签配对，并保留内联协议
• 如果修改了 SKILL.md 结构，必须调用 $prompt-enhance
• 修复尝试失败 3 次后必须停止——报告结果，并在进行第 4 次尝试前询问用户

任务

根据 logs.txt 文件（项目根目录）修复 Agent 技能。

$ARGUMENTS

规则

• 如果没有提供内容 → 直接向用户提问以澄清
• 如果提供了 URL → 使用 Explore 子 Agent 探索所有内部链接
• 如果提供了 GitHub URL → 使用 repomix + 并行的 Explore 子 Agent
• 修改 SKILL.md 时：确认 `` 代码块保持配对

---

[重要] 开始前，务必使用任务跟踪将所有工作拆分为小任务。

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

批判性思维准则 — 运用批判性思维和顺序思维。每项断言都必须有可追溯的证据，只有置信度 >80% 时才能采取行动。 反幻觉： 绝不要把猜测说成事实——每项断言都要引用来源，坦然承认不确定性，自查输出是否有误，独立交叉核对，对自己的判断保持审慎——没有证据的确信是所有幻觉的根源。

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

务必注意 遵循 AI 防错要求——整体优先地调试，在负责的层修复，编码前明确歧义，压缩上下文后重新阅读文件。

结束提醒

重要，务必注意 开始前，使用任务跟踪将工作拆分为小型待办任务 重要，务必注意 编辑 SKILL.md 时保持 SYNC 标签配对 重要，务必注意 结构性修复后，对 SKILL.md 调用 $prompt-enhance 重要，务必注意 修复尝试失败 3 次后立即停止——报告结果，并在第 4 次尝试前询问用户 重要，务必注意 每项断言都要引用 file:line 证据（置信度 >80% 才能采取行动）

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

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

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