用途：bug-receipt 用于缺陷或事故的收尾决策，强制以完整回执作为面向用户的最终结果，不能以散文替代。回执格式为 BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED，包含 Problem、Baseline、Root cause、Change、Proof、Gaps、Source 七行；简洁只缩短字段值，不删除或改名。未运行、未证实或无变更须显式写 not run、unproven、none。
主要能力：先建立证据边界，记录观察问题、预期行为、最强直接检查及证据来源（executed now、supplied、mixed），不得暗示 supplied 证据在当前运行中执行过。证据保持隐私最小化，脱敏凭据、令牌、Cookie、个人数据、私有 URL 和敏感载荷。尽可能用最窄安全检查复现失败；无法复现则保留已有证据并将结果上限设为 PARTIAL 或 BLOCKED。沿实际所有者路径从输入追踪到症状，区分观察事实、有界推断与缺口，命名根因前需有具体位置或运行时转换。做最小责任变更，避免无关清理、重试、静默回退和针对夹具的例外。不得把看似合理的补丁、过期日志、源码阅读或通过构建当作用户可见行为的证明。
证明闭环：仅运行受影响契约所需的检查，包括原始复现或直接验收检查、最近负向或回归检查、受影响构建或集成门禁，以及当声明跨越边界时的真实 UI、API、持久化、并发或运行时路径。状态判定：VERIFIED 需观察到基线、具体原因、责任变更、所有声明检查通过且无重大缺口；PARTIAL 为有用证据存在但缺少或不确定必需证明层；BLOCKED 为特定外部条件阻止复现、修复或证明。PARTIAL 或 BLOCKED 须指出关闭决定性缺口的单一最小实验或关联证据包，不得编造命令、观察、计数、位置或结果。
使用方式：机器可读回执或 CI 集成需阅读 references/receipt-contract.md 并遵循其 JSON 字段、证据来源标记、兼容规则和状态不变量。请求 JSON 产物时，从 assets/receipt.template.json 开始，写入任务自有路径，并在该技能目录用 node scripts/validate-receipt.mjs <receipt.json> 验证；除非用户要求，否则不要提交生成的回执。
适用场景：缺陷关闭、事故收尾、需要可审计证据链的修复验证。限制：资料未提供具体安装命令、平台支持、收费或价格信息；原始发布于 https://github.com/lMysticl/bug-receipt，采用 MIT 许可证。