codeprobe

コードレビューオーケストレーター

読み取り専用の制約

このスキルは、レビュー対象のコードベースに対して厳密に読み取り専用です。 ユーザーのソースツリー内のファイルを変更、書き込み、編集、削除してはいけません。レビュー対象のプロジェクトに副作用をもたらすコマンド（npm install、pip install、git コミット、データベースの変更など）を実行してはいけません。修正が必要な場合は、ユーザーが別途実行できる、コピー＆ペースト可能な修正プロンプトを生成してください。

文書化されている唯一の例外 — レポート成果物： /codeprobe audit の終了後、オーケストレーターは現在の作業ディレクトリに ./codeprobe-reports/<project>-<cmd>-<timestamp>.md という単一の Markdown レポートを書き込みます（例：./codeprobe-reports/growth-engine-audit-2026-04-23-221047.md）。これはこのスキル独自の出力であり、レビュー対象のコードを変更するものではありません。それ以外の書き込みは、どこに対しても許可されていません。

Git も読み取り専用です： /codeprobe diff は読み取り専用の git コマンド（git diff、git merge-base、git ls-files、git rev-parse、git status）を実行できます。リポジトリや作業ツリーを変更する git コマンド（コミット、チェックアウト、スタッシュ、リセット、フェッチ、プルなど）は、絶対に実行してはいけません。

この制約への違反は、ユーザーの要求にかかわらず、決して許容されません。

---

1. コマンドの振り分け

ユーザーの入力を解析し、サブコマンドと対象パスを抽出してください。入力形式は次のとおりです。

/codeprobe [subcommand] [path]

振り分け表

コマンド	動作	呼び出すサブスキル
/codeprobe audit <path>	完全な監査 — ビジュアルな健全性ダッシュボード（カテゴリ別スコア、コードベースの統計、注目箇所）に続いて、修正プロンプト付きの詳細な P0～P3 の指摘事項を提示	すべての利用可能なサブスキル + file_stats.py
/codeprobe solid <path>	SOLID 原則のみを分析	codeprobe-solid
/codeprobe security <path>	セキュリティ監査のみ	codeprobe-security
/codeprobe smells <path>	コードの臭いのみを検出	codeprobe-code-smells
/codeprobe architecture <path>	アーキテクチャのみを分析	codeprobe-architecture
/codeprobe patterns <path>	デザインパターンのみを分析	codeprobe-patterns
/codeprobe performance <path>	パフォーマンス監査のみ	codeprobe-performance
/codeprobe errors <path>	エラーハンドリング監査のみ	codeprobe-error-handling
/codeprobe tests <path>	テスト品質の監査のみ	codeprobe-testing
/codeprobe framework <path>	フレームワークのベストプラクティスのみ	codeprobe-framework
/codeprobe quick <path>	上位 5 件の問題 — すべてのサブスキルをスキャンモードで実行し、上位 5 件の詳細を生成	すべての利用可能なサブスキル
/codeprobe diff [base]	ベースブランチと比較した変更ファイルの PR 形式のレビュー（デフォルト：main、フォールバック：master）— セクション 4A を参照	変更ファイルに対象を絞った、9 つすべてのサブスキル
/codeprobe report	前回の監査からレポートを生成	（フェーズ 3 — セクション 10 を参照）

デフォルトの動作

• サブコマンドが指定されていない場合：ユーザーに希望する内容を尋ねてください。利用可能なコマンドを提示してください。
• パスが指定されていない場合：現在の作業ディレクトリを使用してください。
• フェーズ 3 のスタブ：ユーザーが report を実行した場合は、セクション 10 のスタブメッセージで応答してください。

---

2. スタックの自動検出

いずれかのサブスキルに振り分ける前に、対象パスの技術スタックを検出してください。これにより、読み込んでサブスキルに渡すリファレンスガイドが決まります。

検出手順

1. Glob を使用して、対象パスのファイル拡張子をスキャンします（再帰的に、適切な深さまで）。
2. 以下の検出ルールを適用します。複数のスタックが同時に該当する場合があります。

シグナル	検出されるスタック	読み込むリファレンス
.php ファイル	PHP / Laravel	references/php-laravel.md
.js、.ts、.jsx、.tsx ファイル	JavaScript / TypeScript	references/javascript-typescript.md
.py ファイル	Python	references/python.md
.jsx、.tsx ファイルがあり、next.config.* が存在する	React / Next.js	references/react-nextjs.md
.sql ファイルまたは migrations/ ディレクトリ	SQL / データベース	references/sql-database.md
routes/ ディレクトリまたは API ルートのパターン	API 設計	references/api-design.md

3. 検出したスタックごとに、対応するリファレンスファイルが存在することを確認します。存在しない場合は、何も通知せずにスキップします。
4. サブスキルに渡す、該当するリファレンスファイルの絶対パスをすべて収集します。リファレンスの内容をオーケストレーター自身のコンテキストに読み込まないでください。サブエージェントが各自の領域に関連するリファレンスを直接読み込むことで、すべてのコンテキストウィンドウを簡潔に保てます。

リファレンスの解決

リファレンスは、このスキルのディレクトリ内にある references/ ディレクトリにあります。ユーザーのプロジェクトではなく、この SKILL.md ファイルの場所を基準にパスを解決し、作業ディレクトリがユーザーのプロジェクトであるサブエージェントに渡す前に、絶対パスに変換します。

{this-skill's-directory}/references/{reference-file}.md

リファレンスファイルが存在しない場合は、そのまま続行します。リファレンスが見つからないことを理由にレビューを中止しないでください。

---

3. 設定の読み込み

プロジェクトのルート（対象パスまたはその祖先ディレクトリ）に .codeprobe-config.json ファイルがあるか確認します。

設定スキーマ

{
  "severity_overrides": {
    "long_method_loc": 50,
    "large_class_loc": 500,
    "deep_nesting_max": 4,
    "max_constructor_deps": 6
  },
  "skip_categories": ["codeprobe-testing"],
  "skip_rules": ["SPEC-GEN-001"],
  "framework": "laravel",
  "extra_references": [],
  "report_format": "markdown"
}

設定の動作

• 存在しない場合：すべてのデフォルト設定が適用されます。エラーにはなりません。
• severity_overrides：サブスキルに渡し、それに応じてしきい値を調整します。
• skip_categories：audit モードまたは quick モードであっても、指定されたサブスキルは実行しません。
• skip_rules：サブスキルに渡し、一致する ID の検出結果を抑制します。
• framework：設定されている場合、そのフレームワークの自動検出をスキップし、対応するリファレンスを強制的に読み込みます。その他の自動検出は引き続き実行します。
• extra_references：追加のリファレンスファイルパスを読み込み、サブスキルに渡します。
• report_format：出力形式の設定です（デフォルト：markdown）。

---

4. サブスキルの実行

コンテキストの準備（各サブスキルの実行前に1回）

サブスキルを呼び出す前に、オーケストレーターが共有コンテキストを準備します。オーケストレーター自身はソースファイルの内容を読みません。各サブエージェントが担当領域に必要なファイルを読みます。これにより、オーケストレーターのコンテキストを簡潔に保ち、コードベースがすべてのエージェントのプロンプトに重複して含まれるのを防ぎます。

1. shared-preamble.md（このスキルのディレクトリ内）から共有プリアンブルを読み込みます。ここには、すべてのサブスキルで共有する出力仕様、実行モード、制約が記載されています。

2. 対象パスのファイルマニフェストを作成します。

   • 推奨：python3 scripts/file_stats.py <target_path> を1回実行し（スクリプトのパスはこの SKILL.md を基準に解決）、ファイルごとの出力からマニフェストを作成します。
   • 代替手段（Python 3 が利用できない場合）：ソースファイル（.ts、.tsx、.js、.jsx、.py、.php、.vue、.sql、.css、.scss）と、next.config.*、package.json、composer.json、requirements.txt、.env.example などの設定ファイルを Glob で検索し、wc -l で行数を取得します。
   • 除外対象（どちらの方法でも）： node_modules、vendor、.git、__pycache__、.next、dist、build、.venv、venv、env、codeprobe-reports/ を除外します（同梱スクリプトの SKIP_DIRS に一致）。
   • マニフェストには、検出されたスタックとともに、{filepath} ({LOC} lines) の形式で1行につき1ファイルを記載します。

3. 参照ファイルのパスを収集します（セクション2のスタック検出時にすでに解決済み）。内容ではなくパスのみを収集します。

4. 各サブスキルの SKILL.md を読み込み、検出ロジックをエージェントのプロンプトにインラインで含められるようにします。サブスキルは兄弟ディレクトリにあります。この SKILL.md の場所を基準に ../codeprobe-{name}/SKILL.md を解決してください。サブスキル名だけでエージェントがサブスキルを解決できるとは限りません。エージェントにそのスキルが登録されていない可能性があるため、内容をインラインで含めることが、確実に渡す唯一の方法です。

呼び出しプロトコル

実行する各サブスキルについて、次の内容を含むプロンプトを指定して Agent を起動します。

1. 共有プリアンブル（shared-preamble.md から）：出力仕様、モード、制約。
2. サブスキルの SKILL.md の内容を、次のマーカーの間にインラインで含めます。

   === SUB-SKILL: codeprobe-{name} ===
   {content of ../codeprobe-{name}/SKILL.md, frontmatter stripped}
   === END SUB-SKILL ===
   

   エージェントには次のように伝えます。「上記のサブスキルを実行してください。オーケストレーターが読み込む内容をすべてすでに提供しているため、Standalone Mode のセクションは無視してください。」
3. モード：full または scan のいずれか。
4. ファイルマニフェスト：パス、行数、検出されたスタック。エージェントには次のように指示します。「検出テーブルに関連するファイルを調べるには Read/Grep/Glob を使用してください。すべてのファイルを無差別に読むのではなく、担当領域に必要なものを対象にしてください。」
5. 参照ファイルのパス：該当する参照ガイドの絶対パスと、次の指示：「重大度と修正プロンプトを確定する前に、調査結果に関連する参照資料を読んでください。」
6. 設定の上書き：.codeprobe-config.json の重大度の上書きとスキップルール。
7. 対象パス：対象プロジェクトのルートが分かるようにします。
8. サブスキル固有の事前計算済みスクリプト出力（該当する場合）：
   • codeprobe-architecture の場合：エージェントの起動前に、Bash 経由で python3 scripts/dependency_mapper.py <target_path> を実行し、JSON 出力を取得します。追加のコンテキストブロックとして === DEPENDENCY_GRAPH === ... === END DEPENDENCY_GRAPH === のラベルを付けて渡します。サブスキルはこれを循環依存検出の正解情報として使用します。Python 3 が利用できない場合、またはスクリプトが失敗した場合は、このブロックを省略します。サブスキルは LLM ベースのインポート追跡にフォールバックします。
   • codeprobe-performance の場合：scripts/complexity_scorer.py の出力が利用可能であれば（任意）、=== COMPLEXITY_SCORES === ... === END COMPLEXITY_SCORES === として渡します。

サブスキル自身の SKILL.md には、その領域固有の検出ロジックのみが記載されています。その他の共有コンテキスト（出力形式、モード、ファイルマニフェスト、参照パス、事前計算済みスクリプトデータ）は、オーケストレーターのプロンプトから渡されます。サブエージェントはソースファイルを自分で読み込みます。

各サブスキルから返された調査結果を、標準出力仕様（セクション5）の形式で収集します。

実行モード

モード	使用元	動作
full	/codeprobe audit、/codeprobe diff、/codeprobe solid など	完全な分析を実行し、すべての指摘事項を返します
scan	/codeprobe quick	同じ完全な分析を実行しますが、カテゴリごとの重大度別件数と、出力契約の全フィールドを含む上位5件の候補指摘事項だけを返します（どちらのモードでも分析コストは同じです。scan モードでは出力を絞り込むため、オーケストレーターは2回目のパスを実行せずにカテゴリをまたいで候補を順位付けできます）

実行順序

• 並列処理： サブスキルエージェントは互いに独立しており、重複排除とスコアリングはすべてのエージェントから結果が返された後にのみ行います。該当するサブスキルエージェントはすべて、単一のメッセージで並列に起動し、1つずつ実行しないでください。以下に示す固定のカテゴリ順はレポート表示用であり、実行順ではありません。（例外：Claude.ai の縮退モード（セクション9）では、サブエージェントを利用できないため順次実行します。）
• 起動前： scripts/dependency_mapper.py を使って依存関係グラフを事前に計算し（codeprobe-architecture の Invocation Protocol ステップ8）、マニフェストとコードベース統計のために scripts/file_stats.py を実行します（Python 3 が利用できない場合は適宜スキップします）。
• /codeprobe audit：9つすべてのサブスキルを full モードで起動します。表示順：codeprobe-security、codeprobe-error-handling、codeprobe-solid、codeprobe-architecture、codeprobe-patterns、codeprobe-performance、codeprobe-code-smells、codeprobe-testing、codeprobe-framework。すべての指摘事項を収集します。重複排除を適用します（セクション7A）。重大度別件数からカテゴリスコアを算出します。ファイルごとに指摘事項を集計し、フラグが立ったカテゴリの種類数で順位付けしてホットスポットを算出します。
• /codeprobe quick：9つすべてのサブスキルを scan モードで（並列に）起動します。各サブスキルの上位5件の候補を収集します（出力契約の詳細をすでにすべて含んでいます）。候補全体を重大度順（critical > major > minor > suggestion）に順位付けし、同率の場合はカテゴリの重み（セクション7）で決着させます。全体の上位5件を選択して出力します。これは単一パスであり、再実行はありません。

利用可能なサブスキル

1. codeprobe-security — セキュリティ脆弱性の検出
2. codeprobe-error-handling — エラー処理とレジリエンス
3. codeprobe-solid — SOLID 原則の分析
4. codeprobe-architecture — アーキテクチャ分析
5. codeprobe-patterns — デザインパターンのアドバイザー
6. codeprobe-performance — パフォーマンスとスケーラビリティ
7. codeprobe-code-smells — コードスメルの検出
8. codeprobe-testing — テストの品質とカバレッジ
9. codeprobe-framework — フレームワーク固有のベストプラクティス

---

4A. 差分レビュー（/codeprobe diff [base]）

PR スタイルのレビューです。ベースブランチと比較して変更された箇所だけを分析し、レビュー作業をマージ予定のコードに集中させます。

前提条件

• Git リポジトリが必要です：git rev-parse --is-inside-work-tree で確認してください。リポジトリ内でない場合は、差分レビューには Git が必要であることをユーザーに伝え、代わりに /codeprobe audit を提案してください。
• Git の使用は厳密に読み取り専用です（上記の READ-ONLY CONSTRAINT を参照）。

ベースの解決

1. ユーザーがベースの ref を指定した場合は、それを使用します（git rev-parse --verify <base> で確認してください）。
2. 指定がない場合は、まず main、次に master を試します。
3. どちらも解決できない場合は、比較対象のベースをユーザーに尋ねてください。

変更ファイルの収集

1. マージベースを計算します：MB=$(git merge-base <base> HEAD)。ベースの先端ではなくマージベースと比較することで、このブランチの変更のみをレビューできます。これは、ベースが更新されていても PR の差分と一致します。
2. 変更ファイル：git diff --name-status $MB（意図どおり、未コミットの作業ツリーの変更も含まれます。リリースされる内容をレビューします）。削除されたファイル（ステータス D）は除外します。
3. 未追跡ファイル：git ls-files --others --exclude-standard。
4. 両方のリストをマニフェストに使用するソース／設定ファイルの拡張子（セクション 4）で絞り込み、同じディレクトリ除外を適用します。
5. ファイルごとの変更行範囲：git diff -U0 $MB -- <file> から @@ ハンクヘッダー（新しいファイル側）を解析します。未追跡ファイルは全体を変更箇所として扱います。
6. 結果のリストが空の場合は、「<base> に対してレビュー可能な変更はありません」と報告して終了します。求められていない全体監査には切り替えないでください。

実行

標準フロー（セクション 2〜4）を実行し、次の点を調整します。

• ファイルマニフェストには、変更行範囲を注記した変更済み／未追跡ファイルのみを含めます。
• 9 つすべてのサブスキルを full モードで並列に起動します。各エージェントへのプロンプトに、次の文を追加します：「これは差分のレビューです。すべての指摘はマニフェスト内のファイルに紐付け、注記された変更行を優先してください。コンテキストを確認するために周辺ファイルや関連ファイルを Read しても構いませんが、変更されていないファイルの指摘は報告しないでください。」
• 依存関係グラフ（dependency_mapper.py）は引き続きプロジェクト全体を対象に実行します。変更されたインポートが、変更されていないファイルを経由して循環を作る可能性があるためです。
• 重複排除（セクション 7A）とスコアリング（セクション 7）は通常どおり適用し、差分に関する指摘のみを対象に計算します。ホットスポットの計算とコードベースの統計は、コードベース全体の状態を示すもので差分の内容ではないため、省略します。

出力

セクション 8（/codeprobe diff サブセクション）を参照してください。差分の出力には templates/pr-review-comment.md を使用します。

---

5. 出力仕様

すべてのサブスキルによるすべての指摘には、次のフィールドを含める必要があります。

フィールド	必須	説明
id	はい	{PREFIX}-{NNN} 形式の一意な識別子（例：SRP-001、SEC-003）
severity	はい	critical、major、minor、suggestion のいずれか
severity_rationale	はい	この重大度に該当し、1 段階下ではない理由を説明する 1 文。
location	はい	ファイルパス＋行範囲（例：src/UserService.php:45-67）
problem	はい	問題を説明する 1 文
evidence	はい	コードからの具体的な証拠。該当する行を引用します
suggestion	はい	問題を修正する方法
fix_prompt	はい	修正を適用するためにユーザーが Claude Code に渡せる、コピー＆ペースト可能なプロンプト
refactored_sketch	いいえ	改善後のコードを示す任意のコードスニペット

指摘の形式例

### SRP-001 | Major | `src/UserService.php:45-67`

**Problem:** UserService violates Single Responsibility — handles authentication, email sending, and database queries in one class.

**Severity rationale:** Major (not Minor) because three unrelated responsibilities are concentrated in one class on a critical auth path — refactoring will touch every caller; not Critical because the code works correctly today, this is a maintainability risk, not a production defect.

**Evidence:**
> Lines 45-50: `public function authenticate($credentials) { ... }`
> Lines 52-60: `public function sendWelcomeEmail($user) { ... }`
> Lines 62-67: `public function findByUsername($name) { ... }`

**Suggestion:** Extract email logic into a dedicated `UserMailer` service and database queries into a `UserRepository`.

**Fix prompt:**
> Refactor `src/UserService.php` to follow Single Responsibility Principle: extract `sendWelcomeEmail()` into a new `UserMailer` class and `findByUsername()` into a `UserRepository` class. Keep `authenticate()` in `UserService` and inject the new dependencies.

---

6. 重大度レベル

レベル	優先度	意味	例
Critical	P0	本番環境で被害を引き起こす、確認済みのバグ、悪用可能なセキュリティ脆弱性、またはデータ損失／破損のリスク	ユーザー入力を使った SQL インジェクション、データ変更エンドポイントの認証漏れ、データ破損を引き起こす競合状態、主要な処理経路での未処理クラッシュ、複数段階の書き込みにおける DB トランザクションの欠落
Major	P1	直ちに本番環境で不具合が発生するものではないものの、リスクを高める、保守性、信頼性、またはスケーラビリティ上の重大な問題	重要なビジネスロジックのテスト不足、巨大なクラス、コードの重複、外部呼び出しのエラー処理不足、N+1 クエリ、入力検証の不足
Minor	P2	長期的な健全性のために対処する価値のある、リスクの低いコードの問題	マジックナンバー、深いネスト、わかりにくい命名、エッジケースのテスト不足、冗長なエラー詳細
Suggestion	P3	あれば望ましい改善案。無視しても実質的なリスクはありません	パターンを活用する機会、スタイルの改善、推測に基づく汎用化

重大度のガードレール

以下は決してクリティカルではありません。最大でもメジャーとして分類してください。

• テストの不足（重要なビジネスロジックであっても）
• コードの重複や大規模なクラス／ファイル
• あらゆる種類のコードスメル
• フレームワークの規約違反
• ドキュメント、コメント、型アノテーションの不足

クリティカルは、以下の場合にのみ使用します。

• 確認済みのバグ（誤った結果を返す、またはクラッシュするコード）
• 悪用可能なセキュリティ脆弱性（インジェクション、認証の回避、証拠のある IDOR）
• データ損失または破損のリスク（トランザクションの欠如、書き込み時の競合状態）
• 機密データの漏えい（コード内のシークレット、ログ内の認証情報）

サブスキルは、検出テーブルに指定された重大度を超えて検出事項をエスカレートしないでください。 テーブルに「メジャー」とある場合は、個別の事例が深刻に思えても、メジャーとして報告してください。オーケストレーターのスコア計算式では、各レベルの検出数が考慮されます。

---

7. スコアリング

すべての検出事項を収集した後、カテゴリごとのスコアと総合スコアを計算します。

カテゴリスコアの計算式

単一の重大度レベルがスコアを過度に支配しないよう、各ペナルティ要素には上限が設けられています。

crit_penalty  = min(50, critical_count * 15)
major_penalty = min(30, major_count * 6)
minor_penalty = min(10, minor_count * 2)

category_score = max(0, 100 - crit_penalty - major_penalty - minor_penalty)

提案はスコアに影響しません。

根拠： 減衰効果により、単一の重大度がスコアを最低点まで下げることを防ぎます。クリティカルな問題が4件あるカテゴリのスコアは50となり（0ではありません）、問題はあるものの、コードが完全に壊れているわけではないことを反映します。3つのレベルすべてを合わせたペナルティの最大値は90であるため、スコアが0になるには、すべての重大度にわたる極めて深刻な検出事項が必要です。

カテゴリの重み

カテゴリ	重み
セキュリティ	20%
SOLID	15%
アーキテクチャ	15%
エラー処理	12%
パフォーマンス	12%
テスト品質	10%
コードスメル	8%
デザインパターン	4%
フレームワーク	4%

9つすべてのカテゴリが有効です。重みの合計は100%です。

総合スコア

overall = sum(category_score_i * weight_i for each active category)

.codeprobe-config.json の skip_categories で一部のカテゴリが除外されている場合は、有効な重みの合計で割って正規化します。

overall = sum(category_score_i * weight_i for each active category) / sum(weight_i for each active category)

結果を [0, 100] の範囲に収めます。

スコアの解釈

範囲	ステータス
80-100	健全
60-79	要対応
0-59	クリティカル

---

7A. カテゴリ間の重複排除

スコアを計算する前に、複数のカテゴリから同じ問題を指摘している検出事項を重複排除します。

重複排除の手順

1. 指摘事項を場所ごとにグループ化します。 各指摘事項の location を {file}:{start_line} に正規化します。2 つの指摘事項は、同じファイルにあり、行範囲が重なる場合（つまり、start_line_A <= end_line_B かつ start_line_B <= end_line_A）、重複しています。

2. まず、本当の意見の相違がないか確認します。 重複排除の対象は「同じ問題を異なる視点から指摘したもの」であり、相反する推奨事項ではありません。重複する 2 つの指摘事項が相反する方向を示している場合（例：SOLID が抽象化の抽出を推奨する一方で、Performance がその抽象化によるオーバーヘッドを指摘する、Architecture が疎結合を推奨する一方で、Performance が局所性を推奨するなど）、重複排除しないでください。両方の指摘事項を重大度を下げずに残し、レポートの Conflicting Recommendations セクションに、トレードオフを明記した 1 行の注記とともに記載します。運用担当者が緊張関係を把握して判断できるようにしてください。ひとつを黙って選ぶと、人間の判断が必要な場面が隠れてしまいます。

3. 異なるカテゴリーに属する、残りの重複指摘事項のグループごとに、次の処理を行います。 a. 主要な指摘事項を選択します。 次の優先順位に従います。

   • 認証、インジェクション、データ漏えいに関するものは、セキュリティの指摘事項（SEC）を優先します
   • 例外や検証に関する問題は、エラーハンドリングの指摘事項（ERR）を優先します
   • クエリやキャッシュに関する問題は、パフォーマンスの指摘事項（PERF）を優先します
   • 構造上の違反は、SOLID の指摘事項（SRP/OCP/LSP/ISP/DIP）を優先します
   • レイヤーや境界に関する違反は、アーキテクチャの指摘事項（ARCH）を優先します
   • それでも判断できない場合は、ウェイト（Section 7）が高いカテゴリーを優先します b. 重複を削除します。 グループ内の主要ではない指摘事項をそれぞれ、指摘事項リストから完全に削除します。これらはレポート本文にも、各カテゴリーの重大度別件数にも含めません。（以前のバージョンのように、重複を suggestion に格下げすると、ノイズによって suggestion の件数が膨らむだけです。） c. 主要な指摘事項から相互参照します。 主要な指摘事項の suggestion フィールドに、Also flagged by: {重複したcategory:idのペアのリスト} を追加します。これにより、複数カテゴリーから指摘されたことが保持され（ホットスポットのランキングにも反映されます）、重複エントリも避けられます。 d. 削除件数を集計します。 削除した重複の総数を記録し、ダッシュボードの「削除された重複」行に報告します。

4. 重複排除の後、カテゴリーごとに重大度別の合計を再集計してから、スコアリングに進みます。

例

• 同じ場所で「Refresh bypasses quota」が SEC-007、ERR-011、FW-001 として見つかった場合：SEC-007 を残し（相互参照「Also flagged by: ERR-011, FW-001」）、ERR-011 と FW-001 を削除します。
• 同じファイルで「God component」が SRP-001、SMELL-001、ARCH-005 として見つかった場合：SRP-001 を残し（構造上の問題には SOLID の優先順位を適用）、その他を削除します。
• SRP-002 が「OrderService から PricingCalculator を抽出する」と提案し、同じ行で PERF-004 が「このホットパスはインラインのままにすべきです。間接化によってリクエストごとにメモリー割り当てのコストが発生します」と述べている場合：実際の意見の相違です。両方を残し、Conflicting Recommendations に記載します。

---

8. レポートのレンダリング

使用されたコマンドに基づいて、最終出力をレンダリングします。

/codeprobe audit — 完全監査レポート

templates/full-audit-report.md（Read で読み込み）にあるテンプレートを使って、保存するレポートファイル用の Markdown を組み立てます。ターミナル出力は要約です。「Report saved」の行だけでなく、ユーザーにはターミナル上で視覚的な要約を必ず表示してください。

ターミナルと保存ファイルの出力内容（必須）：

出力先	表示する内容	出力方法
ターミナル	ダッシュボード + エグゼクティブサマリー + 重大な指摘事項（詳細をすべて表示）+ 優先度順の修正項目（上位5件）+ 「Report saved」の行	アシスタントの応答に Markdown セクションをストリーミング
保存ファイル（./codeprobe-reports/<project>-<cmd>-<ts>.md）	すべて：ダッシュボード、エグゼクティブサマリー、重大／主要な指摘事項、軽微な指摘／提案の件数、優先度順の修正項目全件	Write ツールでプレーンな Markdown を書き込む

ターミナルを空のままにしたり、保存確認だけにしたりしてはいけません。過去の実行で Claude が保存行だけを出力した場合は、指示に従った処理フローに問題があります。以下の手順を順番に実行して修正してください。

手順

A. データを計算する（両方の出力先で共通）

1. セクション4に従ってサブスキルを実行し、指摘事項を収集して、セクション7Aに従って重複を除外します。
2. カテゴリ別スコア、全体スコア、ホットスポット、コードベース統計を算出します。
3. メモリ上に「レポートバンドル」を組み立てます：{dashboard_data, exec_summary, critical[], major[], minor_counts[], suggestion_counts[], fix_order[]}。

B. ターミナルに出力する（ユーザー向け — 以下を順番に、アシスタントの応答に Markdown として直接出力します）

ダッシュボードを Bash ツール経由で出力してはいけません。Claude Code の UI では Bash ツールの出力はデフォルトで折りたたまれ（+N lines (ctrl+r to expand)）、ダッシュボードが折りたたまれた部分に隠れてしまいます。ユーザーがすぐに確認できるように、通常のアシスタント応答の Markdown としてダッシュボードを出力してください。Ghostty や iTerm2 などの最新のターミナルでは、太字、インラインコードの強調表示、強調などが独自に適用されます。この方法で利用できる色付けはこれだけです。色が付かなくてもプレーンテキストで問題ありません。応答に ANSI エスケープシーケンスを埋め込んで無理に色を付けようとしてはいけません。

（scripts/render_dashboard.py は、Claude Code の外でユーザーが自分のシェルから監査を直接実行する際、標準出力が実際の TTY になる場合に使用できます。/codeprobe audit の処理フロー内から実行してはいけません。）

1. ダッシュボード（Markdown） — ダッシュボードのブロックをそのまま出力します。以下を含めます：タイトル行（## Code Health Report — {project}）、**Overall Health:** {score}/100 [{status_label}]、9行のカテゴリ別スコアの Markdown テーブル（列は Category | Score | Bar | Status、バーはバッククォートで囲み、スコアに比例する20文字の Unicode █／░を使用）、コードベース統計ブロック（ファイル数、LOC、バックエンド／フロントエンドの内訳、最大のファイル、テスト比率、コメント比率）、ホットスポットの一覧（最大3件）。Status 列のラベルはプレーンテキストとし、絵文字や角括弧を含めてはいけません。
2. エグゼクティブサマリー — 最も重要な指摘事項を取り上げた2～3文を記載します。
3. 重大な指摘事項 — 詳細 — 重大な指摘事項ごとに、ID、場所、問題、根拠、提案、修正プロンプトを記載します。最も重要な情報を示すセクションです。必ずターミナルに表示してください。
4. 優先度順の修正項目（上位5件） — 優先度順の修正項目全件から先頭5件を記載します。全件は保存ファイルを参照するよう案内してください。
5. 保存確認行 — --> Report saved to ./codeprobe-reports/{project}-{cmd}-{YYYY-MM-DD-HHMMSS}.md（絵文字なし、ASCII の矢印）。ターミナル出力の最後の行にします。

主要な指摘事項のテーブル、軽微な指摘／提案の件数、修正項目全件は、ターミナルに出力してはいけません。これらは保存ファイルに記載されるため、重複してターミナルに出すと出力が冗長になります。全体像を確認する場合は、保存ファイルを開くようユーザーに案内してください。

C. 保存ファイル用の Markdown を書き込む

1. templates/full-audit-report.md のプレースホルダーを使って、完全な Markdown を作成します。これには、ターミナルに出力されないセクション（重大な指摘事項の表、軽微な指摘事項と提案の件数、優先順位付けされた修正順の全項目）も含まれます。
2. ファイル名を {project}-{cmd}-{YYYY-MM-DD-HHMMSS}.md として決定します。
   • {project} — 対象パスを絶対パスに解決します（ユーザーがパスを指定していない場合は、現在の作業ディレクトリを使用します）。そのベース名を取得し、そのベース名がファイルを指している場合は拡張子を取り除きます。スラッグ化します（小文字にし、[^a-z0-9]+ に一致する連続部分を単一の - に置き換え、先頭と末尾の - を取り除きます）。スラッグが空になった場合は、unknown を使用します。
   • {cmd} — セクション 1 でルーティングされたサブコマンド（audit、quick、diff、security、solid、architecture、performance、errors、tests、smells、patterns、framework）を小文字にしたものです。
   • {YYYY-MM-DD-HHMMSS} — 現在の現地時刻です。
3. ./codeprobe-reports/ が存在することを確認します（存在しない場合は Bash で mkdir -p ./codeprobe-reports を実行します）。
4. Write ツールを使って、./codeprobe-reports/{project}-{cmd}-{YYYY-MM-DD-HHMMSS}.md に書き込みます。
5. 書き込みに失敗した場合（ファイルシステムが読み取り専用、アクセス許可がないなど）は、ターミナルに短いインラインの注記を表示します。ただし、サマリーを再出力してはいけません。

D. ターミナル出力の契約（必須要件）

• ターミナルには、次の順序で必ず出力します。ダッシュボード → 実行サマリー → 重大な指摘事項 → 修正順の上位 5 項目 → 「Report saved」行。
• 重大な指摘事項が 0 件の場合は、ダッシュボード、実行サマリー、1 行の「No critical issues found」注記、修正順の上位 5 項目（重大な指摘事項のみ）、保存確認を表示します。空の出力にはしません。
• レポートの保存に失敗しても、ターミナルにはサマリー全体を出力します。ファイルへの書き込みによってサマリーの出力を妨げてはいけません。
• テンプレートファイルが見つからない場合は、同じセクション順に従ってインラインで生成します。保存手順（C）は引き続き適用されます。

ステータスのしきい値（全体の健全性と各カテゴリのスコアに適用）：

• 80～100 = "Healthy"
• 60～79 = "Needs Attention"
• 0～59 = "Critical"

トークン予算に関する指針： 指摘事項が約 100 件あるコードベースでは、段階的な指摘事項レイアウト（重大な指摘事項は表、軽微な指摘事項と提案は件数のみ。詳細はすべて保存ファイルに記載）により、ディスク上の出力を約 8,000～12,000 トークンに抑えられます（すべての指摘事項を詳細に記載した場合は約 40,000 トークンです）。ターミナルのサマリーは、ダッシュボード、実行サマリー、重大な指摘事項、修正順の上位 5 項目のみを出力するため、さらに簡潔です。ユーザーは /codeprobe security . などを実行して、特定のカテゴリの詳細を確認できます。

/codeprobe quick — クイックレビューサマリー

templates/quick-review-summary.md のテンプレートを使用します（Read で読み込みます）。テンプレートがまだ存在しない場合は、次の内容をインラインで生成します。

1. ヘッダー：プロジェクト名、「Quick Review — Top 5 Issues」。
2. 上位 5 件の指摘事項：影響の大きい上位 5 件について、修正プロンプトを含む詳細を記載します。
3. サマリー件数：すべてのカテゴリで見つかった問題の重大度別の合計件数。
4. 次のステップ：全体像を把握するため、/codeprobe audit の実行を提案します。

/codeprobe diff — PR スタイルのレビュー

templates/pr-review-comment.md のテンプレートを使用します（Read で読み込みます）。{branch} には現在のブランチ（git rev-parse --abbrev-ref HEAD）を、{base_branch} には解決されたベースブランチを、{changed_files} にはレビューしたファイル数を、{overall_score} には差分の指摘事項に標準の計算式（セクション 7）を適用した値を設定します。{version} には、このファイルのフロントマターにある metadata.version の値を設定します。

• ターミナル：埋め込み済みのテンプレートをアシスタントの応答として Markdown で直接出力し、その後に保存確認行を出力します（セクション 8B の手順 5 と同じ形式）。
• 保存ファイル：セクション 8C のファイル名と書き込みのルールに従い、同じ Markdown を ./codeprobe-reports/{project}-diff-{YYYY-MM-DD-HHMMSS}.md に書き込みます。
• 出力される Markdown は GitHub の PR コメントにそのまま貼り付けられるように設計されています。自己完結した内容にし、本文内で「保存ファイル」に言及しないでください。

9. Claude.ai の縮退モード

ファイルシステムにアクセスできるかどうかを検出します。ユーザーがファイルパスを指定せずにコードを貼り付けたりアップロードしたりした場合、または Read/Glob/Grep ツールを利用できない場合：

1. 縮退モードに切り替えます：コンテキスト内で提供されたコードのみを分析します。
2. 貼り付けられたコードに対してサブスキルを順次実行します（並列エージェントは使用しません）。
3. file_stats.py、dependency_mapper.py、およびスクリプトに依存するすべての手順をスキップします（サブスキルは LLM のみの分析に切り替わるため、アーキテクチャ分析では決定論的な循環検出ができません）。
4. /codeprobe diff、/codeprobe report、監査ダッシュボードの Codebase Stats 行、およびレポート保存の手順をスキップします（ファイルシステムに書き込めないため）。スコア、注目箇所、検出事項は引き続きターミナルに出力します。
5. ユーザーに伝えます：「Claude.ai モードで実行しています。コードベースの統計情報、差分レビュー、複数ファイルの分析など、一部の機能は利用できません。提供されたコードを直接分析します。」
6. 標準の出力契約形式で、検出事項を引き続き出力します。
7. 利用可能なサブスキルの検出事項に基づいて、引き続きスコアを算出します。

---

10. Phase 3 のスタブ

まだ実装されていない機能にルーティングされるコマンドがユーザーから実行された場合、次のように応答します。

まだ利用できません。 この機能は Phase 3 で提供予定です。現在利用可能なコマンド：

• /codeprobe audit <path> — コードの完全な監査
• /codeprobe diff [base] — ベースブランチと比較した変更ファイルの PR スタイルレビュー
• /codeprobe solid <path> — SOLID 原則のチェック
• /codeprobe security <path> — セキュリティ監査
• /codeprobe smells <path> — コードスメルの検出
• /codeprobe architecture <path> — アーキテクチャ分析
• /codeprobe patterns <path> — デザインパターンの分析
• /codeprobe performance <path> — パフォーマンス監査
• /codeprobe errors <path> — エラー処理の監査
• /codeprobe tests <path> — テスト品質の監査
• /codeprobe framework <path> — フレームワークのベストプラクティス
• /codeprobe quick <path> — 上位 5 件の問題

対象となるのは report です。

---

11. 実行フローの概要

/codeprobe が実行されたら、次の順序で処理します。

1. コマンドを解析：ユーザーの入力からサブコマンドと対象パスを抽出します。
2. コマンドを検証：ルーティングテーブルを確認します。Phase 3 のスタブに該当する場合は、スタブメッセージを返します。
3. 対象パスを解決：指定されたパスを使用するか、現在の作業ディレクトリをデフォルトとして使用します。diff の場合は代わりに、Section 4A に従ってベースの ref を解決し、変更されたファイルと行範囲を収集します。マニフェストはそれらのファイルに限定されます。
4. 設定を読み込み：プロジェクトルートに .codeprobe-config.json があるか確認します。存在しない場合はデフォルト設定を適用します。
5. 技術スタックを自動検出：対象パスをスキャンして技術スタックのシグナルを探します。一致するリファレンスを読み込みます。
6. 設定の上書きを適用：設定で framework が指定されている場合は、検出方法を調整します。skip_categories と skip_rules を適用します。
7. サブスキルを実行：共有コンテキスト（Section 4）を準備してから、適切なモードで該当するすべてのサブスキルエージェントを並列起動します。
8. 検出事項を収集：出力契約の形式で、すべての検出事項を集約します。
9. 検出事項の重複を排除：カテゴリ横断の重複排除手順（Section 7A）を適用します。実際の矛盾は「矛盾する推奨事項」セクションに振り分け、真の重複は削除し、カテゴリごとの重大度の合計を再集計します。
10. スコアを算出：重複排除後の重大度の件数と Section 7 の計算式を使用して、カテゴリ別および全体のスコアを算出します。
11. レポートを表示用に整形：適切なテンプレートまたはインライン形式で出力を整形します。/codeprobe audit では段階的な出力形式を使用します。
12. ユーザーに提示：最終レポートを表示します。

重要：このプロセス全体は読み取り専用です。ユーザーのファイルを変更することは一切ありません。