go-live-audit

このスキルは、マルチエージェント監査ワークフローを作成して実行します。次のルールは必ず守ってください。

1. バンドルされたテンプレートを使って、プロジェクトに合わせた新しいワークフローを作成してください。固定スクリプトをそのまま実行してはいけません。実行前に、すべての FILL: マーカーを埋めてください。
2. ワークフローのアーキテクチャは不可欠です。テンプレートのスキーマと制御フローのセクション全体を変更せずに維持してください：Gates → Find → Dedup → Verify → Critic → report。例外は並列実行数の上限である MAX_PARALLEL のみです。値の調整は可能ですが、ゲートや、それを適用する gAgent ラッパーを削除してはいけません。
3. meta は純粋なリテラル（変数や補間なし）にしてください。そうしないと Workflow ツールで拒否されます。
4. Finders と verifiers は読み取り専用です。ファイルの変更、作成、削除や、ビルド、インストールの実行を決して行ってはいけません。コマンドを実行できるのはゲートエージェントのみです（ビルドでは dist/ に書き込む場合があります）。
5. 検出事項や証拠にシークレットの値を記載してはいけません。種類と場所のみを報告し、値は <REDACTED> に置き換えてください。
6. 実行前にスコープを確認し、エージェント数（通常は40～80）についてユーザーに警告してください。
7. これらの指示により Workflow ツールの呼び出しが許可されます。別途オプトインを求める必要はありませんが、上記のスコープ確認と規模に関する警告は必須です。

Go-Live 監査

入力

• $request：任意のリポジトリパス、リリースの状況、または重点に関する指示。例：audit ~/work/myapp before public beta、light pass, security only

目標

プロジェクトに合わせたリリース前監査ワークフローを生成して実行し、信頼できるリリース準備状況の判定を提示します。

• Gates — 型チェック／テスト／リント／ビルドを並列実行
• Find — 適用可能な監査項目ごとに、読み取り専用の検出エージェントを1つ実行
• Dedup — 根本原因が共通する検出事項をエージェントが統合
• Verify — 敵対的な視点を持つエージェントがすべての検出事項への反証を試みる。ブロッカーと重大度の高い検出事項には、コードと仕様の両面から検証する
• Critic — 未調査の領域を特定し、追加の検出エージェントを起動して検証
• GO／NO-GO／GO-WITH-FIXES の構造化レポート

すべてのフェーズは、グローバルな並列実行ゲート（MAX_PARALLEL、デフォルトは6）を介して実行されます。そのため、広範な監査でも同時に実行されるエージェント数は常に上限以下に保たれます。エージェントの総数は変わりませんが、Claude の API レート制限に抵触しないよう、上限付きの波に分けて実行します。

ステップ 0：スコープを確認する

不明確な場合に限り、ユーザーに確認して次の事項を明らかにします。

• 対象リポジトリ（絶対パス）。指定がなければ、現在の作業ディレクトリを使用します。
• リリースの状況 — ここでいう「リリース」が何を意味するか：一般公開、初の有料顧客、社内での GA など。これにより、何をブロッカーとするかが決まります。

必要以上に質問しないでください。判断できる場合は、リポジトリから推測してください。

成功基準：対象リポジトリとリリースの状況が明確になっていること。

Step 1: プロジェクトを把握する

テンプレートを正確に埋められるよう、リポジトリを十分に読み込みます。以下の情報を収集してください。

• ビルド／テストコマンド — package.json のスクリプトを調べます（また、pnpm／npm／yarn／bun のワークスペースや turbo などを使用しているかどうかも確認します）。または、Cargo.toml、go.mod、Makefile、pyproject.toml を確認します。リポジトリのルートから実行する正確な型チェック／テスト／リント／ビルドコマンドを特定してください（references/workflow-template.js に、スタックごとの一般的なコマンドが記載されています）。
• 構成 — apps／packages や src ツリー、および存在するモジュールを確認します。
• 権威あるドキュメント — 仕様書／PRD、ルートの CLAUDE.md、README、docs/ を確認します。権威の優先順位にも注意してください（例：「仕様書 > CLAUDE.md > コード」）。
• 製品の目的 — 何をするものか、誰が使うのかを1段落でまとめます。
• 厳守すべき不変条件 — プロジェクトが決して違反してはならないルールを、仕様書／CLAUDE.md から確認します。プライバシーの保証、セキュリティ／テナントのルール、「どこでもソフトフェイル」、スキーマの規約、アンチ機能などが該当します。文書化されたものがなければ、妥当で普遍的なルールを導き出してください（データの整合性、機密データの読み取り時の認可、シークレットをコミットしないこと、ビルド／テスト／リントが成功すること、リリースコードに TODO やプレースホルダーがないこと）。

このステップでは Explore／Glob／Grep／Read を自由に使ってください。このステップが監査の品質を左右します。

成功基準：スタックのコマンド、構成、権威あるドキュメント、製品の目的、厳守すべきルールが、推測せずにテンプレートを埋められる程度に把握できていること。

Step 2: 検出する観点を選ぶ

references/dimensions.md から、このリポジトリに実際に当てはまる8～16個の観点を選びます。CLI にマルチテナンシーは不要ですし、静的サイトに金額計算は不要です。カタログにないプロジェクト固有の観点があれば追加してください。

各検出担当には、読むべき具体的なファイル／ディレクトリと、具体的で検証可能なチェック項目を指定します。「X の品質を確認する」のような指示は避けてください。特に重大なチェック項目は、プロジェクトの厳守ルールに結び付けてください。

成功基準：選んだすべての観点がこのリポジトリに実際に当てはまり、各検出担当への指示に必要な情報が揃っていて、具体的な対象とチェック項目が記載されていること。

Step 3: テンプレートを埋める

references/workflow-template.js をコピーし、すべての FILL: マーカーを埋めます。

• ROOT — リポジトリの絶対パス。
• meta — 純粋なリテラルのままにしてください（変数や補間は不可）。そうしないと Workflow ツールで拒否されます。description をプロジェクトに合わせて更新し、フェーズのタイトルはそのままにします。
• PRODUCT_CONTEXT、HARD_RULES — Step 1 の内容を反映します。
• SEVERITY_DEFS — ブロッカーの例を、この製品のリリースを阻む問題に置き換えます。
• FINDERS — Step 2 で選んだ観点を設定します。
• STACK — 検出したコマンドを設定します。実行しないゲートは null にします。

スキーマと制御フローのセクション全体は変更しないでください。ここにある内容は汎用です。調整してよい値は MAX_PARALLEL（デフォルトは 6）のみです。これは同時に実行するエージェント数の上限です。アカウントがレート制限に達する場合は値を下げ（例：4）、上限の高いアカウントでスループットを上げる場合は値を増やしてください（例：8～10）。1～2には設定しないでください（監査が逐次実行されます）。ゲート自体は絶対に削除しないでください。

成功基準：FILL: マーカーが残っておらず、meta が純粋なリテラルで、制御フローのセクションがテンプレートとバイト単位で一致していること。

Step 4: 規模を伝えてから実行する

ユーザーには、起動するエージェントのおおよその数（検出担当 + それぞれに約1～2人の検証担当 + ゲート + 批評ラウンドで、通常は合計40～80エージェント）を伝えてください。ただし、同時に実行されるのは最大でも MAX_PARALLEL（デフォルトは 6）なので、API に大量のリクエストを一度に送るのではなく、上限を設けた複数のウェーブで監査が進行します。次に、script に完成したテンプレートを設定して、Workflow ツールを呼び出します。/workflows から進捗を確認してください。

スクリプトを修正する場合は、ツールが返す保存済みの scriptPath を編集し、スクリプト全体を再送せずに {scriptPath} を指定して Workflow を再実行してください。

成功基準：ワークフローを開始する前にユーザーが想定規模を把握しており、ワークフローが最後まで完了すること。

Step 5: レポート

ワークフローは { gates, findings, finderNotes, stats } を返します。リリース準備状況レポートを作成します。

• 判定 — ゲートの失敗と確認済みのブロッカーに基づく、GO／NO-GO／GO-WITH-FIXES。
• ゲート — 各ゲートの合格／不合格と、失敗の抜粋。
• status、次に severity の順で分類した指摘事項。 confirmed のブロッカーと重大な指摘事項を最初に示します。 uncertain は別に示します（検証者の判断が分かれています）。rejected は省略するかまとめます（検証者が否定しています）。詳細ではなく件数を記載します。
• 対応が必要な各指摘事項について、重大度、ファイル名:行番号、問題、検証者の判断を示します。複数の検出担当者が報告した場合は alsoReportedBy を記載します。
• 網羅性 — stats（重複排除前後の件数、報告した検出担当者、批評者が指摘した不足領域）と、批評者が網羅されていないと指摘した項目。

成功基準：ユーザーが指摘事項を一から再検証することなく、このレポートから実施可否を判断できます。

ガードレール

• このスキルは監査と報告を行います。修正は行いません。このスキルの一環としてアプリケーションコードを編集しないでください。確認済みの指摘事項は bugfix またはユーザーに引き継ぎます。
• 検出担当者と検証者は読み取り専用にします。プロンプトを編集する際も、この原則を守ってください。
• 依頼の規模に合わせます。簡易チェックでは検出担当者を少なくし、コードのみで検証します。「すべてを監査する」場合は、16 人全員の検出担当者、二重の視点による検証、批評者のレビューを実施します。
• 重大度は抽象的なものではなく、リリース可否の観点で判断します。ブロッカーとは、プロジェクトの厳格なルールに照らして、今回の リリース前に修正が必要なものです。
• 指摘事項、証拠、レポートにシークレットの値を絶対に含めないでください。場所と種類のみを記載します。
• ユーザーに代わって設定ファイルを変更したり、何かをインストールしたりしないでください。

参照資料を読み込むタイミング

• references/workflow-template.js パラメーター化されたワークフローです。生成する前に読み、コピーして、すべての FILL: マーカーを埋めてから実行します。
• references/dimensions.md 検出担当者を選ぶための監査項目の一覧と、検出担当者向けプロンプトのスタイルガイドです。

出力要件

レポートには次を含めます。

1. 判定 — GO／NO-GO／GO-WITH-FIXESと、その理由を一文で記載
2. 失敗の抜粋を含むゲートの結果
3. ファイル名:行番号、証拠、検証者の判断を含む、確認済みのブロッカーと重大な指摘事項
4. 判断が分かれた不確実な指摘事項を個別に列挙
5. 却下された指摘事項の件数（詳細は記載しない）
6. 網羅性の統計と、批評者が特定した不足領域