メニュー
プロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない（codex-review / cross-review を使う）。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | audit |
| version | 1.0.0 |
| description | プロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない（codex-review / cross-review を使う）。 |
| disable-model-invocation | true |
プロジェクト監査オーケストレーター。以下の手順に従って監査を実行してください。
issues/audit-log ファイルを読み取ってください（存在しない場合はスキップ）。
このログには過去の監査実行記録が含まれています。
以下の監査タイプ一覧をユーザーに提示してください。
ログに直近7日以内の実行記録がある場合、該当タイプに (最終: MM/DD) を付記してください。
| ID | カテゴリ | 名前 | 説明 |
|---|---|---|---|
| design | 設計 | 設計改善 | 今後問題になりうる設計上の課題を探す |
| responsibility | 設計 | 責務集中 | 責務が集中しているクラス/モジュールを探す（行数でなく多角的に判定） |
| duplication | 設計 | コード重複 | コピペされたロジック、抽出すべき類似実装を探す |
| polymorphism | 設計 | ポリモーフィズム置換 | 条件分岐（if/switch）をポリモーフィズムで置き換えられる箇所を探す |
| ui-components | 設計 | UIコンポーネント共通化 | 共通化できるビュー・UIパターンを探す |
| ux | UX | UX改善 | UX的に劣っている箇所を探す |
| security | 品質 | セキュリティ | ハードコードされた秘密情報、インジェクション脆弱性、安全でない依存関係などOWASP観点の問題を探す |
| resource-leaks | 品質 | リソースリーク | リソースリークの可能性が高いコードを探す |
| broken-code | 品質 | 壊れたコード | コードベースの破損や設計的破綻を探す |
| dead-code | 品質 | デッドコード | 未使用のimport・関数・変数・クラス、到達不能コードを探す |
| error-handling | 品質 | エラーハンドリング | 握りつぶされた例外、不整合なエラー処理パターン、リカバリ不能な障害パスを探す |
| performance | 品質 | パフォーマンス | N+1クエリ、不要な計算、メモリ効率の悪い処理を探す |
| test-cleanup | テスト | 無意味テスト削除 | 意味のないテストコードを探して削除する |
| test-helpers | テスト | テストヘルパー共通化 | 繰り返し使われているテストヘルパーを共通化する |
| dependency | 管理 | 依存関係 | 未使用・脆弱・重複した依存パッケージを探す |
| issues-done | 管理 | 完了issue確認 | 未完了の issue をコードと照合し、実は完了済みのものを issues/done に移動する |
| lint-from-done | 改善 | lint転用調査 | issues/done から lint ルールに転用できるパターンを探す |
| general | 総合 | 総合課題発見 | カテゴリを問わず問題になりうる課題を探す |
AskUserQuestion は最大4選択肢のため、カテゴリ別に2段階で選択させてください。
1問目: カテゴリを選択（multiSelect: true）
2問目以降: 選択されたカテゴリ内の具体的なタイプを選択（multiSelect: true）。 以下のルールに従ってください:
~/.claude/skills/forge/_common/modes.md を読み取り、「モード一覧」テーブルから利用可能なモード名・説明を取得してください。
このファイルが存在しない場合はプロジェクトローカルの _claude/skills/forge/_common/modes.md を試してください。
両方存在しない場合は forge が未導入のため、自動的に「直接実行」を選択し、以下の選択をスキップしてください。
取得したモード一覧 + 直接実行を以下のように2段階で選択させてください。
1問目: 実行方式を選択
2問目（forge 選択時のみ）: modes.md から読み取ったモード名を最大4つ提示して選択させてください。
選択された監査タイプと実行モードに基づいて監査を実行します。
/forge スキルを呼び出して以下のプロンプトを実行してください。
ユーザーが選択したモードを明示的に指定してください。
各監査タイプのプロンプト:
[モード名]モードで実行して。今後問題になりうる、設計系に改善するべき実装を探してissuesディレクトリに書き出して[モード名]モードで実行して。責務が集中しているクラス/モジュールを探してissuesディレクトリに書き出して。ただし行数やメソッド数の多さだけで責務集中と判定しないこと。責務の数（変更理由の数）・凝集度の低さ・依存の広がり・状態の絡み・抽象度の不統一など複数観点で裏付けが取れた箇所のみを違反とし、単に大きいだけのものは除外する[モード名]モードで実行して。コピペされたロジックや類似実装を探して、共通化すべき箇所をissuesディレクトリに書き出して[モード名]モードで実行して。条件分岐（if/else チェーンや switch 文）でタイプや種別に応じた振り分けをしている箇所を探し、ポリモーフィズム（プロトコル/インターフェース/サブクラス）で置き換え可能な候補をissuesディレクトリに書き出して。特に同じ条件が複数箇所に散在しているケースを優先して[モード名]モードで実行して。UIコンポーネント（モーダル、リスト、ボタン、フォーム等）の中で共通化・抽出できるビューパターンを探してissuesディレクトリに書き出して[モード名]モードで実行して。UX的に劣っている箇所を探してissuesディレクトリに書き出して[モード名]モードで実行して。ハードコードされた秘密情報、インジェクション脆弱性、安全でない依存関係などセキュリティ上の問題を探してissuesディレクトリに書き出して[モード名]モードで実行して。リソースリークしている可能性の高いコードを探してissuesディレクトリに書き出して[モード名]モードで実行して。コードベースを見て壊れている箇所がないか、設計的に破綻している箇所がないか調べて[モード名]モードで実行して。未使用のimport・関数・変数・クラスや到達不能コードを探してissuesディレクトリに書き出して[モード名]モードで実行して。握りつぶされた例外、不整合なエラー処理パターン、リカバリ不能な障害パスを探してissuesディレクトリに書き出して[モード名]モードで実行して。N+1クエリ、不要な計算、メモリ効率の悪い処理などパフォーマンス上の問題を探してissuesディレクトリに書き出して[モード名]モードで実行して。テストコードのうち、意味のないテストになっているコードを探して削除して[モード名]モードで実行して。テストコードのうち、繰り返し使っているヘルパーを見つけて共通化して[モード名]モードで実行して。未使用・脆弱・重複した依存パッケージを探してissuesディレクトリに書き出して[モード名]モードで実行して。issuesディレクトリで未着手のissueを一通り確認して、実は完了しているものがあれば完了と分かるように記録してissues/doneに移動して[モード名]モードで実行して。issues/doneの中身を確認して、lintに転用すると有用そうなことがないかを調べてissuesディレクトリに書き出して[モード名]モードで実行して。プロジェクトを眺めて、設計とかUXとかカテゴリなんでもいいので、問題になりうる課題を探してissuesディレクトリに書き出してforge を使わず、あなた自身が直接タスクを実行してください。 Explore エージェントでコードベースを調査し、発見事項を issues ディレクトリに書き出してください。 出力フォーマットは issues 配下の既存ファイルに合わせてください（既存ファイルがない場合は、問題の説明・該当箇所（file:symbol）・推奨対応の3点を各 issue に含めてください）。
各監査タイプの調査指針:
verify-design-intent-before-refactor.md と同じ思想）監査完了後、発見事項を issues ディレクトリに書き出した場合は git commit してください。
issues/audit-log に以下の形式で追記してください。
ファイルが存在しない場合は新規作成してください。
YYYY-MM-DD HH:MM <audit-type-id> <mode> <output-files>
フィールドはタブ区切りです。<mode> は forge 経由なら forge-<モード名>（modes.md のモード名: Standard / Minimum+ / Maximum / Minimum / Ultra）、直接実行なら direct。例:
2026-02-15 14:30 design forge-Standard issues/design-improvements.md
2026-02-15 14:45 broken-code direct issues/broken-code-findings.md
2026-02-15 15:00 general forge-Minimum+ issues/general-issues.md
複数の監査タイプが選択された場合は、各タイプを順番に実行し、それぞれログを記録してください。
実行中にエラーが発生した場合は、そのタイプのログに error と記録し、次のタイプに進んでください。
すべてのタイプの実行が完了（またはエラー）した後、エラーがあった場合はユーザーに報告してください。
audit-log 自体も commit に含めてください。
issues/readme.md に従うこと。作成前に必ず issues/readme.md を読み、ファイル名の形式（番号プレフィックス等）と次の issue 番号を確認してくださいissues/readme.md が存在しない場合は issues/<audit-type-id>-<簡潔な説明>.md をフォールバックとしてくださいこのセッションで行った変更をコミットする。「コミットして」「commit」「/c」で発火。push はしない／クレデンシャルは混入させない。
codex をメイン実装者として実コードを書かせ (codex exec -s workspace-write)、Claude はオーケストレーション (スコープ分割・成果物検証・観測駆動デバッグ・commit/push・反復) に徹するワークフロー。大きめの実装/移植/プロトコル実装で、余っている codex トークンを使い切りたい時に使う。「codex に書かせて」「codex メインで実装」「codex に作らせて」「codex-drive」「/codex-drive」で発火。typo・数行修正には使わない (それは Claude が直接やる)。
タスク着手時に codex にリードしてもらうワークフロー。codex に設計/方針を主導（リード）させ、その方針に沿って Claude が実装し、実装後は codex でレビューする。余っている codex トークンを積極的に消費したい時に使う。「codexにリードしてもらって」「設計から codex に任せて」「タスクを codex 主導で」「codex-lead」「/codex-lead」で発火。
Claude Fable 5 の特徴・長所・仕様と、その働き方を他モデル (Opus 等) が再現するための行動規範。「fable」「fableっぽく」「fable流」「Fable の働き方」「/fable」で発火。以降のセッション全体の振る舞いに適用する。
AVFoundation (AVPlayer / AVPlayerLayer / AVPlayerItemVideoOutput / AVAsset) の落とし穴・文書化されていない実装挙動・debugging チェックリストを集約した reference skill。Swift / Objective-C で AVPlayer を使った動画再生 / seek / scrub / frame stepping を実装・debug するときに発火。VLCKit ではなく **AVFoundation 系** の問題に特化。
macOS アプリのクラッシュログ (.ips) を解析し、根本原因を特定するスキル。「クラッシュした」「crash」「.ips」「DiagnosticReports」「SIGSEGV / SIGABRT」で発火。**macOS 専用**（.ips 構造参照と crash-analyzer の bin/tt-crash-log 前提が macOS 向け。iOS の .ips は未対応）。解析は crash-analyzer subagent に委譲する。クラッシュログが存在しない一般のバグ調査・テスト失敗には使わない。