health-check

/health-check — 8 次元プロジェクト評価

概要

8 つの各次元を A〜F で評価し、評価の根拠となった具体的なデータポイントを示したうえで、GPA にまとめるデータ主導の健全性評価を実行します。直感は評価ではありません。各次元では MCP ツールまたは CLI コマンドを使い、A 未満の評価にはすべて、優先順位と必要な工数の見積もりを含む具体的な改善策を提示します。「OrderService、PaymentProcessor、ShippingCalculator のテストクラスを追加する」は実行可能ですが、「テストカバレッジを改善する」は実行可能ではありません。

このスキルは、キットの標準評価システムを管理します。詳細な評価基準、GPA スケール、レポートテンプレートは references/grading-rubric.md にあります。評価の実施時には、このファイルを読み込んでください。

口調は診断的で、懲罰的ではありません。C 評価は改善への道筋であり、失敗ではありません。

使用する場面

• 不慣れなプロジェクトや新しいプロジェクトへのオンボーディング時 — ベースラインを設定します
• 「このプロジェクトの健全性は？」「このプロジェクトを評価して」「コードベースをレビューして」「成績表」
• リリース前の品質ゲート、または月次・四半期のメンテナンスレビュー
• クリーンアップスプリント（/de-sloppify）の後 — 進捗を示すために再評価します
• 技術的負債の優先順位付け — 評価が最も低い次元に、次のスプリントで取り組みます

手順

ステップ 1：範囲を選択する

シナリオ	次元
全体評価（オンボーディング、リリース前、月次レビュー）	8 つすべて
簡易チェック（スプリント中間のチェックポイント、デモ前、マージ後）	1〜4 のみ
大規模なリファクタリング後	1（ビルド）、3（アーキテクチャ）、4（テスト）
依存関係の更新後	1（ビルド）、7（セキュリティ）
クリーンアップスプリント後	クリーンアップした次元のみ再評価

ステップ 2：各次元を評価する

評価基準を確認するため、references/grading-rubric.md を読み込んでから、各次元のデータを収集します。コード品質を深く評価する次元については、code-review スキルを使って code-reviewer エージェントに委任してください。

#	次元	データソース
1	ビルドの健全性	dotnet build --no-restore — エラーと警告
2	コード品質	MCP detect_antipatterns — summary を読み取り、確信度の高いもののみ評価
3	アーキテクチャ	MCP get_project_graph + detect_circular_dependencies（プロジェクトおよび型）
4	テストカバレッジ	MCP get_test_coverage_map — 最初に applicable を確認（行カバレッジではなく、構造上の指標）
5	デッドコード	MCP find_dead_code(scope: "solution") — 確信度の高いものを評価し、conventionFiltered は無視
6	API サーフェス	MCP get_public_api + find_references — 過剰な公開、戻り値の型の一貫性
7	セキュリティ態勢	dotnet list package --vulnerable --include-transitive + シークレット／認証のスポットチェック（詳細調査：/security-scan）
8	ドキュメント	公開 API の XML ドキュメントの網羅率 + README の最新性

ステップ 2.5：トリアージゲート（評価を付ける前に実施）

検出ツールの出力は証拠であり、評価そのものではありません。ノイズの多い件数が誤った評価に変わるのを防ぐため、すべての検出結果をまずこのゲートに通してください。

1. 違反リストではなく summary を読みます。 リストが途中で切り詰められていても、summary.byId は完全です。切り詰められたリストをサンプルとして使い、全体に当てはめて推測してはいけません。
2. suppressed を除外します。 抑制された件数と summary.suppressionConfig をレポートに記録し、抑制状況を見えるようにします。
3. medium は保留にします。 これらはレビュー対象であり、評価の入力にはしません。カテゴリごとに要約し、修正したり件数に含めたりしないでください。
4. high のみ評価します。 これらは状況にかかわらず誤りです。
5. 不変条件を確認します。 対象リポジトリの CLAUDE.md に意図的な仕様として記載されている内容とシグナルが矛盾する場合は、不変条件を優先します。評価する前に確認してください。
6. 断定する前に読みます。 実際に開いていない検出結果について説明してはいけません。すべてを開けない場合は、確認できたものを報告し、その旨を明記してください。

作業を進めながら、references/grading-rubric.md のトリアージ表に記入してください。表を埋められない場合、その次元はまだ評価できる状態ではありません。

ステップ 3：評価と集計

評価基準のしきい値を厳密に適用し、決して相対評価にしないでください（「この規模のプロジェクトとしてはかなり良い」という考え方で基準は損なわれます。警告が 15 件なら、プロジェクトの規模にかかわらず評価は C です）。GPA（A=4.0 … F=0.0）に換算し、実際に評価した項目のみを平均してください。「未評価」と記された項目は GPA の対象から除外し、F として採点しないでください。

ステップ 4：レポート

references/grading-rubric.md のテンプレートに従ってレポートカードを作成してください。主な所見を記載した評価表、総合 GPA、優先度付きの推奨事項（それぞれ対象の型／ファイル、優先順位、工数の見積もりを含む）を記載します。以前のレポートがある場合は、推移の比較表を追記してください。

例

User: /health-check

Claude: Running full 8-dimension assessment...

| Dimension | Grade | Key Finding |
|-----------|-------|-------------|
| Build Health | A | 0 errors, 2 warnings |
| Code Quality | B | 3 high-confidence findings in 4.2K lines; 31 medium untriaged |
| Architecture | A | Clean direction, 0 cycles |
| Test Coverage | Not assessed | Integration-driven suite — structural metric invalid |
| Dead Code | B | 5 unused methods (79 convention-discovered, not counted) |
| API Surface | B | 2 overexposed service types |
| Security | A | 0 vulnerable packages |
| Documentation | D | 12/30 public APIs documented |

Overall GPA: 3.1 (B) — averaged over 7 graded dimensions.

Triage: 44 AP005 raw → all log-and-rethrow wrappers (medium); 2 AP004 real.

Priority: (1) `SystemSeeder` → `TimeProvider`, ~15 min; (2) XML docs on the 8
endpoint classes, ~1 day; (3) review the 44 catch blocks or suppress by path.

関連項目

• references/grading-rubric.md — 評価基準、GPA の尺度、レポートテンプレートの正本
• /de-sloppify — ヘルスチェックで見つかった問題のクリーンアップパイプライン
• /security-scan — ディメンション 7 の詳細な 6 層スキャン
• /code-review — 変更ごとのレビュー（このスキルではプロジェクト全体を評価します）
• /verify — 変更セットの合否を判定するパイプライン。評価形式の審査ではありません