Communitygithub.com

Bug Receipt(バグレシート)

エビデンスに基づくバグ修正、根本原因分析、AIコーディングエージェントの結果検証を実現するポータブルエージェントスキルです。

Bug Receipt(バグレシート) とは?

Bug Receiptは、AIコーディングエージェント(Claude Code, Cursor, Codex等)向けに設計された、エビデンス駆動型のバグ修正・インシデント対応スキルです。このスキルは、すべてのバグやインシデントのクローズアウト時に「BUG RECEIPT」と呼ばれる構造化されたレシート(領収書)を出力することを強制します。レシートには問題、ベースライン、根本原因、変更内容、証明、ギャップの各項目が必須で、省略は一切許されません。スキルは、観察された事実と推論を明確に分離し、具体的な証拠に基づいてのみ根本原因を特定するよう設計されています。また、UI、API、永続化、競合状態など様々な検証面に対して必要な直接証拠の種類を定義し、状況に応じてVERIFIED/PARTIAL/BLOCKEDのステータスを割り当てます。これにより、AIエージェントによる修正結果の透明性と検証可能性を大幅に向上させます。

対応~Claude Code~Codex CLI~Cursor
npx skills add lMysticl/bug-receipt

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Bug Receipt(バグレシート) は何をしますか?

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

すべてのバグまたはインシデントのクローズアウト判断において、ユーザーが簡潔な返答を要求したり、このフォーマットを明示しなかった場合でも、以下に示す完全なレシートをユーザー向けの結果全体として返却してください。簡潔さはフィールドの値を短くするものであり、行を削除したり名前を変更するものではありません。レシートを散文で置き換えないでください。

BUG RECEIPT · VERIFIED | PARTIAL | BLOCKED

Problem    <観測された欠陥と期待される動作>
Baseline   <失敗する操作またはコマンドと決定的な結果;または not run>
Root cause <証明されたメカニズム;または unproven な仮説>
Change     <責任のある変更;または none>
Proof      <提供または実行されたチェック:結果;決定的なレイヤーをすべて含める>
Gaps       <none;または不足している正確な証明と、そのギャップを埋めるための単一の次の実験・パッケージ>
Source     executed now | supplied | mixed

not run、unproven、none を明示的に使用してください。レシートを完全に見せかけるために行を省略しないでください。

エビデンスの境界を確立する

編集を行う前に、観測された問題、期待される動作、最も直接的なチェック、およびエビデンスのソース(executed now、supplied、mixed)を記録してください。提供されたエビデンスが現在の実行で実行されたことを決して示唆しないでください。

エビデンスはプライバシーを最小限に保ちます。資格情報、トークン、クッキー、個人データ、プライベートURL、機密ペイロードは編集し、障害の再現や関連付けに必要な識別子と抜粋のみを保持します。

可能であれば、最も狭い安全なチェックで障害を再現してください。再現が不可能な場合は、得られたエビデンスを保持し、結果を PARTIAL または BLOCKED に制限してください。

トレースと修復

  1. 入力から症状までのライブなオーナーパスを追跡します。
  2. 観測された事実、範囲を限定した推論、ギャップを分離します。
  3. 根本原因を特定する前に、具体的な場所またはランタイムの遷移を要求します。
  4. 最小限の責任のある変更を行います。無関係なクリーンアップ、再試行、サイレントフォールバック、フィクスチャ固有の例外を避けてください。

もっともらしいパッチ、古いログ、ソースコードの読み取り、ビルドの成功を、ユーザーから見える動作の証明に変換しないでください。

証明ループを閉じる

影響を受ける契約によって要求されるチェックのみを実行します。

  • 元の再現または直接的な受け入れチェック
  • 最も近い否定または回帰チェック
  • 影響を受けるビルドまたは統合ゲート
  • 主張がその境界を越える場合の、実際のUI、API、永続化、並行性、またはランタイムパス

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

検証面必要な直接証拠
ロジックまたは失敗テスト元の失敗入力またはフォーカステストが合格すること
UI動作実際の操作と、関連するコンソールおよびネットワークの観測結果
APIまたは統合リクエスト、レスポンス、および責任のあるサービス動作
永続化実際のオーナーパスを通じた書き込み/読み取りまたはリロードのラウンドトリップ
競合状態またはライフサイクル繰り返しの同時トリガー;0または1の成功;影響を受けた行とトランザクションの証拠;最終不変条件
システム間ブロッカータイムスタンプまたはリクエストID付きのサニタイズされた1件の失敗リクエスト/レスポンス、エッジおよびアプリケーションログ、トレースがその所有者に到達する場合のIDプロバイダーログ

ステータスの割り当て

  • VERIFIED: 観測されたベースライン、具体的な原因、責任のある変更、宣言されたすべてのチェックが合格、重要なギャップなし。
  • PARTIAL: 有用なエビデンスが存在するが、必須の証明レイヤーが欠落しているか決定的でない。
  • BLOCKED: 特定の外部条件により、再現、修復、または証明が妨げられている。

PARTIAL または BLOCKED の場合、決定的なギャップを埋める単一の最小限の実験または相関エビデンスパッケージを指定してください。コマンド、観測結果、カウント、場所、結果を invent(創作)しないでください。

機械可読なレシートまたはCI統合については、references/receipt-contract.md を参照し、そのJSONフィールド、エビデンスソースマーカー、互換性ルール、ステータス不変条件に準拠してください。

JSONアーティファクトが要求された場合は、assets/receipt.template.json から開始し、タスク所有のパスに書き込み、このスキルディレクトリから node scripts/validate-receipt.mjs <receipt.json> で検証してください。ユーザーが要求しない限り、生成されたレシートをコミットしないでください。

関連スキル