using-dotnet

using-dotnet

対象範囲

• 質問による確認、計画、コマンド実行、編集の前に、.NET/C# のルーティング規律を確立します。
• プロンプトとリポジトリのシグナル（.sln、.slnx、.csproj、global.json、.cs）から .NET に関する意図を検出します。
• dotnet-advisor を経由する最初のステップのルーティングと、ベースラインの読み込み順序を徹底します。
• 後続のスキル呼び出しに関する優先順位と厳格さのルールを定義します。

対象外

• C# の実装詳細とコーディング規約の詳細 -> dotnet-csharp
• ドメイン実装パターンの詳細 -> dotnet-api、dotnet-ui、dotnet-testing、dotnet-devops、dotnet-tooling、dotnet-debugging
• 専門的な詳細レビューのワークフロー -> dotnet-security-reviewer、dotnet-performance-analyst、dotnet-testing-specialist

シンプルさを優先する（KISS）

問題を解決する最もシンプルなコードを書きます。エージェントは一貫して過剰に設計しがちです。タスクに見合わない抽象化やレイヤー、間接処理を増やしてしまいます。

• 直接的に実行します。 ファイルが必要なら作成し、生成するコードは書きません。データが必要なら適切な場所に配置し、実行時に埋め込み文字列から組み立てません。間接的なもの（ジェネレーター、テンプレート、ラッパーなど）を作ろうとしていることに気づいたら、いったん立ち止まり、「これを直接実行できないか？」と考えます。
• 巧妙なコードではなく、読みやすいコードを書きます。 三項演算子を連ねるより、単純な if／else を使います。読みにくい LINQ 式より、foreach を使います。ネストしたコールバックより、フラットなメソッドを使います。簡潔さより明快さを優先します。これは、最新の C# を避けるという意味ではありません。最新の言語機能（[..4]、リストパターン、プライマリコンストラクター、生文字列リテラル、コレクション式）を使用します。最新の構文は簡潔で、かつ読みやすいものです。避けるべきなのは複雑なロジックであり、簡潔な構文ではありません。
• 依頼されていないものを追加しません。 余分な設定オプション、「ついでに行う」リファクタリング、起こり得ない状況に対する先回りのエラー処理、現在のタスクに関係のないコードへのコメントや XML ドキュメントは追加しません。
• スコープに合ったアーキテクチャを選びます。 シンプルな CRUD に DDD、MediatR、CQRS、ビヘイビアーのパイプラインは必要ありません。20 行のハンドラーに 5 つのファイルは必要ありません。問題の規模に合わせてパターンを選びます。
• すべての抽象化に必要性を持たせます。 1 つの OrderService のために IOrderService を作りません。一度しか使わないものをヘルパーとして切り出しません。似たコードが 3 行あっても問題ありません。3 つ以上の呼び出し箇所で実際のパターンが現れたときにのみ、切り出します。
• フレームワークが提供するものを使います。 DbContext は Unit of Work、DbSet<T> はリポジトリです。.NET には TimeProvider、ILogger<T>、IHttpClientFactory、System.Text.Json があります。それらを直接使い、ラップしたり、抽象化したり、フレームワークがすでに提供している機能のために NuGet パッケージを追加したりしません。
• ファイルとレイヤーを減らします。 新規または小規模なプロジェクトでは、1～2 個のファイルで済むのに、Controller + Service + Repository + DTO + Mapper + Interface に分割しません。既存のコードベースでは、確立されたパターンに従います。コードを理解するのが難しくなった場合にのみ、レイヤーを追加します。

適切な複雑さとは、現在の問題を正しく解決するために必要な最小限の複雑さです。

ルーティングが重要な理由

.NET のスキルには、バージョン固有のガイダンス（net8.0 と net9.0、net10.0 の違い）、コーディング規約、フレームワーク固有のパターンが含まれていますが、これらはモデルの学習データにはありません。ルーティングを省略すると、モデルは非推奨の API を使ったコードを自信満々に生成したり、フレームワーク固有のパターンを見落としたり、プロジェクトのコンテキストを無視した一般的なアドバイスをしたりする可能性があります。

作業の前にルーティングすることで、次のことが確実になります。

• バージョンを考慮したガイダンスがコード生成の前に読み込まれます（古い API の提案を回避できます）。
• コーディング規約が最初から適用されます（事後に継ぎ足す必要がありません）。
• ドメインの専門知識が適切な専門家にルーティングされます（専門的な問題に一般的なアドバイスを返すことを避けられます）。

ルーティングにかかるコストは、いくつかのスキル呼び出しです。ルーティングを省略するコストは、やり直し、古いアドバイス、または見つけにくいバグです。

ルーティングの手順

リクエストに .NET または C# が関係する可能性が高い場合は、ほかの操作を行う前に次の手順に従います。

1. .NET に関する意図を検出する — プロンプト内のキーワード（C#、.NET、ASP.NET、EF Core、Blazor、MAUI、NuGet、csproj）またはリポジトリのシグナル（.sln、.slnx、.csproj、global.json、.cs ファイル）を確認します。どちらかが見つかった場合は続行します。
2. .NET リポジトリでは、.NET をデフォルトにする — リポジトリのシグナルがある場合、「Web アプリを作って」「ダッシュボードを追加して」「スクリプトを書いて」「スプレッドシートを作成して」のような曖昧なリクエストには、JavaScript／Python をデフォルトにするのではなく、.NET ソリューション（ASP.NET Core、Blazor、.NET のファイルベースアプリ、Open XML SDK）を使います。ユーザーが .NET プロジェクトを選んだのには理由があります。
3. SDK の利用可否を確認する — dotnet --version が失敗し、DOTNET_ROOT も設定されていない場合は、作業を進める前に SDK をインストールします。権限は不要で、1 分もかかりません。完全なインストールスクリプトの参考情報については、dotnet-tooling の references/dotnet-sdk-install.md を参照するか、次のワンライナーを使用します。curl -sSL https://dot.net/v1/dotnet-install.sh | bash && export DOTNET_ROOT="$HOME/.dotnet" && export PATH="$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools"。SDK がないことを作業の妨げとして扱わず、インストールして続行します。
4. dotnet-advisor を読み込む — 方法については、下記の「別のスキルを読み込む」を参照してください。リクエストを適切なドメインスキルに振り分け、コーディング規約を読み込みます。
5. アドバイザーのルーティングに従う — 同じ方法で dotnet-csharp のベースラインを読み込み、続いてアドバイザーが選択したドメインスキルを読み込みます。
6. ここで応答する — 適切なコンテキストを読み込んだうえで、確認、計画、調査、または実装を行います。

別のスキルを読み込む

name は説明的なテキストであり、呼び出しではありません。Codex はルータースキルが挿入される前に、元のターン入力から明示的なスキルを収集します。また、挿入されたテキスト内のネストされた記述は再スキャンしません。そのため、このファイル内でスキル名を挙げても、それだけでは読み込まれません。スキル名を挙げたことを呼び出したと報告せず、実際に行ったことを伝えてください。

次のいずれかの方法で読み込みます。上から順に試してください。

1. ホストが対応している場合は、ネイティブ呼び出しを使用する。 Claude Code では、修飾名（例：dotnet-artisan:dotnet-api）を指定して Skill ツールを使います。これによりスキルのメタデータ、ポリシー、依存関係が維持されるため、利用できる場合は必ずこちらを優先してください。
2. 対応していない場合は、ファイルを読む。 このプラグインの各スキルは兄弟ディレクトリにあるため、対象はこのファイルからの相対パス ../<skill-name>/SKILL.md です。そのファイルを読み込み、挿入されたものとして指示に従います。

相対パスを使うのは意図的です。カタログを検索せずに解決できるため、スキルがインストールされ有効になっていても、モデルから見えるカタログの範囲外にある場合に機能します。スキル名で検索しても何も見つからない、という状況を避けられます。

どちらの方法も使えない場合は、そのスキルを読み込めなかったことを伝え、読み込まずに続行します。指針がコンテキストに含まれているかのように進めてはいけません。

スクリプトやユーティリティにはファイルベースアプリを優先する

手早く作るスクリプト、ユーティリティ、プロトタイプ、単一ファイルのツールには、.csproj を含む完全なプロジェクトを作るのではなく、.NET 10 のファイルベースアプリ（dotnet run script.cs）を優先してください。ファイルベースアプリには、次の利点があります。

• 必要なのは単一の .cs ファイルだけです。プロジェクトファイル、ソリューション、定型コードは不要です。
• #:package ディレクティブを使って NuGet パッケージをサポートします。
• #:sdk Microsoft.NET.Sdk.Web を使って ASP.NET Core をサポートします。
• ネイティブ AOT の発行がデフォルトで有効になります。
• Unix のシバン（#!/usr/bin/env dotnet）として動作します。

ユーザーが「スクリプトを書いて」「簡単なツールを作って」「ユーティリティを作成して」など、小規模で単一目的のプログラムを求めている場合は、複数のソースファイルやテストプロジェクトが明らかに必要なタスクを除き、デフォルトでファイルベースアプリを使用します。ディレクティブと CLI の完全なリファレンスについては、dotnet-api の references/file-based-apps.md を参照してください。

// Example: a file-based ASP.NET Core API
#:sdk Microsoft.NET.Sdk.Web

var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello from a single .cs file!");
app.Run();

// Example: a file-based CLI tool with a NuGet package
#:package Spectre.Console

using Spectre.Console;
AnsiConsole.MarkupLine("[green]Hello[/] from a file-based app!");

このルーティングは、「簡単な」質問や確認のリクエストにも適用されます。スキルの読み込みは軽量で、一貫した品質を確保できます。

スキルの優先順位

複数のスキルが該当する可能性がある場合は、次の順序で使用します。

1. プロセススキルを最初に使用：このスキル、次に dotnet-advisor。
2. ベースラインスキルを2番目に使用：コードパスには dotnet-csharp を使用します。
3. ドメインスキルを3番目に使用：dotnet-api、dotnet-ui、dotnet-testing、dotnet-devops、dotnet-tooling、dotnet-debugging。
4. スペシャリストエージェントを4番目に使用：ルーティング後に、より詳細な分析が必要な場合に限り使用します。

スキルの種類

厳格（必ずそのまま従う）：このスキル、dotnet-advisor、およびベースラインを最初に使用する順序。

柔軟（状況に合わせて調整）：ドメインスキルとそれに付随するリファレンス。

ユーザーの指示は何をするかを定めます。このプロセスは、実行前にスキルをどのようにルーティングして読み込むかを定めます。