dx-code-analyzer-run

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

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

コードアナライザーの結果を扱うすべての操作は、必ず <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 がすでに含まれています。

---

概要

エコシステム： このスキルは、3 つの Code Analyzer スキルで構成されるスイートの一部です。dx-code-analyzer-run（スキャンと結果）・dx-code-analyzer-configure（セットアップ、設定、CI/CD）・dx-code-analyzer-custom-rule-create（カスタムルールの作成）。

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

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

対象範囲外： sf やプラグインのインストール・設定（→ dx-code-analyzer-configure）、カスタムルールやエンジンの作成（→ dx-code-analyzer-custom-rule-create）、エンジン提供の修正を超える AI 生成の修正、詳細なリファクタリング、CI/CD の設定（→ dx-code-analyzer-configure）。

使用可能なツール： 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. 必ず タイムスタンプ付きのファイル名を指定して --output-file を渡してください（例：./code-analyzer-results-20260512-143022.json）。標準出力に依存しないでください。
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）、認証済みの org（ApexGuru）。

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

1. 停止します。前提条件をご自身でインストールしたり、診断したりしないでください。
2. dx-code-analyzer-configure に委任します。すべてのセットアップを担当します。
3. 完了したら、ここに戻ってスキャンを再実行します。

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

---

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

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

ユーザーの発言	ルールセレクター	備考
「コードをスキャンして」／「コードアナライザーを実行して」	Recommended	厳選されたセット。すべてのファイル形式が対象
「セキュリティの問題を確認して」／「セキュリティレビュー」	all:Security:(1,2)	すべてのエンジン。Critical と High
「変更をスキャンして」／「差分を確認して」	（ステップ 1.5 を参照）	git diff でファイルを取得し、スキャン可能な形式に絞り込んで、--target で渡します
「PMD を実行して」／「Apex を確認して」	pmd	Apex クラスとトリガー
「LWC をリントして」／「JavaScript を確認して」	eslint	JavaScript／TypeScript／LWC
「重複を見つけて」／「コピー＆ペーストを確認して」	cpd	コードクローン
「脆弱性を確認して」／「ライブラリをスキャンして」	retire-js	JavaScript ライブラリの CVE
「詳細な分析」／「データフロー分析」	sfge	Java 11 以降、10〜20 分。--workspace "force-app" を使用
「パフォーマンス分析」／「ガバナ制限」	apexguru	認証済みの組織が必要です
「自分の Flow を分析して」	flow	--target **/*.flow-meta.xml、Python 3
「AppExchange セキュリティレビュー」	all:Security:(1,2)	<skill_dir>/references/special-behaviors.md → AppExchange を参照

---

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

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

1.1 エンジン

PMD／Apex → pmd · ESLint／JS／TS／lint → eslint · Flow → flow · 重複／CPD → cpd · 脆弱性／CVE／RetireJS → retire-js · SFGE／データフロー → sfge · パフォーマンス／ApexGuru → apexguru · 正規表現 → regex · すべて → all · 指定なし → Recommended。

1.2 カテゴリ

セキュリティ／OWASP → Security · パフォーマンス → Performance · ベストプラクティス → BestPractices · スタイル／フォーマット → CodeStyle · 設計／複雑さ → Design · バグ → ErrorProne · ドキュメント → Documentation。

1.3 重大度

1=Critical · 2=High · 3=Moderate · 4=Low · 5=Info。「重大度が Critical のみ」→ 1 · 「Critical と High」→ (1,2) · 「Moderate 以上」→ (1,2,3)。

1.4 特定のルール

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

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

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

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

1.5 対象

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

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

1.6 出力

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

1.7 比較／差分

「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。

---

ステップ 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 を渡します（ステップ 6 の自動修正が有効になります）。
• ワークスペース全体をスキャンする場合は、--target を省略します。
• 差分スキャン：git diff --name-only → スキャン可能な種類に絞り込む → --target として渡します。

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

---

ステップ 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. 結果を直ちに解析します（ステップ 5）。次に何をするかユーザーに尋ねてはいけません。

---

ステップ 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。

---

ステップ 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 の提案を受け入れた場合、新しいタイムスタンプを使って同じスキャンを再実行します（元の結果は上書きしません）。修正前後の違反件数を比較し、差分を示します。問題なく解決した違反は結果から除外されます。残った違反は、手動での修正が必要か、今回の修正とは無関係です。

---

ステップ 7：既存の結果を検索・絞り込む

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

実行するタイミング

既存の結果を絞り込み、フィルタリング、順位付け、または確認するようユーザーから依頼された場合に実行します。

• 「セキュリティ違反だけを表示してください」
• 「AccountService.clsには何がありますか？」
• 「PMDの問題だけを表示してください」／「重大と高だけに絞ってください」
• 「どの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
「重大と高」／「重大度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。

---

スキル間の連携

このスキルは、3つのスキルで構成されるCode Analyzerエコシステムの一部です。他のスキルが担当する作業を試みず、適切に引き継いでください。

このスキルから dx-code-analyzer-configure に引き継ぐ場合：

• 事前チェックに失敗した場合（CLIがない、プラグインがインストールされていない、エンジンの前提条件が満たされていない）→停止して引き継ぎ、修正後に戻ります
• ユーザーからCI/CDのセットアップ、code-analyzer.yml の編集、重大度の変更、またはエンジンの無効化を依頼された場合→すべて引き継ぎます

このスキルから dx-code-analyzer-custom-rule-create に引き継ぐ場合：

• ユーザーから新しいルールの作成、XPathの記述、正規表現ルールの記述、または組み込みルールでは対応できないパターンの適用を依頼された場合→すべて引き継ぎます。このスキルでルールを作成しようとしないでください。

他のスキルがここにハンドオフする場合:

• dx-code-analyzer-configure がセットアップを完了 → スキャンを進める (ステップ 1〜5)
• dx-code-analyzer-custom-rule-create がルールの作成を完了 → 新しいルールを対象にスキャンを進める (例: --rule-selector pmd:<RuleName>) ことで動作を検証する

責務の境界

このスキルは スキャン → 調査 → 修正 のワークフロー全体をエンドツーエンドで担います。インストール、設定ファイルの管理、ルールの作成は担いません。

---

制約と注意点

項目	理由 / 対処
tee 経由でタイムスタンプ付き JSON + .log を使用する	上書きを防ぎ、ログと結果を対応付ける
--format フラグ	v4 以降で削除済み。--output-file <path>.<ext> を使用する
フォアグラウンド、タイムアウト 1200000ms	SFGE は 10〜20 分かかることがある。バックグラウンド化すると出力が失われる
スクリプトは絶対 <skill_dir> パスで実行する	./scripts/ はスキルディレクトリではなくユーザーの CWD を基準に解決される
確認なしで修正を適用しない	ユーザーがコード変更を承認する必要がある
修正前のベンダーファイルチェック	50% 以上がベンダー製 (jQuery/Bootstrap/*.min.js) の場合、先にフィルタリングする
修正スクリプトの順序: フィルタ (必要な場合) → discover → apply → summarize	summarize を省略すると、ユーザーに結果レポートが渡らない
SFGE には明示的な --workspace が必要	指定しないとテンプレートファイルがコンパイルエラーを引き起こす
部分的なルール名を先に検索する	推測すると結果が 0 件になる。sf code-analyzer rules を使用する
ONLY 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/diff/大規模スキャン
references/vendor-file-handling.md	ベンダーファイルの検出とフィルタリング
references/post-scan-workflows.md	ステップ 7〜9 — クエリ、ルールの説明、ルールの一覧表示

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