running-code-analyzer

コードアナライザー スキルの実行

⚠️ 重要：スクリプトの使用は必須です

コードアナライザーの結果に関するすべての操作は、<skill_dir>/scripts/ 内の同梱スクリプトを必ず経由してください。例外はありません。

❌ 誤り — 絶対に行わないでください：

# WRONG: inline Python to parse results
python3 -c "import json; data = json.load(open('results.json'))..."

# WRONG: inline Node.js to parse results
node -e "const data = require('./results.json')..."

# WRONG: jq to filter results
cat results.json | jq '.violations[] | select(.engine=="pmd")'

# WRONG: reading the results file directly (it can be 10MB+)
Read tool → code-analyzer-results-*.json

run_code_analyzer およびあらゆる mcp__* ツールも禁止です。Bash のみを使用してください。

✅ 正しい — 必ず次の方法で行ってください：

# Summarize scan results
node "<skill_dir>/scripts/parse-results.js" "./code-analyzer-results-TIMESTAMP.json"

# Filter/rank/query results (by engine, severity, file, rule, category)
node "<skill_dir>/scripts/query-results.js" "./code-analyzer-results-TIMESTAMP.json" --engine pmd --summary

# List/browse available rules (by engine, category, language, severity)
node "<skill_dir>/scripts/list-rules.js" "Security" --top 10

# Look up what a rule means
node "<skill_dir>/scripts/describe-rule.js" "ApexCRUDViolation" --engine pmd

# Discover fixable violations
node "<skill_dir>/scripts/discover-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

# Apply fixes (after user confirms)
node "<skill_dir>/scripts/apply-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

# Summarize applied fixes
node "<skill_dir>/scripts/summarize-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

# Filter vendor files (jQuery, Bootstrap, *.min.js) before applying fixes
node "<skill_dir>/scripts/filter-violations.js" "./code-analyzer-results-TIMESTAMP.json" "./code-analyzer-results-TIMESTAMP-filtered.json" --report

<skill_dir> は、この SKILL.md があるディレクトリの絶対パスです。絶対に ./scripts/ を使わないでください。これはスキルディレクトリではなく、ユーザーの CWD を基準に解決されます。

集計、フィルター、順位に関する質問（「違反が最も多いファイルはどれですか？」「PMD の問題はいくつありますか？」「件数順の上位ルールは？」「重大度別の内訳は？」など）には、query-results.js で回答してください。出力には topRules、topFiles、severityCounts がすでに含まれています。

---

概要

このスキルは、自然言語によるリクエスト（「セキュリティ上の問題をスキャンして」「変更を確認して」など）を適切な sf code-analyzer run コマンドに変換し、任意のエンジン、対象、重大度の組み合わせでスキャンを実行し、実行可能な結果を提示します。エンジン提供の修正が利用できる場合は、それを検出し、ユーザーに確認を求めたうえで安全に適用し、検証を提案します。静的解析、セキュリティレビュー、AppExchange 認定、コード品質チェック、Salesforce プロジェクト内の重複や脆弱性の検出に使用してください。

対象範囲： スキャンの実行、結果の解析／フィルタリング／順位付け、エンジンの自動修正の適用、差分ベースのスキャン、すべての出力形式（JSON/HTML/SARIF/CSV/XML）、ルールの説明／一覧表示、スキャン失敗のトラブルシューティング。

対象外： sf またはプラグインのインストール／設定（→ configuring-code-analyzer）、カスタムルール／エンジンの作成、エンジン提供のもの以外の AI 生成修正、詳細なリファクタリング、CI/CD の設定（→ configuring-code-analyzer）。

使用可能なツール： Bash（sf code-analyzer、node、git diff、date）、Read、Write、Edit。禁止： あらゆる MCP ツール、Agent ツール、ウェブツール、その他のスキル、Python、jq、インラインスクリプト／ヒアドキュメント。このスキルは、スキャンから修正、検証、結果の検索、説明までのワークフロー全体を一貫して担当します。

---

コマンド構文のルール（最初に必ずお読みください — 例外なし）

1. コマンドは sf code-analyzer run です。sf scanner run（非推奨の v3）ではありません。
2. --format フラグは使用しないでください。 --output-file <path>.<ext> を使います。拡張子によって形式が決まります。
3. 必ずタイムスタンプ付きの名前（例：./code-analyzer-results-20260512-143022.json）を指定して --output-file を渡してください。標準出力には頼らないでください。
4. フォアグラウンドでのみ実行してください（run_in_background は使用しないでください）。大規模なスキャンではタイムアウトを 1200000ms に設定します。
5. エラーの原因となる 無効な v3 フラグ： --format、--engine、--category、--json。代わりに --rule-selector と --output-file を使用してください。
6. ツールの制限： Bash、Read、Write、Edit のみ。MCP ツール、Agent ツール、ウェブツール、その他のスキルは使用しないでください。

理由：v4 以降の CLI ではフラグのインターフェースが再設計されており、v3 のフラグを使うとエラーになります。

フラグとセレクターの詳細：<skill_dir>/references/flag-reference.md。

---

前提条件

必要なもの：Salesforce CLI（sf）、@salesforce/plugin-code-analyzer（v5.x 以降）、Java 11 以降（PMD/CPD/SFGE）、Node.js 18 以降（ESLint/RetireJS）、Python 3（Flow）、認証済みの組織（ApexGuru）。

事前確認：sf code-analyzer --help 2>&1 | head -1 を実行します。失敗した場合、またはスキャンでエンジンの起動エラー（例：「PMD failed to start」、「java: command not found」、「SFGE failed」）が報告された場合：

1. 停止してください。自分で前提条件のインストールや診断を試みないでください。
2. configuring-code-analyzer に引き継いでください。すべてのセットアップを担当します。
3. 完了したらここに戻り、スキャンを再実行してください。

スキャンがそれ以外の理由で失敗した場合は、<skill_dir>/references/error-handling.md を参照してください。

---

クイックスタート：よくあるパターン

以下のリクエストに当てはまる場合は、ステップ 3（ビルドコマンド）に進んでください。当てはまらない場合は、ステップ 1 に進んでください。

ユーザーの発言	ルールセレクター	備考
"scan my code" / "run code analyzer"	Recommended	厳選されたセット、すべてのファイルタイプ
"check for security issues" / "security review"	all:Security:(1,2)	すべてのエンジン、Critical+High
"scan my changes" / "check the diff"	（ステップ 1.5 を参照）	git diff でファイルを取得し、スキャン可能なタイプに絞り込み、--target で渡します
"run PMD" / "check my Apex"	pmd	Apex クラスとトリガー
"lint my LWC" / "check my JavaScript"	eslint	JavaScript/TypeScript/LWC
"find duplicates" / "check for copy-paste"	cpd	コードクローン
"check for vulnerabilities" / "scan libraries"	retire-js	JavaScript ライブラリの CVE
"deep analysis" / "data flow analysis"	sfge	Java 11 以降、10～20 分、--workspace "force-app" を使用
"performance analysis" / "governor limits"	apexguru	認証済みの組織が必要です
"analyze my Flows"	flow	--target **/*.flow-meta.xml、Python 3
"AppExchange security review"	all:Security:(1,2)	<skill_dir>/references/special-behaviors.md → AppExchange を参照

---

ステップ 1：ユーザーの意図を解析する

以下の 7 つの観点からリクエストを解析します。複数の観点を組み合わせることもできます。

1.1 ENGINE

PMD/Apex → pmd · ESLint/JS/TS/lint → eslint · Flows → flow · duplicates/CPD → cpd · vulnerabilities/CVE/RetireJS → retire-js · SFGE/data flow → sfge · performance/ApexGuru → apexguru · regex → regex · everything → all · unspecified → Recommended。

1.2 CATEGORY

security/OWASP → Security · performance → Performance · best practices → BestPractices · style/format → CodeStyle · design/complexity → Design · bugs → ErrorProne · docs → Documentation。

1.3 SEVERITY

1=Critical · 2=High · 3=Moderate · 4=Low · 5=Info。「critical only」→ 1 · 「critical+high」→ (1,2) · 「moderate and above」→ (1,2,3)。

1.4 SPECIFIC RULE

ユーザーがルール名（例："ApexCRUDViolation"、"no-unused-vars"）を指定した場合：--rule-selector <engine>:<ruleName>、エンジンが不明確な場合は <ruleName> のみを指定します。

⚠️ 部分的な名前： --rule-selector には正確な完全名が必要です（例：no-hardcoded-values ではなく @salesforce-ux/slds/no-hardcoded-values-slds2）。ワイルドカードは使えません。確信が持てない場合は、まず名前を調べてください。推測しないでください：

sf code-analyzer rules --rule-selector all 2>&1 | grep -i "USER_KEYWORD"

複数の一致がある場合は、どれを使うかユーザーに尋ねてください。一致がない場合は、該当するものがなかったことをユーザーに伝えてください。

1.5 TARGET

特定のパス → --target <path> · glob（「すべての Apex」）→ --target **/*.cls,**/*.trigger · 「変更分」/「diff」→ git diff --name-only [base]...HEAD を実行し、スキャン可能なタイプに絞り込んで --target で渡します · 「LWC」→ --target **/lwc/** · 「Flows」→ --target **/*.flow-meta.xml · 指定なし → 省略（ワークスペース全体）。

Diff の絞り込みの詳細：<skill_dir>/references/special-behaviors.md。

1.6 OUTPUT

**デフォルトは JSON です。**ユーザーから明示的に要求があった場合のみ変更してください。ファイル名：TIMESTAMP=$(date +%Y%m%d-%H%M%S) を使い、./code-analyzer-results-<YYYYMMDD-HHmmss>.<ext> とします。形式：.json（デフォルト）、.html、.sarif、.csv、.xml。

1.7 COMPARISON / DELTA

「main 以降の新しい変更」→ git diff --name-only main...HEAD → そのファイルをスキャン · 「前回のコミット以降」→ HEAD~1 · 「develop との比較」→ develop...HEAD。

---

ステップ 2：ルールセレクターを作成する

構文：: = AND、, = OR、() = グループ化。

• エンジンのみ：pmd
• エンジン + カテゴリ：pmd:Security
• エンジン + 重大度：pmd:2
• 複合条件：(pmd,eslint):Security:(1,2) = （PMD または ESLint）AND Security AND 重大度（1 または 2）
• 特定のルール：pmd:ApexCRUDViolation
• すべて：all

詳細：<skill_dir>/references/command-examples.md。

---

Step 3: 完全なコマンドを組み立てる

TIMESTAMP=$(date +%Y%m%d-%H%M%S)
sf code-analyzer run \
  --rule-selector <selector> \
  --target <targets> \                                              # optional
  --output-file "./code-analyzer-results-${TIMESTAMP}.json" \       # default JSON
  --include-fixes \                                                 # always
  --workspace <path>                                                # optional

• デフォルトではタイムスタンプ付き JSON を使用し、明示的に要求された場合のみ形式を変更します。
• 必ず --include-fixes を渡します（Step 6 の自動修正が有効になります）。
• ワークスペース全体をスキャンする場合は、--target を省略します。
• 差分スキャン：git diff --name-only → スキャン可能な種類に絞り込む → --target として渡します。

特別なケース（SFGE/ApexGuru/AppExchange/差分）：<skill_dir>/references/special-behaviors.md。

---

Step 4: スキャンを実行する

Bash ツールのみを使用してください。run_code_analyzer MCP ツールは使用しないでください。

1. Bash でタイムスタンプを生成します：date +%Y%m%d-%H%M%S → 例：20260512-143022。
2. ユーザーに次のように伝えます：

   Starting scan...
   Results: ./code-analyzer-results-20260512-143022.json
   Log:     ./code-analyzer-results-20260512-143022.log
   May take several minutes for large codebases.
   

3. 文字列としてのタイムスタンプを埋め込んで実行します（$TIMESTAMP は使用しません）。フォアグラウンドで実行し、タイムアウトを 1200000ms に設定して、tee で .log に出力します：

   sf code-analyzer run --rule-selector Recommended \
     --output-file "./code-analyzer-results-20260512-143022.json" \
     --include-fixes 2>&1 | tee "./code-analyzer-results-20260512-143022.log"
   

4. 終了コード 0 は成功です。エラーが発生した場合は、ログファイルと <skill_dir>/references/error-handling.md の両方を確認します。
5. 直ちに結果を解析します（Step 5）。次に何をするかユーザーに尋ねないでください。

---

Step 5: 結果を解析して提示する

スキャン直後に解析スクリプトを実行します。確認のために一時停止してはいけません。

node "<skill_dir>/scripts/parse-results.js" "./code-analyzer-results-TIMESTAMP.json"

⚠️ 禁止事項：

• ❌ スクリプトコードを自分で作成または生成しないでください
• ❌ node scripts/parse-results.js のような相対パスのみの指定は使用しないでください（ユーザーの CWD からは解決されません）
• ❌ ヒアドキュメントやインラインのスクリプトコンテンツを使用しないでください
• ❌ 解析スクリプトの代わりに jq を使用しないでください（シェルのクォートで問題が発生します）
• ❌ JSON ファイルを直接読み込まないでください

提示テンプレート

## Scan Complete

**Found X violations** across Y files.

| Severity | Count |
|----------|-------|
| Critical (1) | X |
| High (2) | X |
| Moderate (3) | X |
| Low (4) | X |
| Info (5) | X |

### Top Issues
| # | Rule | Engine | Sev | File | Line |
|---|------|--------|-----|------|------|
| 1 | ApexCRUDViolation | pmd | 2 | AccountService.cls | 42 |
| ... up to 10 most critical |

### Top Rules by Frequency
| Rule | Engine | Count |
|------|--------|-------|
| no-var | eslint | 170 |
| ... |

Full results: `./code-analyzer-results-20260512-143022.json`

結果の規模に応じて調整します：0 →「違反は見つかりませんでした」；1–10 → すべてを 1 つの表に表示；11–50 → 重大度別の件数＋上位 10 件；50–5000 → 件数＋上位 10 件の違反＋上位 10 件のルール＋上位 5 件のファイル；5000+ → 同様の内容に、範囲を絞り込む提案（重大度／カテゴリ／フォルダー）を追加します。必ず最後に出力パスを示し、次の操作としてフィルター／ルールの説明／修正の適用を提案してください。

大量の結果の処理：<skill_dir>/references/special-behaviors.md。

---

Step 6: エンジン提供の修正を適用する（スキャン後）

エンジン提供の修正は決定的です（AI が生成したものではありません）。手順：ベンダーファイルの除外（必要な場合）→ 検出 → 提示 → ユーザーの確認を待つ → 適用 → 要約。

6.1 ベンダーファイルのフィルター（必要な場合）

ユーザーが「コードを修正して」／「プロジェクトのソース」と言った場合、または上位の違反ファイルがベンダーライブラリ（jQuery、Bootstrap、*.min.js）の場合に実行します：

node "<skill_dir>/scripts/filter-violations.js" \
  "./code-analyzer-results-TIMESTAMP.json" \
  "./code-analyzer-results-TIMESTAMP-filtered.json" \
  --report

報告：「ベンダーファイル X 件（違反 Y 件）を除外しました（jQuery、Bootstrap など）。プロジェクトファイル Z 件のみに修正を適用します。」6.2 以降ではフィルター済みファイルを使用します。検出ロジック：<skill_dir>/references/vendor-file-handling.md。

6.2 検出

node "<skill_dir>/scripts/discover-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

6.3 提示して確認を求める（その後停止）

### Engine-Provided Fixes Available
**X of Y violations** have auto-fixes provided by the analysis engine:

| Rule | Engine | Sev | Fixable Count |
|------|--------|-----|---------------|
| no-var | eslint | 3 | 170 |
| ... |

These are safe, deterministic fixes generated by the engines (not AI-generated).

Would you like me to apply these fixes? (yes / no / select specific rules)

⚠️ ユーザーが当初「スキャンしてすべて修正」と言っていた場合でも、停止して返信を待ってください。 次のターンで、新たに「はい」／「適用」／「進めて」と明確に返答された場合にのみ適用します。

6.4 適用

node "<skill_dir>/scripts/apply-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

（6.1 でフィルター済みファイルが作成された場合は、それを使用します。）

6.5 要約（6.4 の直後に必ず実行）

node "<skill_dir>/scripts/summarize-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

続けて、次の内容を提示します：

### Engine-Provided Fixes Applied Successfully ✓
**Applied X auto-fixes across Y files.**

| Severity | Fixes Applied |
|----------|---------------|
| Critical (1) | X |
| ... |

| Rule | Fixes Applied |
|------|---------------|
| no-var | 169 |
| ... |

Want me to re-run the scan to verify the fixes resolved the violations?

6.6 — ユーザーの選択への対応

• 辞退／「いいえ」： 適用と要約を省略します。再スキャンはしません。
• 「ルールを選択」： 検出リストを該当するルールに絞り込み、フィルター済みファイルを apply-fixes.js に渡します。
• 「すべて」／「はい」： apply-fixes.js を、完全な（またはベンダーフィルター済みの）結果ファイルにそのまま適用します。

6.7 — 検証のための任意の再スキャン

ユーザーが 6.5 の提案を受け入れた場合は、新しいタイムスタンプで同じスキャンを再実行します（元のファイルを上書きしないでください）。修正前後の違反件数を比較し、差分を示します。正常に解決した違反は消え、残った違反には手動での対応が必要か、今回の修正とは無関係です。

---

Step 7: 既存の結果を検索・フィルターする

Step 5 の後、ユーザーはスキャン全体を再実行せずに、特定の部分集合を詳しく確認したい場合があります。このステップでは、結果の調査に関するすべてのリクエストに対応します。

実行するタイミング

既存の結果を絞り込む、フィルターする、順位付けする、または詳しく調べるよう求められたときに実行します：

• 「セキュリティ違反だけを表示して」
• 「AccountService.clsには何がある？」
• 「PMDの問題だけを表示して」／「重大度がCriticalとHighのものに絞って」
• 「どのESLintルールが検出された？」／「lwcフォルダー内の違反を表示して」
• 「重大度の高い順に上位20件」／「違反が最も多いファイルはどれ？」
• 「最もよく使われているルールは？」／「エンジンごとの違反数は？」／「重大度別に内訳を表示して」

重要： 既存のスキャン結果に関する質問（フィルター、順位付け、集計、件数確認）には、必ずquery-results.jsを使用してください。結果のJSONを解析するために、インラインのPython、jq、または場当たり的なスクリプトを決して書かないでください。クエリスクリプトの出力には、すでにtopRules、topFiles、severityCountsが含まれています。

実行方法

Step 4と同じ結果ファイルに対してクエリスクリプトを実行します（再スキャンは不要です）：

node "<skill_dir>/scripts/query-results.js" "./code-analyzer-results-TIMESTAMP.json" [options]

ユーザーの発言	オプション
「セキュリティ違反」	--category Security
「PMDの問題だけ」	--engine pmd
「CriticalとHigh」／「重大度1〜2」	--severity 1,2
「AccountService.cls内」	--file AccountService.cls
「ApexCRUDViolationルール」	--rule ApexCRUDViolation
「上位20件」	--top 20
「ファイル順に並べて」	--sort file
「件数だけ教えて」	--summary
「違反が最も多いファイルはどれ？」	--sort file --summary（topFilesを参照）
「PMDの違反が最も多いファイルはどれ？」	--engine pmd --summary（topFilesを参照）
「最もよく使われているルールは？」	--summary（topRulesを参照）
「エンジンごとの件数は？」	Step 5の概要を使用するか、エンジンごとに--engine X --summaryを実行します
組み合わせ	--engine pmd --severity 1,2 --top 5

出力形式と表示テンプレート：<skill_dir>/references/post-scan-workflows.md。

---

Step 8: ルールを説明する

ユーザーから「このルールはどういう意味？」や「どう修正すればいい？」と尋ねられた場合、このステップで特定のルールを検索して説明します。

実行するタイミング

• 「ApexCRUDViolationとは？」
• 「このルールを説明して」／「なぜこれが検出されたの？」
• 「no-varとはどういう意味？」
• 「OperationWithLimitsInLoopを修正するには？」
• 「この違反について教えて」

実行方法

node "<skill_dir>/scripts/describe-rule.js" "<rule-name>" [--engine <engine>]

スキャン時のコンテキストからエンジンがわかる場合は--engineを指定します。より広範囲に検索する場合は省略します。success／multiple_matches／not_foundのいずれかが返されます。ステータスの処理とテンプレート：<skill_dir>/references/post-scan-workflows.md。

---

Step 9: 利用可能なルールを一覧表示する

トリガー：「利用できるセキュリティルールは？」、「すべてのPMDルールを一覧表示して」、「JavaScriptのルール」、「推奨ルール」、「ESLintルールはいくつ？」、「Apexのルール」。

node "<skill_dir>/scripts/list-rules.js" "<selector>" [options]

ユーザーの発言	セレクター	オプション
「セキュリティルール」	Security
「PMDルール」	pmd
「ESLintのセキュリティルール」	eslint:Security
「JavaScriptのルール」	JavaScript
「Apexのルール」	Apex
「推奨ルール」	Recommended
「重大度の高いルール」	(1,2)
「件数だけ教えて」	Recommended	--count-only
「セキュリティルールの上位10件」	Security	--top 10

フィルター：--engine、--severity、--top（デフォルトは100）、--count-only。スクリプトはCLIを呼び出す前にセレクタートークンを事前検証します（secruityのようなタイプミスを検出します）。表示方法：<skill_dir>/references/post-scan-workflows.md。

---

制約と注意点

項目	理由／対処方法
タイムスタンプ付きの JSON と .log を tee で使用する	上書きを防ぎ、ログと結果を対応させます
--format フラグ	v4 以降では削除されています。--output-file <path>.<ext> を使用してください
フォアグラウンドで実行し、タイムアウトを 1200000ms にする	SFGE の実行には 10～20 分かかることがあり、バックグラウンドで実行すると出力が失われます
絶対パスの <skill_dir> を指定してスクリプトを実行する	./scripts/ はスキルのディレクトリではなく、ユーザーの CWD を基準に解決されます
確認なしに修正を適用しない	コードの変更にはユーザーの承認が必要です
修正前にベンダーファイルを確認する	ベンダー製ファイル（jQuery／Bootstrap／*.min.js）が 50% 以上を占める場合は、先にフィルタリングしてください
修正スクリプトの実行順：フィルタリング（必要な場合）→ 検出 → 適用 → 要約	要約を省略すると、ユーザーに結果を報告できません
SFGE では --workspace を明示する	指定しないと、テンプレートファイルが原因でコンパイルエラーが発生します
ルール名の一部を先に検索する	推測した名前では結果が 0 件になります。sf code-analyzer rules を使用してください
Bash ツールのみを使用し、MCP は使用しない	run_code_analyzer などの MCP ツールでは、スクリプトのワークフローを迂回してしまいます
修正に他のスキルを呼び出さない	このスキルがワークフロー全体を一貫して担当します
再スキャンせず、既存の結果を検索する	ステップ 7 では、既存の JSON をすぐにフィルタリングできます
スキャン結果が 0 件	ルールセレクターが無効です。sf code-analyzer rules --rule-selector <selector> で確認してください
jq の解析に失敗する	シェルの引用符の問題です。代わりに parse-results.js／query-results.js を使用してください
LLM がインラインスクリプトを作成する	スクリプトは作成せず、<skill_dir>/scripts/ にある既存のものを使用してください
即席の Python でランキング／集計に回答する	必ず query-results.js を使用してください。出力にはすでに topFiles／topRules／severityCounts が含まれています

---

参考ファイル一覧

スクリプト（必ず絶対パスの <skill_dir>/ を付けて node 経由で実行し、Read は使用しないでください）：

ファイル	使用するタイミング
<skill_dir>/scripts/parse-results.js	ステップ 5 — スキャン JSON から概要を抽出する
<skill_dir>/scripts/filter-violations.js	ステップ 6.1 — 修正対象からベンダーファイル（jQuery、Bootstrap）を除外する
<skill_dir>/scripts/discover-fixes.js	ステップ 6.2 — 修正可能な違反を特定する
<skill_dir>/scripts/apply-fixes.js	ステップ 6.4 — ユーザーの確認後にエンジンの修正を適用する
<skill_dir>/scripts/summarize-fixes.js	ステップ 6.5 — 適用した変更を要約する
<skill_dir>/scripts/query-results.js	ステップ 7 — 再スキャンせずに既存の結果をフィルタリング／詳細確認する
<skill_dir>/scripts/describe-rule.js	ステップ 8 — ルールの説明とドキュメントを調べる
<skill_dir>/scripts/list-rules.js	ステップ 9 — 検証付きでセレクター別に利用可能なルールを一覧表示／参照する

参考資料（必要に応じて読み込みます）：

ファイル	読み込むタイミング
references/quick-start.md	コマンド構文のテンプレートを確認するとき
references/flag-reference.md	フラグの全ドキュメント、ルールセレクターの構文を確認するとき
references/error-handling.md	スキャン失敗の原因を診断するとき
references/engine-reference.md	エンジンの機能、ファイルの種類、ルールタグを確認するとき
references/command-examples.md	あまり一般的でないコマンドの実行例を確認するとき
references/special-behaviors.md	SFGE／ApexGuru／AppExchange／差分／大規模スキャンを扱うとき
references/vendor-file-handling.md	ベンダーファイルを検出してフィルタリングするとき
references/post-scan-workflows.md	ステップ 7～9 — 検索、ルールの説明、ルール一覧を確認するとき

examples/ には、出力構造の検証とコマンドパターン（基本／大規模／セキュリティスキャン、修正ワークフロー）が含まれています。