running-code-analyzer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Running Code Analyzer Skill

运行Code Analyzer技能

⚠️ CRITICAL: Tool Selection

⚠️ 重要提示：工具选择

BEFORE DOING ANYTHING ELSE:

This skill MUST use the Bash tool to execute

sf code-analyzer run

and Node.js scripts.

DO NOT use these tools under any circumstances:

❌
```
run_code_analyzer
```
(MCP tool)
❌
```
mcp__*
```
(any MCP tool)
❌ Any tool containing
```
mcp
```
in its name

If you see a

run_code_analyzer

tool available, ignore it completely. Use only the Bash tool with

sf code-analyzer run

在执行任何操作之前：

本技能必须使用Bash工具来执行

sf code-analyzer run

命令及Node.js脚本。

绝对禁止使用以下工具：

❌
```
run_code_analyzer
```
（MCP工具）
❌
```
mcp__*
```
（任何MCP工具）
❌ 名称中包含
```
mcp
```
的任何工具

如果看到可用的

run_code_analyzer

工具，请完全忽略它，仅使用Bash工具执行

sf code-analyzer run

。

Overview

概述

This skill translates natural language requests ("scan for security issues", "check my changes") into the correct

sf code-analyzer run

command, executes scans with 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 this skill for static analysis, security reviews, AppExchange certification, code quality checks, or finding duplicates/vulnerabilities in Salesforce projects.

本技能可将自然语言请求（如“扫描安全问题”“检查我的代码变更”）转换为正确的

sf code-analyzer run

命令，支持任意组合的引擎/扫描目标/严重等级执行扫描，并呈现可操作的结果。当引擎提供修复方案时，会自动发现这些方案，征求用户确认后安全应用，并提供验证选项。本技能适用于Salesforce项目的静态分析、安全审查、AppExchange认证、代码质量检查，或查找重复代码/漏洞。

Scope

适用范围

In scope:

Running
```
sf code-analyzer run
```
with any combination of engines, targets, categories, severities
Parsing and presenting scan results in actionable format
Applying engine-provided auto-fixes when available
Handling diff-based scans (scan only changed files)
Supporting all output formats (JSON, HTML, SARIF, CSV, XML)
Troubleshooting scan failures and prerequisite issues

Out of scope:

Installing or configuring Salesforce CLI or Code Analyzer plugin (use setup documentation)
Writing custom Code Analyzer rules or engines (separate skill needed)
AI-generated code fixes beyond engine-provided deterministic fixes
Deep code refactoring or architectural changes based on violations
Setting up CI/CD integration for automated scanning (separate workflow skill)

包含范围：

运行
```
sf code-analyzer run
```
命令，支持任意组合的引擎、扫描目标、问题类别、严重等级
解析扫描结果并以可操作的格式呈现
应用引擎提供的自动修复方案（若可用）
处理基于diff的扫描（仅扫描变更文件）
支持所有输出格式（JSON、HTML、SARIF、CSV、XML）
排查扫描失败及前置条件问题

排除范围：

安装或配置Salesforce CLI或Code Analyzer插件（请使用安装文档）
编写自定义Code Analyzer规则或引擎（需使用单独技能）
超出引擎提供的确定性修复之外的AI生成代码修复
基于违规问题进行深度代码重构或架构变更
设置CI/CD集成以实现自动化扫描（需使用单独工作流技能）

Command Syntax Rules (READ THIS FIRST)

命令语法规则（请先阅读）

The following rules are ABSOLUTE and override any prior knowledge:

The command is
sf code-analyzer run
— NOT
```
sf scanner run
```
(deprecated v3 command)
There is NO
--format
flag — use
```
--output-file <path>.<ext>
```
instead (extension determines format)
ALWAYS use
--output-file
to write results to a file — do NOT rely on terminal stdout

ALWAYS include
--output-file
with a timestamped filename (e.g.,

./code-analyzer-results-20260512-143022.json

)

Do NOT run in background — use foreground with timeout of 1200000ms for large scans

INVALID v3 flags:

--format

--engine

--category

--json

— these cause errors, use

--rule-selector

and

--output-file

instead

NEVER use MCP tools — ONLY use the Bash tool to execute
```
sf code-analyzer run
```
Tool restriction: This skill MUST use ONLY: Read, Bash, Write, Edit tools
Forbidden tools: Do NOT use any MCP tools (mcp__*), Agent tool, or web tools
Script execution: ALL scripts MUST be executed via
```
node <skill_dir>/scripts/*.js
```
using the Bash tool

Why: The v4+ CLI redesigned the flag interface. Old v3 flags cause "unknown flag" errors.

For complete flag reference and rule selector syntax, see

<skill_dir>/references/flag-reference.md

以下规则为绝对要求，优先级高于任何已有知识：

命令必须为
sf code-analyzer run
— 不可使用
```
sf scanner run
```
（已废弃的v3版本命令）
不存在
--format
参数 — 请使用
```
--output-file <path>.<ext>
```
替代（文件扩展名决定输出格式）
必须始终使用
--output-file
将结果写入文件 — 不可依赖终端标准输出
必须始终使用带时间戳的文件名作为
```
--output-file
```
的值（例如：
```
./code-analyzer-results-20260512-143022.json
```
）
不可在后台运行 — 需在前台运行，大型扫描超时时间设置为1200000ms
无效的v3版本参数：
```
--format
```
、
```
--engine
```
、
```
--category
```
、
```
--json
```
— 这些参数会导致错误，请使用
```
--rule-selector
```
和
```
--output-file
```
替代
绝对禁止使用MCP工具 — 仅可使用Bash工具执行
```
sf code-analyzer run
```
工具限制： 本技能仅可使用：Read、Bash、Write、Edit工具
禁止使用的工具： 不可使用任何MCP工具（mcp__*）、Agent工具或Web工具
脚本执行： 所有脚本必须通过
```
node <skill_dir>/scripts/*.js
```
使用Bash工具执行

原因： v4+版本的CLI重新设计了参数接口，旧的v3版本参数会触发“未知参数”错误。

如需完整的参数参考及规则选择器语法，请查看
<skill_dir>/references/flag-reference.md
。

Prerequisites

前置条件

User must have: 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).

If a scan fails, read

<skill_dir>/references/error-handling.md

. For quick command examples, see

<skill_dir>/references/quick-start.md

用户必须已安装：Salesforce CLI（

sf

）、@salesforce/plugin-code-analyzer（v5.x+）、Java 11+（用于PMD/CPD/SFGE）、Node.js 18+（用于ESLint/RetireJS）、Python 3（用于Flow），并已认证Salesforce组织（用于ApexGuru）。

若扫描失败，请阅读

<skill_dir>/references/error-handling.md

。如需快速命令示例，请查看

<skill_dir>/references/quick-start.md

。

Tool Usage Rules

工具使用规则

Allowed: Bash (sf code-analyzer, node, git, date), Read, Write, Edit
Forbidden: MCP tools, Agent tool, Web tools, other skills

This skill owns the complete scan-fix-verify workflow. Using MCP tools bypasses the validated script workflow.

允许使用： Bash（用于执行sf code-analyzer、node、git、date命令）、Read、Write、Edit
禁止使用： MCP工具、Agent工具、Web工具、其他技能

本技能全权负责完整的扫描-修复-验证工作流，使用MCP工具会绕过已验证的脚本工作流。

Quick Start: Common Patterns

快速入门：常见场景

Use this decision tree for fast pattern matching before going to Step 1 detailed parsing:

User Says	Action	Rule Selector	Notes
"scan my code" / "run code analyzer"	Default scan	`Recommended`	Curated rule set, all file types
"check for security issues" / "security review"	Security scan	`all:Security:(1,2)`	All engines, Critical+High only
"scan my changes" / "check the diff"	Diff-based scan	Get changed files via `git diff` , filter to scannable types, use `--target`	See Step 1.5 for filtering logic
"run PMD" / "check my Apex"	PMD only	`pmd`	Apex classes and triggers
"lint my LWC" / "check my JavaScript"	ESLint only	`eslint`	JavaScript/TypeScript/LWC
"find duplicates" / "check for copy-paste"	CPD (Copy-Paste Detector)	`cpd`	Detects code clones
"check for vulnerabilities" / "scan libraries"	RetireJS	`retire-js`	JavaScript library CVEs
"deep analysis" / "data flow analysis"	SFGE (Graph Engine)	`sfge`	Requires Java 11+, 10-20min, use `--workspace "force-app"`
"performance analysis" / "governor limits"	ApexGuru	`apexguru`	Requires authenticated org
"analyze my Flows"	Flow engine	`flow`	Target: `*/.flow-meta.xml` , requires Python 3
"AppExchange security review"	AppExchange scan	`all:Security:(1,2)`	Read `<skill_dir>/references/special-behaviors.md` → AppExchange section

If the pattern matches above, proceed directly to Step 3 (Build Command). Otherwise, continue to Step 1 for detailed parsing.

在进入步骤1的详细解析前，可使用以下决策树快速匹配场景：

用户请求	操作	规则选择器	说明
"扫描我的代码" / "运行代码分析器"	默认扫描	`Recommended`	精选规则集，支持所有文件类型
"检查安全问题" / "安全审查"	安全扫描	`all:Security:(1,2)`	所有引擎，仅扫描严重等级1（Critical）和2（High）的问题
"扫描我的变更" / "检查diff内容"	基于diff的扫描	通过 `git diff` 获取变更文件，过滤为可扫描类型，传入 `--target`	查看步骤1.5的过滤逻辑
"运行PMD" / "检查我的Apex代码"	仅使用PMD引擎	`pmd`	扫描Apex类和触发器
"检查我的LWC代码风格" / "检查我的JavaScript代码"	仅使用ESLint引擎	`eslint`	扫描JavaScript/TypeScript/LWC代码
"查找重复代码" / "检查复制粘贴代码"	使用CPD（复制粘贴检测器）	`cpd`	检测代码克隆
"检查漏洞" / "扫描库"	使用RetireJS	`retire-js`	扫描JavaScript库的CVE漏洞
"深度分析" / "数据流分析"	使用SFGE（图引擎）	`sfge`	需要Java 11+，耗时10-20分钟，需使用 `--workspace "force-app"`
"性能分析" / " governor限制检查"	使用ApexGuru	`apexguru`	需要已认证的Salesforce组织
"分析我的Flow"	使用Flow引擎	`flow`	扫描目标： `*/.flow-meta.xml` ，需要Python 3
"AppExchange安全审查"	AppExchange扫描	`all:Security:(1,2)`	阅读 `<skill_dir>/references/special-behaviors.md` → AppExchange章节

若场景匹配上述内容，可直接进入步骤3（构建命令）。否则，继续步骤1进行详细解析。

Step 1: Parse the User's Intent

步骤1：解析用户意图

Analyze the user's request along these 7 dimensions. Any can be combined freely:

从以下7个维度分析用户请求，各维度可自由组合：

1.1 ENGINE — Which analysis engine(s)?

1.1 引擎 — 使用哪个分析引擎？

Map user keywords to

--rule-selector

values:

PMD / Apex rules →
```
pmd
```
ESLint / JS/TS rules / lint →
```
eslint
```
Flows / Flow analysis →
```
flow
```
duplicates / copy-paste / CPD →
```
cpd
```
vulnerabilities / CVE / libraries / RetireJS →
```
retire-js
```
SFGE / data flow / deep analysis →
```
sfge
```
performance / ApexGuru →
```
apexguru
```
regex / pattern rules →
```
regex
```
all engines / everything →
```
all
```
Not specified / general "scan" →
```
Recommended
```
(default)

将用户关键词映射为

--rule-selector

的值：

PMD / Apex规则 →
```
pmd
```
ESLint / JS/TS规则 / lint →
```
eslint
```
Flows / Flow分析 →
```
flow
```
重复代码 / 复制粘贴 / CPD →
```
cpd
```
漏洞 / CVE / 库 / RetireJS →
```
retire-js
```
SFGE / 数据流 / 深度分析 →
```
sfge
```
性能 / ApexGuru →
```
apexguru
```
正则 / 模式规则 →
```
regex
```
所有引擎 / 全部扫描 →
```
all
```
未指定 / 通用“扫描”请求 →
```
Recommended
```
（默认值）

1.2 CATEGORY — What kind of issues?

1.2 类别 — 检查哪类问题？

Map user keywords to category tags:

security / vulnerabilities / OWASP →
```
Security
```
performance / speed / optimization →
```
Performance
```
best practices / quality →
```
BestPractices
```
code style / formatting →
```
CodeStyle
```
design / complexity →
```
Design
```
error prone / bugs →
```
ErrorProne
```
documentation / comments →
```
Documentation
```

将用户关键词映射为类别标签：

安全 / 漏洞 / OWASP →
```
Security
```
性能 / 速度 / 优化 →
```
Performance
```
最佳实践 / 代码质量 →
```
BestPractices
```
代码风格 / 格式 →
```
CodeStyle
```
设计 / 复杂度 →
```
Design
```
易出错 / 漏洞 →
```
ErrorProne
```
文档 / 注释 →
```
Documentation
```

1.3 SEVERITY — How critical?

1.3 严重等级 — 问题的严重程度？

Severity levels: 1=Critical (must fix), 2=High (should fix), 3=Moderate (recommended), 4=Low (nice to fix), 5=Info (FYI)

Map user keywords:

"critical only" / "sev 1" →
```
1
```
"critical and high" / "sev 1-2" →
```
(1,2)
```
"moderate and above" / "sev 1-3" →
```
(1,2,3)
```

严重等级： 1=Critical（必须修复），2=High（应该修复），3=Moderate（建议修复），4=Low（可选修复），5=Info（仅供参考）

用户关键词映射：

"仅严重问题" / "sev 1" →
```
1
```
"严重和高优先级问题" / "sev 1-2" →
```
(1,2)
```
"中等及以上问题" / "sev 1-3" →
```
(1,2,3)
```

1.4 SPECIFIC RULE — Named rule?

1.4 特定规则 — 指定规则名称？

If the user mentions a specific rule by name (e.g., "ApexCRUDViolation", "no-unused-vars"):

Map to:
```
--rule-selector <engine>:<ruleName>
```
If engine is ambiguous, use just the rule name:
```
--rule-selector <ruleName>
```

⚠️ IMPORTANT — Partial Rule Names: The

--rule-selector

flag requires the EXACT full rule name (e.g.,

@salesforce-ux/slds/no-hardcoded-values-slds2

, not

no-hardcoded-values

). It does NOT support wildcards or partial matches.

When you are NOT 100% certain of the full rule name:

Do NOT guess — a wrong name returns 0 results and wastes a scan cycle

Instead, look up the rule first using the

sf code-analyzer rules

command with grep:

bash

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

Extract the full rule name from the output, then use it in your scan command
If grep returns multiple matches, present them to the user and ask which one they meant
If grep returns 0 matches, tell the user no rule matched their keyword

若用户提及特定规则名称（例如："ApexCRUDViolation"、"no-unused-vars"）：

映射为：
```
--rule-selector <engine>:<ruleName>
```
若引擎不明确，仅使用规则名称：
```
--rule-selector <ruleName>
```

⚠️ 重要提示 — 规则名称部分匹配：

--rule-selector

参数需要完整的规则名称（例如：

@salesforce-ux/slds/no-hardcoded-values-slds2

，而非

no-hardcoded-values

），不支持通配符或部分匹配。

若无法100%确定完整规则名称：

请勿猜测 — 错误的名称会导致扫描返回0结果，浪费扫描周期

应先使用

sf code-analyzer rules

命令结合grep查找规则：

bash

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

从输出中提取完整规则名称，再用于扫描命令
若grep返回多个匹配结果，将结果展示给用户并询问具体需要哪一个
若grep返回0匹配结果，告知用户没有匹配其关键词的规则

1.5 TARGET — What files to scan?

1.5 扫描目标 — 扫描哪些文件？

Map user keywords:

Specific file/folder →
```
--target <path>
```
Glob pattern / "all Apex classes" →
```
--target **/*.cls,**/*.trigger
```
"my changes" / "diff" → Run
```
git diff --name-only [base]...HEAD
```
, filter to scannable types, pass as
```
--target
```
"LWC" →
```
--target **/lwc/**
```
"Flows" →
```
--target **/*.flow-meta.xml
```
Not specified → Entire workspace (omit
```
--target
```
)

For diff filtering details: See

<skill_dir>/references/special-behaviors.md

用户关键词映射：

特定文件/文件夹 →
```
--target <path>
```
通配符模式 / "所有Apex类" →
```
--target **/*.cls,**/*.trigger
```
"我的变更" / "diff内容" → 执行
```
git diff --name-only [base]...HEAD
```
，过滤为可扫描类型，传入
```
--target
```
"LWC" →
```
--target **/lwc/**
```
"Flows" →
```
--target **/*.flow-meta.xml
```
未指定 → 扫描整个工作区（省略
```
--target
```
）

diff过滤详情： 查看

<skill_dir>/references/special-behaviors.md

。

1.6 OUTPUT — What format?

1.6 输出格式 — 使用哪种格式？

DEFAULT: Always JSON. Only change if user EXPLICITLY requests another format.

Naming:

./code-analyzer-results-<YYYYMMDD-HHmmss>.<ext>

(timestamp via

TIMESTAMP=$(date +%Y%m%d-%H%M%S)

)

Formats:

.json

(default),

.html

(report),

.sarif

(GitHub/IDE),

.csv

(spreadsheet),

.xml

默认： 始终使用JSON格式。仅当用户明确要求其他格式时才更改。

命名规则：

./code-analyzer-results-<YYYYMMDD-HHmmss>.<ext>

（时间戳通过

TIMESTAMP=$(date +%Y%m%d-%H%M%S)

生成）

支持格式：

.json

（默认）、

.html

（报告）、

.sarif

（GitHub/IDE兼容）、

.csv

（电子表格）、

.xml

1.7 COMPARISON — Delta/trend analysis?

1.7 对比分析 — 增量/趋势分析？

Map user keywords:

"new since main" →
```
git diff --name-only main...HEAD
```
→ scan those files
"new since last commit" →
```
git diff --name-only HEAD~1
```
"compared to develop" →
```
git diff --name-only develop...HEAD
```

用户关键词映射：

"相较于main分支的新问题" →
```
git diff --name-only main...HEAD
```
→ 扫描这些文件
"相较于上一次提交的新问题" →
```
git diff --name-only HEAD~1
```
"相较于develop分支的新问题" →
```
git diff --name-only develop...HEAD
```

Step 2: Build the Rule Selector

步骤2：构建规则选择器

Syntax:

= AND,

= OR,

()

= grouping

Examples:

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 rules:
```
all
```

More examples:

<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：构建完整命令

Generate timestamp:

TIMESTAMP=$(date +%Y%m%d-%H%M%S)

Build command:

bash

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

Key decisions:

DEFAULT: timestamped JSON (
```
.json
```
). Only change format if user explicitly requests HTML/SARIF/CSV/XML.
Always include
```
--include-fixes
```
(enables Step 6 auto-fix)
Omit
```
--target
```
to scan entire workspace
For diff-based scans: get files via
```
git diff --name-only
```
, filter to scannable types, pass as
```
--target
```

Special cases: See

<skill_dir>/references/special-behaviors.md

for SFGE/ApexGuru/AppExchange/diff filtering.

生成时间戳：

TIMESTAMP=$(date +%Y%m%d-%H%M%S)

构建命令：

bash

sf code-analyzer run \
  --rule-selector <selector> \
  --target <targets> \              # 可选
  --output-file "./code-analyzer-results-${TIMESTAMP}.json" \  # 默认：JSON
  --include-fixes \                 # 必须包含
  --workspace <path>                # 可选

关键决策：

默认使用带时间戳的JSON格式（
```
.json
```
）。仅当用户明确要求HTML/SARIF/CSV/XML时才更改格式。
必须始终包含
```
--include-fixes
```
（启用步骤6的自动修复功能）
省略
```
--target
```
以扫描整个工作区
基于diff的扫描：通过
```
git diff --name-only
```
获取文件，过滤为可扫描类型，传入
```
--target
```

特殊场景： 查看

<skill_dir>/references/special-behaviors.md

中关于SFGE/ApexGuru/AppExchange/diff过滤的内容。

Step 4: Execute the Scan

步骤4：执行扫描

⚠️ TOOL REQUIREMENT: Use Bash tool ONLY. DO NOT use run_code_analyzer (MCP tool) or any MCP tool.

Rules: Foreground only (no

run_in_background

), hardcoded filename (not

$TIMESTAMP

), timeout 1200000ms, no

sleep

, log output to timestamped file.

Steps:

Generate timestamp:
```
date +%Y%m%d-%H%M%S
```
→ capture output (e.g.,
```
20260512-143022
```
) using Bash tool

Tell user:

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

Run command with literal timestamp in filename and

tee

to capture log (timeout: 1200000):

⚠️ IMPORTANT: Use the Bash tool, NOT the run_code_analyzer MCP tool.

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"

After completion: Exit 0 = success. Error output → check both the log file and
```
<skill_dir>/references/error-handling.md
```
.
IMMEDIATELY parse results (Step 5). Do NOT ask user what they want.

⚠️ 工具要求：仅可使用Bash工具。禁止使用run_code_analyzer（MCP工具）或任何MCP工具。

规则： 仅在前台运行（不可使用

run_in_background

），文件名使用固定时间戳（不可使用

$TIMESTAMP

变量），超时时间1200000ms，不可使用

sleep

，日志输出到带时间戳的文件。

步骤：

生成时间戳：执行
```
date +%Y%m%d-%H%M%S
```
→ 捕获输出（例如：
```
20260512-143022
```
）必须使用Bash工具

告知用户：

开始扫描...
结果文件：./code-analyzer-results-20260512-143022.json
日志文件：./code-analyzer-results-20260512-143022.log
大型代码库可能需要数分钟时间。

执行命令，文件名使用固定时间戳，并通过

tee

捕获日志（超时时间：1200000）：

⚠️ 重要提示： 使用Bash工具，不可使用run_code_analyzer MCP工具。

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"

扫描完成后：退出码0表示成功。若有错误输出 → 检查日志文件及
```
<skill_dir>/references/error-handling.md
```
。
立即解析结果（步骤5），不可询问用户下一步操作。

Step 5: Parse and Present Results

步骤5：解析并呈现结果

Parsing Rules:

解析规则：

Execute the parse script using
<skill_dir>
— see below
NEVER use
jq
to parse results — jq one-liners WILL fail due to shell quoting issues
Run it IMMEDIATELY after the scan — do NOT ask the user "what would you like next?"

使用
<skill_dir>
路径执行解析脚本 — 详见下文
禁止使用
jq
解析结果 — jq单行命令会因shell引号问题导致失败
扫描完成后立即执行解析 — 不可询问用户“接下来需要做什么？”

Script Execution

脚本执行

All scripts are bundled in the

scripts/

subdirectory of the same directory that contains this SKILL.md file. Use the absolute path to that directory — do NOT use

./scripts/

as that resolves relative to the current working directory, not the skill directory.

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

所有脚本都包含在本SKILL.md文件所在目录的

scripts/

子目录中。请使用该目录的绝对路径 — 不可使用

./scripts/

，因为该路径相对于当前工作目录，而非技能目录。

bash

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

⚠️ 禁止：

❌ 自行编写或生成脚本代码
❌ 使用相对路径如
```
node scripts/parse-results.js
```
（无法从用户的当前工作目录正确解析）
❌ 使用here文档或内联脚本内容
❌ 使用
```
jq
```
替代解析脚本

How to Present Results:

结果呈现方式：

ALWAYS present a concise summary, then point to the output file for full details.

undefined

必须先呈现简洁摘要，再引导用户查看输出文件获取完整详情。

undefined

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

共发现X个违规问题，分布在Y个文件中。

严重等级	数量
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
2	ApexSOQLInjection	pmd	1	QueryHelper.cls	18
... (show up to 10 most critical)

#	规则	引擎	严重等级	文件	行号
1	ApexCRUDViolation	pmd	2	AccountService.cls	42
2	ApexSOQLInjection	pmd	1	QueryHelper.cls	18
...（最多显示10个最严重的问题）

Top Rules by Frequency

高频规则

Rule	Engine	Count
no-var	eslint	170
ApexDoc	pmd	165
...

Full results:

./code-analyzer-results-20260512-143022.json

undefined

规则	引擎	出现次数
no-var	eslint	170
ApexDoc	pmd	165
...

完整结果：

./code-analyzer-results-20260512-143022.json

undefined

Result Presentation Rules:

结果呈现规则：

0 violations: "Scan complete — no violations found! Output:
```
<path>
```
"
1-10: Show all violations in table
11-50: Show severity counts + top 10 violations
50-5000: Show counts + top 10 violations + top 10 rules + top 5 files
5000+: Same as 50-5000, plus suggest narrowing scope (severity/category/folder)

Always end with: Output file path + next-action offers (explain rules / apply fixes)

For large result sets: See

<skill_dir>/references/special-behaviors.md

0个违规问题：“扫描完成 — 未发现违规问题！输出文件：
```
<path>
```
”
1-10个违规问题：在表格中显示所有违规问题
11-50个违规问题：显示严重等级统计 + 前10个违规问题
50-5000个违规问题：显示统计数据 + 前10个违规问题 + 前10个高频规则 + 前5个问题最多的文件
5000+个违规问题：与50-5000个的呈现方式相同，额外建议缩小扫描范围（严重等级/类别/文件夹）

必须以以下内容结尾： 输出文件路径 + 后续操作选项（解释规则 / 应用修复）

针对大型结果集： 查看

<skill_dir>/references/special-behaviors.md

。

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

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

After presenting results, check if violations have engine-provided fixes (deterministic, not AI-generated).

Rules: NEVER apply without confirmation. Use EXACT scripts from

<skill_dir>/scripts/

. Filter vendor files if needed, then: Discover → Apply → Summarize.

Flow: Filter vendor (6.1 if needed) → discover (6.2) → present (6.3) → ASK user → apply (6.4) → summarize (6.5) → present results.

呈现结果后，检查违规问题是否有引擎提供的修复方案（确定性修复，非AI生成）。

规则：未经用户确认，绝对不可应用修复。 使用

<skill_dir>/scripts/

中的脚本。若需要，先过滤第三方库文件，然后按以下流程操作：发现修复方案 → 应用修复 → 总结结果。

流程： 过滤第三方库（若需要，步骤6.1）→ 发现修复方案（步骤6.2）→ 呈现修复方案（步骤6.3）→ 询问用户 → 应用修复（步骤6.4）→ 总结修复结果（步骤6.5）→ 呈现最终结果。

6.1 — Check for vendor files (if needed)

6.1 — 检查第三方库文件（若需要）

If user said "fix my code" or "project source", or if top files by violation count are vendor libraries (jQuery, Bootstrap, *.min.js), run:

bash

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

Present: "Excluded X vendor files (Y violations) - jQuery, Bootstrap, etc. Applying fixes to Z project files only."

Use filtered file for Step 6.3+. See:

<skill_dir>/references/vendor-file-handling.md

for detailed logic.

若用户提及“修复我的代码”或“项目源码”，或违规问题最多的文件是第三方库（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.3及后续操作。详情： 查看

<skill_dir>/references/vendor-file-handling.md

中的逻辑。

6.2 — Discover fixable violations

6.2 — 发现可修复的违规问题

bash

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

(Use filtered file from Step 6.1 if created.)

bash

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

（若步骤6.1生成了过滤后的文件，请使用该文件。）

6.3 — Present fixable violations and ASK for confirmation

6.3 — 呈现可修复的违规问题并请求用户确认

After running the discovery script, present results:

undefined

执行发现脚本后，呈现结果：

undefined

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
no-hardcoded-values-slds2	eslint	4	76
...

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)

undefined

Y个违规问题中的X个有分析引擎提供的自动修复方案：

规则	引擎	严重等级	可修复数量
no-var	eslint	3	170
no-hardcoded-values-slds2	eslint	4	76
...

这些是由引擎生成的安全、确定性修复方案（非AI生成）。

是否需要应用这些修复方案？（是 / 否 / 选择特定规则）

undefined

⚠️ STOP HERE AND WAIT FOR USER RESPONSE.

⚠️ 在此处停止并等待用户回复。

Even if the user originally said "scan and fix everything", you MUST still stop here and wait. Present the table, ask the question, and WAIT for a response in the NEXT turn.

即使用户最初要求“扫描并修复所有问题”，也必须在此处停止并等待用户回复。 呈现表格，询问用户，等待用户的下一次回复。

6.4 — Apply fixes ONLY after user confirms

6.4 — 仅在用户确认后应用修复

Only proceed after user says "yes", "apply", "go ahead" IN A SEPARATE RESPONSE.

bash

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

(Use filtered file if Step 6.1 created one.)

仅当用户在单独的回复中表示“是”“应用”“继续”时，才可执行此步骤。

bash

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

（若步骤6.1生成了过滤后的文件，请使用该文件。）

6.5 — After applying, ALWAYS run the summary script

6.5 — 应用修复后，必须执行总结脚本

⚠️ MANDATORY: After the apply script completes, you MUST run the summary script as your VERY NEXT action.

bash

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

Then present to the user:

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.

Severity	Fixes Applied
Critical (1)	X
High (2)	X
...

Rule	Fixes Applied
no-var	169
...

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

undefined

已在Y个文件中应用X个自动修复。

严重等级	已应用修复数量
Critical (1)	X
High (2)	X
...

规则	已应用修复数量
no-var	169
...

是否需要重新运行扫描以验证修复是否解决了违规问题？

undefined

6.6 — If user declines: Skip. If selects rules: filter. If "all": run as-is.

6.6 — 若用户拒绝：跳过修复。若用户选择特定规则：过滤规则后应用。若用户选择“全部”：按原计划执行。

6.7 — Re-scan (optional): Re-run with new timestamp, compare before/after counts.

6.7 — 重新扫描（可选）：使用新的时间戳重新运行扫描，对比修复前后的违规数量。

Rules / Constraints

规则 / 约束

Constraint	Rationale
Timestamped output (JSON + log)	Prevents overwrite; enables history tracking
Use `tee` for logs	Keeps logs in working dir with matching timestamp
Never use `--format` flag	Removed in v4+; use `--output-file <path>.<ext>` instead
Foreground scans, 1200000ms timeout	SFGE takes 10-20min; backgrounding loses output
Execute scripts from `<skill_dir>/scripts/`	Never write inline scripts or heredocs
Never apply fixes without confirmation	User must explicitly approve code modifications
Check for vendor files before fixes	If 50%+ vendor (jQuery, Bootstrap), filter first
Run fix scripts in order	Filter (if needed) → Discover → Apply → Summarize
SFGE needs explicit `--workspace`	Prevents template file compilation errors
Look up partial rule names first	Guessing fails; use `sf code-analyzer rules` to find exact name
ONLY Bash tool, never MCP	run_code_analyzer MCP tool bypasses script workflow
Never invoke other skills for fixes	This skill owns complete workflow end-to-end

约束	原因
带时间戳的输出文件（JSON + 日志）	防止文件覆盖；支持历史追踪
使用 `tee` 记录日志	将日志保存在工作目录中，与结果文件使用相同时间戳
禁止使用 `--format` 参数	v4+版本已移除；使用 `--output-file <path>.<ext>` 替代
前台扫描，超时时间1200000ms	SFGE扫描耗时10-20分钟；后台运行会丢失输出
从 `<skill_dir>/scripts/` 执行脚本	禁止编写内联脚本或here文档
未经确认不可应用修复	用户必须明确批准代码修改
应用修复前检查第三方库文件	若50%以上的违规问题来自第三方库（如jQuery、Bootstrap），需先过滤
按顺序执行修复脚本	过滤（若需要）→ 发现 → 应用 → 总结
SFGE需要显式指定 `--workspace`	防止模板文件编译错误
先查找部分匹配的规则名称	猜测规则名称会导致失败；使用 `sf code-analyzer rules` 查找准确名称
仅使用Bash工具，禁止使用MCP工具	run_code_analyzer MCP工具会绕过脚本工作流
禁止调用其他技能进行修复	本技能全权负责完整的工作流

Gotchas

常见问题

Issue	Why It Happens	Solution
`--format` flag error	Removed in v4+	Use `--output-file <path>.<ext>`
Scan returns 0 results	Invalid rule selector	Run `sf code-analyzer rules --rule-selector <selector>` to verify
SFGE compilation error	Template files in workspace	Set `--workspace "force-app"`
jq parsing fails	Shell quoting issues	Use `node "<skill_dir>/scripts/parse-results.js"`
Inline scripts written	LLM generates custom code	NEVER write scripts — use existing from <skill_dir>/scripts/
Scan times out	Large SFGE	Increase timeout to 1200000ms
run_code_analyzer MCP used	LLM prefers MCP over Bash	Use Bash tool ONLY
Other skills invoked	LLM delegates to other skills	Use apply-fixes.js from this skill only
Most violations are vendor	Includes jQuery, Bootstrap, *.min.js	Run filter-violations.js before applying fixes

问题	原因	解决方案
`--format` 参数错误	v4+版本已移除该参数	使用 `--output-file <path>.<ext>` 替代
扫描返回0结果	规则选择器无效	执行 `sf code-analyzer rules --rule-selector <selector>` 验证
SFGE编译错误	工作区中包含模板文件	设置 `--workspace "force-app"`
jq解析失败	shell引号问题	使用 `node "<skill_dir>/scripts/parse-results.js"`
生成内联脚本	大语言模型生成了自定义代码	禁止编写脚本 — 使用 `<skill_dir>/scripts/` 中的现有脚本
扫描超时	SFGE扫描大型代码库	将超时时间增加至1200000ms
使用了run_code_analyzer MCP工具	大语言模型偏好MCP工具而非Bash	仅使用Bash工具
调用了其他技能	大语言模型将任务委托给其他技能	仅使用本技能的apply-fixes.js脚本
大多数违规问题来自第三方库	扫描包含了jQuery、Bootstrap、*.min.js等文件	应用修复前先执行filter-violations.js

Output Expectations

输出要求

Every scan produces: timestamped JSON file, concise summary (severity/top violations/rules/files), next-action offers. If fixes applied: summary by severity/rule, offer verification.

每次扫描必须生成：带时间戳的JSON文件、简洁摘要（严重等级/主要违规问题/高频规则/问题文件）、后续操作选项。若应用了修复：按严重等级/规则总结修复结果，并提供验证选项。

Reference File Index

参考文件索引

<skill_dir>

is the absolute path to the directory containing this SKILL.md file.

<skill_dir>

是包含本SKILL.md文件的目录的绝对路径。

Scripts (Always execute, never read)

脚本（仅可执行，不可读取内容）

File	When 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/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 — 总结已应用的变更

References (Read when needed)

参考文档（需要时读取）

File	When to read
`<skill_dir>/references/quick-start.md`	Command syntax templates
`<skill_dir>/references/flag-reference.md`	Flag docs, rule selector syntax
`<skill_dir>/references/error-handling.md`	Scan failure diagnosis
`<skill_dir>/references/engine-reference.md`	Engine capabilities, file types, rule tags
`<skill_dir>/references/command-examples.md`	Uncommon command scenarios
`<skill_dir>/references/special-behaviors.md`	SFGE/ApexGuru/AppExchange/diff/large scans
`<skill_dir>/references/vendor-file-handling.md`	Vendor file detection and filtering logic

Examples in

<skill_dir>/examples/

show output structure validation and command patterns (basic/large/security scans, fix workflows).

文件	读取场景
`<skill_dir>/references/quick-start.md`	命令语法模板
`<skill_dir>/references/flag-reference.md`	参数文档、规则选择器语法
`<skill_dir>/references/error-handling.md`	扫描失败诊断
`<skill_dir>/references/engine-reference.md`	引擎能力、支持的文件类型、规则标签
`<skill_dir>/references/command-examples.md`	特殊命令场景
`<skill_dir>/references/special-behaviors.md`	SFGE/ApexGuru/AppExchange/diff/大型扫描场景
`<skill_dir>/references/vendor-file-handling.md`	第三方库文件检测及过滤逻辑

<skill_dir>/examples/

中的示例展示了输出结构验证及命令模式（基础/大型/安全扫描、修复工作流）。