| 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 をはじめとするセキュリティ診断ツールが出力したレポートを読み込み、以下を出力する。
- 対応不要候補リスト — アーキテクチャや設計上の理由で対応不要と考えられる件と根拠。最終判断はユーザーが行う
- 優先順位付き依頼リスト —
tsumiki:dev-debug にそのままコピペできるフォーマット
- まとめテーブル — 全件を一覧で整理
外部ツールへの依存なし。コードベースを直接読んでアーキテクチャを判断する。
起動方法
/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 する。件ごとに読み直さない。
- レポートファイル（「起動方法」のファイル検出ルールに従って特定する）
- 存在しない場合はエラーを報告して終了
- レポートのヘッダーからプロジェクトのルートディレクトリを推定する
knowledge/triage.mdknowledge/priority.mdlib/output_formatter.md
ステップ2: 検出ファイルを一括で Read する
レポートから全検出項目のファイルパスを一覧化し、まとめて Read する。
1件ずつ処理しながら読むのではなく、先にすべて読んでコンテキストに入れる。
- ファイルが見つからない場合はユーザーに正しいパスを確認してから進む
- 無闇に Grep で全ファイルを探さない
- 判断に必要な関連ファイルは「この件を分析した結果、判断できなかった場合のみ」追加で Read する
ステップ3: 全件を一括で分析する
ステップ1〜2で読んだ内容をもとに、全検出項目を一括で分析する。件ごとにループして都度判断するのではなく、全体像を把握した上でまとめて行う。
分析対象から除外する finding（triage.md の除外対象セクションも参照）:
<!-- ipa-triage:begin ... ipa-triage:end --> ブロックで 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 をしない
