Community编程与开发github.com

thananon/调试咒语

四步调试规范——复现、追踪失败路径、证伪假设、交叉验证所有线索。调试开始时完整背诵咒语,随后按顺序应用四个步骤。

调试咒语 是什么?

这个技能定义了一套严谨的四步调试规范,旨在帮助开发者和AI代理系统性地诊断和修复Bug。它通过一条核心咒语引导用户或AI,在调试开始时首先逐字背诵,然后严格遵循“复现问题”、“追踪失败路径”、“证伪假设”和“交叉验证线索”四个步骤,任何修复方案都必须在完成全部步骤后才能提出。该技能支持通过 `/debug-mantra` 命令手动触发,也能在用户报告Bug、抛出错误、请求调试或粘贴堆栈跟踪/错误日志时自动激活。其核心价值在于将零散的调试经验转化为可重复、可验证的标准化流程,有效避免在信息不足的情况下仓促修改代码。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/thananon/9arm-skills/tree/main/skills/debug-mantra

Installed? Explore more 编程与开发 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

调试咒语 是做什么的?

四步调试规范——复现、追踪失败路径、证伪假设、交叉验证所有线索。调试开始时完整背诵咒语,随后按顺序应用四个步骤。在 /debug-mantra 触发时,以及用户报告Bug、说某些东西损坏/抛出错误/失败、要求调试/诊断/调查问题、或粘贴堆栈跟踪/错误日志时主动启用。

咒语

第一步:复现。我能否在干净状态下以最简步骤看到失败? 第二步:追踪失败路径。故障从哪一条执行路径萌生? 第三步:证伪假设。我的假设是否经得起置换/改变/检验? 第四步:交叉验证。我是否遗漏了其他线索?日志、断言、其他行为、输入变化……

步骤

  1. 复现问题 — 在干净环境中获取最简复现步骤。
  2. 追踪失败路径 — 从错误信息反向跟踪代码的失败路径。
  3. 证伪假设 — 通过置换、改变或检验当前假设,尽量证伪它。
  4. 交叉验证 — 检查日志、断言、其他行为或输入变化,确保没有遗漏任何线索。

触发方式

  • 手动:/debug-mantra
  • 自动:用户报告Bug、说某些东西损坏/抛出错误/失败、要求调试/诊断/调查问题、或粘贴堆栈跟踪/错误日志时主动调用。

在完成全部四个步骤之前,不要提出任何修复方案。

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

thananon/management-talk

Rewrite engineer-to-engineer content for engineering-org leadership (VPs, directors, PMs, release managers, execs in an engineering-savvy company) and shape it for the channel it is going to — JIRA comment, Slack post, async standup line, email, or meeting talking-points. Trigger when the user asks to write/rewrite for management / exec / VP / director / PM / release manager, asks for an "executive summary / leadership update / status update", says "make this less technical / less jargony", or asks for a slack / email / standup / meeting version of work originally written engineer-to-engineer.

thananon/post-mortem

Write the canonical engineering record of a fixed bug — root cause, mechanism, fix, validation, and how it slipped through. Engineer-audience, code identifiers welcome. Use after a debug session lands a fix, before closing the ticket. Trigger on /post-mortem, when the user says "write the post-mortem / postmortem / RCA / root cause analysis", "document this fix", "write up the root cause", "close out this bug with a writeup", or hands you a fixed-and-validated bug and asks for the writeup.

thananon/scrutinize

Outsider-perspective end-to-end review of a plan, PR, or code change. First questions intent and whether a simpler/more elegant approach would achieve the same goal, then traces the actual code path (not just the diff) to verify the change does what it claims. Output is concise, actionable, and every call carries its rationale. Trigger on /scrutinize and proactively whenever the user asks to review, audit, sanity-check, or get a second opinion on a plan, PR, diff, design doc, or proposed code change.

相关技能