監査

1つ以上のコードベース監査を調整します。スコーピング質問を1つずつ行い、その後すべてのエージェントを並列実行します。ユーザーのさらなるインタラクションは不要です。

入力

$ARGUMENTSはオプションのコンテキストです。特定の懸念事項、リポジトリパス、または実行する監査です。

プロセス

ステップ 1: 監査を選択する

どの監査を実行するかをユーザーに尋ねます。これは最初のメッセージで最初かつ唯一の質問です。

どの監査を実行しますか？

A) 3つすべて（ヘルスチェック + 評価 + ドキュメント）
B) コード評価 — 3つの視点にわたる12段階スコアリング
C) 技術的負債 — 4つのベクトル全体での監査
D) ドキュメント — 6つのフェーズ全体でのドリフト検出

$ARGUMENTSが既に監査を指定している場合（例："/audit all"）、この質問をスキップしてステップ2に進みます。

ユーザーの回答を待ってから続行します。

ステップ 2: フォローアップ質問を1つずつ尋ねる

選択された監査に基づいて、関連するスコーピング質問をメッセージごとに1つ尋ねます。各回答を待ってから次を尋ねます。

まずユニバーサル質問から始め、次に監査固有の質問を尋ねます。

ユニバーサル（常に最初に尋ねます）:

既知の問題点 — すべての監査者に冷たい状態でスキャンする代わりに、開始仮説を提供します。

コードベースで既に問題があると分かっている部分はありますか？
繰り返し破損する場所、触るのを避けたい領域、すべてのPRを遅くするモジュール。

A) はい（どの領域が何が問題か教えてください）
B) いいえ — すべてをフレッシュな目でスキャンしてください

評価を選択した場合（BまたはA）:

コード評価は3つの評価者エージェントを並列実行し、各エージェントが4つの柱をスコアリングします（合計12個）。スコアは選択したロールレベルに調整されます。

ロールレベル — スコアリング基準を設定します。「シニア」評価は本番環境で実証されたパターンを期待します。「ジュニア」評価は基礎に焦点を当てます。

このコードベースを何のロールレベルに対して評価すべきですか？

A) ジュニア開発者 — 基礎：可読性、基本的なエラーハンドリング、テスト存在確認
B) ミッドレベル開発者 — パターン：関心の分離、一貫した規約、テストカバレッジ
C) シニア開発者 — 本番環境：防御的なコーディング、監視可能性、パフォーマンス認識、型の厳密性
D) スタッフ+／プリンシパル — システム：アーキテクチャの一貫性、スケーラビリティ、運用の優秀性

焦点領域 — 評価者が特に注意を払う領域を絞り込みます。選択に関わらず、すべての12柱をスコアリングします。

評価者がより重く重みづけすべき特定の懸念がありますか？

A) パフォーマンス — ホットパス、アルゴリズムの複雑性、リソース管理
B) セキュリティ — 入力検証、認証パターン、シークレット管理
C) テスト — カバレッジ品質、テストアーキテクチャ、エッジケース
D) アーキテクチャ — 関心の分離、モジュール性、結合度
E) 複数（どれを指定してください）
F) なし — すべての柱全体で均衡の取れた評価

スコープと除外 — 評価する対象と飛ばす対象です。

評価者は何を見るべきですか？

A) フルリポジトリ、標準除外（vendor、generated、node_modules、__pycache__）
B) フルリポジトリ、除外なし
C) 特定のディレクトリのみ（含める、または除外すべき場所を教えてください）

柱のオーバーライド — デフォルトでは、パイプラインはすべての12柱が9/10に達するまで改善します。Creativityなどの一部の柱は、コード変更を通じて改善できない場合があります。オーバーライドを使用すると、より低いしきい値を設定したり、柱を改善ゲートから完全に除外できます。

12の柱は以下の通りです:

採用視点: Problem-Solution Fit、アーキテクチャ、コード品質、クリエイティビティ
ストレス視点: プラグマティズム、防御性、パフォーマンス、型の厳密性
Day 2視点: テスト価値、再現性、Gitの衛生管理、オンボーディング

デフォルト9/10のしきい値以下で受け入れるべき柱はありますか？

A) なし — すべての12柱で9/10を要求
B) 特定のオーバーライド（柱と目標スコアを教えてください。例：「Creativity: 7、Git Hygiene: 受け入れ」）

ヘルスチェックを選択した場合（CまたはA）:

ヘルスチェック監査は4つのベクトル全体で技術的負債をスキャンします：アーキテクチャ、構造、運用、コードの衛生管理。検出項目は重大度によって優先順位付けされます（CRITICAL > HIGH > MEDIUM > LOW）。パイプラインはすべてのCRITICALおよびHIGH検出項目が解決されるまで改善します。

ゴール — 監査者が強調する負債ベクトルを決定します。

この監査の主要な目標は何ですか？

A) 一般的なヘルスチェック — 4つのベクトルを同等にスキャン
B) 本番環境の強化 — 運用負債を強調（エラーハンドリング、タイムアウト、リソースリーク、監視可能性）
C) オンボーディング準備 — 構造と衛生管理の負債を強調（命名、デッドコード、ドキュメント、テストカバレッジ）
D) リリース前のクリーンアップ — CRITICAL/HIGHアイテムのみに焦点、MEDIUM/LOWをスキップ

デプロイメントターゲット — 「運用負債」の意味を変えます。Lambda関数は長期実行コンテナとは異なる懸念があります。

デプロイメントターゲットは何ですか？

A) サーバーレス（Lambda、Cloud Functions）— コールドスタート、実行制限、ステートレス制約
B) コンテナ（ECS、Kubernetes、Docker）— リソース管理、ヘルスチェック、グレースフルシャットダウン
C) 静的ホスティング／SPA — ビルドパイプライン、CDN、クライアント側の懸念
D) モノリス／従来型サーバー — プロセス管理、コネクションプーリング、メモリリーク
E) 複数（どれを指定してください）
F) まだデプロイされていない／不確実

スコープと制約 — 監査対象と制限事項を1つの質問で示します。

ヘルスチェック監査は何をカバーすべきであり、何が制限されていますか？

A) フルリポジトリ、制約なし
B) フルリポジトリ、ただし特定の領域をスキップ（どれを指定してください。例：「レガシー認証モジュールに触れないでください」）
C) 特定のディレクトリのみ（どれを指定してください）

既存のツーリング — 強化フェーズ（強化段階）が既に存在するガードレールを知ることで、重複した作業をしないようにします。

既に導入されている開発ツーリングは何ですか？

A) フルセットアップ — リンター、CIパイプライン、pre-commitフック、型チェック
B) 部分的（何を持っているか教えてください。例：「ESLintはありますがCIはありません」）
C) なし — リンティング、CI、またはフック設定なし

ドキュメントを選択した場合（DまたはA）:

ドキュメント監査は6つの検出フェーズを実行します：発見、比較（ドリフト/ギャップ/陳腐化）、コード例、リンク整合性、設定/環境、構造。ドキュメントの主張を実際のコード動作と比較します。

スコープと制約 — 監査するドキュメントと制限事項です。

どのドキュメントを監査すべきであり、何が制限されていますか？

A) すべてのドキュメント、制約なし
B) すべてのドキュメント、ただし特定のファイルをスキップ（どれを指定してください）
C) 特定のディレクトリのみ（どれを指定してください）
D) READMEとAPIドキュメントのみ

言語スタック — 利用可能な自動生成ツールを決定します（TSの場合はtypedoc、Pythonの場合はsphinx、REST APIの場合はswagger）。

主要な言語スタックは何ですか？

A) JS/TS — typedoc、swagger-jsDocが利用可能
B) Python — sphinx、mkdocstringsが利用可能
C) 両方

防止ツーリング — ドキュメントドリフトが定期的なクリーンアップではなくCI失敗になるよう追加する自動チェック。

ドキュメントを修正した後、どのドリフト防止ツーリングを追加すべきですか？

A) Markdownリンティング（markdownlint）+ リンクチェック（lychee）— すべてのPRで書式設定問題と壊れたリンクをキャッチ
B) 自動生成APIドキュメント（typedoc/sphinx）— 単一の情報源はプローズではなくコードに存在
C) AとBの両方
D) なし — 既存のドキュメントを修正するだけ、新しいツーリングなし

ステップ 3: プラン識別子を生成する

すべての質問に回答した後、ディレクトリ名を生成します：YYYY-MM-DD-audit-slug

日付：今日の日付
スラッグ：リポジトリの短い名前（例：audit-ragstack、audit-my-app）
場所：docs/plans/YYYY-MM-DD-audit-slug/

ディレクトリを作成します。

ステップ 4: ロールプロンプトを読む

エージェントをスポーンする前に、必要なすべてのロールプロンプトファイルを読みます。選択された監査のプロンプトのみを読みます。

ヘルスチェック選択時: skills/pipeline/health-auditor.mdを読む
評価選択時: skills/pipeline/eval-hire.md、skills/pipeline/eval-stress.md、skills/pipeline/eval-day2.mdを読む
ドキュメント選択時: skills/pipeline/doc-auditor.mdを読む

ステップ 5: すべてのエージェントを並列でスポーンする

すべての監査者/評価者エージェントは読み取り専用です。コードベースを探索しますが、変更しません。選択されたすべてのエージェントを単一の並列バッチでスポーンします（「all」の場合は最大5エージェント）:

+-------------------------------------------------------------------+
|                    並列エージェントスポーン                         |
+-------------------------------------------------------------------+
|                                                                   |
|  ヘルスチェック監査 ─┐                                             |
|  評価採用 ──────────┤                                             |
|  評価ストレス ──────┤  すべてのエージェントが同時実行              |
|  評価Day2 ────────┤                                             |
|  ドキュメント監査 ─┘                                             |
|                  ↓                                                |
|  オーケストレーターがすべての応答を収集し、摂取ドキュメントを作成   |
|                                                                   |
+-------------------------------------------------------------------+

エージェント1: ヘルスチェック監査者（ヘルスチェック選択時）

<role_prompt>
[health-auditor.md の内容]
</role_prompt>

<task>
現在の作業ディレクトリのコードベースを監査します。
ゴール: [ステップ 2から]
スコープ: [ステップ 2から]
既存のツーリング: [ステップ 2から]
制約: [ステップ 2から]
</task>

エージェント2: 評価 — プラグマティスト（評価選択時）

<role_prompt>
[eval-hire.md の内容]
</role_prompt>

<task>
現在の作業ディレクトリのコードベースを評価します。
ロールレベル: [ステップ 2から]
焦点領域: [ステップ 2から]
除外: [ステップ 2から]
</task>

エージェント3: 評価 — オンコールエンジニア（評価選択時）

<role_prompt>
[eval-stress.md の内容]
</role_prompt>

<task>
現在の作業ディレクトリのコードベースを評価します。
ロールレベル: [ステップ 2から]
焦点領域: [ステップ 2から]
除外: [ステップ 2から]
</task>

エージェント4: 評価 — チームリード（評価選択時）

<role_prompt>
[eval-day2.md の内容]
</role_prompt>

<task>
現在の作業ディレクトリのコードベースを評価します。
ロールレベル: [ステップ 2から]
焦点領域: [ステップ 2から]
除外: [ステップ 2から]
</task>

エージェント5: ドキュメント監査者（ドキュメント選択時）

<role_prompt>
[doc-auditor.md の内容]
</role_prompt>

<task>
現在の作業ディレクトリのドキュメントをコードベースの現実と照らし合わせて監査します。
ドキュメントスコープ: [ステップ 2から]
制約: [ステップ 2から]
</task>

ステップ 6: 摂取ドキュメントを検証して作成する

すべてのエージェントが完了した後、各エージェントの出力に完了シグナルが含まれていることを確認します:

ヘルスチェック監査者: AUDIT_COMPLETEをチェック
評価採用: EVAL_HIRE_COMPLETEをチェック
評価ストレス: EVAL_STRESS_COMPLETEをチェック
評価Day2: EVAL_DAY2_COMPLETEをチェック
ドキュメント監査者: DOC_AUDIT_COMPLETEをチェック

シグナルがない場合、エージェントが切り詰められた可能性があります。不完全なエージェントをユーザーに報告し、部分的なデータでその摂取ドキュメントを作成しないでください。有効なシグナルを持つ他の摂取ドキュメントは引き続き作成できます。

有効なシグナルを持つエージェントの場合、摂取ドキュメントを作成します:

ヘルスチェック: docs/plans/YYYY-MM-DD-audit-slug/health-audit.mdをfrontmatterのtype: repo-healthで作成
評価: 3つのすべての評価者出力をdocs/plans/YYYY-MM-DD-audit-slug/eval.mdに統合し、frontmatterでtype: repo-evalとpillar_overridesを含める
ドキュメント: docs/plans/YYYY-MM-DD-audit-slug/doc-audit.mdをfrontmatterのtype: doc-healthで作成

個々の摂取スキルのSKILL.mdファイル（repo-health、repo-eval、doc-health）の正確な出力テンプレートを参照してください。

ステップ 7: マニフェストにログする

リポジトリルートの.claude/skill-runs.jsonにエントリを追加します。ファイルが存在しない場合、最初に空の配列で作成します。各エントリは、スキル使用状況がリポジトリとOS再インストール全体で追跡できるよう、スキルが実行された時刻を記録します。

{
  "skill": "audit",
  "date": "YYYY-MM-DD",
  "plan": "YYYY-MM-DD-audit-slug",
  "audits": ["health", "eval", "docs"]
}

audits: 選択された監査をリストアップします（health、eval、docsのサブセット）
既存ファイルを読み、JSONの配列をパースし、新しいエントリを追加して、書き戻します
ファイルが不正な場合、新しいエントリのみを含む新鮮な配列でそれをオーバーライトします

ステップ 8: ハンドオフ

監査完了: docs/plans/YYYY-MM-DD-audit-slug/

生成された摂取ドキュメント:
- [health-audit.md — X critical、Y high、Z medium、W low]
- [eval.md — N/12の柱がターゲットで達成]
- [doc-audit.md — Xドリフト、Yギャップ、Z陳腐化、Wブロックされたリンク]

改善するには、実行してください:
/pipeline YYYY-MM-DD-audit-slug

パイプラインはすべての監査タイプにわたって1つの統合プランを作成します。

ルール

実施: 監査選択質問を最初に、単独で尋ねる
実施: フォローアップ質問を1つずつ尋ね、各回答を待つ
実施しない: すべての質問に回答した後、ユーザーに再度プロンプトを表示しない — すべてのエージェントを自律的に実行
実施しない: 改善を開始しない — 唯一の出力は摂取ドキュメント
実施しない: 摂取ドキュメントを作成した後、評価者または監査者エージェントを再度実行しない — このスキル中に正確に1回実行します。再評価は改善完了後の/pipelineで発生します。
実施: ロールプロンプトの内容をエージェントプロンプトに埋め込む（エージェントはスキルディレクトリファイルにアクセスできません）
実施: すべての摂取ドキュメントを同じプランディレクトリに生成
実施: 各監査完了後に結果を報告

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

audit

SKILL.md 本文

監査

入力