From hw
Conducts symptom-driven root-cause analysis of concrete failures using a structured debug workflow with hypothesis validation and optional auto-fix.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hw:debugThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
📌 输出语言规则:
📌 输出语言规则: 读取 config.yaml → output.language
当用户需要症状驱动的根因分析而非预防性审计扫描时,使用此技能进行五步调试工作流。
如果调试已经从一次性诊断变成持续 root-cause investigation(需要多轮假设、实验、解释、结论或跨回合恢复),自动切换或建议进入 Analysis lane:加载 skills/analysis/SKILL.md,使用 /hw:analysis enter "<question>" 或 /hw:analysis continue 语义,并把完整证据写入 Analysis ledger。Debug 报告可保留症状入口,但 durable source of truth 应变为 .pipeline/analysis/<cycle-or-milestone>/ledger.yaml 或已有 legacy ledger。
当项目 execution.worker_separation.mode 启用时:
execution.worker_separation.mode=off 时,在可行的情况下将实现帮助与测试复现分开execution.worker_separation.mode=recommended 时,如果复现/测试和实现合并到一个 Worker 上,调试不得声称 Worker 分离验证;停止、重试、推迟或要求用户明确确认降级后才能进行本地角色敏感编辑execution.worker_separation.mode=strict 时,调试必须在声称完成证据前保持复现/测试、实现和审计/验证 Worker 的独立性test 或复现 Worker 拥有失败复现、失败测试、夹具、快照、断言、验证命令和证据;implement Worker 不得创建、编辑或重写该测试证据implement Worker 仅拥有生产/运行时/文档修复,不得生成或冒充 test 或 audit/hw:audit 仍是规范的审计通道,调试不得将审计静默合并到修复器中requested、started、completed|failed|blocked 和 closed|close_failed;在推进前等待证据,并在调试停止、阻塞、中止或完成时关闭/释放 Workeroutput.language 和 output.timezone。output.language 生成根因报告和可选的修复建议,并按 references/completion-report-contract.md 写出完成说明:
无无--auto-fix 编辑或独立验证前,确认所需的 Worker 授权或停止并给出阻塞原因。--auto-fix 时,仅在验证通过后才声称成功。close_failed 及 Worker ID 和原因;未解决的 Worker 生命周期无法满足调试验证证据。.pipeline/debug/,时间戳使用 output.timezone,并追加调试生命周期条目。current.phase=lifecycle_debug。prompt_state.analysis_summary,包含 question、ledger path、outcome/conclusion、confidence、next action 和计数;不要把完整 hypotheses 或 experiments 写入 state。references/debug-spec.mdreferences/analysis-spec.mdreferences/analysis-ledger-spec.mdreferences/completion-report-contract.mdreferences/log-spec.mdSKILL.mdnpx claudepluginhub hypoxanthineovo/hypo-workflow --plugin hwInvestigates root causes of bugs systematically before applying fixes. Runs four phases: Investigate, Analyze, Hypothesize, Implement. Enforces no guessing, triggers on verification failures or debug invocation.
Guides developers through systematic root cause investigation of bugs and failures. Use when encountering test failures, errors, or unexpected behavior.
Provides a structured root-cause debugging workflow for any bug, test failure, or unexpected behavior. Run before proposing fixes to avoid random or symptom-level patches.