bug-reproduction-brief

Bug 复现简报

当 Bug 报告不完整、间歇性出现、依赖特定环境，或混杂了假定的原因时，使用本技能。目标是在开始诊断或修复之前，先证实最小可观察的失败。

1. 记录观察到的失败

记录确切的错误、错误的输出、时间戳、受影响的路径或命令，以及已知的最小输入。保留相关日志，但不得包含密钥或个人数据。将二手描述标注为未经验证。

2. 确认环境

只记录你可以检查的事实：

• 仓库和提交；
• 运行时和包管理器版本；
• 操作系统或容器；
• 依赖锁定文件；
• 相关的功能开关；
• 目标是本地、测试、预发布还是生产环境。

绝不要猜测凭据或生产配置。

3. 区分预期行为与实际行为

写出两条明确的可观察陈述：

Expected: [observable result]
Actual:   [observable result, including status or error]

不要把怀疑的原因写进任何一条陈述。

4. 精简复现步骤

从报告的路径开始，然后逐一移除无关的数据、服务和步骤。保留仍会失败的最小测试夹具。如果失败不再出现，则恢复最后移除的条件并记录下来。

优先使用隔离的测试、最小脚本或最小安全请求，而不是针对生产环境进行复现。

5. 证明可重复性

在安全的情况下，至少运行两次最小复现。记录命令和输出。如果失败是间歇性的，报告观察到的频率和持续时间，而不是称其为确定性的。

6. 在修复前停止

经过验证的复现就是交付物。在编写简报时不要修改实现代码，因为这会破坏证据，或把诊断与修复混在一起。

输出

# Bug Reproduction Brief

- Target and commit:
- Environment:
- Expected:
- Actual:
- Minimal steps:
- Minimal fixture:
- Reproduced: yes / no / intermittent
- Evidence:
- Unknowns:
- Safe next hypothesis to test:

安全边界

• 不要仅仅为了复现 Bug 而更改生产数据。
• 不要发布密钥、客户记录或私有源代码。
• 不要仅凭相关性就断言根本原因。
• 优先使用只读或可逆的探查方式。
• 在完成经过验证的复现后停止；诊断和修复是独立的工作流。

示例提示词

Use the Bug Reproduction Brief skill on the failing checkout test. Do not fix it yet. Reduce it to the smallest safe failing fixture and report the exact command evidence, expected result, actual result, and remaining unknowns.

来源与许可

改编自 https://github.com/skyestrela/ai-agent-skill-preview 上采用 MIT 许可的工作流。