Menu
遇到任何 bug、测试失败或非预期行为时使用；在提出修复方案之前必须先完成系统化的 root cause 调查。
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
初始化新 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：在宣称修复成功前做验证来自真实排障经验：