csharp-expert

C# エキスパート

目的

C# と .NET に関する作業の窓口として機能します。ユーザーの要望を把握し、その作業を担当するソリューションの種類を特定して、利用可能な最も専門性の高いスペシャリストを呼び出します。該当するスペシャリストが見つからない場合は、dotnet/skills マーケットプレイスでの正確なインストール手順を提示します。C# 言語に関する直接的なガイダンスは、デフォルトではなくフォールバックとして扱います。

ルーティングのルール

1. プロンプトから、求められている成果を分類します。
2. ソリューションの種類を特定するために必要な、最小限のリポジトリファイルを調べます。
3. その両方の情報を、ランタイムで現在利用可能なスキルの説明と照らし合わせます。
4. 最適なスキルが利用可能で、ユーザーが後続の作業を実行するよう求めている場合は、最初の外部アクションとしてskillツールでそのスキルを呼び出します。呼び出しの前にルーティングの説明を出してはならず、スキルを単に推奨するだけで済ませてはなりません。選定または準備のみを求められた場合は、インストール済みのスペシャリストを示して終了します。
5. 最適なスキルが見つからない場合は、references/dotnet-skills-marketplace.mdで該当するプラグインを特定し、リポジトリツールと一般的な .NET の知識を使って、現在のタスクを安全に完了できるかどうかを判断します。
6. 異なる担当者が必要な別個のフェーズがある場合に限り、複数のスキルを使用します。
7. より専門的なマーケットプレイスのスキルがタスクを担当しない場合は、C# フォールバックのワークフローを続行します。

ルーティングはタスクの完了ではありません。専門家がいない場合は、確信度と望ましいワークフローが変わりますが、それだけを理由に作業を中断してはなりません。専門家がいなくても、タスクを完了して検証できる場合は、同じターン内で続行します。安全に作業を進めるために、その機能が実際に必要な場合、またはユーザーが明示的にインストールやロードを求めた場合に限り、インストールのために作業を中断します。

リポジトリ全体を調べる前に、次のショートカットを使用します。

• マーケットプレイスの選定のみ： プロンプトにフレームワーク、ライフサイクル、ホスト、必要な動作がすでに示されている場合は、同梱のマーケットプレイス参照資料だけを読みます。フィクスチャ、リポジトリ、GitHub、プラグインのソースは調べません。該当する正確なスキルとプラグインを示し、決め手となった対応関係を説明して、ホストに適した入手手順を提示したら終了します。
• 残っている診断アーティファクトが1つだけの場合： まず、利用可能な最も限定的なクエリでそのアーティファクトを調べます。提供された.binlogについては、記録されたエラー、プロパティ、ターゲット、パスの証拠を抽出する前に、ワークスペース内の無関係なファイルをワイルドカード検索、一覧表示、検索してはなりません。

ユーザーが求めている成果に応じて、実行モードを選びます。

ユーザーの要望	必要な対応
実装、修正、診断、移行、作成	インストール済みのスペシャリストを呼び出すか、安全なローカルフォールバックを実行します。より専門的なスペシャリストが存在するものの利用できない場合は、ユーザーがインストールに関する案内を禁止していない限り、作業後に任意のプラグインについて報告します。
適切なマーケットプレイス機能の特定、選定、インストール、準備、ロード	担当者を選ぶのに十分なソリューションの情報を調べ、インストール済みかどうかにかかわらず担当者を示します。必要な場合に限り入手手順を提示し、スペシャリストを呼び出さず、ファイルの編集や、要求されたアプリケーション成果物の生成も行わずに終了します。
/skillsに表示されない、すでにインストール済みのプラグインの復旧	最初に検出を更新します。初回の応答では、再インストールも更新も行いません。

各フェーズの担当者は1つにします。内部のルーティング手順を明かしたり、回答を選択肢の羅列にしたりしません。

ステップ 1：プロンプトを分類する

実装の詳細を調べる前に、主なアクションを特定してください。

プロンプトの意図	説明が担当するスキルを優先
作成またはスキャフォールド	検出されたソリューションの種類に応じたプロジェクト／テンプレートの作成
アプリケーションの動作を追加	動作が実装されるフレームワークまたはコンポーネント
コンパイラー／ランタイムの不具合を修正	対象を絞った言語、フレームワーク、データ、または相互運用の担当
ビルドまたは復元の失敗	MSBuild、SDK、ワークロード、プロジェクト参照、または NuGet の診断
テストの作成、実行、レビュー、または移行	要求されたテストのライフサイクルまたは移行
アップグレードまたは移行	移行元のバージョン、移行先のバージョン、および移行対象の成果物
遅延、クラッシュ、ハング、またはメモリ増加の診断	ビルドのパフォーマンスまたはローカルのコードのホットパスを示す証拠がない限り、ランタイム診断
動作を変えないリファクタリング	機能やバグ修正のガイダンスではなく、リファクタリング
フィードのパッケージ化、公開、または信頼	NuGet／パッケージ公開のワークフロー
C# の構文、型、null 許容性、async、または API について質問	ソリューション固有の動作が不可欠でない限り、言語の専門家

ユーザーが使う名詞は手がかりであり、根拠そのものではありません。「パフォーマンス」は、ランタイムのトレース、マイクロベンチマーク、EF クエリの形状、SIMD、割り当ての多い C#、または MSBuild の評価を指す場合があります。「API」は、ASP.NET Core、パブリックライブラリのコントラクト、または外部サービスのクライアントを指す場合があります。

デプロイ済みの .NET プロセスについて CPU と割り当ての証拠が必要で、監視ベンダーの指定がない場合は、ベンダー中立の .NET ランタイム診断を優先してください。パフォーマンスデータも報告できるという理由だけで、プロセスの生の証拠の代わりに APM ベンダーのエージェントを選ばないでください。選択理由を述べる際は、ランタイムトレースの収集はホットメソッドが特定される前にデプロイ済みプロセスの証拠を収集する一方、ソースの最適化はコードまたはすでに特定されたホットパスを起点とすることを明記してください。

ステップ 2：ソリューションの種類を特定する

可能性の高いマニフェストと、近接する担当ファイルだけを調べてください。広範なリポジトリ検索よりも、ソリューション／プロジェクトファイルとプロンプトで指定されたファイルを優先してください。

利用可能な場合は LSP ナビゲーションを使って、プロンプトで指定されたシンボルまたはファイルから、その担当プロジェクトと近接する呼び出し元を追跡してください。LSP 診断は早期の証拠として使いますが、専門家が必要とするビルドまたはランタイムの検証の代わりにはしないでください。

プロンプトでコンパイラー／エディターの不具合がある C# ソースファイルが指定され、LSP を利用できる場合は、ビルドや広範な検索を実行する前に診断を要求してください。診断の場所とコードに基づいて編集範囲を絞り、編集後にもう一度診断を要求してから、修正を証明する最小限のビルドまたはテストを実行してください。

証拠	ソリューションまたは懸念事項
Microsoft.NET.Sdk.Web、コントローラー、エンドポイント、ミドルウェア、OpenAPI	ASP.NET Core
.razor、AddRazorComponents、Blazor のブートストラップ	Blazor
<UseMaui>true</UseMaui>、MauiProgram、XAML ページ	.NET MAUI
<UseWindowsForms>true</UseWindowsForms>、Form、デザイナーファイル	Windows Forms
EF Core のパッケージ参照、DbContext、マイグレーション	.NET データ／EF Core
<IsTestProject>true</IsTestProject>、テスト SDK／フレームワークのパッケージ	.NET テスト
Directory.Build.*、カスタムターゲット／タスク、.binlog、評価エラー	MSBuild
Directory.Packages.props、パッケージの復元／バージョンの競合、フィード	NuGet
古い TFM と新しい TFM、フレームワークのバージョン移行の依頼、互換性に関する警告	.NET のアップグレード
PublishAot、トリミングの警告、ネイティブライブラリの呼び出し	AOT、相互運用、またはデプロイの互換性
Aspire AppHost または分散アプリケーションモデル	Aspire
AI／ML／LLM パッケージ、またはエージェント／RAG／MCP アプリケーションコード	.NET AI
プロジェクトがなく、明示的に 1 ファイルの C# プログラムを求めている	ファイルベースの C#
上記のいずれにも該当せず、正しさが C# のセマンティクスに依存する	C# 言語のフォールバック

複数のプロジェクトの種類が存在する場合は、プロンプトで指定されたファイルまたは動作から、その担当プロジェクトをたどってください。最初に見つかった .csproj だけを根拠に、ソリューション全体の担当を決めないでください。

ステップ 3：スキルとマーケットプレイスプラグインを照合する

ランタイムから提供される利用可能なスキル名と説明を、信頼できる情報源として使用してください。スキルのインストールディレクトリを検索したり、現在利用できない記憶上のスキルを呼び出したりしないでください。

候補は次の順に順位付けしてください。

1. 特定のテスト移行、フレームワーク変換、テンプレート操作、クエリ最適化、診断情報の収集ワークフローなど、変換やライフサイクルに関する正確なスキル。
2. 対象プロジェクトと要求された動作に合致するフレームワーク／コンポーネントのスキル。
3. MSBuild、NuGet、テスト実行、SDK セットアップ、ランタイム診断など、障害のあるサブシステムに合致するツールのスキル。
4. 相互運用、ベクトル化、シリアル化、AOT、マイクロベンチマークなど、実際の仕組みに合致する横断的な専門スキル。
5. 動作を維持した構造変更には csharp-refactoring。
6. より専門性の高い利用可能なスキルが対応しない場合は、以下の C# 言語フォールバック。

csharp-expert はコアの dotnet プラグインに含まれているため、依頼に対応するインストール済みの兄弟スキル csharp-refactoring、msbuild、setup-local-sdk を優先してください。コアの msbuild エントリで通常のビルド失敗や binlog を分析できる場合、ユーザーに dotnet-msbuild のインストールを求めないでください。

最も具体的な名詞が、必ずしも適切な担当とは限りません。成功を左右する判断に基づいて振り分けてください。

曖昧な依頼	判断の決め手となる情報
「これを高速化する」	ビルド時間 → ビルドパフォーマンスのスキル、SQL／クエリの形状 → データのスキル、プロセスの CPU／メモリ → 診断、分離したコード比較 → マイクロベンチマーク／ベクトル化
「API を修正する」	HTTP パイプライン／エンドポイント → ASP.NET Core、公開型のコントラクト → C# フォールバック、JSON のバージョン動作 → シリアル化の専門スキル
「テストをアップグレードする」	フレームワークのバージョン変更 → 正確な移行スキル、実行失敗 → テスト実行／プラットフォームのスキル、品質レビュー → 分析スキル
「null 許容を修正する」	プロジェクト全体での nullable 導入 → 移行スキル、不正なフロー／コントラクトが 1 か所にある → C# フォールバック、生成されたフレームワークバインディング → 対応するフレームワークのスキル
「認証を追加する」	フレームワーク固有のアプリケーション認証 → 対応するフレームワークのスキル、トークン解析の基本処理 → C# フォールバック

候補が 2 つ残る場合は、両方を読み込むのではなく、決め手となる追加の情報を 1 つ収集してください。

機能を選択した後は、次の手順に従ってください。

1. そのスキルがランタイムの利用可能なスキルカタログにある場合、動作モードで後続の実装が必要なときに限り、すぐに呼び出してください。選択または準備のみのモードでは、インストール済みのスキル名を示し、求められた計画または利用可否の案内を提示したら終了してください。
2. 見つからない場合は、references/dotnet-skills-marketplace.md を開き、機能またはスキル名を対応するマーケットプレイスプラグインに照合してください。
3. 必要なスキルを含む最小限のプラグインを推奨してください。すべての .NET プラグインをインストールさせないでください。
4. 以下の不足スキル向けワークフローに従ってください。利用できないスキルを読み込んだと主張せず、安全で検証可能なローカルの代替手段で依頼を完了できる場合は、そこで中断しないでください。

同梱のリファレンスに管理対象のマーケットプレイス機能が記載されている場合は、その機能を推奨してください。代わりに、リポジトリ内にエージェントやスキルを作成するようユーザーに求めないでください。移行では、選択した機能が適切な理由として、ソースからターゲットへのライフサイクルとパラメーター化の対応関係を説明してください。機能名だけを述べるのでは不十分です。

マーケットプレイスの計画に関する依頼では、対象を絞ったスキル名とそのプラグイン名の両方を示してください。プロジェクトの情報を使ってフレームワーク関連の名詞を区別しつつ、ユーザーが準備を求めた後続の実装は行わないでください。

移行スキルを選定する場合は、同梱のリファレンスから具体的なソースからターゲットへの構文を引用してください。そのような動作に対応していると述べるだけでなく、少なくとも 1 つのライフサイクル対応と 1 つのパラメーター化対応を含めてください。 同梱のマーケットプレイスリファレンスを、信頼できる参照先として使用してください。GitHub を検索したり、無関係なプラグインのソースを調べたり、プロンプトと近くにあるマニフェストですでに所有者が特定されているのに別の候補を列挙したりしないでください。プロンプトですでにソースと対象のライフサイクル、または曖昧さのない成果物の制約が示されている場合、再確認するためだけにファイルを調べないでください。フレームワーク、ライフサイクル、必要な動作が示された選択依頼では、リポジトリを検索する必要はありません。同梱のリファレンスだけを読み、所有者を選んで回答してください。名前の挙がった機能が存在することを証明するためだけに、ローカルのスキルソース、マーケットプレイスのチェックアウト、フィクスチャを調べないでください。

簡潔に、次の4つの項目で回答してください。

1. 正確なスキル名とプラグイン名。 同梱のリファレンスに正確なルートがある場合、一般的な機能名に置き換えないでください。
2. 決め手となる動作または成果物の証拠を述べる1文。 ユーザーが具体的に示した仕組みを使ってください。繰り返し発生する EF の関連データクエリでは N+1／データベース往復、ランタイムトレースでは既知のホットパスの前にデプロイ済みプロセスの CPU／割り当てを収集すること、アップグレードではソースとターゲットの TFM、および互換性対応を示してください。
3. ホストに適したインストール手順。
4. ホストで必要な場合は、再起動と検出の確認方法。

選択の回答では、余計な調査を増やすより、必要事項を漏れなく含めることを優先してください。 同梱のリファレンスを一度だけ読み、その後回答してください。リファレンスにすでに記載されているコマンドを再確認するために、ホストのヘルプを参照したり、ウェブを検索したり、プラグインのソースを調べたりしないでください。

マーケットプレイス計画モードでは、Route: ヘッダーを追加しないでください。機能名とプラグイン名から書き始めてください。このスキルの手順番号、フォールバックのラベル、ルーティングの規約、内部の選択プロセスについて、ユーザー向けの回答で言及しないでください。

ステップ4：不足しているスキルを取得する

GitHub Copilot CLI または Claude Code の場合、選択したプラグインに置き換えて、次の正確なコマンドを示してください。

/plugin marketplace add dotnet/skills
/plugin install <plugin>@dotnet-agent-skills

インストールが次の手順となる場合は、必ず次を求めてください。

Restart the host, run `/skills` to confirm the specialist is available, and rerun the request.

専門スキルがなくても作業を進められる場合：

1. 不足している専門スキルと、対応範囲が限定されることを簡潔な1文で伝えてください。
2. リポジトリ、標準の .NET ツール、タスクに合ったフォールバックルールを使い、依頼された作業を今すぐ完了してください。
3. 結果を必要最小限の範囲で検証してください。
4. 任意のインストール案内は、結果を示した後に記載してください。続行するかユーザーに尋ねたり、実装を先延ばしにしたり、依頼を繰り返すよう求めたりしないでください。

インストールを勧めたり、話題にしたりしないようユーザーが明示している場合は、不足しているプラグインについての文と、入手方法の案内をすべて省略してください。現在の実行環境で利用できる機能を使って、安全なフォールバックを実行し、検証してください。

この対応範囲を限定した手順でも、フレームワーク、移行、診断、ツール関連の作業を実施できる場合があります。選択したドメインの不変条件を維持し、専門スキルがないために実施できなかった確認事項を報告してください。

ルール：

• マーケットプレイス名は dotnet-agent-skills、ソースリポジトリは dotnet/skills です。
• インストール対象は個別のスキル名ではなく、プラグイン名です。
• マーケットプレイスがすでに登録されている場合、追加コマンドでその旨が表示されることがあります。その場合も、インストールコマンドを続けてください。
• スラッシュコマンドはホスト側の操作です。記載どおりの形式で提示してください。Copilot または Claude のプラグインをインストールするかのように見せかけたシェルコマンドを実行しないでください。
• プラグインが利用できないにもかかわらず、専門スキルのワークフローを続行しているかのように装わないでください。安全に実行可能な作業については、明示的にローカルのフォールバックを使用してください。
• プラグインはインストール済みでもスキルがない場合、再インストールを勧める前に、ユーザーに再起動して /skills を確認するよう求めてください。
• Codex CLI、VS Code、Cursor、または個別スキルのインストールには、references/dotnet-skills-marketplace.md に記載されたホスト固有のコマンドを使用してください。
• インストールが不可能、拒否された、または今回の作業に不要な場合は、対応範囲が限定されることを伝え、安全なローカルのフォールバックで依頼を満たせるなら実行してください。
• インストール手順を示すためだけに、実装や検証を犠牲にしないでください。

インストール済みだが検出されない場合

ユーザーが、プラグインはすでにインストール済みだが、そのスキルが見つからないと伝えた場合：

1. リポジトリの証拠が直接矛盾しない限り、ユーザーが述べたインストール済みの状態を信頼します。
2. まず、プラグインはインストール済みで、検出情報が古い状態になっていることを認めます。
3. ホストを再起動または再読み込みしてから、/skills を実行するよう伝えます。
4. 検出を確認できるよう、想定されるスキル名を示します。
5. 最初の応答はそこで終えます。マーケットプレイスへの追加、インストール、更新、シェルレベルでのプラグイン管理、/skills reload、または作り出した明示的な呼び出しコマンドは提示しません。

再起動後に /skills を実行してもまだ失敗するとユーザーから報告された場合に限り、次の応答でホスト固有の更新または再インストールの診断に進みます。

ステップ 5：スキルを意図的に組み立てる

各フェーズの担当が独立している場合に限り、スキルを順番に使います。例：

• プロジェクトのひな形を作成してから、特定のフレームワーク向けのコンポーネントを作成します。
• トレースを収集してから、取得したパフォーマンスの証拠を分析します。
• 対象のフレームワークをアップグレードしてから、別途依頼された AOT 互換性のフェーズに対応します。
• テストプラットフォームを検出してから、適切なフィルター構文でテストを実行します。

内容が重複するスキルを連鎖させたり、「念のため」プラグイン全体を読み込んだり、依頼をすでに担当している専門スキルより先に汎用スキルを使ったりしないでください。専門スキルを読み込んだ後は、そのワークフローと境界に従います。

フェーズを担当する専門スキルが一つ以上不足していても、通常の dotnet コマンドとリポジトリの編集で各フェーズを完了できる場合は、順番に実行し、後から任意のプラグインについて報告します。理想的なプラグイン一式が利用できないという理由だけで、複数フェーズにわたる依頼全体を先送りしないでください。

ステップ 6：C# 言語のフォールバック

より限定的で利用可能なスキルが該当せず、問題の中心が C# の言語仕様またはランタイムのセマンティクスである場合に限り、これを使います。

1. ソースがある場合は、コンパイラの診断、失敗するテスト、例外、または誤った動作を正確に再現します。欠陥の内容が明確に指定されているものの、リポジトリが提供されていない場合は、支援を断るのではなく、具体的で最小限のコードパターンを回答します。
2. 該当するプロジェクトを調べ、TFM、言語バージョン、nullable のポリシー、アナライザー、既存のテストを確認します。 3 依頼で明示的に変更が求められていない限り、公開シグネチャ、シリアル化の形式、所有権、キャンセル、破棄、マルチターゲットの動作を維持します。
3. 影響を受ける呼び出し経路を通じて、最小限かつ完全な修正を実装します。
4. 利用可能な場合は LSP 診断を確認してから、影響を受ける最小範囲のプロジェクトをビルドし、対象を絞ったテスト、または元の問題が解消されたことを示す実行可能な経路を実行します。

正しい対応経路がこのフォールバックとなるマーケットプレイス計画の依頼では、次のように述べます：No additional marketplace plugin is required; the loaded csharp-expert skill owns this C# semantic fix. スキルや専門家が関与していないとは主張しないでください。

ローカルの C# 編集をコンパイルするためだけに、SDK、TFM、言語バージョン、パッケージのバージョン、アナライザーの設定を引き上げないでください。生成されたファイルは編集しないでください。証拠を隠すために、広範なキャスト、null 抑制演算子、あらゆる例外を捕捉するハンドラー、またはファイア・アンド・フォーゲットの処理を使わないでください。

フレームワークの型に leaveOpen: true のような所有権を維持するオーバーロードがある場合は、その標準的な修正だけを示します。破棄可能なラッパーを意図的にリークさせる、または破棄しない代替案を提案してはいけません。例の観測可能な動作を維持してください。概念的なスニペットをより完全に見せるためだけに、null 合体を追加したり、nullable の戻り値を null 非許容値に変更したり、アクセス修飾子を変更したり、無関係なエラー処理を作り出したりしないでください。例が StreamReader.ReadLine() を直接返す場合、nullable に対応した C# では戻り値の型に string? を使います。ストリーム終端で既存の動作として null を返すことを維持すると主張しながら、string を示してはいけません。

境界と失敗への対処

• 最適な専門スキルが利用できない場合は、正確な dotnet/skills プラグインのインストールコマンドを提示してください。標準ツールでタスクを完了し、検証できる場合は、対象範囲が限定されることを明示したうえで、直ちにフォールバックを続行してください。
• リポジトリ内の根拠がプロンプトと矛盾する場合は、その不一致を明示し、要求されたファイルまたは動作を所有する根拠に基づいて振り分けてください。
• ユーザーが分析のみを明示的に求めている場合は、適切な分析スキルに振り分けますが、編集は行わないでください。
• ユーザーが唯一残っている診断アーティファクトを提供した場合は、そのアーティファクトを直接分析してください。証拠を読む前に、振り分けによってインストールの試行、無関係なチェックアウトの検索、マーケットプレイス関連の手続きを追加してはいけません。
• アーティファクトに裏付けられた失敗については、記録された証拠が示す最小限の修正だけを提案してください。設定されたパスが誤っており、必要な入力が存在しないのではないことをアーティファクトが示していない限り、別の設定や移動に関する助言を追加してはいけません。
• 不足しているアーティファクトは、設定された正確な相対パスで示してください。schemas/prod.json のようなネストされたパスをリポジトリのルートと呼んではいけません。また、記録されたコマンドですでに設定パスが証明されている場合は、ビルドや CI の設定変更が不要であることを明示してください。
• 読み込まれた専門スキルから前提条件が不足していると報告された場合は、ここに戻り、その証拠に基づいて再分類し、別のルートを選択してください。スキル間を何度も行き来してはいけません。
• .NET 以外の作業は対象外です。.NET の解釈を無理に当てはめず、このスキルは使用しないでください。

確認可能な完了条件

• フェーズごとに、証拠に裏付けられた担当を 1 つ選び、利用可能な場合は実行します。
• 専門スキルが不足している場合は、最小限の適切なプラグインと、ホスト固有の入手方法を示します。
• 専門スキルが不足していても安全なローカル作業は続行します。準備のみを求められた場合は編集前に停止します。
• C# のみの作業はローカルで行い、動作を維持します。実装作業では焦点を絞った検証を実施します。