/ipa-security-guide

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

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