Debug repro loop

Skill zaixincheng174-ai/codex-agent-governance-skills/core/skills/debug-repro-loop

工程现场环路 P1。用于 bug、失败测试、性能变慢、卡住、浏览器/工具异常等诊断任务。诊断默认不进入 project-lifecycle;先用本 skill 做复现、定位、最小修复、回归验证。若诊断升级成重构/新功能/项目级交付,再转入 project-lifecycle。From its SKILL.md

Install

npx -y skills add zaixincheng174-ai/codex-agent-governance-skills --skill debug-repro-loop

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 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.

SKILL.md

2.9 KB, ~1.0k tokens by cl100k_base, as published. Nobody here has run it

debug-repro-loop —— 诊断专用复现闭环

1. 触发条件

必须触发:

用户问"为什么报错 / 为什么慢 / 为什么挂住 / 帮我 debug / 诊断一下"。
测试、构建、CI、本地服务、浏览器流程、性能路径出现失败或退化。
需要先复现现象再判断是否修代码。

不触发:

明确的新功能、重构、成体系交付;这些走 project-lifecycle。
已有明确补丁方案且只需机械应用的一行小改。
纯解释错误信息且不需要现场验证。

2. 核心规则

先复现,再解释;不能复现就不能把原因说死。
先定位最小失败面,再改最小补丁;不要把诊断变成顺手重构。
性能诊断必须保留基线和复测口径;不要用感觉判断变快。
工具/浏览器/外部服务问题要区分:本地代码问题、环境问题、权限/网络问题、工具自身问题。
若发现需要架构设计或多模块重写,停下并转入 project-lifecycle。

3. 执行路径

写下症状:用户看见的失败、命令、页面、输入、期望/实际。
复现:运行最小命令或操作,记录可复现证据;不可复现则记录尝试和差异。
缩小:用日志、二分、定向测试、最小数据或浏览器证据定位到文件/函数/边界。
判因:只陈述证据支持的原因;假设必须标成假设。
修复:只改直接导致失败的最小代码面。
回归:重跑原复现步骤,再跑与风险匹配的相关检查。
输出:症状、根因、改动、验证、残余风险。

4. 输出格式

Debug Repro Report
Symptom: <用户可见现象>
Reproduction: <命令/步骤 + 结果>
Narrowed cause: <文件/函数/边界 + 证据>
Fix scope: <修改了什么,为什么是最小面>
Regression evidence: <原复现是否通过 + 相关检查>
Escalation: <无 / 转 project-lifecycle 的理由>
Verdict: <FIXED / BLOCKED / INCONCLUSIVE>

5. 门禁

门禁项	严重度	检查
DR0 复现证据	blocker	是否跑过能代表症状的最小复现?
DR1 根因有定位	blocker	根因是否有文件/函数/命令/页面证据?
DR2 修复最小	blocker	是否只改直接相关代码,无顺手重构?
DR3 回归验证	blocker	原失败路径是否重跑并通过或明确仍阻塞?
DR4 边界诚实	warning	无法复现、环境阻塞、性能噪声是否显式说明?

6. 反例

不要先改代码再找复现。
不要把"可能是 X"写成根因。
不要用一次绿色全量测试掩盖原失败路径没有重跑。
不要把诊断中发现的重构机会直接做掉。

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.