Agent Skills › didi/helixharness › systematic-debugging

systematic-debugging

GitHub

系统化调试工具，用于复现异常、缩小范围、验证假设并定位根因。在用户授权下执行修复与回归验证，严格区分症状与根因，确保修复有效。

helixharness/skills/systematic-debugging/SKILL.md didi/helixharness

Trigger Scenarios

测试失败编译或运行时错误预期行为与实际行为不一致观察到功能回退

Install

npx skills add didi/helixharness --skill systematic-debugging -g -y

More Options

Non-standard path

npx skills add https://github.com/didi/helixharness/tree/main/helixharness/skills/systematic-debugging -g -y

Use without installing

npx skills use didi/helixharness@systematic-debugging

指定 Agent (Claude Code)

npx skills add didi/helixharness --skill systematic-debugging -a claude-code -g -y

安装 repo 全部 skill

npx skills add didi/helixharness --all -g -y

预览 repo 内 skill

npx skills add didi/helixharness --list

SKILL.md

Frontmatter

{
    "name": "systematic-debugging",
    "description": "用户独立调用的调试工具。复现异常、缩小范围、验证假设并定位根因，按用户授权修复和验证，不由研发命令自动触发。",
    "disable-model-invocation": true
}

系统化调试

用户明确要求使用本 Skill，且真实不一致已经出现时，独立开展调试：

expected behavior != actual behavior
test fails
compile/runtime error appears
observed behavior regresses or contradicts an agreed requirement

不要把这个 skill 用于模糊的设计讨论。那属于 planning，不属于 debugging。

目标

基于证据找到根因，再用回归检查确认修复真实有效。

工作流

明确不一致是什么。写清楚：
- expected behavior
- actual behavior
- where it was observed
稳定复现。优先用一个确定性的命令、请求或测试来复现。如果复现不稳定，要明确记录。
缩小范围。检查：
- input data
- call path
- changed files
- environment/config assumptions
提出假设。假设必须具体且可证伪。好的例子：
- "null value enters mapper X and breaks branch Y" 不好的例子：
- "something is wrong with the service"
执行有区分度的检查。选择能排除某个假设的下一条命令或检查。
确认根因。区分清楚：
- symptom
- trigger
- root cause
做最小且合理的修复。仅在用户已授权修复时执行；只要求诊断时，交付根因、证据和修复建议，不修改代码。除非根因要求，否则不要顺手做大范围重构。
重新执行复现和回归检查。不重新验证，修复就不算完成。