ipa-security-guide - SKILL.md Agent Skill

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.md
knowledge/priority.md
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 をしない