القائمة
在遇到任何 bug、测试失败或非预期行为时使用，在提出修复方案之前
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
在当前会话中执行包含若干独立任务的实现计划时使用
Kimi WebBridge lets AI control the user's real browser — navigate, click, type, read, screenshot, and interact with any website using the user's actual login sessions. Use this skill whenever the user wants to interact with websites, automate browser tasks, scrape web content, or perform any action requiring a real browser. Also use when the user mentions "browser", "webpage", "open URL", "screenshot", or asks to read/interact with any website. Use even for simple-sounding browser requests — the daemon handles all complexity.
对 PostgreSQL 数据库执行只读检查时使用。优先读 doc/db/quick-guide 匹配场景，表结构按需 docker exec psql 查询；查库后评估是否沉淀 quick-guide。触发词：查数据库、检查表、行数、数据覆盖、schema、docker exec psql、DB 状态、doc/db、快捷检索指南、quick-guide。
在进行任何创意性工作之前必须使用此技能 — 创建功能、构建组件、添加功能、实现需求或修改行为。在实现前探索用户意图、需求和设计。用户说"头脑风暴"或类似的表达时，应触发此技能。
调用 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。
当面临 2 个以上可独立执行、无共享状态或顺序依赖的任务时使用
| 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 —— 用条件轮询替代任意超时相关技能：
来自实际调试会话：