linxuan-sys
linxuan-sys/opencode-skills-chinese
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/linxuan-sys/opencode-skills-chinese --skill systematic-debugging命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
任何时候只要涉及.pptx文件——无论是作为输入、输出还是两者兼有——就使用此技能。这包括：创建幻灯片、推介文件或演示文稿；读取、解析或提取任何.pptx文件中的文本（即使提取的内容将用于其他地方，比如邮件或摘要）；编辑、修改或更新现有演示文稿；合并或拆分幻灯片文件；处理模板、布局、演讲者备注或注释。只要用户提到"deck"、"slides"、"presentation"或引用.pptx文件名，无论他们后续打算如何处理内容，都要触发此技能。如果需要打开、创建或处理.pptx文件，使用此技能。
使用p5.js创建带有种子随机和交互式参数探索的算法艺术。当用户请求使用代码创建艺术、生成艺术、算法艺术、流场或粒子系统时使用此技能。创建原创算法艺术，而不是复制现有艺术家的作品，以避免侵犯版权。
引导用户完成结构化的文档协作工作流程。当用户想要编写文档、提案、技术规范、决策文档或类似结构化内容时使用。此工作流程帮助用户高效地传递上下文、通过迭代优化内容，并验证文档对读者是否有效。当用户提到编写文档、创建提案、起草规范或类似文档任务时触发。
基于 SOC 职业分类
正在显示 SKILL.md
| 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 - 用条件轮询替代任意超时相关技能：
来自调试实践的数据：