القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
استنادا إلى تصنيف SOC المهني
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/linxuan-sys/opencode-skills-chinese --skill systematic-debuggingيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
عرض SKILL.md
任何时候只要涉及.pptx文件——无论是作为输入、输出还是两者兼有——就使用此技能。这包括：创建幻灯片、推介文件或演示文稿；读取、解析或提取任何.pptx文件中的文本（即使提取的内容将用于其他地方，比如邮件或摘要）；编辑、修改或更新现有演示文稿；合并或拆分幻灯片文件；处理模板、布局、演讲者备注或注释。只要用户提到"deck"、"slides"、"presentation"或引用.pptx文件名，无论他们后续打算如何处理内容，都要触发此技能。如果需要打开、创建或处理.pptx文件，使用此技能。
使用p5.js创建带有种子随机和交互式参数探索的算法艺术。当用户请求使用代码创建艺术、生成艺术、算法艺术、流场或粒子系统时使用此技能。创建原创算法艺术，而不是复制现有艺术家的作品，以避免侵犯版权。
引导用户完成结构化的文档协作工作流程。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效地传递上下文、通过迭代优化内容，并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
| name | systematic-debugging |
| description | 在提出修复方案前，遇到任何bug、测试失败或意外行为时使用 |
随机修复浪费时间还会引入新bug。快速补丁会掩盖根本问题。
核心原则： 在尝试修复前必须找到根本原因。仅修复症状等同于失败。
违反本流程的字面要求就是违背调试的核心精神。
未先开展根本原因调查，绝不提出修复方案
如果你还没有完成第一阶段，就不能提出修复方案。
适用于所有技术问题：
尤其在以下场景必须使用：
以下场景也不要跳过：
你必须按顺序完成每个阶段才能进入下一阶段。
在尝试任何修复前：
仔细阅读错误信息
稳定复现问题
检查最近的变更
在多组件系统中收集证据
当系统包含多个组件时（CI → 构建 → 签名，API → 服务 → 数据库）：
在提出修复方案前，添加诊断埋点：
对每个组件边界：
- 记录进入组件的数据
- 记录离开组件的数据
- 验证环境/配置传递
- 检查每一层的状态
运行一次收集证据，明确哪里出了问题
然后分析证据确定故障组件
再针对该特定组件展开调查
示例（多层系统）：
# 第一层：工作流
echo "=== 工作流中可用的密钥: ==="
echo "IDENTITY: ${IDENTITY:+已设置}${IDENTITY:-未设置}"
# 第二层：构建脚本
echo "=== 构建脚本中的环境变量: ==="
env | grep IDENTITY || echo "IDENTITY不在环境中"
# 第三层：签名脚本
echo "=== 钥匙串状态: ==="
security list-keychains
security find-identity -v
# 第四层：实际签名
codesign --sign "$IDENTITY" --verbose=4 "$APP"
这会揭示： 哪一层出了问题（密钥 → 工作流 ✓，工作流 → 构建 ✗）
跟踪数据流
当错误出现在调用栈深处时：
查看本目录下的root-cause-tracing.md了解完整的反向跟踪技术。
快速版本：
在修复前找到规律：
找到可运行的示例
对照参考实现
识别差异
理解依赖关系
科学方法：
提出单一假设
最小化测试
验证后再继续
当你不确定时
修复根本原因，而非症状：
创建失败测试用例
superpowers:test-driven-development技能编写规范的失败测试实现单一修复
验证修复
如果修复没有生效
如果3次以上修复失败：重新审视架构
表明存在架构问题的模式：
停下来重新审视基础设计：
在尝试更多修复前和你的人类伙伴讨论
这不是假设失败 - 这是架构错误。
如果你发现自己有这些想法：
所有这些都意味着：停止，回到第一阶段。
如果3次以上修复失败： 重新审视架构（见第四阶段第5点）
注意这些提示：
当你看到这些时： 停止，回到第一阶段。
| 借口 | 现实 |
|---|---|
| "问题很简单，不需要走流程" | 简单问题也有根本原因。流程处理简单bug更快。 |
| "紧急情况，没时间走流程" | 系统化调试比猜测试错快得多。 |
| "先试试这个，之后再调查" | 第一次修复会定下调子。从一开始就做对。 |
| "确认修复生效后我再写测试" | 未测试的修复不牢靠。先写测试才能证明修复有效。 |
| "同时改多个地方省时间" | 无法确定哪个改动生效了。还会引入新bug。 |
| "参考实现太长，我改改用就行" | 一知半解肯定会出bug。完整阅读参考实现。 |
| "我知道问题在哪，我来修复" | 看到症状 ≠ 理解根本原因。 |
| "再试一次修复"（失败2次后） | 3次以上失败 = 架构问题。重新审视模式，不要继续修复。 |
| 阶段 | 核心活动 | 成功标准 |
|---|---|---|
| 1. 根本原因 | 阅读错误、复现问题、检查变更、收集证据 | 理解是什么问题以及为什么会发生 |
| 2. 模式分析 | 找到可运行示例、对比差异 | 识别出差异点 |
| 3. 假设验证 | 提出理论、最小化测试 | 假设被证实或提出新假设 |
| 4. 实现修复 | 创建测试、修复问题、验证 | bug解决，测试通过 |
如果系统化调查显示问题确实是环境相关、时序依赖或外部因素导致的：
但是： 95%的"没有根本原因"情况都是调查不完整导致的。
这些技术是系统化调试的一部分，可在本目录中获取：
root-cause-tracing.md - 反向跟踪调用栈找到bug的原始触发点defense-in-depth.md - 找到根本原因后在多层添加验证condition-based-waiting.md - 用条件轮询替代任意超时相关技能：
来自调试实践的数据：