Claude Code や GitHub Copilot CLI に C# コードを書かせても、MSBuild エラーの原因診断や Entity Framework Core クエリの最適化、テストフレームワークの移行といった「本当に助けてほしい場面」で精度が出ない、と感じることはないでしょうか。汎用的なプロンプトだけでは .NET 特有の作法まで踏み込ませることが難しく、生成物のレビュー工数が膨らみがちです。
その解として 2026 年 2 月に公開されたのが、Microsoft .NET チーム公式のリポジトリ「.NET Skills(dotnet/skills、英語圏の記事では dotnet skills とも表記されます)」です。Anthropic が提唱した Agent Skills オープン標準に準拠し、.NET 開発の作法 を SKILL.md 形式でエージェントに注入できます。ただし類似リポジトリ(microsoft/skills や laravel/agent-skills 等)も存在するため、「自分のプロジェクトに導入すべきか」「どのプラグインから入れるか」「他リポジトリと併用すべきか」を判断するには一定の情報整理が必要です。
本記事では、dotnet/skills に収録された 16 プラグインの中身、対応する AI コーディングエージェントの導入手順、類似リポジトリとの差分、品質メンテナンスの体制までを整理し、初見エンジニアが翌日の業務で採用可否を判断できる材料を提供します。動作検証を含まないドキュメントベースの整理で、公式リポジトリ(gh api /repos/dotnet/skills)と公式ブログの記述内容に基づいて解説します。
.NET Skills(dotnet/skills)とは
.NET Skills は、Microsoft .NET チームが公式に維持している AI コーディングエージェント向けのスキル集です。GitHub 上では dotnet/skills として公開されており、Repository description には「Repository for skills to assist AI coding agents with .NET and C#」と記載されています。
リポジトリの基本情報
gh api /repos/dotnet/skills で取得した基本情報は次のとおりです。数値・属性値は本記事執筆時点のものです。
項目 | 値 |
|---|---|
owner / name | dotnet / skills |
description | Repository for skills to assist AI coding agents with .NET and C# |
主要言語 | C# |
ライセンス | MIT |
スター数 | 4,514 |
フォーク数 | 332 |
直近 push | 2026-07-10 |
visibility | public |
archived | false |
fork | false |
disabled | false |
private | false |
archived と fork はいずれも false であり、本家として現役でメンテナンスされているリポジトリです。直近 push が本記事執筆日(2026 年 7 月 10 日)と同日である点からも、活発に更新されていることが確認できます。ライセンスは MIT で、社内プロジェクトでも比較的取り込みやすいライセンス設計です。
公式発表と .NET チームの狙い
.NET Skills は 2026 年 3 月に .NET Blog で正式に発表されました(Extend your coding agent with .NET Skills)。発表記事では、汎用プロンプトから始めるアプローチの限界を指摘し、Microsoft 自身が .NET を出荷する過程で培ったパターンをスキルとして共有する方針が示されています。
同発表では、AI コーディングエージェントに「.NET Skills を差し込むだけで、Microsoft 内部で検証されたワークフローをそのまま活用できる」という設計思想が説明されています。つまり .NET Skills は単なるサンプル集ではなく、「.NET 開発のベストプラクティスをエージェントの実行可能な手順に落とし込んだリポジトリ」と位置付けられています。
.NET Skills が解決する課題
Claude Code / GitHub Copilot CLI / Cursor などの AI コーディングエージェントは、汎用プロンプトのままでも幅広い言語のコーディングを支援できます。しかし .NET / C# の実務では、次のような場面で精度が落ちるケースがあります。
- MSBuild のビルド失敗ログを渡しても、原因の切り分けや
binlog解析までは提案できない - Entity Framework Core のクエリを書かせても、
IncludeやAsNoTrackingの使い分けまで踏み込まない - 旧テストフレームワーク(xUnit / VSTest)から MSTest v4 / Microsoft.Testing.Platform への移行手順が曖昧になる
- MAUI や Blazor のように SDK 固有のコマンド・診断ツール(
dotnet-maui doctor等)を活用しないと解決しない問題に太刀打ちできない
これらは「AI が .NET の作法を知らない」ことに起因します。汎用モデルにその都度プロンプトで教え込むのは冗長で、しかも案件間でノウハウが継承されません。
.NET Skills はこの問題を、Agent Skills 標準に準拠した SKILL.md(YAML フロントマター + 手順)としてスキルを配布することで解決します。エージェント側は各 SKILL.md をタスクに応じて呼び出し、「Microsoft 公式のワークフロー」を実行時に注入できます。開発者側は「毎回コンテキストにコピペする」ような運用から解放され、再現性のある .NET タスク実行が期待できます。
Agent Skills 標準と Progressive Disclosure の仕組み
.NET Skills の理解を進めるには、その土台となる Agent Skills 標準を押さえておくと役立ちます。標準の公式サイトは agentskills.io で公開されており、Claude / Claude Code / GitHub Copilot / VS Code / Cursor / Codex CLI / Gemini CLI / OpenHands など多数の AI エージェントが採用しています。
SKILL.md フォーマット
Agent Skills 標準における最小構成は、YAML フロントマターと本文からなる SKILL.md ファイル 1 つです。dotnet/skills の plugins/dotnet/skills/setup-local-sdk/SKILL.md から抜粋します(出典: https://github.com/dotnet/skills/blob/main/plugins/dotnet/skills/setup-local-sdk/SKILL.md)。
---
name: setup-local-sdk
license: MIT
description: >
Install a .NET SDK locally for safe preview testing...
USE FOR: trying .NET previews safely, testing specific SDK versions...
DO NOT USE FOR: system-wide SDK installs...
---
description に「USE FOR:」と「DO NOT USE FOR:」の両方を明示しているのが特徴です。エージェントは「どんなタスクで使うか」だけでなく「使うべきでない状況」も判定できるため、誤発火(本来は別のスキルで解くべきタスクへの適用)を抑制できます。本文側では Purpose / When NOT to use / Inputs / Workflow のセクションで具体手順を規定します。
Progressive Disclosure の 3 段階
Agent Skills 標準の中核となる考え方が Progressive Disclosure(段階的開示)です。多数のスキルを保有しつつコンテキストを圧迫しないよう、3 段階で必要な情報だけを読み込みます。
- Discovery: エージェント起動時に、各 SKILL.md の
nameとdescriptionメタデータのみをロード - Activation: ユーザーのタスクに合致するスキルが見つかった時点で、その SKILL.md 本文全体を読み込み
- Execution: 実行段階で、必要に応じてスクリプト・参照ドキュメント・アセットを追加ロード
この仕組みにより、.NET Skills の 16 プラグイン合計で数百に及ぶスキルを持たせても、コンテキストウィンドウが破綻しにくい構造になっています。「入れれば入れるほどエージェントの反応が鈍る」といったリスクを抑えられる点は、採用判断の重要な安心材料です。
収録される 16 プラグインの全体像
dotnet/skills は、目的別に整理された 16 個のプラグインから構成されます。各プラグインは複数のスキル(SKILL.md)を束ねる単位で、Copilot CLI / Claude Code 等のマーケットプレイスから個別にインストールできます。プラグインごとの品質・スコアリング状況は公式ダッシュボード dotnet.github.io/skills で公開されています。
6 カテゴリでのプラグイン俯瞰
16 プラグインを役割別に整理すると、次のようにグルーピングできます(各プラグイン名は GitHub リポジトリの plugins/ 配下のディレクトリ名に対応します)。
カテゴリ | プラグイン | 主な守備範囲 |
|---|---|---|
日常開発 |
| LSP 統合、C# スクリプト、P/Invoke、EF Core クエリ最適化 |
ビルド / パッケージ |
| MSBuild 診断・近代化、Central Package Management への変換 |
診断 / 性能 |
| dotnet-trace、dump 収集、マイクロベンチマーク、パフォーマンス分析 |
テスト |
| テスト生成、カバレッジ分析、xUnit/VSTest→MSTest/MTP 移行 |
移行 / 近代化 |
| .NET バージョン移行(9→10、10→11)、AOT 互換、nullable 参照、.NET 11 の新 API |
特定領域 |
| Web API、Blazor、MAUI、AI/ML/MCP、テンプレートエンジン |
実験段階 |
| 卒業前提の未成熟スキル置き場 |
「日常的な C# 開発」から「大規模移行」「AI アプリ実装」までを一通りカバーする構成で、汎用モデル単体では踏み込みにくい領域を補う位置付けです。
特に厚い MSBuild と test プラグインの中身
16 プラグインの中でも dotnet-msbuild と dotnet-test は突出してスキル数が多く、深いドメイン専門化が進んでいます。
dotnet-msbuild は 18 個のスキルを収録しており、binlog-failure-analysis(binlog によるビルド失敗解析)、build-perf-baseline(ビルド性能ベースライン化)、msbuild-modernization(近代化)、target-authoring(Target の設計)などが含まれます。加えて msbuild.agent.md / build-perf.agent.md / msbuild-code-review.agent.md といったカスタムエージェント(.agent.md 形式)が用意され、親エージェントから専門エージェントへ処理を委任する階層構造を持っています。
dotnet-test は 20 個のスキルを収録しており、assertion-quality(アサーション品質判定)、crap-score(CRAP スコアリング)、coverage-analysis(カバレッジ分析)、test-anti-patterns(アンチパターン検出)などがあります。カスタムエージェントも code-testing-builder / code-testing-fixer / code-testing-generator / code-testing-implementer / code-testing-linter / code-testing-planner / code-testing-researcher / code-testing-tester の 8 種類に加え、test-quality-auditor / testability-migration が用意されています。テスト設計のフェーズごとに担当エージェントを分ける発想は、レビュー精度の高い運用を目指した設計です。
MSBuild とテストは .NET プロジェクトの継続的なメンテナンスコストが特に高い領域であり、この 2 プラグインの厚みは .NET Skills の投資対効果を語るうえで重要な差別化ポイントです。
実験段階の dotnet-experimental の位置付け
dotnet-experimental は「品質基準は同等でも、まだ本流プラグインに卒業する前段階のスキル」を置くための実験場です。CONTRIBUTING.md によれば、実験プラグインも他プラグインと同じ eval.yaml によるスコアリング対象で、卒業前提で管理されています。本番運用では「必要に応じて選択的に導入する」扱いにするのが安全です。
プロジェクトフェーズ別「入れると効果が高いプラグイン」
16 プラグインを一気に入れる必要はありません。自分のプロジェクトが今どのフェーズにあるかを踏まえ、優先度の高いものから 1〜3 個入れることで導入効果を体感しやすくなります。
フェーズ別マッピング
フェーズ | まず 1 つ入れるなら | 次に入れるなら | 補足 |
|---|---|---|---|
新規開発(Web API / Blazor) |
|
| テンプレート生成は |
既存保守(大規模プロジェクト) |
|
| binlog 解析・性能ベースライン化が効果的 |
.NET 移行(9→10、10→11) |
|
| AOT 互換や nullable 参照移行を含む |
テスト整備 |
|
| 品質監査系エージェントで既存テスト評価 |
MAUI 開発 |
|
|
|
Blazor 開発 |
|
| 双方向レンダリング・JS Interop 用スキルあり |
AI 機能実装(LLM / MCP) |
|
| MCP サーバの C# 実装向けスキル多数 |
最初に入れるべき 1 つを選ぶ判断軸
.NET Skills の効果を最短で確認するには、次の順で判断軸を当てはめると迷いにくくなります。
- 今もっとも時間を取られている作業は何かを洗い出す(MSBuild エラー診断 / テスト整備 / 移行作業 / 特定領域のトラブル対応)
- その作業に該当するプラグインを 1 つ選ぶ
- 使用感が確認できたら、
dotnet-test(テストの標準品質底上げ)とdotnet-msbuild(ビルド安定化)を横串で追加検討する
まず 1 つに絞ることで、Progressive Disclosure による効率的な発火動作も体感しやすくなります。
対応する AI コーディングエージェントと導入手順
.NET Skills は Agent Skills 標準に準拠しているため、対応するエージェントの多くから同じ配布物を利用できます。README の Installation セクションに沿った、公式の導入コマンドを整理します。改変せずそのまま引用します(出典: https://github.com/dotnet/skills#installation)。
Copilot CLI / Claude Code の導入
Copilot CLI と Claude Code はどちらも、マーケットプレイスの追加とプラグインインストールの 2 コマンドで完了します。
/plugin marketplace add dotnet/skills
/plugin install <plugin>@dotnet-agent-skills
(出典: https://github.com/dotnet/skills#installation)
追加後にエージェントを再起動し、/skills コマンドで有効化されたスキル一覧を確認します。<plugin> の部分には dotnet-msbuild などのプラグイン名を指定します。
VS Code / Cursor / Codex CLI の導入
VS Code / VS Code Insiders は Preview 段階の機能を利用します。settings.json に次のキーを追加します。
{
"chat.plugins.enabled": true,
"chat.plugins.marketplaces": ["dotnet/skills"]
}
(出典: https://github.com/dotnet/skills#installation)
Cursor はマーケットプレイスパネルから検索して追加するか、ローカルにチェックアウトしたリポジトリを ~/.cursor/plugins/local/dotnet-agent-skills にシンボリックリンクして再読み込みする方法が示されています。
Codex CLI(v0.121.0 以降)は次のコマンドで追加します。
codex plugin marketplace add dotnet/skills
(出典: https://github.com/dotnet/skills#installation)
追加後、/plugins から個別のプラグインを選択します。個別スキル単位で導入する場合は skill-installer install <URL> 形式が用意されています。
ロールバックとバージョン管理
導入後の撤退や更新は次のような設計になっています。
- プラグイン単位でのアンインストール: Copilot CLI / Claude Code はマーケットプレイスから追加・削除を管理するため、プラグイン単位で外せます。VS Code / Cursor では
settings.jsonや~/.cursor/plugins/local/の設定を戻せば有効化前の状態に戻せます - バージョン管理:
/plugin update相当のコマンドで更新できます(各エージェントのマーケットプレイス機能に準じます) - 実験プラグインの扱い:
dotnet-experimentalは本番運用では選択的導入とし、本流プラグインに卒業した際に切り替える運用が想定されています
導入と撤退の両方向を確認できていれば、「試しに入れたが元に戻せなくなる」といったリスクを回避しやすくなります。詳細は前掲の .NET Blog 発表記事(Extend your coding agent with .NET Skills)でも紹介されています。
.NET Skills と類似リポジトリの違い
.NET Skills と似た性格のリポジトリは複数存在します。「どれを選ぶか」を判断するために、代表的な 3 つと比較します。
比較サマリ
観点 | dotnet/skills | MicrosoftDocs/Agent-Skills | ||
|---|---|---|---|---|
対象言語・領域 | .NET / C# 全般 | 多言語(Python / .NET / TS / Java / Rust) × Azure SDK | PHP / Laravel | Microsoft / Azure ドキュメント |
スキル軸 | ビルド・テスト・移行・LSP・MCP | Azure サービス連携(identity / storage / messaging / monitoring 等) | Laravel リファクタ・Cloud・Nightwatch | ドキュメント準拠の知識ベース |
.NET 開発への深さ | 極めて深い(MSBuild 18 / test 20 スキル) | 標準的(.NET 向けは 28 スキル) | 対象外 | ドキュメント参照ベース |
カスタムエージェント | 16 個(testing 系 10 個・MSBuild 系 3 個・diag / template-engine / test-migration 各 1 個) | あり | あり( | 主にスキル |
メンテナンス主体 | Microsoft .NET チーム | Microsoft Azure / AI 部門 | Laravel 公式 | MicrosoftDocs |
ライセンス | MIT | MIT | MIT | MIT |
同じ「Microsoft 発の Skills 集」でも、.NET Skills と microsoft/skills はターゲット領域が異なります。前者は「.NET / C# 開発そのもの」に焦点を当て、MSBuild・テスト・移行など言語ランタイム側の深い知識に強みがあります。後者は「Azure SDK 連携」が主眼で、多言語向けに広く展開されており、.NET は 28 スキルというサブセット扱いです。
microsoft/skills との併用パターン
「Azure 上で稼働する .NET アプリケーション」を開発する場合、両者は補完関係で使えます。役割分担の目安は次のとおりです。
.NET Skillsを主軸に据える: MSBuild / EF Core / テスト / 言語機能移行 / MAUI・Blazor 等、.NET SDK 内で完結するタスクを担わせるmicrosoft/skillsを補完として入れる: Azure Identity、Azure Storage、Application Insights、Azure AI Foundry などクラウドサービス連携タスクを担わせる
laravel/agent-skills は対象言語が PHP のため直接の比較対象にはなりません。ただし「フレームワークベンダーが Agent Skills を公式配布する」という点では同型の取り組みであり、Agent Skills 標準がエコシステム横断で拡がっている状況を示す例と位置付けられます。
.NET / C# 開発そのもの の深いドメイン支援を求めるならば、事実上 .NET Skills が第一選択となります。Azure 連携を加えたい場合は microsoft/skills を追加するという段階的な導入が現実的です。
品質・メンテナンスの健全性
Microsoft 公式のリポジトリと聞くと安心感がある一方で、「実験段階のプロトタイプではないか」「本番運用に耐えるのか」といった懸念も浮かびます。CONTRIBUTING.md(dotnet/skills/CONTRIBUTING.md)を確認すると、次のような品質ガードレールが敷かれていることが分かります。
- CODEOWNERS 必須: 全プラグイン・スキル・エージェントに
.github/CODEOWNERSで最低 2 名の FTE または GitHub team が割り当てられる。属人化を避け、複数人でのレビュー体制が担保されている - eval.yaml によるスコアリング: 新規スキル追加時は必ず対応する
tests/<plugin>/<skill>/にeval.yamlとフィクスチャを追加する。正確性・効率性の評価が仕組みとして組み込まれている - ダッシュボード公開: dotnet.github.io/skills で各プラグイン・スキルの評価結果が可視化されている。品質状況を外部からも参照できる
- 実験と本流の分離: 未成熟なスキルは
dotnet-experimentalプラグインに置き、卒業前提で管理する。本流プラグインの品質水準を守る運用 - PR ポリシー: 1 スキル / 1 エージェント単位の小さな PR が推奨される。イシューでのスコープ合意も原則化されている
加えて、リポジトリの更新頻度(本記事執筆日と同日の 2026-07-10 に push、スター数 4,514、フォーク数 332)は、コミュニティからの継続的な関心と貢献を示唆します。
これらの仕組みを踏まえると、.NET Skills は「Microsoft 公式でありながら実験プロトタイプではなく、本番導入を前提とした品質管理が敷かれているリポジトリ」と評価できます。ただし採用にあたっては、実験プラグインの選択的導入や、社内での試験期間の設定など、自社のリスク許容度に応じた運用ルールを合わせて設計することを推奨します。
まとめ – .NET Skills を採用すべきプロジェクトの条件
ここまでの整理を踏まえ、.NET Skills の採用を検討する価値があるプロジェクトの条件を 3 つに絞ります。以下のいずれかに該当する場合、翌日から /plugin marketplace add dotnet/skills を実行して評価に入る価値があります。
- Claude Code / GitHub Copilot CLI / Cursor / Codex CLI などのエージェントで C# / .NET を扱っている → Agent Skills 標準に対応した環境がすでに整っており、導入コストが小さい
- MSBuild 診断 / テスト整備 / .NET バージョン移行のいずれかに時間を取られている
→ 特に厚い
dotnet-msbuild(18 スキル)とdotnet-test(20 スキル)の恩恵を受けやすい - Microsoft 公式のワークフローを AI エージェントに載せたい → CODEOWNERS・eval.yaml・ダッシュボードによる品質管理体制が備わっている
初手のアクションとしては、先ほどのフェーズ別マッピングで自プロジェクトに該当する 1 プラグインを選び、Copilot CLI か Claude Code に /plugin marketplace add dotnet/skills と /plugin install <plugin>@dotnet-agent-skills を実行するのが最短です。Azure 上の .NET アプリを扱うプロジェクトであれば、microsoft/skills の該当スキルを補完として並行導入する運用が現実的です。
.NET Skills(英語圏で dotnet skills と表記されるケースを含む)は「AI コーディングエージェントを .NET 開発の現場で使いこなすための Microsoft 公式レール」です。動作検証を伴わないドキュメントベースの整理に基づく採用判断ではありますが、リポジトリ属性(archived=false / fork=false)と品質ガードレールを併せて確認すれば、初見エンジニアでも「導入する / しない」の意思決定に踏み切れる材料は揃っています。まずは 1 プラグインから、業務での再現性を検証してみてはいかがでしょうか。



