Skills

Skill 68 of 200

Bug Receipt

Close defects and incidents with a BUG RECEIPT and VERIFIED, PARTIAL, or BLOCKED status after diagnosis, repair, or recovery.

2 minutes · 490 words · 6 sections

Install

$ npx skills add github/awesome-copilot --skill bug-receipt

$ npx skills add github/awesome-copilot

» /plugin marketplace add github/awesome-copilot

The first command installs just this skill, by the name in its SKILL.md; the second installs the whole repository.

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.

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

Follow the live owner path from input to symptom.
Separate observed facts, bounded inferences, and gaps.
Require a concrete location or runtime transition before naming root cause.
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 (opens in a new tab) 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 (opens in a new tab), 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 (opens in a new tab) under the MIT License.

Colophon for this issue

Colophon

How this issue was made

Source

github.com/github/awesome-copilot, branch main, last pushed 24 September 2026.

Licence

MIT — the text of every skill is reproduced unmodified, frontmatter included, under the upstream licence.

Discovery

200 skills found by walking the repository tree for SKILL.md, not by matching a directory convention. 2 distinct layouts observed: .github/skills/*/SKILL.md, skills/*/SKILL.md.

Authorship

3 of 200 skills are installed into the repository rather than published from it. They are shelved in the closing “Credited skills” part and remain the work of their own authors. A skill counts as credited when its only copy lives under one agent’s dot directory; visible directories, per-agent mirror sets, and skills installable from this repository on skills.sh all count as published.

Issue colours

Resolved from a curated brand profile — hue 295°, chroma 0.190. Two accent tones are generated per issue and each is proven against its own ground before it ships: a single accent that passes AA on both light and dark paper is arithmetically impossible.

Heading repairs

1 repair applied to this skill so the document has one h1 and no skipped levels:

Removed “Bug Receipt”, a leading h1 that duplicated the skill title.

Spec compliance

Every skill satisfies the Agent Skills specification’s frontmatter rules.

Images

Images inside a skill come from the upstream repository. Where the author gave no alternative text we mark the image decorative rather than inventing a description — a plausible caption we made up is worse than none for the reader who depends on it.

Marketplace

A plugin manifest is published at .github/plugin/marketplace.json by GitHub, declaring 162 plugins. It is read for editorial metadata only — never as the skill index, which is always the repository tree.

Signal

Install counts come from skills.sh. They measure downloads, not quality, and an unranked repository is not an unread one.

Agent surfaces

The whole issue is available as one markdown document at /github/awesome-copilot.md, and each skill at its own .md URL.

Publication

Set by Skills Docs from the source repository. Body text is Literata at the reader’s chosen size and measure; code is Geist Mono. Nothing on this page was written by us except this paragraph.

Mandatory closeout output

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

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

Follow the live owner path from input to symptom.
Separate observed facts, bounded inferences, and gaps.
Require a concrete location or runtime transition before naming root cause.
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.

Source and license

Originally published at https://github.com/lMysticl/bug-receipt (opens in a new tab) under the MIT License.

Bug Receipt

Mandatory closeout output

Establish the evidence boundary

Trace and repair

Close the proof loop

Assign status

Source and license

Colophon

Bug Receipt

Mandatory closeout output

Establish the evidence boundary

Trace and repair

Close the proof loop

Assign status

Source and license

Appendix 68.1–68.4

References2 files

ScriptsJavaScript · 1 file

AssetsJSON · 1 file

Colophon

Appendix 68.1–68.4

References2 files

ScriptsJavaScript · 1 file

AssetsJSON · 1 file