bug-receipt — GitHub Copilot skill: what it does, how to install
Closes defects and incidents using a mandatory BUG RECEIPT with VERIFIED, PARTIAL, or BLOCKED status. It stops the agent from guessing repairs.
npx skills add github/awesome-copilot --skill bug-receiptWhat bug-receipt does
The skill forces the agent to end any bug or incident resolution with a structured BUG RECEIPT. This block records the observed defect, baseline run, verified root cause, applied change, proof, gaps, and evidence source. The agent cannot substitute prose for this receipt. Rows cannot be omitted; missing checks must explicitly state not run, unproven, or none.
During diagnosis, the assistant traces the live owner path from input to failure. It forbids silent fallbacks and unrelated cleanups, demanding the smallest responsible fix. Direct proof is required at the affected layer, such as a focused test, an API roundtrip, or a database transaction. For CI pipelines, receipts can be exported to JSON using assets/receipt.template.json and checked with node scripts/validate-receipt.mjs .
Install this skill when your AI agent prematurely claims a bug is fixed without running decisive checks.
What it helps with
- Close defect tickets with a mandatory structured receipt
- Distinguish verified root causes from unproven hypotheses
- Record conclusive resolution status as VERIFIED, PARTIAL, or BLOCKED
- Validate generated receipt.json artifacts against contract rules
Example prompts for the agent
- Investigate the payment timeout, patch it, and return a BUG RECEIPT.
- Diagnose this failing test and produce a receipt with decisive proof.
- Generate a task-owned receipt.json for this incident closeout.
How to install bug-receipt
1Skills CLI (Vercel)
npx skills add github/awesome-copilot --skill bug-receipt2GitHub CLI
gh skill install github/awesome-copilot bug-receipt3Manually: put the files in place
.github/skills/bug-receipt/SKILL.md1Skills CLI (Vercel)
npx skills add github/awesome-copilot --skill bug-receipt -a claude-code2Manually: put the files in place
~/.claude/skills/bug-receipt/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/bug-receipt/
Manually: put the files in place
.agents/skills/bug-receipt/SKILL.mdFor all projects use ~/.agents/skills/
Manually: put the files in place
.cursor/skills/bug-receipt/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
Platform CLI
gemini skills install https://github.com/github/awesome-copilot --path skills/bug-receiptManually: put the files in place
.devin/skills/bug-receipt/SKILL.mdThe legacy .windsurf/skills/ path still works
Claude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set554
The whole set →Similar
Questions about bug-receipt
How to install bug-receipt for GitHub Copilot?
Run npx skills add github/awesome-copilot --skill bug-receipt or gh skill install github/awesome-copilot bug-receipt. Alternatively, place the file in .github/skills/bug-receipt/SKILL.md.
What does bug-receipt do?
It enforces an unyielding closeout format for bug fixes instead of informal conversational replies. Every diagnosis must document reproduction, concrete code changes, and test results.
What do the VERIFIED, PARTIAL, and BLOCKED statuses mean?
VERIFIED requires a proven cause, a minimal change, and passing checks with no gaps. PARTIAL applies when evidence is incomplete, while BLOCKED marks an external blocker that stops diagnosis or verification.
Source text
SKILL.md · MIT
--- name: bug-receipt description: 'Close defects and incidents with a BUG RECEIPT and VERIFIED, PARTIAL, or BLOCKED status after diagnosis, repair, or recovery.' metadata: version: "1.4.1" --- # Bug Receipt ## Mandatory closeout output For every bug or incident closeout decision, return the complete receipt below as the entire user-facing result, even when the user requests a concise reply or does not name this format. Concision shortens field values; it never removes or renames a row. Do not replace the receipt with prose. ```text 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 ``` Use `not run`, `unproven`, or `none` explicitly. Never omit a row to make the receipt look complete. ## Establish the evidence boundary Before editing, record the observed problem, intended behavior, strongest direct check, and evidence source: `executed now`, `supplied`, or `mixed`. Never imply that supplied evidence was executed in the current run. Keep evidence privacy-minimal. Redact credentials, tokens, cookies, personal data, private URLs, and sensitive payloads; preserve only the identifiers and excerpts needed to reproduce or correlate the failure. Reproduce the failure with the narrowest safe check when possible. If reproduction is unavailable, preserve the evidence obtained and cap the result at `PARTIAL` or `BLOCKED`. ## Trace and repair 1. Follow the live owner path from input to symptom. 2. Separate observed facts, bounded inferences, and gaps. 3. Require a concrete location or runtime transition before naming root cause. 4. Make the smallest responsible change; avoid unrelated cleanup, retries, silent fallbacks, and fixture-specific exceptions. Do not convert a plausible patch, stale log, source read, or passing build into proof of the user-visible behavior. ## Close the proof loop Run only checks required by the affected contract: - original reproduction or direct acceptance check; - nearest negative or regression check; - affected build or integration gate; - real UI, API, persistence, concurrency, or runtime path when the claim crosses that boundary. Use these decisive boundaries: | Surface | Required direct proof | | --- | --- | | Logic or failing test | Original failing input or focused test now passes | | UI behavior | Real interaction plus relevant console and network observation | | API or integration | Request, response, and responsible service behavior | | Persistence | Write/read or reload round trip through the real owner path | | Race or lifecycle | Repeated concurrent trigger; zero-or-one success; affected-row and transaction evidence; final invariant | | Cross-system blocker | One sanitized failing request/response with timestamp or request ID, edge and application logs, and identity-provider logs when the trace reaches that owner | ## Assign status - `VERIFIED`: observed baseline, concrete cause, responsible change, all declared checks passed, no material gap. - `PARTIAL`: useful evidence exists, but a required proof layer is missing or inconclusive. - `BLOCKED`: a specific external condition prevents reproduction, repair, or proof. For `PARTIAL` or `BLOCKED`, name the single minimal experiment or correlated evidence package that closes the decisive gap. Never invent a command, observation, count, location, or result. For a machine-readable receipt or CI integration, read [references/receipt-contract.md](references/receipt-contract.md) and conform to its JSON fields, evidence-source marker, compatibility rule, and status invariants. When a JSON artifact is requested, start from [assets/receipt.template.json](assets/receipt.template.json), write it to a task-owned path, and validate it with `node scripts/validate-receipt.mjs <receipt.json>` from this skill directory. Do not commit the generated receipt unless the user requests it. ## Source and license Originally published at https://github.com/lMysticl/bug-receipt under the MIT License.
© github · MIT · github/awesome-copilot