在遇到任何 bug、测试失败或非预期行为时使用，在提出修复方案之前
npx skills add https://github.com/dark789g-ux/cryptotrading --skill systematic-debugging复制此命令并粘贴到 Claude Code 中以安装该技能
任何需要驱动浏览器的任务都用此 skill —— UI 验证、网页自动化、截图、带登录态抓取、代码改动手测。用户提到打开浏览器、在浏览器里测 UI、截网页、在运行中的应用里验证、或任何 web 交互时都触发。需与具体工具 skill（如 kimi-webbridge，负责工具 API 机制）**并用**；本 skill 提供策略层和任务结束时的强制复盘协议，把新经验沉淀到 references/lessons-learned.md。任何浏览器任务**第一时间**读本 skill —— 里面的经验都是真实踩坑换来的，不该再踩第二次。
在进行任何创意性工作之前必须使用此技能 — 创建功能、构建组件、添加功能、实现需求或修改行为。在实现前探索用户意图、需求和设计。用户说"头脑风暴"或类似的表达时，应触发此技能。
用户输入"提交代码"时触发，Claude 根据当前 git 改动分析生成符合 Conventional Commits 规范的 message，经用户确认后完成提交。
当面临 2 个以上可独立执行、无共享状态或顺序依赖的任务时使用
调用 DeepSeek API（/chat/completions）的强制查阅规范，覆盖思考模式（reasoning_content / thinking / reasoning_effort）与多轮对话上下文拼接。**任何**涉及 DeepSeek API 的代码编写、修改、排错前必须先调用本 skill。触发词：DeepSeek、deepseek、deepseek-v4-pro、reasoning_content、思考模式、thinking mode、reasoning_effort、deepseek 多轮、deepseek chat completions、api.deepseek.com。
查询 Tushare 接口文档。**任何**涉及 Tushare 的场景都必须先调用本 skill 查文档，包括：（1）写代码/同步/对接 Tushare；（2）回答"Tushare 是否支持 X""有没有 Y 接口""某接口要多少积分""字段单位是什么""能否取美股/港股/期货/基金数据"等事实型问答；（3）排查 Tushare 返回空/报错；（4）评估 Tushare 与其它数据源的能力边界。触发词包括但不限于：Tushare、tushare、ts_code、pro_api、A股/美股/港股/期货/基金/财务/指数/资金流/龙虎榜/复权 + Tushare。**禁止凭记忆、训练数据、历史代码或邻近接口推断回答任何 Tushare 相关问题——包括"接口是否存在""积分门槛""字段单位""更新频率"。**
| name | systematic-debugging |
| description | 在遇到任何 bug、测试失败或非预期行为时使用，在提出修复方案之前 |
随意的修复浪费时间，还会引入新 bug。临时补丁只会掩盖深层问题。
核心原则： 在尝试修复之前，永远先找到根因（root cause）。修复症状即是失败。
违背本流程的字面规定，就是违背调试的精神。
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
（未先做根因调查，不得动手修复）
如果你还没完成阶段 1，就不能提出修复方案。
适用于任何技术问题：
尤其要在以下情况使用：
不要在以下情况跳过流程：
你必须完成每个阶段，才能进入下一个。
在尝试任何修复之前：
仔细阅读错误信息
稳定地复现
检查近期改动
在多组件系统中收集证据
当系统包含多个组件时（CI → build → signing，API → service → database）：
在提出修复之前，先加入诊断埋点（diagnostic instrumentation）：
For EACH component boundary:
- Log what data enters component
- Log what data exits component
- Verify environment/config propagation
- Check state at each layer
Run once to gather evidence showing WHERE it breaks
THEN analyze evidence to identify failing component
THEN investigate that specific component
示例（多层系统）：
# 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。
简版：
修复前先找到模式（pattern）：
找到可工作的范例
对照参考实现
找出差异
理解依赖
科学方法：
形成单一假设
以最小改动验证
继续之前先验证
当你不知道时
修复根因，而非症状：
创建会失败的测试用例
superpowers: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 —— 用条件轮询替代任意超时相关技能：
来自实际调试会话：