Menü
遇到任何 bug、测试失败或非预期行为时使用；在提出修复方案之前必须先完成系统化的 root cause 调查。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
初始化新 skill 目录（运行 init_skill.py）、打包 skill（运行 package_skill.py）、或需要了解 skill 结构规范时使用。
在编写 skill 内容、验证 skill 是否有效、或需要用 TDD 方法测试 skill 能否被正确遵守时使用。
Frontend Master - 大师级前端页面开发。智能分析项目技术栈，生成独特设计美感的 UI，避免'AI审美'。自动持久化设计规范，保持项目一致性。整合 Frontend-Design 设计哲学 + UI-UX Pro Max 设计数据库。触发词: 前端、页面、组件、UI、登录页、落地页、dashboard、表单、卡片、导航栏。
你必须在任何创意工作之前使用：新功能、组件搭建、添加能力或修改行为。先通过对话澄清用户意图、需求与设计，再进入实现。
当你面对 2 个以上彼此独立的任务（无共享状态、无顺序依赖）时使用：为每个独立问题域派发一个 agent 并行推进。
当你已经有一份书面的 implementation plan，需要在独立 session 中按批执行并在批次间做 review checkpoint 时使用。
| name | systematic-debugging |
| description | 遇到任何 bug、测试失败或非预期行为时使用；在提出修复方案之前必须先完成系统化的 root cause 调查。 |
乱改只会浪费时间并制造新 bug；“快速补丁”会掩盖底层问题。
核心原则： 在尝试任何修复之前，永远先找到 root cause。只修症状 = 失败。
只遵守字面、不遵守精神，就是在违背 debugging。
未完成 root cause 调查，禁止提出修复
如果你还没完成 Phase 1，就不能开始给“修复方案”。
适用于任何技术问题：
尤其在这些时候更要用：
不要因为这些理由跳过：
你必须完成当前阶段，才能进入下一阶段。
在尝试任何修复之前：
认真读错误信息
稳定复现
检查近期变更
多组件系统：先加证据采集
当系统存在多个组件边界（CI → build → signing，API → service → database）时：
在提出修复前，先加诊断/日志来定位断点：
对每个组件边界：
- 记录进入该组件的数据
- 记录离开该组件的数据
- 验证 environment/config 是否正确传递
- 在每一层检查 state
跑一遍，收集证据来回答“在哪一层坏掉”
然后只针对坏掉的那层深入调查
示例（多层系统）：
# 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 ✗）。
当错误深埋在 call stack 里：
请阅读本目录的 root-cause-tracing.md 获取完整的“逆向回溯”技巧。
快速版：
在修复前先找到规律：
找能工作的对照样例
对照参考实现
列出差异
理解依赖
用科学方法：
提出一个单一假设
最小化验证
验证结果再继续
当你不知道时
修 root cause，不修症状：
先写一个会失败的测试用例
superpowers:test-driven-development 来写合格的 failing test实现单一修复
验证修复
如果修复无效
当 3+ 次修复都失败：质疑架构
提示存在架构问题的模式：
停止并质疑基本假设：
在继续更多修复前，先与 human partner 讨论。
这不是“假设失败”，而是“架构不对”。
如果你发现自己在想：
这些都意味着：STOP。回到 Phase 1。
如果 3+ 次修复失败： 质疑架构（Phase 4.5）。
当你听到这些重定向：
看到这些：STOP，回到 Phase 1。
| 借口 | 现实 |
|---|---|
| “问题很简单，不需要流程” | 简单问题也有 root cause；流程对简单 bug 更快。 |
| “紧急，没时间走流程” | 系统化比 guess-and-check 更快。 |
| “我先试这个，再调查” | 第一次修复会定下节奏，从一开始就做对。 |
| “我确认修复有效后再写测试” | 没测试的修复不牢靠；test-first 才能证明。 |
| “一次改多个更省时间” | 无法隔离哪个改动起作用，还会引入新 bug。 |
| “reference 太长，我就按感觉套用” | 半懂不懂必出 bug；要完整读完。 |
| “我看到问题了，直接修” | 看到症状 ≠ 理解 root cause。 |
| “再试一次修复”（已失败 2+） | 3+ 失败提示架构问题：别再修症状，去质疑 pattern。 |
| Phase | 关键活动 | 成功标准 |
|---|---|---|
| 1. Root Cause | 读错误、复现、看变更、采证据 | 理解 WHAT + WHY |
| 2. Pattern | 找对照样例、对照 reference | 找到差异 |
| 3. Hypothesis | 提假设、最小验证 | 假设被证实或更换假设 |
| 4. Implementation | 写测试、修复、验证 | 问题解决 + 测试通过 |
如果系统化调查显示问题确实是环境/时序/外部依赖导致：
但： 95% 的“没有 root cause”其实是 Phase 1 不完整。
本目录包含系统化 debugging 的辅助技巧：
root-cause-tracing.md：沿 call stack 逆向回溯到最初触发点defense-in-depth.md：找到 root cause 后，在多层加入校验condition-based-waiting.md：用条件轮询替代任意 timeout相关 skills：
superpowers:test-driven-development：用于 Phase 4 Step 1 的 failing testsuperpowers:verification-before-completion：在宣称修复成功前做验证来自真实排障经验：