SkillAgentSearch skills...

bug-receipt

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

Install / Use

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

Installs into whichever agent you are using.

About this skill
📄

SKILL.md

Installable skill definition

Quality Score

91/100

Category

Marketing

Supported Platforms

Universal

Tags

Our assessment of bug-receipt

bug-receipt scores 91/100 on our quality scale, 77th of 301 Marketing skills we index (top 26%).

Its SKILL.md is 4.3 KB long, split into 7 sections with 1 code example: a solid amount of guidance for an agent.

With 39,348 GitHub stars, it is one of the more widely adopted skills in the catalogue.

Substance
26/30
Structure
15/20
Description
15/15
Adoption
20/20
Freshness
15/15

Maintenance, license and trust

  • The repository was last updated 3 days ago, so bug-receipt is actively maintained.
  • It is released under the MIT license, a permissive license that allows use, modification and commercial use with attribution.
  • Its trust signals score 100/100, with no cautions. These come from repository metadata, not a code audit — read the skill file before letting an agent act on it.

bug-receipt compared with similar skills

All 4 of these similar skills score higher than bug-receipt; compare them before choosing.

SkillScoreStarsUpdatedFormat
bug-receipt (this skill)by github9139.3k3d agoSKILL.md
algorithmic-artby anthropics100177.9k5d agoSKILL.md
pptxby anthropics100177.9k5d agoSKILL.md
designby nextlevelbuilder100130.2k6d agoSKILL.md
ui-ux-pro-maxby nextlevelbuilder100130.2k6d agoSKILL.md

Frequently asked questions

How do I install bug-receipt?
Run npx skills add github/awesome-copilot --skill bug-receipt. The install tabs above show the steps for each supported agent.
Which AI agents does bug-receipt work with?
It is written for Universal, as a SKILL.md file. Other agents that read the same format can often use it too.
Is bug-receipt safe to use?
It is MIT-licensed and scores 100/100 on trust signals. Skills are instructions an agent will follow, so read the file before installing it and do not approve commands you do not understand.
Is bug-receipt still maintained?
The repository was last updated 3 days ago, so bug-receipt is actively maintained.

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.

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 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, 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.

Related Skills

View on GitHub
GitHub Stars39.3k
CategoryMarketing
Updated3d ago
Forks5.0k

Languages

JavaScript

Trust signals

100/100

From repository metadata: license, adoption, age and documentation. Not a code audit — see the Safety scan above for what the skill file itself contains.

No cautions