Easyuseaide complex debugging
Skill john-ops-lab/EasyUseAIDE/assets/skills/easyuseaide-complex-debugging
面向个人开发者的跨 IDE Agent AI 编码工程化规则、Skills 与项目交付模板。
npx -y skills add john-ops-lab/EasyUseAIDE --skill easyuseaide-complex-debuggingAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 15 days oldThe repository was created 15 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use this skill for intermittent, repeated, concurrent, performance, resource-leak, flaky-test, integration, or production-only failures that need investigation beyond an ordinary bug fix. If another general debugging workflow is active, keep it as the primary root-cause process and use this skill only for additional failure-mode checks; do not run two complete debugging workflows.
SKILL.md
3.3 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it
复杂故障排查
目标不是快速制造看似有效的补丁，而是形成可重复证据、定位根因并验证修复。
与已有调试框架配合
如果其他插件、Skill 或项目规则已经指定通用调试流程，以该流程作为根因调查主流程。本 Skill 只补充间歇性、并发、性能、资源泄漏、失败恢复和反复复发场景的专项检查。
复用已有故障描述、复现步骤、假设记录、测试和日志证据，不重新创建第二套调查流程。两个流程要求真正冲突时，遵循用户当前指令和项目规则；仍无法解决时先报告差异，不默默选择。
1. 定义故障
开始复杂故障调查时，读取 assets/incident-investigation.md，根据当前项目情况创建调查记录，并在排查过程中持续更新。
记录：
- 预期行为；
- 实际行为；
- 首次出现时间和变化；
- 稳定复现还是间歇出现；
- 影响范围；
- 当前已有证据；
- 已尝试方案及结果。
区分事实、推断和未知。
2. 建立最小复现
优先获得：
- 最小输入；
- 最小环境；
- 稳定命令；
- 失败日志、错误码或指标；
- 修改前必然失败的测试。
不能稳定复现时，先增加必要的可观测性，不盲目修改核心逻辑。
3. 缩小范围
按证据逐层排除：
- 输入与配置；
- 调用链与数据流；
- 边界条件；
- 外部依赖；
- 并发与事务；
- 超时、重试和部分失败；
- 缓存和状态；
- 资源释放；
- 环境和版本差异。
每次只验证一个主要假设，并记录结果。
4. 选择验证工具
按问题使用：
- 单元或集成测试；
- 日志和结构化事件；
- Trace；
- 指标和性能剖析；
- 数据库执行计划、锁和事务视图；
- 网络抓包或请求录制；
- 线程、进程、内存和文件句柄分析；
- 二分定位；
- 故障注入；
- 并发或压力测试。
没有基准时不声称性能提升。
5. 修复原则
- 修复根因，不只屏蔽症状；
- 保持改动最小；
- 不删除测试或放宽断言；
- 证据不足时不进行大规模重构；
- 多次修补仍反复出现时，重新检查领域模型、数据流和设计边界。
6. 验证修复
确认：
- 原始复现不再失败；
- 修改前失败、修改后通过；
- 相邻正常场景未受影响；
- 必要回归测试已增加；
- 并发、重复、失败恢复或资源释放得到与风险匹配的验证；
- 未验证内容和剩余风险明确记录。
7. 沉淀
记录根因、关键证据、修复、回归测试和长期改进。临时调试流水不全部写入长期项目文档。
长期项目中，将依据 assets/incident-investigation.md 完成的调查记录保存到项目 docs/ 下，并在 project-status.md 中引用，不在状态文件中复制完整调查内容。