quality-ci

.NET 品質 CI

対象となる状況

• CI に .NET のコード品質ゲートを追加、または強化する場合
• .NET リポジトリ向けのアナライザー、カバレッジ、ミューテーションテスト、アーキテクチャテストのツールを選定する場合
• .editorconfig、dotnet format、警告ポリシーを標準化する場合

価値

• コード、ドキュメント、設定、テスト、CI、レビュー成果物など、具体的なプロジェクト差分を作成します
• 明示的な計画、検証、最終確認のスキルを活用して、曖昧さを減らします
• 再利用可能なプロジェクトコンテキストを残し、今後の作業をより迅速かつ安全にします

使用しない状況

• .NET 以外のリポジトリ
• .NET の品質スタックに関する選定を伴わない、一般的な CI/CD のガイダンス
• 品質ゲートを変更しない、フレームワーク固有のテスト作成

入力

• 最も近い AGENTS.md
• 現在のリポジトリルートの .editorconfig と MSBuild プロパティ
• 現在の CI ワークフローとパッケージ参照
• 使用中のテストランナーモデル：VSTest または Microsoft.Testing.Platform

クイックスタート

1. 最も近い AGENTS.md を読み、対象範囲と制約を確認します。
2. 成果が許容できるものになるまで、このスキルの Workflow を Ralph Loop で実行します。
3. 具体的な成果物と検証の証拠を含めて、Required Result Format で返します。

ワークフロー

1. リポジトリ固有のベースラインから始めます：
   • リポジトリルートの .editorconfig
   • dotnet format --verify-no-changes
   • EnableNETAnalyzers、AnalysisLevel、警告ポリシーを明示した SDK アナライザー
2. 実際の不足を補う場合に限り、サードパーティ製アナライザーを追加します：
   • StyleCopAnalyzers
   • Roslynator
   • Meziantou.Analyzer
   • xUnit、MSTest、TUnit などのフレームワークアナライザー
3. 品質ゲートを目的別に分けます：
   • フォーマットとスタイル
   • 正確性と静的解析
   • カバレッジとレポート
   • アーキテクチャルール
   • セキュリティスキャン
   • ミューテーションテスト
4. 複雑さには、複合的なアプローチを使います：
   • CA1502 によるしきい値設定
   • AGENTS.md による保守性の制限
   • アーキテクチャテスト
   • リスクに応じたカバレッジとミューテーションテスト
5. AGENTS.md と CI で責任範囲を明確にします：
   • フォーマットに使うコマンド
   • 解析に使うコマンド
   • カバレッジ測定に使うコマンド
   • テストが使用するランナーモデル
6. .NET コードを変更した後は、エージェントがリポジトリの品質チェックを実行できる状態にします：
   • フォーマット
   • ビルド
   • 解析
   • 対象を絞ったテスト
   • より広範なテスト
   • 設定されている場合は、カバレッジ測定とレポート生成
   • リポジトリで実際に有効化されている場合に限り、追加の設定済みゲート
7. 可能な場合は、ツール固有のセットアップを専用スキルに任せます：
   • format
   • code-analysis
   • analyzer-config
   • stylecop-analyzers、roslynator、meziantou-analyzer などのアナライザーパックスキル
   • eslint、stylelint、htmlhint、webhint、biome、sonarjs、metalint、chous など、.NET と Node を併用するリポジトリ向けのフロントエンドアセット品質スキル
   • coverlet、reportgenerator などのカバレッジ／レポートスキル
   • netarchtest、archunitnet、codeql などのアーキテクチャ／セキュリティスキル
8. 責任範囲が重複し、競合するツールの併用を避けます。意見の強いフォーマッターを追加する場合は、dotnet format を置き換えるのか、補完するのかを定義します。

テスト出力の予算

• ネイティブランナーの進捗表示と ANSI を有効にしてください（対応する MTP／TUnit ランナーでは --progress on --ansi on）。ローカルでは PTY を使用してください。進捗の再描画をモデルコンテキストに再生しないでください。VSTest で MTP のスイッチを使わず、検出されたランナーのフラグを使用してください。
• 警告とエラーに加えて、最後にサマリーを 1 つだけ表示してください（件数、所要時間、終了コード）。テスト専用のコンソールログは Warning に設定してください。Information／Debug／Trace、成功したテストの出力、想定された負のテストのノイズはコンテキストに含めないでください。ビルドの詳細度を下げるだけでは、アプリケーションのログはフィルターされません。
• 失敗、クラッシュ、起動エラー、タイムアウト時には、失敗したテスト／リソース、根本例外、関連するスタックフレームを表示してください。重複を除き、診断ツールの応答は 80 行または 8 KiB のいずれか早い方を上限としてください。標準出力／標準エラー、ホストログ、ブラウザーのコンソール履歴、DOM／HTML、TRX、クラッシュ時のアーティファクトを自動的にダンプしないでください。
• 必要な診断情報は、サイズ制限付きまたはローテーションされるアーティファクトに保持し、そのリンクを示してください。正確な失敗箇所／相関情報で検索し、範囲を限定した抜粋を読み取ってください。ログ全体を読み込まないでください。ノイズの多い出力はツールに渡す前に取得／フィルターし、実際の終了コードを保持し、切り詰めたことを明示してください。実際の動作状況を監視してください。出力がないことだけではハングしたとは判断できません。

設定がない場合のブートストラップ

品質ゲートが要求されているものの設定されていない場合は、次の手順で有効化してください。

1. .csproj、Directory.Build.*、.editorconfig、ツールマニフェスト、CI ワークフローファイルを調べ、現在の状態を検出します。
2. ゲートのカテゴリごとに、オーナーとなるコマンドを 1 つだけ選択します（format、analyze、test、coverage、architecture、security、mutation）。
3. 必要最小限のパッケージまたはツールをインストールし、チェックイン対象の設定ファイルをコミットします。
4. 明示的なコマンドを指定して、ゲートを AGENTS.md と CI の両方に組み込みます。
5. 最初の検証を実行し、対応可能な失敗を修正してから再実行します。
6. 新たに有効化され、合格した場合は status: configured を返します。問題が残っていてもベースラインが改善した場合は status: improved を返します。
7. ゲートがこのリポジトリの対象外であることが明示されている場合に限り、status: not_applicable を返します。

提供する成果物

• 文書化された .NET 品質ベースライン
• 明示的かつ再現可能な CI コマンド
• リポジトリのランナーモデルに合ったアナライザーとカバレッジの選択
• エージェントと CI 向けに文書化された変更後の品質確認
• 特記事項を明示したうえで、デフォルトではオープンソースかつ無料のツールを選択

検証

• リポジトリルートの .editorconfig を、ルールごとの重大度を定めるデフォルトの信頼できる情報源とする
• フォーマット、アナライザー、カバレッジのコマンドがランナーと互換性を持つ
• 追加するツールが互いに重複せず、それぞれ異なる不足を補う
• 複雑性とアーキテクチャのポリシーが暗黙ではなく、明示されている
• 品質ゲートが設定されている場合、.NET コードの変更にはテスト以外のチェックへの合格も求める
• ライセンスまたはホスティングに関する注意事項は、ツールをデフォルトのゲートにする前に文書化する

Ralph Loop

ドキュメント、アーキテクチャ、テスト、ツールの作業を含むすべてのタスクで Ralph Loop を使用してください。

1. まず計画を立てます（必須）。
   • 現在の状態を分析する
   • 目標、制約、リスクを定義する
   • 詳細な実行計画を書く
   • 最後に実行する最終検証スキルを、順序と理由とともに列挙する
2. 計画した手順を 1 つ実行し、具体的な差分を作成します。
3. 結果をレビューし、次に行うべき具体的な修正を含めて所見を記録します。
4. 小さな単位で修正し、関連するチェックまたはレビューを再実行します。
5. 反復ごとに計画を更新します。
6. 結果が許容できる状態になるか、明示的な例外だけが残るまで繰り返します。
7. 依存関係が不足している場合は、ブートストラップするか、明確な理由と代替手段を添えて status: not_applicable を返します。

必須の結果形式

• status: complete | clean | improved | configured | not_applicable | blocked
• plan: 簡潔な計画と現在の反復ステップ
• actions_taken: 実施した具体的な変更
• validation_skills: 最後に実行したスキル、または実行を見送った理由
• verification: コマンド、チェック、またはレビューによる検証の概要
• remaining: 未解決の主な項目、または none

実行を伴わないセットアップのみの依頼では、status: configured と正確な次のコマンドを返してください。

リファレンスを読み込む

• references/editorconfig-and-ci.md
• references/quality-toolchain.md
• references/workflows.md
• references/checklist.md

依頼の例

• 「この .NET リポジトリに最適な OSS CI スタックを定義してください。」
• 「.NET アナライザー、カバレッジ、ミューテーションテストのガイダンスを追加してください。」
• 「.NET ソリューションの .editorconfig と CI の設定を一致させてください。」