メニュー
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/zouyangxiaohao111/javaclawbot --skill systematic-debuggingコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Generate Excalidraw diagrams from natural language descriptions. Use when asked to "create a diagram", "make a flowchart", "visualize a process", "draw a system architecture", "create a mind map", or "generate an Excalidraw file". Supports flowcharts, relationship diagrams, mind maps, and system architecture diagrams. Outputs .excalidraw JSON files that can be opened directly in Excalidraw.
Use when starting any conversation - establishes how to find and use skills, requiring Skill tool invocation before ANY response including clarifying questions
基于浏览器的视觉头脑风暴伴侣，专为'反 AI 味'设计而生的设计 intelligence。融合 99 UX 准则 + 71 品牌 craft_notes + 人文与情感原则，让 mockup 一眼有人味儿。**前置依赖：必须加载 [brainstorming]**
SOC 職業分類に基づく
SKILL.md を表示中
| name | systematic-debugging |
| description | 当遇到任何 bug、测试失败或意外行为时使用，在提出修复方案之前 |
随机修复浪费时间并制造新 bug。快速补丁掩盖潜在问题。
核心原则： 在尝试修复之前始终找到根本原因。修复症状是失败。
违反此流程的字面意思就是违反调试的精神。
没有根本原因调查就不能修复
如果你还没有完成阶段 1，就不能提出修复方案。
用于任何技术问题：
特别在以下情况使用：
不要跳过：
你必须完成每个阶段才能进入下一个。
在尝试任何修复之前：
仔细阅读错误信息
一致地复现
检查最近的更改
在多组件系统中收集证据
当系统有多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：
在提出修复之前，添加诊断埋点：
对于每个组件边界：
- 记录进入组件的数据
- 记录离开组件的数据
- 验证环境/配置传播
- 检查每层的状态
运行一次收集证据，显示在哪里中断
然后分析证据识别故障组件
然后调查该特定组件
示例（多层系统）：
# Layer 1: Workflow
echo "=== Secrets available in workflow: ==="
echo "IDENTITY: ${IDENTITY:+SET}${IDENTITY:-UNSET}"
# Layer 2: Build script
echo "=== Env vars in build script: ==="
env | grep IDENTITY || echo "IDENTITY not in environment"
# Layer 3: Signing script
echo "=== Keychain state: ==="
security list-keychains
security find-identity -v
# Layer 4: Actual signing
codesign --sign "$IDENTITY" --verbose=4 "$APP"
这揭示： 哪层失败（secrets → workflow ✓, workflow → build ✗）
追踪数据流
当错误在调用栈深处时：
请参阅本目录中的 root-cause-tracing.md 了解完整的向后追踪技术。
快速版本：
在修复之前找到模式：
找到工作示例
与参考对比
识别差异
理解依赖
科学方法：
形成单一假设
最小化测试
验证后再继续
当你不知道时
修复根本原因，而非症状：
创建失败测试用例
zjkycode:test-driven-development 技能编写正确的失败测试实现单一修复
验证修复
如果修复不起作用
如果 3 次以上修复失败：质疑架构
表明架构问题的模式：
停止并质疑基础：
在尝试更多修复之前与你的伙伴讨论
这不是失败的假设 - 这是错误的架构。
如果你发现自己在想：
所有这些都意味着：停止。返回阶段 1。
如果 3 次以上修复失败： 质疑架构（见阶段 4.5）
注意这些重定向：
当你看到这些：停止。返回阶段 1。
| 借口 | 现实 |
|---|---|
| "问题很简单，不需要流程" | 简单问题也有根本原因。流程对简单 bug 很快。 |
| "紧急情况，没时间走流程" | 系统化调试比猜测检查的盲目尝试更快。 |
| "先尝试这个，然后调查" | 第一次修复设定模式。从一开始就做对。 |
| "我会在确认修复有效后写测试" | 未测试的修复不会持久。测试先证明它。 |
| "一次多个修复节省时间" | 无法隔离什么有效。导致新 bug。 |
| "参考太长，我会适应模式" | 部分理解保证 bug。完整阅读。 |
| "我看到问题了，让我修复它" | 看到症状 ≠ 理解根本原因。 |
| "再尝试一次修复"（2 次以上失败后） | 3 次以上失败 = 架构问题。质疑模式，不要再修复。 |
| 阶段 | 关键活动 | 成功标准 |
|---|---|---|
| 1. 根本原因 | 阅读错误、复现、检查更改、收集证据 | 理解什么和为什么 |
| 2. 模式 | 找到工作示例、对比 | 识别差异 |
| 3. 假设 | 形成理论、最小化测试 | 确认或新假设 |
| 4. 实现 | 创建测试、修复、验证 | Bug 解决，测试通过 |
如果系统化调查揭示问题确实是环境、时序依赖或外部的：
但是： 95% 的"没有根本原因"案例是不完整的调查。
这些技术是系统化调试的一部分，可在本目录中找到：
root-cause-tracing.md - 通过调用栈向后追踪 bug 以找到原始触发点defense-in-depth.md - 在找到根本原因后在多层添加验证condition-based-waiting.md - 用条件轮询替换任意超时相关技能：
来自调试会话：