--- name: ipa-security-guide description: ipa-security-check をはじめとするセキュリティ診断ツールが出力したレポートを読み込み、各検出項目を優先順位付きの dev-debug 依頼リストに変換する。対象プロジェクトの言語・FWを問わず汎用的に使える。コードベースを直接読んでアーキテクチャ判断を行う。 argument-hint: "[レポートファイルパス (省略時: ipa-security-report-*.md を自動検出)] [-o 出力ファイルパス]" --- # IPA Security Guide Skill ## このスキルが行うこと `ipa-security-check` をはじめとするセキュリティ診断ツールが出力したレポートを読み込み、以下を出力する。 1. **対応不要候補リスト** — アーキテクチャや設計上の理由で対応不要と考えられる件と根拠。最終判断はユーザーが行う 2. **優先順位付き依頼リスト** — `tsumiki:dev-debug` にそのままコピペできるフォーマット 3. **まとめテーブル** — 全件を一覧で整理 外部ツールへの依存なし。コードベースを直接読んでアーキテクチャを判断する。 ## 起動方法 ``` /ipa-security-guide /ipa-security-guide <レポートファイルパス> /ipa-security-guide -o <出力ファイルパス> /ipa-security-guide <レポートファイルパス> -o <出力ファイルパス> ``` - レポートファイルパスを省略した場合は、`security-reports/ipa-security-report-*.md` を優先して自動検出する。見つからない場合はカレントディレクトリの `ipa-security-report-*.md` も検索する - **1件のみ**: 自動で使用する - **複数件**: ファイル名一覧を提示し、AskUserQuestion でユーザーに選んでもらう - **0件**: `ipa-security-report.md` へのフォールバックを試みる。それも存在しない場合はエラーを報告して終了する - `-o` を指定した場合は結果をそのパスに Write する。省略した場合は画面出力のみ ## 前提条件 - 入力はセキュリティ診断ツール（`ipa-security-check` 等）が生成した Markdown レポートであること - 対象プロジェクトの言語・フレームワークは問わない ## ファイル構成 ``` ipa-security-guide/ ├── SKILL.md ← 本ファイル（Claude が最初に読む） ├── knowledge/ │ ├── triage.md ← 対応不要の判断基準・除外対象の定義 │ └── priority.md ← 優先順位・グループ化の基準 └── lib/ └── output_formatter.md ← 依頼リスト・結果出力のフォーマット定義 ``` ## 実行手順 ### ステップ1: 事前準備（一括読み込み） 以下をすべて Read する。件ごとに読み直さない。 1. レポートファイル（「起動方法」のファイル検出ルールに従って特定する） - 存在しない場合はエラーを報告して終了 - レポートのヘッダーからプロジェクトのルートディレクトリを推定する 2. `knowledge/triage.md` 3. `knowledge/priority.md` 4. `lib/output_formatter.md` ### ステップ2: 検出ファイルを一括で Read する レポートから全検出項目のファイルパスを一覧化し、**まとめて Read する**。 1件ずつ処理しながら読むのではなく、先にすべて読んでコンテキストに入れる。 - ファイルが見つからない場合はユーザーに正しいパスを確認してから進む - 無闇に Grep で全ファイルを探さない - 判断に必要な関連ファイルは「この件を分析した結果、判断できなかった場合のみ」追加で Read する ### ステップ3: 全件を一括で分析する ステップ1〜2で読んだ内容をもとに、全検出項目を一括で分析する。件ごとにループして都度判断するのではなく、全体像を把握した上でまとめて行う。 **分析対象から除外する finding（`triage.md` の除外対象セクションも参照）:** - `` ブロックで `status: 問題なし` または `status: 保留` が設定されているもの（ユーザーがトリアージ済み） - `## 偽陽性候補` セクションに分類されているもの（false-positive-review が偽陽性の疑いありと判定） - 分析対象は `status: 未対応` と `status: 対応する` の finding のみ 各件について以下を判断する： #### 3a. ファイルの目的と検出箇所の文脈を把握する - このファイルが何をしているか - 検出箇所がどのような文脈にあるか - 修正が可能か、どう修正すべきか #### 3b. 対応不要候補の特定 `triage.md`（ステップ1で読済み）の基準で対応不要候補を特定する。 候補が見つかった場合は**必ずユーザーに提示して最終判断を求める**。スキル単独で確定しない。 ユーザーが対応不要と確定した項目については `ipa-skip` コメント追加の依頼を生成する。 #### 3c. グループ化と優先順位付け `priority.md`（ステップ1で読済み）の基準でグループ化と優先順位を決める。 ### ステップ4: 依頼リストを生成・出力する `output_formatter.md`（ステップ1で読済み）のフォーマットに従って結果を出力する。 `-o` オプションが指定されている場合は、出力内容を指定パスに Write する。 省略されている場合は画面に出力するのみ。 ## 重要な原則 - **コードを読む前に対応不要と断定しない** — 判断は必ずコードを確認してから下す - **対応不要の最終判断はユーザーが行う** — スキルは候補と根拠を提示するだけ。確定はユーザーの承認後 - **不明点はユーザーに確認する** — コードから辿れない場合は推測せず一時停止して聞く。ファイルパスやアーキテクチャの詳細など、ユーザーが把握していることは多い - **推測で判断しない** — 確認できなかった情報は「確認できず」と明記し、依頼文内に調査を含める - **アーキテクチャ依存の判断は根拠付きで明示する** — 「なぜ対応しなくてよいか」を省略しない - **依頼文は tsumiki が迷わず実行できる粒度にする** — 情報が足りない依頼は作らない - **不要な Read を避ける** — 検出ファイルから判断できる場合は追加の Grep・Read をしない