| name | audit |
| version | 1.0.0 |
| description | プロジェクト監査。「監査して」「audit」「/audit」で発火。設計/UX/品質/テストなどの観点でコードベース全体を監査し、課題をissuesディレクトリに書き出す。実行ログで重複実行を防止。特定の差分・コミットのレビューには使わない(codex-review / cross-review を使う)。 |
| disable-model-invocation | true |
Audit
プロジェクト監査オーケストレーター。以下の手順に従って監査を実行してください。
Step 1: 実行ログの確認
issues/audit-log ファイルを読み取ってください(存在しない場合はスキップ)。
このログには過去の監査実行記録が含まれています。
Step 2: 監査タイプの選択
以下の監査タイプ一覧をユーザーに提示してください。
ログに直近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)
- 設計 (design, responsibility, duplication, polymorphism, ui-components)
- 品質 (security, resource-leaks, broken-code, dead-code, error-handling, performance)
- テスト (test-cleanup, test-helpers)
- その他 (ux, dependency, issues-done, lint-from-done, general)
2問目以降: 選択されたカテゴリ内の具体的なタイプを選択(multiSelect: true)。
以下のルールに従ってください:
- カテゴリ内のタイプが1つしかない場合は自動選択してこの質問をスキップ
- 候補が合計4つ以下の場合はまとめて1問で提示
- 候補が合計5つ以上の場合は4つずつに分割して質問(カテゴリ単位でまとめる。1カテゴリ内に5つ以上ある場合もさらに4つずつに分割)
Step 3: 実行モードの選択
~/.claude/skills/forge/_common/modes.md を読み取り、「モード一覧」テーブルから利用可能なモード名・説明を取得してください。
このファイルが存在しない場合はプロジェクトローカルの _claude/skills/forge/_common/modes.md を試してください。
両方存在しない場合は forge が未導入のため、自動的に「直接実行」を選択し、以下の選択をスキップしてください。
取得したモード一覧 + 直接実行を以下のように2段階で選択させてください。
1問目: 実行方式を選択
- forge(forge スキル経由で実行)
- 直接実行(forge を使わず直接タスクを実行する)
2問目(forge 選択時のみ): modes.md から読み取ったモード名を最大4つ提示して選択させてください。
Step 4: 監査の実行
選択された監査タイプと実行モードに基づいて監査を実行します。
forge モードが選択された場合
/forge スキルを呼び出して以下のプロンプトを実行してください。
ユーザーが選択したモードを明示的に指定してください。
各監査タイプのプロンプト:
- design:
[モード名]モードで実行して。今後問題になりうる、設計系に改善するべき実装を探してissuesディレクトリに書き出して
- responsibility:
[モード名]モードで実行して。責務が集中しているクラス/モジュールを探してissuesディレクトリに書き出して。ただし行数やメソッド数の多さだけで責務集中と判定しないこと。責務の数(変更理由の数)・凝集度の低さ・依存の広がり・状態の絡み・抽象度の不統一など複数観点で裏付けが取れた箇所のみを違反とし、単に大きいだけのものは除外する
- duplication:
[モード名]モードで実行して。コピペされたロジックや類似実装を探して、共通化すべき箇所をissuesディレクトリに書き出して
- polymorphism:
[モード名]モードで実行して。条件分岐(if/else チェーンや switch 文)でタイプや種別に応じた振り分けをしている箇所を探し、ポリモーフィズム(プロトコル/インターフェース/サブクラス)で置き換え可能な候補をissuesディレクトリに書き出して。特に同じ条件が複数箇所に散在しているケースを優先して
- ui-components:
[モード名]モードで実行して。UIコンポーネント(モーダル、リスト、ボタン、フォーム等)の中で共通化・抽出できるビューパターンを探してissuesディレクトリに書き出して
- ux:
[モード名]モードで実行して。UX的に劣っている箇所を探してissuesディレクトリに書き出して
- security:
[モード名]モードで実行して。ハードコードされた秘密情報、インジェクション脆弱性、安全でない依存関係などセキュリティ上の問題を探してissuesディレクトリに書き出して
- resource-leaks:
[モード名]モードで実行して。リソースリークしている可能性の高いコードを探してissuesディレクトリに書き出して
- broken-code:
[モード名]モードで実行して。コードベースを見て壊れている箇所がないか、設計的に破綻している箇所がないか調べて
- dead-code:
[モード名]モードで実行して。未使用のimport・関数・変数・クラスや到達不能コードを探してissuesディレクトリに書き出して
- error-handling:
[モード名]モードで実行して。握りつぶされた例外、不整合なエラー処理パターン、リカバリ不能な障害パスを探してissuesディレクトリに書き出して
- performance:
[モード名]モードで実行して。N+1クエリ、不要な計算、メモリ効率の悪い処理などパフォーマンス上の問題を探してissuesディレクトリに書き出して
- test-cleanup:
[モード名]モードで実行して。テストコードのうち、意味のないテストになっているコードを探して削除して
- test-helpers:
[モード名]モードで実行して。テストコードのうち、繰り返し使っているヘルパーを見つけて共通化して
- dependency:
[モード名]モードで実行して。未使用・脆弱・重複した依存パッケージを探してissuesディレクトリに書き出して
- issues-done:
[モード名]モードで実行して。issuesディレクトリで未着手のissueを一通り確認して、実は完了しているものがあれば完了と分かるように記録してissues/doneに移動して
- lint-from-done:
[モード名]モードで実行して。issues/doneの中身を確認して、lintに転用すると有用そうなことがないかを調べてissuesディレクトリに書き出して
- general:
[モード名]モードで実行して。プロジェクトを眺めて、設計とかUXとかカテゴリなんでもいいので、問題になりうる課題を探してissuesディレクトリに書き出して
直接実行 (not forge) が選択された場合
forge を使わず、あなた自身が直接タスクを実行してください。
Explore エージェントでコードベースを調査し、発見事項を issues ディレクトリに書き出してください。
出力フォーマットは issues 配下の既存ファイルに合わせてください(既存ファイルがない場合は、問題の説明・該当箇所(file:symbol)・推奨対応の3点を各 issue に含めてください)。
各監査タイプの調査指針:
- design: アーキテクチャ全体を俯瞰し、密結合・循環依存・レイヤー違反・拡張困難な箇所を探す
- polymorphism: 条件分岐(if/else チェーン・switch/case)でタイプや種別ごとに処理を分けている箇所を探し、ポリモーフィズム(プロトコル準拠・サブクラス・ストラテジーパターン等)で置き換え可能な候補を特定する。特に、同じ条件が複数箇所に散在しているケースを優先する
- ui-components: モーダル・リスト・ボタン・フォーム等のUIパターンを横断的に比較し、共通コンポーネントとして抽出できる類似実装を探す
- ux: ユーザー操作フロー・エラーメッセージ・レスポンス速度・一貫性の観点で劣っている箇所を探す
- issues-done: 未完了の issue ファイルを読み、実装済みかどうかをコードベースと照合し、完了済みなら issues/done へ移動する
- resource-leaks: ファイルハンドル・DB接続・イベントリスナー・タイマーなど、解放漏れの可能性がある箇所を探す
- responsibility: 行数・メソッド数の多さ「だけ」で判断しない。責務の数(変更理由の数)・凝集度の低さ・依存の広がり・状態の絡み・抽象度の不統一など複数観点でチェックし、複数の観点で責務集中が裏付けられる箇所のみを違反とする(単に大きいだけのクラスは違反ではない。
verify-design-intent-before-refactor.md と同じ思想)
- lint-from-done: issues/done のパターンを分析し、lint ルールとして自動検出できそうな再発防止策を探す
- broken-code: 到達不能コード・型不整合・未使用の引数・壊れたインポートなど、実行時エラーになりうる箇所を探す
- test-cleanup: 常に pass するアサーション・重複テスト・実装と乖離したモックなど、価値のないテストを探す
- test-helpers: 複数テストファイルで繰り返されているセットアップやユーティリティを特定し、共通ヘルパーへの抽出を提案する
- general: 上記すべての観点を広く浅くカバーし、最も影響が大きい課題を優先して報告する
Step 5: commit と実行ログの記録
commit
監査完了後、発見事項を 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 ディレクトリが存在しない場合は作成してください
- issue ファイルの命名規則は
issues/readme.md に従うこと。作成前に必ず issues/readme.md を読み、ファイル名の形式(番号プレフィックス等)と次の issue 番号を確認してください
issues/readme.md が存在しない場合は issues/<audit-type-id>-<簡潔な説明>.md をフォールバックとしてください
- 既存の issue ファイルと同じカテゴリの場合、既存ファイルへの追記も検討してください