build-fix について
.NET プロジェクトのビルドやテストを反復的に修復するスキルです。失敗を根本原因ごとに分類して修正し、進捗確認と停止条件で無効な再試行を防ぎます。
主な機能
- 01ビルドやテストの反復実行
- 02根本原因ごとのエラー分類
- 03影響の大きい原因から修正
- 04停滞や悪化時の停止
- 05各反復で変更理由を説明
活用シーン
- 01複数のコンパイルエラーの解消
- 02コード変更後のテスト失敗への対処
- 03リファクタリングや NuGet 更新後の問題調査
- 04マージやコード生成後のビルド復旧
MCP 対応
コンパイラ診断の確認、シンボルや参照の特定、プロジェクト依存関係の調査に MCP ツールを使用し、.NET のビルドやテストの修復を支援します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ codewithmukesh/ dotnet-claude-kit --skill build-fixインストール後、Claude Code で/build-fixを入力して読み込まれたか確認します。
詳細
/build-fix
概要
このキットの自律的な反復ループスキルです。失敗した dotnet build
(または失敗した dotnet test)に対して、実行、失敗の解析、
根本原因ごとの分類、対象を絞った修正、再実行を繰り返し、ビルドやテストを
成功させます。ガードが作動するか、成功するまで繰り返します。経験豊富な開発者が
大量のエラーを一つずつ解消していくのと同じ方法ですが、無駄な試行を防ぐ
厳格な上限を設けています。
これは一度だけ修正するものではありません。一つの問題を直すと次の問題が 明らかになるような、連鎖するエラーにも対応します。
使用する状況
- ビルドが壊れており、コンパイラーエラーが複数ある場合
- コード変更後、またはビルド修正の作業後にテストが失敗する場合
- 型名、名前空間、シグネチャに手を加える大規模なリファクタリングの後
- NuGet パッケージの更新後(特にメジャーバージョンの更新)
- コンフリクトを解決したものの、コンパイルしていないブランチをマージした後
- 手動での調整が必要なスキャフォールディングやコード生成の後
- ユーザーが「ビルドを直して」「コンパイルできるようにして」「テストを通して」 「動くまで続けて」「修正を続けて」と言った場合
仕組み
ループのルール(すべてのループに適用)
- 必ず反復回数を制限する — デフォルトの最大回数は 5 回、上限は 10 回です (ユーザーの「続けて」により 3 回延長できますが、10 回を超えることはありません)。5 回の反復で 解決できない場合は、同じ試行を 6 回目も行うのではなく、人間による判断が必要です。
- 進展がなければ終了する — 各反復でエラーまたは失敗の数を減らす必要があります。 修正を試しても同じエラーが残る場合は、行き詰まりです。停止して報告し、 別のアプローチを再検討します。失敗した修正を同じ方法で再試行してはいけません。
- 修正前に分類する — エラーを根本原因ごとにまとめ、効果の大きいものから修正します
(不足している
usingを一つ追加するだけで、後続のエラーが十数個解消することがあります)。 - 反復ごとに状況を明示する — 何を変更し、なぜ変更したかを報告します。
Iteration 3/5: fixed CS0246 by adding using System.Text.Json, 2 remain。 ファイルを黙って変更してはいけません。 - アトミック性 — 各反復の終了時に、コードベースの状態を開始時より悪化させてはいけません。 反復 3 が失敗した場合、コードは反復 2 の状態を維持します。
メインの手順:ビルド修正ループ(最大 5 回)
-
ビルド —
dotnet buildを実行し、エラー出力全体を取得します -
解析 — ファイル、行、メッセージを含む、すべての
error CS####を抽出します -
分類 — 根本原因ごとにまとめます。
カテゴリ コード 修正方針 using/参照の不足 CS0246, CS0234 using、パッケージ、またはプロジェクト参照を追加 型の不一致 CS0029, CS1503 想定される型を確認し、キャストまたは変換 API の変更 CS0117, CS7036 新しいシグネチャを確認し、呼び出し箇所を更新 Null 許容性 CS8600–CS8604 null チェック、 ?.、または??を追加曖昧さ/重複 CS0104, CS0121, CS0111 名前空間を明示するか、重複を削除 メンバーの不足 CS1061 スペルを確認し、メンバーの存在を検証 実装の不足 CS0535 インターフェイス/抽象メンバーを実装 非推奨 API CS0618 推奨される代替手段に置き換え -
修正 — 対象を絞った修正を適用し、根本原因に関わるものや効果の大きいエラーから対応します
-
再ビルド —
dotnet buildを再実行し、エラー数を比較します -
評価 — エラーがゼロの場合は、健全性チェックとして
dotnet testを実行し、 成功を報告します。エラーが減った場合は続行します。同じエラーが残る場合は行き詰まりとして終了し、再検討します。 エラーが増えた場合は、その反復を元に戻し、回帰として報告します。
変化形:テスト修正ループ(最大 5 回。ビルド修正ループに続く場合は 3 回)
同じループとガードを適用し、実行コマンドを dotnet test --no-build にします。
重要な追加手順として、修正前に診断します。
- テストを読む — アサーションとセットアップを理解します
- プロダクションコードを読む — 実際の動作を理解します
- バグの場所を判断します。期待値の誤り → テストを修正。プロダクションコードの バグ → コードを修正。不完全なセットアップ → セットアップを修正。契約の変更 → テストを新しい仕様に合わせて更新します
- テストを通すためにアサーションを決して弱めてはいけません。
悪い例:
Assert.Equal(expected, actual)→Assert.NotNull(actual)。 良い例:元のアサーションを満たすようにプロダクションコードを修正します。
フェイルセーフガード(即時終了)
- 停滞 — 修正後も同じエラー/失敗が発生する、または件数が増減を繰り返す (3 → 2 → 3):修正できなかった内容と、人間が確認すべき点を報告します
- リグレッション — あるイテレーションで、修正したエラーよりも多くのエラーが発生した場合:変更を元に戻し、報告します
- 連鎖的な失敗 — 1つのエラーを修正した結果、2回連続で3つ以上の新たなエラーが発生した場合:アプローチが誤っているため、停止します
- 重大なエラー — SDK の誤り、プロジェクトファイルの欠落、ソリューションの破損、またはテストランナー自体の失敗:人間の介入が必要なため、停止します
- ユーザーによる中断 — 現在のイテレーションを完了して進捗を報告し、次の進め方を確認します
その他のループ
同じ規律、つまり反復回数の上限、進捗の検知、フェイルセーフガードは、リファクターパス(/de-sloppify:対象ごとにビルドとテストを検証し、失敗したら元に戻します)とスキャフォールディング(/scaffold:生成後、ビルド修正ループとテスト修正ループをネストして実行します)にも適用されます。ネストされたループでは予算を少なく設定し(親は5回、ネスト側は3回)、ネストの最大深度は2、合計予算は15です。
呼び出し
| 種類 | 名前 | 目的 |
|---|---|---|
| スキル | instinct-system | 修正パターンを MEMORY.md に記録します |
| エージェント | dotnet-architect | アーキテクチャに関するエラーパターンについて相談します |
使用する MCP ツール
get_diagnostics— ファイルまたはプロジェクト単位のコンパイラーエラー/警告を取得しますfind_symbol— 移動または名前変更された型を特定しますfind_references— 破損した API 変更の影響範囲を評価しますget_project_graph— 参照エラーの修正に必要な依存関係の順序を取得します
例
User: /build-fix
Claude: Running dotnet build...
Found 12 errors across 4 files.
Iteration 1/5:
- 6 errors: Missing namespace (CS0246) — adding using directives
- 3 errors: Type mismatch (CS1503) — updating method signatures
- 3 errors: Interface not implemented (CS0738) — package API changed
Rebuilding... 3 errors remaining.
Iteration 2/5:
- 3 errors: CS0738 after xunit.v3 upgrade
- IAsyncLifetime.InitializeAsync now returns ValueTask (was Task in v2),
and DisposeAsync comes from IAsyncDisposable
- Updating 3 test fixtures to the ValueTask signatures
Rebuilding... 0 errors. Build is green.
Running dotnet test... All 47 tests passed.
Added to Memory > Packages: "xunit.v3 IAsyncLifetime uses ValueTask signatures"
関連項目
/verify— 完全な検証パス(ビルド+テスト+フォーマット+診断)/tdd— 新機能をテストファーストで構築する際のレッド・グリーン・リファクタリング/de-sloppify— ビルドが成功した後に、コード品質の問題を整理します