mcpField
B
bug-receipt

bug-receipt

github.com/githubテスト・品質40.5k43 回インストール今日更新
リポジトリ

bug-receipt について

バグやインシデントのクローズ時に、証拠に基づくレシートをユーザー向けの完全な結果として求めるスキルです。最小限の変更と対象境界での直接検証を重視し、VERIFIED、PARTIAL、BLOCKED の状態を明示します。

主な機能

  1. 01構造化されたクローズレシートの必須化
  2. 02証拠の出所とプライバシー境界の記録
  3. 03症状から具体的な原因への追跡
  4. 04責任範囲内で最小限の変更
  5. 05対象境界での動作検証
  6. 06証拠に基づく状態判定

活用シーン

  1. 01検証証拠を添えたバグ修正のクローズ
  2. 02証拠不足が残るインシデントの報告
  3. 03CI 統合向け機械可読レシートの作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/github/awesome-copilot --skill bug-receipt

インストール後、Claude Code で/bug-receiptを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

assets/
receipt.template.json
references/
receipt-contract.md
receipt.schema.json
scripts/
validate-receipt.mjs

詳細

バグ報告書

必須のクローズアウト出力

バグやインシデントのクローズアウトを判断するたびに、ユーザーが簡潔な回答を求めている場合や、この形式を指定していない場合でも、以下の報告書全体をユーザー向けの回答として返してください。簡潔にする場合は各フィールドの値を短くしますが、行を削除したり名前を変更したりしてはいけません。報告書を文章に置き換えてはいけません。

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

not run、unproven、または none を明示的に使用してください。報告書を完全に見せるために行を省略してはいけません。

証拠の範囲を定める

編集を始める前に、観測した問題、意図された動作、最も確かな直接確認、および証拠の出所（executed now、supplied、または mixed）を記録してください。提供された証拠を今回の実行で確認したかのように示してはいけません。

証拠に含める情報は、プライバシー保護に必要な最小限にしてください。認証情報、トークン、Cookie、個人情報、非公開 URL、機密性の高いペイロードは伏せ、障害の再現や関連付けに必要な識別子と抜粋のみを残してください。

可能な場合は、安全性を保てる最小限の確認方法で障害を再現してください。再現できない場合は、得られた証拠を保持し、結果を PARTIAL または BLOCKED にとどめてください。

追跡と修正

  1. 入力から症状まで、実際に使われる所有者経路をたどります。
  2. 観測された事実、範囲を限定した推論、未解決の点を分けます。
  3. 根本原因を特定する前に、具体的な箇所または実行時の遷移を確認します。
  4. 責任の所在が明確な最小限の変更を行います。無関係な整理、再試行、通知されないフォールバック、フィクスチャ固有の例外は避けます。

妥当そうなパッチ、古いログ、ソースコードの確認、またはビルドの成功を、ユーザーに見える動作の証明として扱ってはいけません。

検証を完了する

影響を受ける契約の検証に必要な確認のみ実行します。

  • 元の再現手順または直接的な受け入れ確認。
  • 最も近い否定テストまたは回帰テスト。
  • 影響を受けるビルドまたは統合ゲート。
  • 主張が境界を越える場合は、実際の UI、API、永続化、並行処理、または実行時の経路。

以下の決定的な境界を使用します。

対象必要な直接証拠
ロジックまたは失敗するテスト元の失敗入力または対象を絞ったテストが現在は成功すること
UI の動作実際の操作、および関連するコンソールとネットワークの観測
API または統合リクエスト、レスポンス、担当サービスの動作
永続化実際の所有者経路を通じた書き込み／読み取りまたは再読み込みの往復
競合またはライフサイクル同時トリガーの反復、成功数が 0 または 1 であること、影響を受けた行とトランザクションの証拠、最終的な不変条件
システム間のブロッカータイムスタンプまたはリクエスト ID を含む、サニタイズ済みの失敗リクエスト／レスポンス 1 件、エッジとアプリケーションのログ、トレースがその所有者に到達する場合は ID プロバイダーのログ

ステータスを割り当てる

  • VERIFIED：ベースラインを観測し、具体的な原因を特定し、責任の所在が明確な変更を行い、宣言したすべての確認に合格しており、重大な未解決点がない。
  • PARTIAL：有用な証拠はあるものの、必要な検証レイヤーが欠けているか、結論が出ていない。
  • BLOCKED：特定の外部条件により、再現、修正、または検証ができない。

PARTIAL または BLOCKED の場合は、決定的な未解決点を解消するための最小限の実験を 1 つ、または相関する証拠一式を 1 つ示してください。コマンド、観測結果、件数、場所、結果を捏造してはいけません。

機械可読な報告書または 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 License の下で提供されています。

コメント

Markdown 対応