Codebase Audit — Codex Native

目的

名前付きドメインレンズを通してローカルコードベースを監査し、エビデンスに基づくレポートを返します。ユーザーが明示的に修正を要求しない限り、監査はレポートのみです。

ドメイン:

• security
• ux
• performance
• api
• copy
• cli

Codex互換性ルール

このスキルはCodex専用です。

• Claude Code の Task、Agent、subagent_type、またはツール呼び出し構文を使用しないでください。
• スキル内のClaude形式のエージェントディレクトリがワーカーを作成できると想定しないでください。
• Codexカスタムエージェントは .codex/agents/ または ~/.codex/agents/ 下の個別のTOMLファイルです。
• Codexサブエージェントはコストが高いため、ユーザーが並列作業、サブエージェント、ドメインごとの1エージェント、または複数エージェント監査を明示的に要求した場合のみ使用してください。
• サブエージェントを使用する場合、ワーカーは読み取り専用のままで簡潔な検出結果を返す必要があります。親エージェントが重大度の正規化、重複排除、最終統合を所有します。
• サブエージェント出力が最終検出結果に影響する可能性がある場合は、../references/specialist-packet-contract.md の共有スペシャリストパケットコントラクトが必要です。統合前に古い、スコープ外の、ラッパーリーク、確認のみ、またはエビデンスなしパケットを拒否してください。

入力

ユーザープロンプトとリポジトリコンテキストから以下を解決してください:

• domain: 上記ドメインの1つ、または複数ドメインスイープ用のリスト。
• scope: デフォルトではリポジトリ全体、またはユーザー提供のファイル/ディレクトリ/機能。
• depth: quick、standard、または deep。デフォルト: standard。
• subagents: ユーザーがCodexサブエージェントまたは並列エージェントを明示的に要求した場合のみtrue。

ドメインが不明な場合は、プロンプトから最も可能性の高いドメインを選択してください。一般的な「このコードベースを監査してください」というリクエストの場合、バックエンド/サービスリポについては security、performance、api を使用します。フロントエンド/プロダクトリポについては security、ux、performance を使用します。CLI/ツーリングリポについては security、cli、performance を使用します。

ワークフロー

1. リポコンテキストを確立する

プロジェクトを分類し、監査サーフェスを特定するのに必要な程度まで検査します:

• リポレイアウト、マニフェスト、フレームワーク/ランタイム、パッケージマネージャー/ビルドシステム
• AGENTS.md、README、ドキュメント、ルート/コマンドエントリポイント、テスト
• 関連する場合は依存関係マニフェストとロックファイル
• ユーザーが指定したターゲットファイルまたは機能パス

広範な網羅的な読み込みよりも rg、マニフェスト読み込み、対象ファイル検査を優先してください。

2. 関連するドメインチェックリストを読み込む

ドメイン固有のチェック、コマンド、レポート形式については、それぞれ references/CHECKLISTS.md、references/TOOLS.md、references/EXAMPLES.md を使用します。

単一ドメイン監査の場合、そのドメインについて詳しく掘り下げます。複数ドメインスイープの場合、検出結果をドメイン分離したままにし、1つのドメインに全体の時間を費やさないようにしてください。

3. 候補の問題を検出する

最初に高速な静的検出を使用します:

• 既知の危険な構成のコード検索
• 依存関係/設定レビュー
• 意図された動作を理解するためのテストと例
• フレームワークの慣例とエントリポイント

次に、周囲のソースを読むことで各候補を検証します。根本原因を説明し、具体的な位置を引用できない限り、検出結果を報告しないでください。正確な file:line 引用を優先してください。合理的な努力の後も行番号が利用できない場合は、最小のパス/シンボルスコープを引用し、その旨を述べてください。

4. 重大度を検証する

ユーザーへの影響と悪用可能性で重大度を割り当てます:

重大度	基準	例
Critical	現在直接悪用可能、データ損失、権限昇格、本番障害リスク	SQLインジェクション、認証バイパス、破壊的コマンドパス
High	深刻な影響だが条件、スケール、またはまれなアクセスが必要	機密アクション上のCSRF漏れ、ホットパス上のN+1、コアエンドポイント上の破損したページネーション
Medium	制限された影響範囲を持つ実際の問題	検証漏れ、紛らわしいフロー、回復を妨げる曖昧なエラー
Low	ポーランド、ベストプラクティス、保守性、軽微なUX/コピー/APIの摩擦	一貫性のない命名、ヘルパーテキスト漏れ、ノイズの多いCLI出力

重大度を過度に評価しないでください。推測的なリスクを検出結果として数えないでください。代わりに「検証が必要」の下にリストアップしてください。

5. レポート

各ドメインに対してこの形式を返します:

# [ドメイン] 監査レポート: [プロジェクトまたはスコープ]

## サマリー
- **スコープ:** [検査されたリポ/ファイル/機能]
- **モード:** [quick/standard/deep; シングルエージェントまたはCodexサブエージェント]
- **合計検出結果:** N
- **Critical:** X | **High:** Y | **Medium:** Z | **Low:** W

## Critical検出結果

### 1. [検出結果のタイトル]
- **位置:** `path/to/file.ext:line`
- **重大度:** Critical
- **問題:** [何が悪いのか]
- **根本原因:** [コードがそれを許可する理由]
- **影響:** [ユーザー/セキュリティ/パフォーマンス/API/UX影響]
- **推奨修正:** [具体的な変更]
- **検証:** [テスト、コマンド、再現手順、または手動チェック]

## High検出結果
[同じ形式]

## Medium検出結果
[同じ形式、より簡潔]

## Low検出結果
[同じ形式、より簡潔]

## 検証が必要
- [ランタイムアクセス、認証情報、本番データ、またはユーザー確認が必要な妥当なリスクのみ]

## ポジティブシグナル
- [コードが既に正しく実行している重要なこと]

クイック複数ドメインスイープの場合、ドメインごとに上位3つの検出結果を返し、ユーザーがさらに要求しない限り合計100行以下に保ってください。

Codexサブエージェントワークフロー

ユーザーがCodexサブエージェント、並列エージェント、またはドメインごとの1エージェントを明示的に要求した場合のみこのセクションを使用してください。

1. 独立した監査ドメインまたは分離したリポスコープごとに作業を分割します。
2. マッチするエージェントがインストールされている場合、要求されたドメインごとに1つのCodexカスタムエージェントを起動します:
   • security → audit_security
   • ux → audit_ux
   • performance → audit_performance
   • api → audit_api
   • copy → audit_copy
   • cli → audit_cli
3. すべてのワーカーに同じスコープ、深さ、出力スキーマ、ファイル編集を避ける命令を与えます。
4. 現在の artifact_state_id、正確なドメイン/スコープ、共有スペシャリストパケットコントラクトの必須パケットフィールドを割り当てます。
5. パケットが進行中の間のみ待機します。ルートが現在のソースエビデンスから完了できるときは古いワーカーをクローズします。
6. 統合前にすべてのパケットを検証します。拒否されたパケットでも値収據を受け取り、検出結果にはなりません。
7. ドメインごとに結果をマージし、重複する検出結果を重複排除し、重大度を正規化し、意見の相違を「検証が必要」で可視化したままにします。
8. カスタムエージェントがインストールされていない場合は、同じドメイン固有の命令でCodex組み込み explorer エージェントを使用するか、ローカルで実行して使用されたフォールバックを述べてください。

ワーカープロンプトテンプレート

Codexサブエージェントを起動するときはこのテンプレートを使用します:

codebase-auditチェックリストを使用して[スコープ]の読み取り専用[ドメイン]監査を実行します。
深さ: [quick|standard|deep]。
ファイルを編集しないでください。
具体的なソースエビデンスで裏付けられた場合のみ検出結果を返します。
各検出結果について、タイトル、重大度、位置、問題、根本原因、影響、推奨修正、検証を含めてください。
また、検証が必要およびポジティブシグナルを返します。
../references/specialist-packet-contract.md フィールドを使用して正確に1つのスペシャリストパケットで終わります: artifact_state_id、artifact_state_label、scope、evidence_refを持つtop_material_signals、unresolved_signals、agreement_pressure、stale、final_call。
出力は簡潔に保ってください。親エージェントが最終レポートを統合します。

アンチパターン

• 具体的なパス、原因、修正なしに「コードが悪い」と言わないでください。
• ドメインを1つの区別されないリストに混在させないでください。
• 手動で検証されなかったgrepヒットを報告しないでください。
• ユーザーが修復を要求しない限り、監査の実行中にファイルを編集しないでください。
• ユーザーが要求しない限り、イシュー/タスクを作成しないでください。
• ユーザーが要求するか、コマンドが既に利用可能で現在のサンドボックス下で安全でない限り、インストール、ネットワークアクセス、または承認を必要とする外部スキャナーを使用しないでください。

参考資料

• references/CHECKLISTS.md — ドメインチェックリストとgrepパターン
• references/TOOLS.md — ドメイン別ツール提案
• references/EXAMPLES.md — レポート例
• references/CODEX_SUBAGENTS.md — Codexのみのサブエージェントプロンプトとインストール注記
• ../references/specialist-packet-contract.md — 共有スペシャリストパケット検証、値収據、待機制限