Menu
遇到任何 bug、测试失败或意外行为时使用，在提出修复前 - 系统化调试
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
何时使用需要为编程项目、monorepo 或多级目录创建/更新 AGENTS.md、CLAUDE.md 软链接、项目级 agent 操作手册、子目录局部规则、验证命令和 Coding Agent 上下文边界时使用。
分析代码库结构并生成中文 token-lean 架构文档。
用于构建或维护个人 LLM 驱动的知识库。触发词：将资料导入 wiki、查询 wiki 知识、检查 wiki 质量、'添加到 wiki'、'我了解什么关于'，或任何提到 'LLM wiki' 的场景。
当有书面实施计划要在单独会话中执行并带审查检查点时使用
用户明确要求隔离工作区、并行分支验证或临时试验时使用 - 创建隔离的 git worktree
开始开发编程相关对话时使用 - 建立如何查找和使用 skills，在做出任何响应前要求先检查适用的 skill
| name | dev-debugging |
| description | 遇到任何 bug、测试失败或意外行为时使用，在提出修复前 - 系统化调试 |
随机修复浪费时间并制造新 bug。快速修补掩盖根本问题。
核心原则： 总是先找到根本原因再尝试修复。症状修复就是失败。
违反此流程的文字就是违反调试的精神。
没有先完成第一阶段根本原因调查，就没有修复
如果你还没有完成第一阶段，你不能提出修复。
对任何技术问题使用：
特别在这些情况下使用：
不要在以下情况下跳过：
你必须完成每个阶段才能进入下一个。
尝试任何修复前：
仔细阅读错误消息
一致重现
检查最近变更
在多组件系统中收集证据
当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：
提出修复前，添加诊断工具：
对每个组件边界：
- 记录什么数据进入组件
- 记录什么数据离开组件
- 验证环境/配置传播
- 检查每层状态
运行一次收集证据显示在哪里中断
然后分析证据识别失败组件
然后调查该特定组件
追踪数据流
当错误在调用堆栈深处时：
修复前找到模式：
找到工作示例
与参考对比
识别差异
理解依赖
科学方法：
形成单一假设
最小测试
继续前验证
当你不知道时
修复根本原因，不是症状：
创建失败测试用例（必须调用 dev-tdd）
dev-tdd skilldev-tdd skill 编写正确的失败测试实现单一修复
验证修复
如果修复无效
如果 3+ 修复失败：质疑架构
表示架构问题的模式：
停止并质疑基本原则：
在尝试更多修复前与用户讨论
这不是失败的假设 - 这是错误的架构。
如果你发现自己在想：
所有这些意味着：停止。返回阶段 1。
如果 3+ 修复失败： 质疑架构（见阶段 4.5）
| 借口 | 现实 |
|---|---|
| "问题简单，不需要流程" | 简单问题也有根本原因。流程对简单 bug 很快。 |
| "紧急情况，没时间走流程" | 系统化调试比猜测检查折腾更快。 |
| "先试试这个，然后再调查" | 第一个修复设定模式。从一开始就正确做。 |
| "确认有效后再写测试" | 未经测试的修复不持久。先测试证明它。 |
| "同时多个修复节省时间" | 无法隔离什么有效。制造新 bug。 |
| "参考太长，我会适配模式" | 部分理解保证 bug。完整阅读。 |
| "我看到问题了，让我修复它" | 看到症状 ≠ 理解根本原因。 |
| 阶段 | 关键活动 | 成功标准 |
|---|---|---|
| 1. 根本原因 | 阅读错误、重现、检查变更、收集证据 | 理解什么和为什么 |
| 2. 模式 | 找到工作示例、对比 | 识别差异 |
| 3. 假设 | 形成理论、最小测试 | 确认或新假设 |
| 4. 实现 | 创建测试、修复、验证 | Bug 解决，测试通过 |
找到根本原因后，不要直接修复。必须使用 TDD：
Phase 4 实施流程：
1. 调用 dev-tdd skill
↓
2. RED: 编写失败测试重现 bug
↓
3. 验证 RED: 运行测试确认失败于预期原因
↓
4. GREEN: 编写最小修复使测试通过
↓
5. 验证 GREEN: 运行测试确认通过
↓
6. REFACTOR: 清理代码（可选）
↓
7. 验证所有测试通过
这些都是错误的。必须先有失败测试。
相关 skill：
来自调试会话：