audit

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 ファイルと同じカテゴリの場合、既存ファイルへの追記も検討してください