Back to Details

dx-code-analyzer-run

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Running Code Analyzer Skill

代码分析器技能使用指南

⚠️ CRITICAL: Mandatory Script Usage

⚠️ 重要提示：必须使用指定脚本

Every interaction with Code Analyzer results MUST go through the bundled scripts in 
<skill_dir>/scripts/
. No exceptions.
所有与Code Analyzer结果的交互都必须通过
<skill_dir>/scripts/
中的捆绑脚本进行，无例外。

❌ WRONG — never do this:

❌ 错误示例 — 请勿这样做：

bash
undefined
bash
undefined

WRONG: inline Python to parse results

错误：使用内联Python解析结果

python3 -c "import json; data = json.load(open('results.json'))..."
python3 -c "import json; data = json.load(open('results.json'))..."

WRONG: inline Node.js to parse results

错误：使用内联Node.js解析结果

node -e "const data = require('./results.json')..."
node -e "const data = require('./results.json')..."

WRONG: jq to filter results

错误：使用jq过滤结果

cat results.json | jq '.violations[] | select(.engine=="pmd")'
cat results.json | jq '.violations[] | select(.engine=="pmd")'

WRONG: reading the results file directly (it can be 10MB+)

错误：直接读取结果文件（文件大小可能超过10MB）

Read tool → code-analyzer-results-*.json

Also forbidden: `run_code_analyzer` and any `mcp__*` tool — Bash only.
Read tool → code-analyzer-results-*.json

同样禁止使用：`run_code_analyzer`及任何`mcp__*`工具 — 仅允许使用Bash。

✅ RIGHT — always do this:

✅ 正确示例 — 请始终这样做：

bash
undefined
bash
undefined

Summarize scan results

汇总扫描结果

node "<skill_dir>/scripts/parse-results.js" "./code-analyzer-results-TIMESTAMP.json"
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
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
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
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"
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"
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"
node "<skill_dir>/scripts/summarize-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

Filter vendor files (jQuery, Bootstrap, *.min.js) before applying fixes

应用修复前过滤第三方库文件（jQuery、Bootstrap、*.min.js）

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

`<skill_dir>` is the absolute path to the directory containing this SKILL.md. **Never** use `./scripts/` — that resolves against the user's CWD, not the skill dir.

Any aggregation, filter, or rank question ("which file has the most violations?", "how many PMD issues?", "top rules by count", "break down by severity") is answered by `query-results.js` — its output already includes `topRules`, `topFiles`, and `severityCounts`.

---
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`字段。

---

Overview

概述

This skill translates natural-language requests ("scan for security issues", "check my changes") into the correct 
sf code-analyzer run
command, executes scans across any combination of engines/targets/severities, and presents actionable results. When engine-provided fixes are available, it discovers them, asks for user confirmation, applies them safely, and offers verification. Use it for static analysis, security reviews, AppExchange certification, code-quality checks, and finding duplicates/vulnerabilities in Salesforce projects.
In scope: running scans, parsing/filtering/ranking results, applying engine auto-fixes, diff-based scans, all output formats (JSON/HTML/SARIF/CSV/XML), describing/listing rules, scan-failure troubleshooting.
Out of scope: installing/configuring 
sf
or the plugin (→ 
dx-code-analyzer-configure
), writing custom rules/engines, AI-generated fixes beyond engine-provided ones, deep refactoring, CI/CD setup (→ 
dx-code-analyzer-configure
).
Allowed tools: Bash (
sf code-analyzer
, 
node
, 
git diff
, 
date
), Read, Write, Edit. Forbidden: any MCP tool, Agent tool, web tools, other skills, Python, 
jq
, inline scripts/heredocs. This skill owns the complete scan-fix-verify-query-explain workflow end-to-end.
本技能可将自然语言请求（如“扫描安全问题”“检查我的代码变更”）转换为正确的
sf code-analyzer run
命令，执行跨任意引擎/目标/严重级别的扫描，并呈现可操作的结果。当引擎提供修复方案时，本技能会发现这些方案、请求用户确认、安全应用修复并提供验证功能。适用于Salesforce项目的静态分析、安全审查、AppExchange认证、代码质量检查，以及查找重复代码/漏洞。
适用范围： 运行扫描、解析/过滤/排序结果、应用引擎自动修复、基于diff的扫描、所有输出格式（JSON/HTML/SARIF/CSV/XML）、规则描述/列表、扫描失败故障排查。
不适用范围： 安装/配置
sf
或插件（请使用
dx-code-analyzer-configure
）、编写自定义规则/引擎、引擎提供的修复之外的AI生成修复、深度重构、CI/CD设置（请使用
dx-code-analyzer-configure
）。
允许使用的工具： Bash（
sf code-analyzer
、
node
、
git diff
、
date
）、Read、Write、Edit。禁止使用： 任何MCP工具、Agent工具、网络工具、其他技能、Python、
jq
、内联脚本/ heredocs。本技能全权负责完整的扫描-修复-验证-查询-解释工作流。

Command Syntax Rules (READ FIRST — ABSOLUTE)

命令语法规则（请先阅读 — 绝对要求）

  1. The command is 
    sf code-analyzer run
     — NOT 
    sf scanner run
    (deprecated v3).
  2. No 
    --format
    flag.     Use 
    --output-file <path>.<ext>
    ; the extension determines the format.
  3. Always pass 
    --output-file
    with a timestamped name (e.g., 
    ./code-analyzer-results-20260512-143022.json
    ) — do not rely on stdout.
  4. Foreground only (no 
    run_in_background
    ); timeout 1200000ms for large scans.
  5. Invalid v3 flags that cause errors: 
    --format
    , 
    --engine
    , 
    --category
    , 
    --json
    . Use 
    --rule-selector
    + 
    --output-file
    instead.
  6. Tool restriction: Bash, Read, Write, Edit only. No MCP tools, no Agent tool, no web tools, no other skills.
Why: the v4+ CLI redesigned the flag interface; v3 flags now error.
Full flag/selector docs: 
<skill_dir>/references/flag-reference.md
.
  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
。

Prerequisites

前置条件

User needs: Salesforce CLI (
sf
), @salesforce/plugin-code-analyzer (v5.x+), Java 11+ (PMD/CPD/SFGE), Node.js 18+ (ESLint/RetireJS), Python 3 (Flow), authenticated org (ApexGuru).
Pre-flight: run 
sf code-analyzer --help 2>&1 | head -1
. If that fails, or if a scan reports an engine startup error (e.g., "PMD failed to start", "java: command not found", "SFGE failed"):
  1. Stop — do not attempt to install/diagnose prerequisites yourself.
  2. Delegate to 
    dx-code-analyzer-configure
     — it handles all setup.
  3. After it finishes, return here and re-run the scan.
If a scan fails for other reasons, see 
<skill_dir>/references/error-handling.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启动失败”“java: command not found”“SFGE失败”）：
  1. 停止操作 — 不要尝试自行安装/诊断前置条件。
  2. 委托给
    dx-code-analyzer-configure
     — 该技能负责所有设置工作。
  3. 设置完成后，返回本技能重新运行扫描。
如果扫描因其他原因失败，请查看
<skill_dir>/references/error-handling.md
。

Quick Start: Common Patterns

快速入门：常见场景

Match the request below; if it matches, jump to Step 3 (Build Command). Otherwise, walk Step 1.
User SaysRule SelectorNotes
"scan my code" / "run code analyzer"
Recommended
Curated set, all file types
"check for security issues" / "security review"
all:Security:(1,2)
All engines, Critical+High
"scan my changes" / "check the diff"(see Step 1.5)Get files via 
git diff
, filter to scannable types, pass via 
--target
"run PMD" / "check my Apex"
pmd
Apex classes and triggers
"lint my LWC" / "check my JavaScript"
eslint
JavaScript/TypeScript/LWC
"find duplicates" / "check for copy-paste"
cpd
Code clones
"check for vulnerabilities" / "scan libraries"
retire-js
JavaScript library CVEs
"deep analysis" / "data flow analysis"
sfge
Java 11+, 10–20 min, use 
--workspace "force-app"
"performance analysis" / "governor limits"
apexguru
Authenticated org required
"analyze my Flows"
flow
--target **/*.flow-meta.xml
, Python 3
"AppExchange security review"
all:Security:(1,2)
See 
<skill_dir>/references/special-behaviors.md
→ AppExchange
匹配以下用户请求；如果匹配，直接跳至步骤3（构建命令）。否则，执行步骤1。
用户请求规则选择器说明
"扫描我的代码" / "运行代码分析器"
Recommended
精选规则集，支持所有文件类型
"检查安全问题" / "安全审查"
all:Security:(1,2)
所有引擎，仅扫描严重+高风险级别
"扫描我的变更" / "检查diff内容"（见步骤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"
"性能分析" / " governor限制检查"
apexguru
需要已认证的组织
"分析我的Flow"
flow
--target **/*.flow-meta.xml
，需要Python 3
"AppExchange安全审查"
all:Security:(1,2)
查看
<skill_dir>/references/special-behaviors.md
→ AppExchange章节

Step 1: Parse the User's Intent

步骤1：解析用户意图

Analyze the request along these 7 dimensions; any can combine.
从以下7个维度分析用户请求；这些维度可组合使用。

1.1 ENGINE

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
.
PMD/Apex → 
pmd
· ESLint/JS/TS/lint → 
eslint
· Flows → 
flow
· 重复代码/CPD → 
cpd
· 漏洞/CVE/RetireJS → 
retire-js
· SFGE/数据流 → 
sfge
· 性能/ApexGuru → 
apexguru
· 正则表达式 → 
regex
· 所有引擎 → 
all
· 未指定 → 
Recommended
。

1.2 CATEGORY

1.2 类别（CATEGORY）

security/OWASP → 
Security
· performance → 
Performance
· best practices → 
BestPractices
· style/format → 
CodeStyle
· design/complexity → 
Design
· bugs → 
ErrorProne
· docs → 
Documentation
.
安全/OWASP → 
Security
· 性能 → 
Performance
· 最佳实践 → 
BestPractices
· 风格/格式 → 
CodeStyle
· 设计/复杂度 → 
Design
· 漏洞 → 
ErrorProne
· 文档 → 
Documentation
。

1.3 SEVERITY

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=Critical（严重） · 2=High（高） · 3=Moderate（中等） · 4=Low（低） · 5=Info（信息）。“仅严重级别” → 
1
· “严重+高风险” → 
(1,2)
· “中等及以上” → 
(1,2,3)
。

1.4 SPECIFIC RULE

1.4 特定规则（SPECIFIC RULE）

If the user names a rule (e.g., "ApexCRUDViolation", "no-unused-vars"): 
--rule-selector <engine>:<ruleName>
, or just 
<ruleName>
if engine is ambiguous.
⚠️ Partial names: 
--rule-selector
requires the exact full rule name (e.g., 
@salesforce-ux/slds/no-hardcoded-values-slds2
, not 
no-hardcoded-values
). No wildcards. If you are not 100% certain, look it up first — do not guess:
bash
sf code-analyzer rules --rule-selector all 2>&1 | grep -i "USER_KEYWORD"
Multiple matches → ask the user which. Zero matches → tell the user nothing matched.
如果用户指定规则（例如“ApexCRUDViolation”“no-unused-vars”）：使用
--rule-selector <engine>:<ruleName>
，如果引擎不明确，仅使用
<ruleName>
。
⚠️ 规则名称注意事项： 
--rule-selector
需要完整准确的规则名称（例如
@salesforce-ux/slds/no-hardcoded-values-slds2
，而非
no-hardcoded-values
）。不支持通配符。如果您无法100%确定，请先查询 — 不要猜测：
bash
sf code-analyzer rules --rule-selector all 2>&1 | grep -i "USER_KEYWORD"
多个匹配结果 → 询问用户选择哪一个。无匹配结果 → 告知用户未找到匹配规则。

1.5 TARGET

1.5 扫描目标（TARGET）

specific path → 
--target <path>
· glob ("all Apex") → 
--target **/*.cls,**/*.trigger
· "my changes"/"diff" → 
git diff --name-only [base]...HEAD
, filter to scannable types, pass as 
--target
· "LWC" → 
--target **/lwc/**
· "Flows" → 
--target **/*.flow-meta.xml
· unspecified → omit (entire workspace).
Diff-filtering details: 
<skill_dir>/references/special-behaviors.md
.
特定路径 → 
--target <path>
· 通配符（“所有Apex文件”） → 
--target **/*.cls,**/*.trigger
· “我的变更”/“diff内容” → 
git diff --name-only [base]...HEAD
，过滤为可扫描类型，作为
--target
传递 · “LWC文件” → 
--target **/lwc/**
· “Flow文件” → 
--target **/*.flow-meta.xml
· 未指定 → 省略（扫描整个工作区）。
Diff过滤详情：
<skill_dir>/references/special-behaviors.md
。

1.6 OUTPUT

1.6 输出（OUTPUT）

Default JSON. Only change if the user explicitly asks. Name: 
./code-analyzer-results-<YYYYMMDD-HHmmss>.<ext>
via 
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
. Formats: 
.json
(default), 
.html
, 
.sarif
, 
.csv
, 
.xml
.
默认JSON格式。仅在用户明确要求时更改格式。文件名：通过
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
生成
./code-analyzer-results-<YYYYMMDD-HHmmss>.<ext>
。支持格式：
.json
（默认）、
.html
、
.sarif
、
.csv
、
.xml
。

1.7 COMPARISON / DELTA

1.7 对比/增量（COMPARISON / DELTA）

"new since main" → 
git diff --name-only main...HEAD
→ scan those · "since last commit" → 
HEAD~1
· "vs develop" → 
develop...HEAD
.
“相对于main分支的新内容” → 
git diff --name-only main...HEAD
→ 扫描这些文件 · “相对于上一次提交” → 
HEAD~1
· “与develop分支对比” → 
develop...HEAD
。

Step 2: Build the Rule Selector

步骤2：构建规则选择器

Syntax: 
:
= AND, 
,
= OR, 
()
= grouping.
  • Engine only: 
    pmd
  • Engine + category: 
    pmd:Security
  • Engine + severity: 
    pmd:2
  • Complex: 
    (pmd,eslint):Security:(1,2)
    = (PMD or ESLint) AND Security AND sev (1 or 2)
  • Specific rule: 
    pmd:ApexCRUDViolation
  • All: 
    all
More: 
<skill_dir>/references/command-examples.md
.
语法：
:
= 逻辑与，
,
= 逻辑或，
()
= 分组。
  • 仅引擎：
    pmd
  • 引擎+类别：
    pmd:Security
  • 引擎+严重级别：
    pmd:2
  • 复杂组合：
    (pmd,eslint):Security:(1,2)
    = （PMD或ESLint）且安全类别且严重级别（1或2）
  • 特定规则：
    pmd:ApexCRUDViolation
  • 所有规则：
    all
更多示例：
<skill_dir>/references/command-examples.md
。

Step 3: Build the Full Command

步骤3：构建完整命令

bash
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
  • Default to timestamped JSON; only change format on explicit request.
  • Always pass 
    --include-fixes
    (enables Step 6 auto-fix).
  • Omit 
    --target
    to scan the whole workspace.
  • Diff scans: 
    git diff --name-only
    → filter scannable types → pass as 
    --target
    .
Special cases (SFGE/ApexGuru/AppExchange/diff): 
<skill_dir>/references/special-behaviors.md
.
bash
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
sf code-analyzer run \
  --rule-selector <selector> \
  --target <targets> \                                              # 可选
  --output-file "./code-analyzer-results-${TIMESTAMP}.json" \       # 默认JSON格式
  --include-fixes \                                                 # 必须添加
  --workspace <path>                                                # 可选
  • 默认使用带时间戳的JSON格式；仅在用户明确要求时更改格式。
  • 必须传递
    --include-fixes
    （启用步骤6的自动修复功能）。
  • 省略
    --target
    则扫描整个工作区。
  • Diff扫描：
    git diff --name-only
    → 过滤可扫描类型 → 作为
    --target
    传递。
特殊场景（SFGE/ApexGuru/AppExchange/diff）：
<skill_dir>/references/special-behaviors.md
。

Step 4: Execute the Scan

步骤4：执行扫描

Use the Bash tool only — never the 
run_code_analyzer
MCP tool.
  1. Generate the timestamp via Bash: 
    date +%Y%m%d-%H%M%S
    → e.g. 
    20260512-143022
    .
  2. Tell the user: 
    Starting scan...
Results: ./code-analyzer-results-20260512-143022.json
Log:     ./code-analyzer-results-20260512-143022.log
May take several minutes for large codebases.
  3. Run with the literal timestamp baked in (not 
    $TIMESTAMP
    ), foreground, timeout 1200000ms, 
    tee
    to a 
    .log
    :
    bash
    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. Exit 0 = success. On error, read both the log file and 
    <skill_dir>/references/error-handling.md
    .
  5. Immediately parse results (Step 5) — do not ask the user what to do next.
仅使用Bash工具 — 切勿使用
run_code_analyzer
MCP工具。
  1. 通过Bash生成时间戳：
    date +%Y%m%d-%H%M%S
    → 例如
    20260512-143022
    。
  2. 告知用户： 
    开始扫描...
结果文件：./code-analyzer-results-20260512-143022.json
日志文件：./code-analyzer-results-20260512-143022.log
大型代码库可能需要数分钟时间。
  3. 使用固定时间戳（而非
    $TIMESTAMP
    ）在前台运行命令，超时时间1200000ms，通过
    tee
    输出到
    .log
    文件：
    bash
    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） — 不要询问用户下一步操作。

Step 5: Parse and Present Results

步骤5：解析并呈现结果

Run the parse script straight after the scan — do not pause to ask:
bash
node "<skill_dir>/scripts/parse-results.js" "./code-analyzer-results-TIMESTAMP.json"
⚠️ DO NOT:
  • ❌ Invent or generate script code yourself
  • ❌ Use bare relative paths like 
    node scripts/parse-results.js
    (won't resolve from user's CWD)
  • ❌ Use heredocs or inline script content
  • ❌ Use 
    jq
    as a substitute for the parse script (shell quoting will break)
  • ❌ Read the JSON file directly
扫描完成后立即运行解析脚本 — 不要暂停询问用户：
bash
node "<skill_dir>/scripts/parse-results.js" "./code-analyzer-results-TIMESTAMP.json"
⚠️ 禁止操作：
  • ❌ 自行编写或生成脚本代码
  • ❌ 使用相对路径如
    node scripts/parse-results.js
    （无法从用户的当前工作目录解析）
  • ❌ 使用heredocs或内联脚本内容
  • ❌ 使用
    jq
    替代解析脚本（shell引用会导致错误）
  • ❌ 直接读取JSON文件

Presentation template

呈现模板

undefined
undefined

Scan Complete

扫描完成

Found X violations across Y files.
SeverityCount
Critical (1)X
High (2)X
Moderate (3)X
Low (4)X
Info (5)X
共发现X处违规问题，涉及Y个文件。
严重级别数量
Critical (1)X
High (2)X
Moderate (3)X
Low (4)X
Info (5)X

Top Issues

主要问题

#RuleEngineSevFileLine
1ApexCRUDViolationpmd2AccountService.cls42
... up to 10 most critical
#规则引擎严重级别文件行号
1ApexCRUDViolationpmd2AccountService.cls42
... 最多显示10个最严重的问题

Top Rules by Frequency

出现频率最高的规则

RuleEngineCount
no-vareslint170
...
Full results: 
./code-analyzer-results-20260512-143022.json

Scale to result size: **0** → "no violations found"; **1–10** → all in one table; **11–50** → severity counts + top 10; **50–5000** → counts + top 10 violations + top 10 rules + top 5 files; **5000+** → same, plus suggest narrowing scope (severity/category/folder). Always end with the output path and offer next actions: filter / explain rule / apply fixes.

Large-result handling: `<skill_dir>/references/special-behaviors.md`.

---
规则引擎数量
no-vareslint170
...
完整结果文件：
./code-analyzer-results-20260512-143022.json

根据结果规模调整呈现方式：**0处违规** → “未发现违规问题”；**1–10处** → 全部显示在一个表格中；**11–50处** → 显示严重级别统计+前10个问题；**50–5000处** → 显示统计+前10个问题+前10个高频规则+前5个违规最多的文件；**5000+处** → 同上，同时建议缩小扫描范围（按严重级别/类别/文件夹）。始终以结果文件路径结尾，并提供后续操作选项：过滤结果 / 解释规则 / 应用修复。

大规模结果处理：`<skill_dir>/references/special-behaviors.md`。

---

Step 6: Apply Engine-Provided Fixes (Post-Scan)

步骤6：应用引擎提供的修复（扫描后）

Engine-provided fixes are deterministic (not AI-generated). Flow: vendor filter (if needed) → discover → present → wait for user confirmation → apply → summarize.
引擎提供的修复是确定性的（非AI生成）。流程：第三方库过滤（如有需要） → 发现可修复问题 → 呈现修复信息 → 等待用户确认 → 应用修复 → 汇总修复结果。

6.1 Vendor file filter (when needed)

6.1 第三方库文件过滤（如有需要）

Run if the user said "fix my code" / "project source", or if top-violation files are vendor libs (jQuery, Bootstrap, 
*.min.js
):
bash
node "<skill_dir>/scripts/filter-violations.js" \
  "./code-analyzer-results-TIMESTAMP.json" \
  "./code-analyzer-results-TIMESTAMP-filtered.json" \
  --report
Report: "Excluded X vendor files (Y violations) — jQuery, Bootstrap, etc. Applying fixes to Z project files only." Use the filtered file in 6.2+. Detection logic: 
<skill_dir>/references/vendor-file-handling.md
.
当用户提及“修复我的代码”“项目源代码”，或主要违规文件为第三方库（jQuery、Bootstrap、
*.min.js
）时运行：
bash
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 Discover

6.2 发现可修复问题

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

6.3 Present + ASK (then STOP)

6.3 呈现修复信息 + 请求确认（然后等待）

undefined
undefined

Engine-Provided Fixes Available

引擎提供的修复可用

X of Y violations have auto-fixes provided by the analysis engine:
RuleEngineSevFixable Count
no-vareslint3170
...
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)

⚠️ **Stop and wait for the user's reply, even if they originally said "scan and fix everything".** Apply only on a fresh "yes" / "apply" / "go ahead" in the next turn.
Y处违规中的X处可由分析引擎提供自动修复：
规则引擎严重级别可修复数量
no-vareslint3170
...
这些是由引擎生成的安全、确定性修复方案（非AI生成）。
是否要应用这些修复？（是 / 否 / 选择特定规则）

⚠️ **停止操作并等待用户回复，即使用户最初要求“扫描并修复所有问题”。** 仅在用户下一轮回复中明确表示“是”/“应用”/“继续”时才执行修复。

6.4 Apply

6.4 应用修复

bash
node "<skill_dir>/scripts/apply-fixes.js" "./code-analyzer-results-TIMESTAMP.json"
(Filtered file if 6.1 created one.)
bash
node "<skill_dir>/scripts/apply-fixes.js" "./code-analyzer-results-TIMESTAMP.json"
（如果步骤6.1生成了过滤文件，则使用该文件。）

6.5 Summarize (MANDATORY immediately after 6.4)

6.5 汇总修复结果（必须在步骤6.4后立即执行）

bash
node "<skill_dir>/scripts/summarize-fixes.js" "./code-analyzer-results-TIMESTAMP.json"
Then present:
undefined
bash
node "<skill_dir>/scripts/summarize-fixes.js" "./code-analyzer-results-TIMESTAMP.json"
然后呈现：
undefined

Engine-Provided Fixes Applied Successfully ✓

引擎提供的修复已成功应用 ✓

Applied X auto-fixes across Y files.
SeverityFixes Applied
Critical (1)X
...
RuleFixes Applied
no-var169
...
Want me to re-run the scan to verify the fixes resolved the violations?
undefined
共在Y个文件中应用了X处自动修复。
严重级别已应用修复数量
Critical (1)X
...
规则已应用修复数量
no-var169
...
是否要重新运行扫描以验证修复已解决违规问题？
undefined

6.6 — Handling the user's choice

6.6 — 处理用户选择

  • Decline / "no": skip apply, skip summarize. Do not re-scan.
  • "Select rules": filter the discovery list to those rules and pass the filtered file to 
    apply-fixes.js
    .
  • "All" / "yes": run 
    apply-fixes.js
    against the full (or vendor-filtered) results file as-is.
  • 拒绝 / “否”： 跳过应用修复和汇总步骤。不要重新扫描。
  • “选择特定规则”： 将发现的可修复列表过滤为指定规则，然后将过滤后的文件传递给
    apply-fixes.js
    。
  • “全部” / “是”： 对完整（或第三方库过滤后的）结果文件运行
    apply-fixes.js
    。

6.7 — Optional re-scan for verification

6.7 — 可选的验证性重新扫描

If the user accepts the offer in 6.5, re-run the same scan with a new timestamp (do not overwrite the original). Compare violation counts before vs. after and show the delta — fixes that resolved cleanly will drop out; remaining violations either need manual remediation or are unrelated.
如果用户接受步骤6.5中的提议，使用新时间戳重新运行相同扫描（不要覆盖原始结果）。比较修复前后的违规数量并显示差值 — 已修复的问题会消失；剩余违规问题可能需要手动修复或与本次修复无关。

Step 7: Query and Filter Existing Results

步骤7：查询和过滤现有结果

After Step 5, the user may want to drill into specific subsets without re-running the entire scan. This step handles all result-exploration requests.
步骤5之后，用户可能希望深入查看特定子集而无需重新运行整个扫描。本步骤处理所有结果探索请求。

When to trigger

触发场景

Activate when the user asks to slice, filter, rank, or explore existing results:
  • "Show me just the security violations"
  • "What's in AccountService.cls?"
  • "Show only PMD issues" / "Filter to critical and high"
  • "What ESLint rules fired?" / "Show violations in the lwc folder"
  • "Top 20 most severe" / "Which file has the most violations?"
  • "What are the most common rules?" / "How many violations per engine?" / "Break it down by severity"
Important: Any question about existing scan results — filtering, ranking, counting, aggregating — MUST use 
query-results.js
. NEVER write inline Python, 
jq
, or ad-hoc scripts to parse the results JSON. The query script already provides 
topRules
, 
topFiles
, and 
severityCounts
in its output.
当用户要求切片、过滤、排序或探索现有结果时激活：
  • “仅显示安全违规问题”
  • “AccountService.cls中有哪些问题？”
  • “仅显示PMD问题” / “过滤为严重和高风险级别”
  • “哪些ESLint规则被触发？” / “显示lwc文件夹中的违规问题”
  • “前20个最严重的问题” / “哪个文件违规最多？”
  • “最常见的规则有哪些？” / “每个引擎有多少违规问题？” / “按严重级别拆分”
重要提示： 任何关于现有扫描结果的问题 — 过滤、排序、统计、聚合 — 必须使用
query-results.js
。切勿编写内联Python、
jq
或临时脚本来解析结果JSON。查询脚本的输出已包含
topRules
、
topFiles
和
severityCounts
字段。

How to execute

执行方式

Run the query script against the same results file from Step 4 (no re-scan needed):
bash
node "<skill_dir>/scripts/query-results.js" "./code-analyzer-results-TIMESTAMP.json" [options]
User saysOptions
"security violations"
--category Security
"PMD issues only"
--engine pmd
"critical and high" / "sev 1-2"
--severity 1,2
"in AccountService.cls"
--file AccountService.cls
"the ApexCRUDViolation rule"
--rule ApexCRUDViolation
"top 20"
--top 20
"sort by file"
--sort file
"just give me counts"
--summary
"which file has the most violations?"
--sort file --summary
(read 
topFiles
)
"which file has most PMD violations?"
--engine pmd --summary
(read 
topFiles
)
"most common rules?"
--summary
(read 
topRules
)
"how many per engine?"use Step 5's summary, or run with 
--engine X --summary
per engine
Combinations
--engine pmd --severity 1,2 --top 5
Output format and presentation templates: 
<skill_dir>/references/post-scan-workflows.md
.
对步骤4中的同一结果文件运行查询脚本（无需重新扫描）：
bash
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
）
“每个引擎有多少违规问题？”使用步骤5的汇总结果，或对每个引擎运行
--engine X --summary
组合请求
--engine pmd --severity 1,2 --top 5
输出格式和呈现模板：
<skill_dir>/references/post-scan-workflows.md
。

Step 8: Describe a Rule

步骤8：解释规则

When the user asks "what does this rule mean?" or "how do I fix this?", use this step to look up and explain a specific rule.
当用户询问“这个规则是什么意思？”或“我该如何修复这个问题？”时，使用本步骤查询并解释特定规则。

When to trigger

触发场景

  • "What is ApexCRUDViolation?"
  • "Explain this rule" / "Why is this flagged?"
  • "What does no-var mean?"
  • "How do I fix OperationWithLimitsInLoop?"
  • "Tell me about this violation"
  • “ApexCRUDViolation是什么？”
  • “解释这个规则” / “为什么会标记这个问题？”
  • “no-var是什么意思？”
  • “我该如何修复OperationWithLimitsInLoop？”
  • “告诉我这个违规问题的详情”

How to execute

执行方式

bash
node "<skill_dir>/scripts/describe-rule.js" "<rule-name>" [--engine <engine>]
Pass 
--engine
when known (from scan context); omit for a broader search. Returns one of 
success
/ 
multiple_matches
/ 
not_found
. Status handling and templates: 
<skill_dir>/references/post-scan-workflows.md
.
bash
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: List Available Rules

步骤9：列出可用规则

Triggers: "what security rules are available?", "list all PMD rules", "rules for JavaScript", "Recommended rules", "how many ESLint rules?", "rules for Apex".
bash
node "<skill_dir>/scripts/list-rules.js" "<selector>" [options]
User saysSelectorOptions
"security rules"
Security
"PMD rules"
pmd
"ESLint security rules"
eslint:Security
"JavaScript rules"
JavaScript
"Apex rules"
Apex
"Recommended rules"
Recommended
"high severity rules"
(1,2)
"just give me counts"
Recommended
--count-only
"top 10 security rules"
Security
--top 10
Filters: 
--engine
, 
--severity
, 
--top
(default 100), 
--count-only
. The script pre-validates selector tokens (catches typos like 
secruity
) before calling the CLI. Presentation: 
<skill_dir>/references/post-scan-workflows.md
.
触发场景：“有哪些安全规则可用？”“列出所有PMD规则”“JavaScript相关规则”“推荐规则”“有多少ESLint规则？”“Apex相关规则”。
bash
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
。脚本会预先验证选择器令牌（捕获拼写错误如
secruity
），然后再调用CLI。呈现方式：
<skill_dir>/references/post-scan-workflows.md
。

Constraints & Gotchas

约束与注意事项

ItemWhy / Fix
Use timestamped JSON + 
.log
via 
tee
Prevents overwrite; matches log to results
--format
flag		Removed in v4+; use 
--output-file <path>.<ext>
Foreground, 1200000ms timeoutSFGE can take 10–20 min; backgrounding loses output
Run scripts with absolute 
<skill_dir>
path
./scripts/
resolves against the user's CWD, not the skill dir
Never apply fixes without confirmationUser must approve code modifications
Vendor file check before fixesIf 50%+ vendor (jQuery/Bootstrap/
*.min.js
), filter first
Fix-script order: filter (if needed) → discover → apply → summarizeSkipping summary leaves the user without an outcome report
SFGE needs explicit 
--workspace
Otherwise template files cause compilation errors
Look up partial rule names firstGuessing returns 0 results; use 
sf code-analyzer rules
ONLY
Bash tool, never MCP
run_code_analyzer
and other MCP tools bypass the script workflow
Never invoke other skills for fixesThis skill owns the full workflow end-to-end
Query existing results, don't re-scanStep 7 filters existing JSON instantly
Scan returns 0 resultsInvalid rule selector — verify with 
sf code-analyzer rules --rule-selector <selector>
jq
parsing fails		Shell quoting — use 
parse-results.js
/ 
query-results.js
instead
Inline scripts written by LLMNever write scripts — use existing ones in 
<skill_dir>/scripts/
Ranking/aggregation answered by ad-hoc PythonAlways use 
query-results.js
; output already has 
topFiles
/
topRules
/
severityCounts
事项原因/解决方法
使用带时间戳的JSON + 
.log
文件并通过
tee
输出		防止文件覆盖；确保日志与结果对应
--format
参数		v4+版本已移除；请使用
--output-file <path>.<ext>
前台运行，超时时间1200000msSFGE扫描可能需要10–20分钟；后台运行会丢失输出
使用绝对路径
<skill_dir>
运行脚本
./scripts/
会解析为用户的当前工作目录，而非技能目录
应用修复前必须获得用户确认用户必须批准代码修改
应用修复前检查第三方库文件如果50%以上的违规来自第三方库（jQuery/Bootstrap/
*.min.js
），先过滤
修复脚本执行顺序：过滤（如有需要）→ 发现 → 应用 → 汇总跳过汇总步骤会导致用户无法获取结果报告
SFGE需要显式传递
--workspace
否则模板文件会导致编译错误
先查询部分匹配的规则名称猜测规则名称会返回0结果；请使用
sf code-analyzer rules
仅使用Bash工具，切勿使用MCP工具
run_code_analyzer
及其他MCP工具会绕过脚本工作流
切勿调用其他技能进行修复本技能全权负责完整的工作流
查询现有结果，不要重新扫描步骤7可即时过滤现有JSON文件
扫描返回0结果规则选择器无效 — 使用
sf code-analyzer rules --rule-selector <selector>
验证
jq
解析失败		Shell引用问题 — 请改用
parse-results.js
/ 
query-results.js
LLM编写内联脚本切勿自行编写脚本 — 使用
<skill_dir>/scripts/
中的现有脚本
使用临时Python脚本进行排序/聚合始终使用
query-results.js
；其输出已包含
topFiles
/
topRules
/
severityCounts

Reference File Index

参考文件索引

Scripts (always execute via 
node
with the absolute 
<skill_dir>/
prefix, never Read):
FileWhen to use
<skill_dir>/scripts/parse-results.js
Step 5 — extract summary from scan JSON
<skill_dir>/scripts/filter-violations.js
Step 6.1 — exclude vendor files (jQuery, Bootstrap) from fixes
<skill_dir>/scripts/discover-fixes.js
Step 6.2 — identify fixable violations
<skill_dir>/scripts/apply-fixes.js
Step 6.4 — apply engine fixes after user confirms
<skill_dir>/scripts/summarize-fixes.js
Step 6.5 — summarize applied changes
<skill_dir>/scripts/query-results.js
Step 7 — filter/drill into existing results without re-scanning
<skill_dir>/scripts/describe-rule.js
Step 8 — look up rule description and documentation
<skill_dir>/scripts/list-rules.js
Step 9 — list/browse available rules by selector with validation
References (read on demand):
FileWhen to read
references/quick-start.md
Command-syntax templates
references/flag-reference.md
Full flag docs, rule-selector syntax
references/error-handling.md
Scan-failure diagnosis
references/engine-reference.md
Engine capabilities, file types, rule tags
references/command-examples.md
Less-common command scenarios
references/special-behaviors.md
SFGE/ApexGuru/AppExchange/diff/large scans
references/vendor-file-handling.md
Vendor-file detection and filtering
references/post-scan-workflows.md
Steps 7–9 — querying, rule description, rule listing
examples/
contains output-structure validation and command patterns (basic/large/security scans, fix workflows).
脚本（始终使用
node
和绝对路径
<skill_dir>/
执行，切勿使用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/
目录包含输出结构验证和命令模式（基础/大规模/安全扫描、修复工作流）。