mcpField
B
build-fix

build-fix

github.com/codewithmukesh開発7912.9k 回インストール12 週間前に更新
リポジトリ

build-fix について

.NET プロジェクトのビルドやテストを反復的に修復するスキルです。失敗を根本原因ごとに分類して修正し、進捗確認と停止条件で無効な再試行を防ぎます。

主な機能

  1. 01ビルドやテストの反復実行
  2. 02根本原因ごとのエラー分類
  3. 03影響の大きい原因から修正
  4. 04停滞や悪化時の停止
  5. 05各反復で変更理由を説明

活用シーン

  1. 01複数のコンパイルエラーの解消
  2. 02コード変更後のテスト失敗への対処
  3. 03リファクタリングや NuGet 更新後の問題調査
  4. 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 パッケージの更新後(特にメジャーバージョンの更新)
  • コンフリクトを解決したものの、コンパイルしていないブランチをマージした後
  • 手動での調整が必要なスキャフォールディングやコード生成の後
  • ユーザーが「ビルドを直して」「コンパイルできるようにして」「テストを通して」 「動くまで続けて」「修正を続けて」と言った場合

仕組み

ループのルール(すべてのループに適用)
  1. 必ず反復回数を制限する — デフォルトの最大回数は 5 回、上限は 10 回です (ユーザーの「続けて」により 3 回延長できますが、10 回を超えることはありません)。5 回の反復で 解決できない場合は、同じ試行を 6 回目も行うのではなく、人間による判断が必要です。
  2. 進展がなければ終了する — 各反復でエラーまたは失敗の数を減らす必要があります。 修正を試しても同じエラーが残る場合は、行き詰まりです。停止して報告し、 別のアプローチを再検討します。失敗した修正を同じ方法で再試行してはいけません。
  3. 修正前に分類する — エラーを根本原因ごとにまとめ、効果の大きいものから修正します (不足している using を一つ追加するだけで、後続のエラーが十数個解消することがあります)。
  4. 反復ごとに状況を明示する — 何を変更し、なぜ変更したかを報告します。 Iteration 3/5: fixed CS0246 by adding using System.Text.Json, 2 remain。 ファイルを黙って変更してはいけません。
  5. アトミック性 — 各反復の終了時に、コードベースの状態を開始時より悪化させてはいけません。 反復 3 が失敗した場合、コードは反復 2 の状態を維持します。
メインの手順:ビルド修正ループ(最大 5 回)
  1. ビルド — dotnet build を実行し、エラー出力全体を取得します

  2. 解析 — ファイル、行、メッセージを含む、すべての error CS#### を抽出します

  3. 分類 — 根本原因ごとにまとめます。

    カテゴリコード修正方針
    using/参照の不足CS0246, CS0234using、パッケージ、またはプロジェクト参照を追加
    型の不一致CS0029, CS1503想定される型を確認し、キャストまたは変換
    API の変更CS0117, CS7036新しいシグネチャを確認し、呼び出し箇所を更新
    Null 許容性CS8600–CS8604null チェック、?.、または ?? を追加
    曖昧さ/重複CS0104, CS0121, CS0111名前空間を明示するか、重複を削除
    メンバーの不足CS1061スペルを確認し、メンバーの存在を検証
    実装の不足CS0535インターフェイス/抽象メンバーを実装
    非推奨 APICS0618推奨される代替手段に置き換え
  4. 修正 — 対象を絞った修正を適用し、根本原因に関わるものや効果の大きいエラーから対応します

  5. 再ビルド — dotnet build を再実行し、エラー数を比較します

  6. 評価 — エラーがゼロの場合は、健全性チェックとして dotnet test を実行し、 成功を報告します。エラーが減った場合は続行します。同じエラーが残る場合は行き詰まりとして終了し、再検討します。 エラーが増えた場合は、その反復を元に戻し、回帰として報告します。

変化形:テスト修正ループ(最大 5 回。ビルド修正ループに続く場合は 3 回)

同じループとガードを適用し、実行コマンドを dotnet test --no-build にします。 重要な追加手順として、修正前に診断します。

  1. テストを読む — アサーションとセットアップを理解します
  2. プロダクションコードを読む — 実際の動作を理解します
  3. バグの場所を判断します。期待値の誤り → テストを修正。プロダクションコードの バグ → コードを修正。不完全なセットアップ → セットアップを修正。契約の変更 → テストを新しい仕様に合わせて更新します
  4. テストを通すためにアサーションを決して弱めてはいけません。 悪い例: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 — ビルドが成功した後に、コード品質の問題を整理します

コメント