classmethod/ipa-security-guide

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 の除外対象セクションも参照）:

• <!-- 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 をしない