backprop について
backpropは、バグや検証失敗をコード修正と仕様変更につなげるスキルです。原因を追跡し、必要に応じて不変条件とテストを追加して修正を検証し、関連変更をまとめてコミットします。
主な機能
- 01失敗の根本原因を追跡
- 02仕様に§Bの記録を追加
- 03必要に応じて動作不変条件を追加
- 04新しい不変条件のテストを作成
- 05修正と全テストスイートを検証
- 06仕様、テスト、コードをまとめてコミット
活用シーン
- 01ユーザー報告のバグ修正
- 02ビルド検証失敗への対応
- 03本番インシデントの教訓を記録
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/backpropを入力して読み込まれたか確認します。
詳細
backprop — バグ → 仕様
計画してから実行する方法ではコードを修正できますが、その経緯は忘れられます。 SDDではコードを修正し、仕様も編集することで、再発を不可能にします。 その編集が backprop です。
backprop を行うタイミング
/buildの検証でテストが失敗したとき。- ユーザーからバグの報告があったとき。
- 本番環境のインシデント後に事後分析を行うとき。
/checkで VIOLATE が検出され、根本原因が判明したとき。
6つのステップ
1. TRACE
失敗の出力またはバグ報告を読みます。 誤った動作が起きている正確なファイルと行番号を見つけます。 根本原因を、簡潔な一文で示します。
2. ANALYZE
次の3つの質問をします。
- 新しい §V 不変条件があれば、この種類のバグを検出できますか？（最も多いケースでは、できます）
- §I に誤りがありますか？仕様で、コードでは実現できない形を要求していましたか？（ときどきあります）
- §T に誤りがありますか？作るものを間違えましたか？（まれですが、実際にあります）
3. PROPOSE
仕様の変更案を作成します。§B は必ず追加します。§V／§I／§T はケースバイケースです。
テンプレート：
§B row: B<next>|<date>|<root cause>|V<N>
§V line: V<next>: <testable rule that would have caught it>
例：
§B row: B3|2026-04-20|refund job ran twice on retry|V7
§V line: V7: ∀ refund → idempotency key check before charge reversal
4. GENERATE TEST
テストのない新しい不変条件は嘘です。まず失敗するテストを追加します。
不変条件を明記する名前をテストに付けます。例：TestV7_RefundIdempotent。
5. VERIFY
コードを修正します。テストを実行し、必ず合格させます。全テストスイートを実行し、リグレッションがないことを確認します。
6. LOG
仕様の編集、テスト、コードの修正をまとめてコミットします。
コミットメッセージ：backprop §B.<n> + §V.<N>: <one-line cause>。
良い不変条件の条件
- コードでテストできる（grep または assert で検証できる）。
- ファイルではなく、動作を対象にしている。
- 可能な場合は肯定形で記述する（
⊥ forbidより! hold）。 - 適用される §I の対象領域を参照している。
悪い例：V8: コードは正しくあるべきです。 良い例：V8: ∀ pg_query ! params interpolated via driver, ⊥ string concat.
§V を追加しないケース
- バグが純粋に機械的なタイプミスで、同種の事例がない場合（使い捨てコードでの
i++とi--の取り違えなど）。 - 修正が一度限りの移行である場合。
- 根本原因が外部依存関係にある場合（代わりに依存関係をアップグレードし、§C に記録します）。
それでも §B の項目は追加します。この失敗モードを検討したことを記録してください。今後、同じ兆候のバグが発生した場合、§B を検索すれば前例を確認できます。
出力形式
backprop の実行ごとに、次のものを作成します。
- §B の項目（必須）。
- §V の項目（通常）。
- テストファイル（§V を追加した場合）。
- コードの修正。
- 1つのコミット。
ダッシュボードはありません。ログファイルもありません。SPEC.md と git が全履歴です。