mcpField
B
bug-receipt

bug-receipt

github.com/github测试与质量40.5k43 次安装今天更新
代码仓库

关于 bug-receipt

用于 Bug 和事件收尾的技能，要求以基于证据的收据作为完整面向用户的结果。它强调最小变更、在受影响边界直接验证，并明确标记 VERIFIED、PARTIAL 或 BLOCKED 状态。

主要功能

  1. 01要求使用结构化收尾收据
  2. 02记录证据来源并保护隐私边界
  3. 03追踪症状至具体原因
  4. 04实施必要的最小变更
  5. 05在受影响边界验证行为
  6. 06依据证据标记状态

适用场景

  1. 01以验证证据完成 Bug 修复收尾
  2. 02报告仍有验证缺口的事件
  3. 03为 CI 集成准备机器可读收据

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/github/awesome-copilot --skill bug-receipt

安装后在 Claude Code 中输入/bug-receipt确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

assets/
receipt.template.json
references/
receipt-contract.md
receipt.schema.json
scripts/
validate-receipt.mjs

详细介绍

Bug Receipt

强制收尾输出

对于每一项 bug 或 incident 的收尾决定，都要将下面完整的 receipt 作为面向用户的全部结果返回，即使用户要求简洁回复或没有点名此格式。简洁只会缩短字段值；它绝不会删除或重命名某一行。不要用散文代替 receipt。

BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED

Problem    <observed defect and intended behavior>
Baseline   <failing interaction or command and decisive result; or not run>
Root cause <proven mechanism; or unproven hypothesis>
Change     <responsible change; or none>
Proof      <supplied or executed check: result; include every decisive layer>
Gaps       <none; or exact missing proof and single next experiment/package>
Source     executed now | supplied | mixed

明确使用 not run、unproven 或 none。绝不要为了让 receipt 看起来完整而省略某一行。

确立证据边界

在编辑之前，记录观察到的问题、预期行为、最强直接检查以及证据来源：executed now、supplied 或 mixed。绝不要暗示所提供的证据是在当前运行中执行的。

保持证据的隐私最小化。遮蔽凭据、令牌、cookie、个人数据、私有 URL 和敏感载荷；只保留复现或关联该故障所需的标识符和摘录。

在可能的情况下，用最窄的安全检查复现故障。如果无法复现，保留已获得的证据，并将结果上限设为 PARTIAL 或 BLOCKED。

追踪与修复

  1. 沿实际 owner 路径从输入追踪到症状。
  2. 区分观察到的事实、有界推断和缺口。
  3. 在命名根因之前，要求有具体位置或运行时状态转换。
  4. 做最小且负责任的更改；避免无关的清理、重试、静默回退和针对特定夹具的例外。

不要将看似合理的补丁、过期日志、源码阅读或通过的构建转化为对用户可见行为的证明。

闭合证明回路

只运行受影响的契约所要求的检查：

  • 原始复现或直接验收检查；
  • 最近的负面或回归检查；
  • 受影响的构建或集成门禁；
  • 当主张跨越真实 UI、API、持久化、并发或运行时路径边界时，检查该路径。

使用以下决定性边界：

表面所需直接证明
逻辑或失败测试原始失败输入或聚焦测试现在通过
UI 行为真实交互加上相关控制台和网络观测
API 或集成请求、响应以及负责服务的行为
持久化通过实际 owner 路径进行的写入/读取或重载往返
竞态或生命周期重复并发触发；零次或一次成功；受影响行和事务证据；最终不变量
跨系统阻塞一个经过脱敏且带时间戳或请求 ID 的失败请求/响应、边缘和应用日志，以及在追踪到达该 owner 时的身份提供方日志

分配状态

  • VERIFIED：观察到基线、具体原因、负责任的更改、所有声明的检查均通过、没有重大缺口。
  • PARTIAL：存在有用证据，但缺少必需的证明层或证明层不确定。
  • BLOCKED：特定的外部条件阻止复现、修复或证明。

对于 PARTIAL 或 BLOCKED，指出能闭合决定性缺口的单个最小实验或关联证据包。绝不要编造命令、观察结果、计数、位置或结果。

要获得机器可读的 receipt 或 CI 集成，请阅读 references/receipt-contract.md 并遵循其 JSON 字段、证据来源标记、兼容性规则和状态不变量。

当请求 JSON 工件时，从 assets/receipt.template.json 开始，将其写入任务拥有的路径，并在该 skill 目录中使用 node scripts/validate-receipt.mjs <receipt.json> 进行验证。除非用户要求，否则不要提交生成的 receipt。

来源与许可证

最初发布于 https://github.com/lMysticl/bug-receipt，采用 MIT License。

评论

支持 Markdown