security-review

プラグインの確認：node "${PLUGIN_ROOT}/scripts/check-version.js" を実行します。メッセージが出力された場合は、続行する前にユーザーに表示してください。

セキュリティレビュー

Power Pages サイトのセキュリティレビュー全体をユーザーに案内します。一致するフォーカススキルを実行し、すべての検出結果を単一の HTML レポートにまとめます。

このスキルでは、ユーザーに技術的な質問をすることはありません。会話では、平易な言葉を使います。

最初のリクエスト： $ARGUMENTS

ワークフロー

このスキルには 6 つのフェーズがあります。フェーズ 2～5 は、それぞれユーザーとの会話の 1 つの段階に対応します。フェーズ 1 と 6 は、ユーザーに見せないセットアップと後片付けです。各段階の目的については、references/flow.md を参照してください。

フェーズ	実行内容	ユーザーへの説明
1 — 前提条件	プロジェクトを見つけ、作業フォルダーをセットアップする	（非表示のセットアップ）
2 — 範囲	目的を確認する — 質問は 1 つ、回答は 3 択、平易な言葉を使う	目的を尋ねる
3 — スキル	一致するスキルを実行し、進捗を伝える	スキャン中
4 — レポート	結果の概要とセクションごとの検出結果を含む統合レポートを作成する	結果の概要 + 検出結果
5 — 提示	結果を提示し、修正対応のフォローアップを提案する	次のステップとガイダンス
6 — 後片付け	一時ファイルを削除する	（非表示の後片付け）

タスクの追跡

タスクを 3 つのグループに分けて作成します。各タスクは、開始時に in_progress、完了時に completed に設定します。

グループ 1 — 前提条件の確認開始時に作成：

タスクの件名	activeForm
前提条件の確認	前提条件を確認中

このタスクのみ作成します。前提条件の確認が完了するまで、他のタスクは作成しないでください。

グループ 2 — 前提条件の確認完了後に作成：

タスクの件名	activeForm
目的の確認	目的を確認中

グループ 3 — 目的の確認後に作成：

タスクの件名	activeForm
スキルの実行	チェックを実行中
レポートの作成	レポートを作成中
検出結果の提示	検出結果を提示中
後片付け	後片付け中

---

1. 前提条件

1.1 プロジェクトを見つける

Glob を使って **/powerpages.config.json を探します。見つからない場合は、まず /create-site でサイトを作成する必要があることをユーザーに伝え、その後停止します。

monitor と release の目的（scan-site または manage-firewall に処理を委任する目的）の場合は、.powerpages-site/website.yml が存在することも確認します。存在しない場合、サイトはまだデプロイされていません。ライブセキュリティレビューを実行するには、まず一度サイトをデプロイする必要があることを平易な言葉でユーザーに伝え、/deploy-site を推奨した後、停止します。サイト名や URL からサイトを特定しようとしないでください。異なるサイトが同じ名前を共有している場合があります。

code-config の目的では、デプロイの確認は不要です。ソースコード、依存関係、認証、Web ロール、テーブルのアクセス許可は、ローカルファイルのみから読み取ります。

1.2 一時作業フォルダーを準備する

新しい作業ディレクトリ <SYSTEM_TEMP>/security-review/ を作成します。このフォルダーには、各スキルがレビュー モードで出力する JSON データファイルを保存します。このフォルダーは後片付けの手順で削除します。

前回の実行が中断されてフォルダーがすでに存在する場合は、続行する前にフォルダー自体ではなく、その中身を削除します。

1.3 ドキュメントの出力先パスを決める

最終 HTML は常に <PROJECT_ROOT>/docs/security-review-<YYYY-MM-DD-HHMMSS>.html に保存します。時刻には実行開始時のローカルタイムスタンプを使います（例：security-review-2026-05-14-053805.html）。必ずタイムスタンプを含めてください。security-review.html のようなタイムスタンプのない名前は使わないでください。これにより、実行ごとに異なるレポートを保存できます。

---

2. 目的を確認する

2.1 目標を確認する

🚦 ゲート（plan · security-review:2.1.goal）： レビューの目標を確認します。選択内容に応じて、3 つのサブスキルセット（code-config／release／monitor）のいずれかに分岐します。

実行タイミング： Phase 2.1 の開始時。ただし、$ARGUMENTS ですでに回答されている場合を除きます。 質問する理由： release を自動選択すると、すべてのサブスキルが実行されます（時間がかかり、不要なスキャンやファイアウォールのエンドポイントへのアクセスが発生する可能性があります）。誤った目標を自動選択すると、レビューの範囲が不適切になります。 キャンセル時： 何も実行されません。まだサブスキルは呼び出されていません。

AskUserQuestion を 1 回だけ呼び出して、ユーザーに質問します。ユーザーの最初のリクエストですでに回答されている場合は、スキップして続行します。

質問 — 何をレビューしますか？

ラベル	説明
コードと設定	ソースコード、依存関係、認証、ウェブロール、テーブルの権限を確認します。ローカルファイルのみを対象にします。
リリース準備状況	公開前に全体をレビューし、すべてを確認します。（推奨）
デプロイ済みサイト	稼働中のサイトに問題がないか確認します。デプロイが必要です。

目標の対応付け（内部用）：

ラベル	目標 ID	スキル
コードと設定	code-config	scan-code、audit-permissions、setup-auth（読み取り専用）
リリース準備状況	release	scan-code、scan-site、manage-headers、manage-firewall、audit-permissions、setup-auth（読み取り専用）
デプロイ済みサイト	monitor	scan-site

2.2 選択したスキルセットを記録する

回答に基づいて selectedSkills リストを作成します。code-config と release の目標では、常に setup-auth の読み取り専用チェックを含めます（既存の YAML を読み取るだけで、スキル自体は実行しません。詳しくは下記 § 3.2 を参照してください）。これは アクセスとデータセキュリティの検証 の一部です。

---

3. 該当するスキルを実行する

Agent ツールを使用して、選択した各スキルをバックグラウンドのサブエージェントとして起動します。各サブエージェントは、引数 --review <SYSTEM_TEMP>/security-review/ を指定してスキルを呼び出します。各スキルは、認証、エラー報告、進捗管理を独自に処理します。

3.1 サブエージェントによるスキルの呼び出し

スキルは、Agent ツールを使用した並列サブエージェントとして実行されます。

デフォルト — Agent の対象となるすべてのスキルを、1 つの並列バッチで起動します。 複数の Agent ツール呼び出しを含む 1 つのメッセージで、選択したすべてのサブエージェントを起動し、並行して実行します。各サブエージェントは run_in_background: true を指定して実行します。Agent の対象となるスキルは scan-code、scan-site、manage-headers、manage-firewall です。これらはすべて --review モードに対応しています。scan-site（サーバー側のスキャンで数分かかります）と scan-code（ローカルの静的解析と依存関係のスキャンで、大規模なプロジェクトでは数分かかる場合があります）が最も時間のかかるスキルです。それ以外は通常、数秒で完了します。

フォールバック — 段階的に起動します。 何らかの理由でハーネスが並列バッチ呼び出しを拒否した場合は、まず時間のかかる scan-code と scan-site を起動し、その後のメッセージで残りのスキルを起動します。これはツールの制約に対するフォールバックであり、推奨される方法ではありません。

インラインチェック（サブエージェントの実行中に行います）。 audit-permissions と setup-auth は --review に対応していないため、Agent 経由で起動してはなりません。§ 3.2 の説明に従ってインラインで処理します。

レポート作成の手順に進む前に、すべてのサブエージェントが完了するまで待機します。

3.1.1 サブエージェントのプロンプトパターン

各サブエージェントには、以下を含む自己完結型のプロンプトを渡します。

1. 呼び出すスキル、および一時ディレクトリのパスを指定した --review 引数
2. スキルがサイトファイルを特定できるようにするプロジェクトのルートパス
3. スコープ確認手順で取得した範囲／深度のパラメーター

サブエージェント呼び出しの例：

Agent({
  description: "Run scan-site",
  prompt: "Invoke the skill `scan-site` with argument `--review <SYSTEM_TEMP>/security-review/`. The Power Pages project root is <PROJECT_ROOT>. <any additional scope parameters>. Write the **transform script stdout verbatim** to <SYSTEM_TEMP>/security-review/scan-site.json. Do NOT synthesize, augment, or re-classify the findings. If the skill fails, write { \"status\": \"skipped\", \"reason\": \"<plain-language reason>\" } instead.",
  run_in_background: true
})

逐語ルール： サブエージェントの出力 JSON には、スキルの変換スクリプトが出力した検出結果だけを含めなければなりません。オーケストレーターは、検出結果の追加、タイトルの書き換え、重大度の追加、その他の編集を行ってはなりません。

3.1.2 期待される出力

すべてのサブエージェントの完了後、<SYSTEM_TEMP>/security-review/<skill-name>.json に JSON ファイルが出力されます。各ファイルは、スキルの変換スクリプトが生成する { status, findings, details? } 形式です。

<SYSTEM_TEMP>/security-review/
├── scan-code.json           (when invoked)
├── scan-site.json
├── manage-headers.json
├── manage-firewall.json
└── audit-permissions.json   (when invoked)

スキルのサブエージェントが失敗またはスキップされた場合は、{ "status": "skipped", "reason": "<平易な言葉による理由>" } 形式のプレースホルダーファイルを作成します。レポート作成のステップでは、§ 3.1.3 との一貫性を保つため、severity フィールドのない、そのセクションの単一の非重大度の所見として表示されます。

3.1.3 重大度ポリシー

重大度を実際に出力するツールに由来する所見のみ、severity フィールドを含めることができます。

セクション	ソース	重大度を指定できますか？
scan-code	opengrep、trivy	はい
scan-site	deep-scan (ZAP)	はい
manage-headers	transform-headers.js（インベントリ）	いいえ
manage-firewall	transform-firewall.js（インベントリ）	いいえ
audit-permissions	Web ロールとテーブル権限の監査	いいえ
setup-auth	サイト設定と認証関連ソースコードの監査	いいえ

インベントリのセクションでは、所見に severity を追加しないでください。info も含め、いかなる値も追加してはいけません。サブエージェントとオーケストレーターは、意見に基づく重大度付きの所見を挿入せず、変換出力をそのまま書き込む必要があります。重大度の代替手段として tag フィールドを使うことも禁止されています。このフィールドは、ツールによる短い機械可読識別子（例：ZAP ルール ID、CWE コード）専用です。レポートテンプレートではタイトルの横に表示されるチップとしてレンダリングされるため、重大度と同等の文字列（critical、warning、info）を指定してはいけません。

3.1.4 注釈ポリシー（平易な言葉によるテキスト）

manage-firewall と manage-headers の変換スクリプトは、構造化された生データのみを生成し、平易な言葉による説明をハードコードしません。サブエージェントは注釈 JSON ファイルを生成し、--annotations を介して変換スクリプトに渡す必要があります。注釈には次の内容を含めます。

• ルールごと、またはヘッダーごとの平易な言葉による説明
• 実際に問題がある場合に限り、任意の修正案

注釈ファイルの形式については、各スキルの SKILL.md § 5.1 を参照してください。エージェントの役割は、生データに基づいて正確かつ簡潔な説明を書くことであり、重大度を作り上げたり、問題を捏造したりすることではありません。

3.2 --review モードのないスキル

audit-permissions と setup-auth は --review をサポートしていません。これらはインラインで処理し、バックグラウンドのサブエージェントとして実行しないでください。

• audit-permissions — Agent ではなく Skill ツールを使って呼び出します。このスキルはWeb ロールとテーブル権限の両方を監査するため、出力には両方を含めます。完了後、出力を読み、所見を共通の所見フィールド（id、title、location、details、fix）にマッピングして、統一された { status, findings, details? } 形式で <SYSTEM_TEMP>/security-review/audit-permissions.json に書き込みます。
• setup-auth — スキルとして呼び出さないでください。代わりに .powerpages-site/site-settings/ の YAML ファイルを直接読み、次の項目を確認します。
  • ID プロバイダーが設定されているか？（Authentication/OpenIdConnect/*/Authority）
  • プロファイルへのリダイレクトが無効になっているか？（Authentication/Registration/ProfileRedirectEnabled = false）
  • Cookie の SameSite 設定はどうなっているか？（HTTP/SameSite/Default）

結果の所見を、同じ形式で <SYSTEM_TEMP>/security-review/setup-auth.json に書き込みます。

両セクションのフィールドポリシー — これらはインベントリのセクションであり、ツール出力の重大度ではありません（§ 3.1.3 を参照）。

• どの所見にも severity フィールドを含めないでください。
• tag フィールドを含めないでください。tag フィールドは、ツールによる短い機械可読識別子（HTTP/X-Frame-Options、ZAP ルール ID 10055、CWE コード）専用です。レポートテンプレートでは tag がタイトルの横に表示されるチップとしてレンダリングされるため、LLM が判断した重大度をそこに隠して指定し、このセクションで明示的に禁止されている重大度の分類を視覚的に再現することは禁止されています。

3.3 状況の更新

すべてのチェックを並行して実行していることをユーザーに伝えます。各サブエージェントが完了したら、短い進捗メッセージを伝えます（例：「コードチェックが完了しました — 重要な問題が2件、軽微な問題が4件あります。」）。専門用語は避けます。スキルの内部的な手順について説明しないでください。すべてのサブエージェントが完了したら、レポートの作成に進む前に、すべてのチェックが完了したことを伝えます。

---

4. 統合レポートの作成

4.1 統合

平易な言葉で、次のステップに関する推奨事項を最大4件、JSON 文字列配列として <SYSTEM_TEMP>/security-review/next-steps.json に書き込みます。全体の状況を2～4文で平易に要約した summary を作成します。

node "${PLUGIN_ROOT}/scripts/build-review-data.js" \
  --reportName "Security Review" \
  --inputDir "<SYSTEM_TEMP>/security-review/" \
  --siteName "<SITE_NAME>" \
  --goalLabel "<GOAL_LABEL>" \
  --scopeLabel "<SCOPE_LABEL>" \
  --summary "<SUMMARY_TEXT>" \
  --nextStepsFile "<SYSTEM_TEMP>/security-review/next-steps.json" \
  --output "<SYSTEM_TEMP>/security-review/security-review-data.json"

4.2 マスター HTML のレンダリング

node "${PLUGIN_ROOT}/scripts/render-review.js" \
  --output "<DOCS_PATH>" \
  --data "<SYSTEM_TEMP>/security-review/security-review-data.json"

---

5. 提示とフォローアップ

5.1 ブラウザーで開く

<DOCS_PATH> をユーザーの既定のブラウザーで開きます。

5.2 スキルの使用状況を記録

参照：${PLUGIN_ROOT}/references/skill-tracking-reference.md

--skillName "SecurityReview" を使用します。

5.3 チャットでの要約

🚦 ゲート（plan · security-review:5.3.next-action）： レポート提示後の次のアクションを尋ねるプロンプト — 「修正方法を説明して／レビューを再実行して／今回はここまで」。修正スキルを呼び出すかどうかを決定します。

トリガー： フェーズ5.1で HTML レポートを書き込みました。 確認する理由： ユーザーがレポートを読む前に修正スキル（/manage-headers、/manage-firewall、/audit-permissions）を自動で呼び出さないようにするため。また、結果がまだ新しい状態でレビューを自動的に再実行すると、時間を無駄にするためです。 キャンセル時に残るもの： なし — docs/security-review-<ts>.html の HTML レポートが最終成果物です。

問題の件数（critical／warning／info）とレポートの保存場所を含む、平易な短い要約をチャットに表示します。その後、AskUserQuestion を使って次のアクションを尋ねます。

質問	選択肢
次に何をしますか？	修正方法を説明して；レビューを再実行して；今回はここまで

ユーザーが「修正方法を説明して」を選んだ場合は、critical の問題をセクションごとにまとめ、それぞれに対応するスキル（/manage-headers、/manage-firewall、/audit-permissions など）を案内します。

ユーザーが「再実行」を選んだ場合は、同じ目標と範囲でこのスキルを再度実行します。

---

6. クリーンアップ

<SYSTEM_TEMP>/security-review/ フォルダー全体を削除します。docs/ に保存された最終 HTML は残します。一時ファイルを削除したことをユーザーに伝えます。

クリーンアップに失敗した場合（ファイルロック、権限など）は、ユーザーに警告して処理を続けます — レポートはすでに書き込まれており、一時フォルダーは後で手動で削除できます。

制約

• ユーザーには平易な言葉で説明する — 技術用語から説明を始めないでください。
• サブエージェントへの並行委任 — 選択した各スキルを、Agent ツール経由で並行サブエージェントとして、1回のメッセージで起動します。サブエージェントの実行中に、インラインの読み取り専用 setup-auth チェックを行います。並行バッチ呼び出しがハーネスに拒否された場合に限り、段階的な起動（§ 3.1 のフォールバック）を使用します。
• 統合 HTML は1つだけ — この実行中にスキルごとの HTML レポートを作成しないでください。スキルは --review モードで実行します。
• 一貫した見た目と使い心地 — ${PLUGIN_ROOT}/scripts/lib/templates/security-review-report.html の共有テンプレートを scripts/render-review.js 経由で使ってレンダリングします。スキルごとの HTML を作成したり、テンプレートを複製したりしないでください。生成するレポートは、既存の audit-permissions レポートと視覚的に一致させます。
• クリーンアップは必須 — クリーンアップは省略できません。クリーンアップの失敗は致命的でない警告として扱いますが、スキルは必ずクリーンアップを試みます。
• 破壊的なサブアクションを自動実行しない — 変更を提案するスキル（例：サイト設定の編集、WAF ルールの削除）は、このオーケストレーション中に読み取り専用の --review モードで実行する必要があります。変更を適用するのは、ユーザーがアクションを選択した後の「修正方法を説明して」というフォローアップに限ります。

参考資料

• references/flow.md — フェーズ2～5での会話の進め方についての根拠と表現例