Skip to main content
skill GitHub Copilot official · GitHub

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.

Install into GitHub Copilot · Skills CLI (Vercel) All methods and platforms ↓
npx skills add github/awesome-copilot --skill bug-receipt
Open on GitHub

What 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-receipt

2GitHub CLI

gh skill install github/awesome-copilot bug-receipt

3Manually: put the files in place

.github/skills/bug-receipt/SKILL.md

From the same set554

The whole set →
git-commit official github This skill reviews Git changes, stages related files, and creates Conventional Commits. Use it when you want an agent to make one commit or split work into separate commits. GitHub Copilot 47,165installs excalidraw-diagram-generator official github Turn a plain-language description into an Excalidraw diagram. Useful for mapping processes, system structure, and relationships between entities. GitHub Copilot 31,639installs multi-stage-dockerfile official github This skill guides GitHub Copilot in writing multi-stage Dockerfiles for different languages and frameworks. Use it when the final runtime image should contain fewer build dependencies. GitHub Copilot 29,688installs documentation-writer official github Skill that turns the agent into a technical writer following the Diátaxis framework: tutorials, how-to guides, reference, and explanation. Proposes structure before writing. GitHub Copilot 27,757installs prd official github Turns a feature idea into a structured PRD with user stories, technical requirements, and risks. Use it when planning a software feature or an AI-powered one. GitHub Copilot 24,035installs refactor official github This skill reshapes existing code without changing its external behavior. Use it for gradual cleanup of large functions, duplication, weak types, and code smells. GitHub Copilot 22,321installs java-springboot official github Gives GitHub Copilot Spring Boot development practices, from project layout to tests and security. Use it when writing or reviewing Java application code. GitHub Copilot 21,272installs create-readme official github This skill reviews a project and creates a structured README.md. Use it when the repository needs clear documentation based on its actual files and code. GitHub Copilot 19,081installs

Similar

frontend-testing-debugging official OpenAI Guides coding agents through structured frontend testing, UI checks, and bug investigations. Runs validation loops using Browser tools or local Playwright. CX Codex GP ChatGPT 159installs clinical-research claude-code-skills Plan a prospective clinical study by selecting endpoints, estimating sample size, and checking feasibility before a phase-gate review. Claude Code 156installs improve-codebase-architecture Matt Pocock This skill scans a codebase for architectural friction, then builds a visual HTML report with refactoring candidates. Use it before a deeper architecture review. Claude Code 1,163,035installs design-taste-frontend Leonxlnx This skill directs the design of public pages and work screens, then checks the result in a browser through screenshots. Use it when an interface feels generic or unfinished. Claude Code CX Codex Cursor +1 673,100installs tdd Matt Pocock Guides the red-green TDD loop: ensures tests are written first, keep them at public interfaces, and avoid coupling to implementation details. Claude Code 1,141,062installs skill-creator official anthropics Creates and refines skills, then tests them with prompts, evaluations, and performance checks. Claude Code Claude.ai 414,180installs agent-browser vercel-labs A CLI skill for browser control: it opens pages, fills forms, clicks buttons, and tests web apps. Use it when an agent needs to act inside a website. Claude Code CX Codex Cursor +1 1,200,000installs prototype Matt Pocock Creates throwaway prototypes for checking state logic or exploring UI before committing the decision to the main codebase. Claude Code 986,201installs

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

See also

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor