addyosmani/debugging-and-error-recovery

指导系统化的根因调试。当测试失败、构建中断、行为与预期不符，或遇到任何意外错误时使用。当你需要用系统化的方法去定位并修复根因，而不是靠猜测时使用。

编程协作开发 Agent Agent 技能写测试仓库问答 skill agent-skill debugging and error recovery addyosmani agent-skills

技术栈: cursor9.2万+许可证: MIT开发者: addyosmani

Skill 介绍Skill 文件

重要提示：本站仅作 Skill 资源导航与收录，正文以 GitHub 原仓库为准，版权归原项目所有。

在 GitHub 查看 ↗

原文译文

以下为摘要预览，完整内容请查看 GitHub 原文。

Debugging and Error Recovery

Overview

Systematic debugging with structured triage. When something breaks, stop adding features, preserve evidence, and follow a structured process to find and fix the root cause. Guessing wastes time. The triage checklist works for test failures, build errors, runtime bugs, and production incidents.

When to Use

Tests fail after a code change
The build breaks
Runtime behavior doesn't match expectations
A bug report arrives
An error appears in logs or console
Something worked before and stopped working

The Stop-the-Line Rule

When anything unexpected happens:

1. STOP adding features or making changes
2. PRESERVE evidence (error output, logs, repro steps)
3. DIAGNOSE using the triage checklist
4. FIX the root cause
5. GUARD against recurrence
6. RESUME only after verification passes

Don't push past a failing test or broken build to work on the next feature. Errors compound. A bug in Step 3 that goes unfixed makes Steps 4-6 wrong.

The Triage Checklist

Work through these steps in order. Do not skip steps.

Step 1: Reproduce

Make the failure happen reliably. If you can't reproduce it, you can't fix it wit…

以下为摘要预览，完整内容请查看 GitHub 原文。

调试与错误恢复

概述

通过结构化分诊进行系统化调试。当出现问题时，停止添加新功能，保留证据，并遵循结构化的流程去定位和修复根因。猜测是在浪费时间。这份分诊清单适用于测试失败、构建错误、运行时 bug 以及生产事故。

何时使用

代码变更后测试失败
构建中断
运行时行为与预期不符
收到 bug 报告
日志或控制台中出现了错误
之前能用的功能突然失效

即停原则

当任何意外情况发生时：

1. STOP —— 停止添加功能或继续改动
2. PRESERVE —— 保留证据（错误输出、日志、复现步骤）
3. DIAGNOSE —— 按分诊清单进行诊断
4. FIX —— 修复根因
5. GUARD —— 防止问题再次发生
6. RESUME —— 只有在验证通过后才继续

不要带着失败的测试或损坏的构建继续做下一个功能。 错误会叠加。第 3 步中未被修复的 bug 会让第 4–6 步也跟着出错。

分诊清单

按顺序完成以下步骤。不要跳过任何步骤。

步骤 1：复现

让失败能够稳定复现。如果无法复现，就无法有信心地修复它。

能否稳定复现失败？
├── 能 → 进入步骤 2
└── 不能
    ├── 收集更多上下文（日志、环境细节）
    ├── 尝试在最小化环境中复现
    └── 如果确实无法复现，记录相关条件并进行监控

当一个 bug 无法复现时：

无法按需复现：
├── 与时序相关？
│   ├── 在怀疑位置附近的日志中加入时间戳
│   ├── 通过人为延迟（setTimeout、sleep）来放大竞态窗口
│   └── 在负载或并发场景下运行，提高冲突概率
├── 与环境相关？
│   ├── 对比 Node/浏览器版本、操作系统、环境变量
│   ├── 检查数据差异（空库 vs 已有数据的库）
│   └── 在环境干净的 CI 中尝试复现
├── 与状态相关？
│   ├── 检查测试或请求之间是否存在状态泄漏
│   ├── 查找全局变量、单例或共享缓存
│   └── 在隔离环境下运行失败场景，与在其他操作之后运行做对比
└── 真的完全随机？
    ├── 在怀疑的位置加入防御性日志
    ├── 针对特定的错误特征设置告警
    └── 记录观察到的条件，等再次出现时重新审视

对于测试失败（以 npm 为例 —— 请按 test-driven-development 技能中 “首先摸清技术栈” 一节所述，替换为仓库自身的测试命令）：

# 运行指定的失败测试
npm test -- --grep "test name"

# 使用详细输出运行
npm test -- -…

重要提示：源文件不在本站托管，请通过 GitHub 查看与下载。

索引更新于 8/25/2026, 9:18:05 PMGitHub ↗

SKILL.md10.6 KB在 GitHub 查看 ↗

addyosmani/debugging-and-error-recovery

Debugging and Error Recovery

Overview

When to Use

The Stop-the-Line Rule

The Triage Checklist

Step 1: Reproduce

调试与错误恢复

概述

何时使用

即停原则

分诊清单

步骤 1：复现

相关资源

yair4Data/mcp-security-analyzer

itsPremkumar/mcptest

Session Continuity Engine

Pay Appraisal

Chat Summary and Export Instructions

Clinical Research Presentation Guidance