Back to Details

configuring-code-analyzer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Configuring Code Analyzer Skill

配置Code Analyzer技能

Overview

概述

This skill manages the 
code-analyzer.yml
configuration file — the single source of truth for how Code Analyzer behaves in a project. All customization (engines, rules, ignores, suppressions) is done by creating or editing this file. If the file doesn't exist, this skill creates it in the current working directory.
本技能管理
code-analyzer.yml
配置文件——它是Code Analyzer在项目中行为的唯一可信来源。所有自定义设置（引擎、规则、忽略项、抑制项）都通过创建或编辑该文件完成。如果文件不存在，本技能会在当前工作目录中创建它。

Scope

适用范围

In scope:
  • Checking prerequisites (sf CLI, Java, Node.js, Python, org auth)
  • Installing/updating the Code Analyzer plugin
  • Creating 
    code-analyzer.yml
    if it doesn't exist
  • Editing 
    code-analyzer.yml
    for all configuration changes
  • Engine settings, rule overrides, ignore patterns, suppressions
  • CI/CD pipeline setup (GitHub Actions, Jenkins, etc.)
  • Environment validation and troubleshooting
Out of scope:
  • Running scans (use 
    running-code-analyzer
    skill)
  • Fixing violations, explaining rules, creating custom rules, suppression management
包含内容：
  • 检查前置条件（sf CLI、Java、Node.js、Python、org授权）
  • 安装/更新Code Analyzer插件
  • 若
    code-analyzer.yml
    不存在则创建该文件
  • 编辑
    code-analyzer.yml
    以完成所有配置变更
  • 引擎设置、规则覆盖、忽略模式、抑制项
  • CI/CD流水线设置（GitHub Actions、Jenkins等）
  • 环境验证和故障排查
不包含内容：
  • 运行扫描（请使用
    running-code-analyzer
    技能）
  • 修复违规问题、解释规则、创建自定义规则、管理抑制项

Tool Usage Rules

工具使用规则

Allowed: Bash (sf, java, node, python3, git, npm), Read, Write, Edit Forbidden: MCP tools, Agent tool, Web tools, other skills, 
which
, 
find
, 
locate
, searching for binaries
允许使用： Bash（sf、java、node、python3、git、npm）、读取、写入、编辑 禁止使用： MCP工具、Agent工具、Web工具、其他技能、
which
、
find
、
locate
、搜索二进制文件

Core Principle: YAML Only When Customizing

核心原则：仅在自定义时创建YAML

Code Analyzer works out of the box with NO config file — all defaults are built into the tool. The 
code-analyzer.yml
file is ONLY created when the user explicitly requests a customization.
Rules:
  • Do NOT create 
    code-analyzer.yml
    proactively     — only when user asks to change something
  • Do NOT duplicate built-in defaults — only write entries that intentionally override behavior
  • Always place at project root — where 
    sfdx-project.json
    or 
    sf-project.json
    lives
  • The CLI auto-discovers it — 
    sf code-analyzer run
    from project root automatically picks up 
    code-analyzer.yml
    in that directory. No 
    --config-file
    flag needed.
  • User says "configure code analyzer" with no specifics? → Ask what they want to customize. Don't create an empty or boilerplate file.
Workflow:
  1. User requests a customization (e.g., "disable PMD", "ignore test files", "increase SFGE memory")
  2. Check if 
    code-analyzer.yml
    exists at project root
  3. If NO → create it at project root with ONLY the requested override
  4. If YES → read it, then edit in the requested change
  5. Validate with 
    sf code-analyzer config
Code Analyzer无需配置文件即可开箱即用——所有默认设置都内置在工具中。仅当用户明确要求自定义时，才创建
code-analyzer.yml
文件。
规则：
  • 请勿主动创建
    code-analyzer.yml
    ——仅当用户要求更改设置时才创建
  • 请勿重复内置默认值——仅写入有意覆盖行为的条目
  • 始终放置在项目根目录——即
    sfdx-project.json
    或
    sf-project.json
    所在位置
  • CLI会自动发现该文件——从项目根目录运行
    sf code-analyzer run
    时，会自动识别该目录下的
    code-analyzer.yml
    ，无需使用
    --config-file
    参数
  • 用户仅说“configure code analyzer”但未指定具体内容？→ 询问用户想要自定义的内容。请勿创建空文件或模板文件。
工作流程：
  1. 用户请求自定义（例如：“disable PMD”“ignore test files”“increase SFGE memory”）
  2. 检查项目根目录是否存在
    code-analyzer.yml
  3. 如果不存在→在项目根目录创建该文件，仅包含用户请求的覆盖配置
  4. 如果存在→读取文件，然后编辑以添加/修改请求的变更
  5. 使用
    sf code-analyzer config
    验证配置

Step 1: Understand Intent and Map to Config Sections

步骤1：理解用户意图并映射到配置章节

The user can request ANY combination of configuration changes in natural language. Your job is to:
  1. Parse what they want — may be one thing or many things combined
  2. Map each request to the correct section(s) of 
    code-analyzer.yml
  3. Create the file if it doesn't exist, then apply all changes
用户可能用自然语言请求任意组合的配置变更。你的任务是：
  1. 解析用户需求——可能是单一需求或多个需求组合
  2. 将每个请求映射到
    code-analyzer.yml
    的对应章节
  3. 如果文件不存在则创建，然后应用所有变更

The 
code-analyzer.yml
Structure (what you can write/edit)

code-analyzer.yml
结构（可写入/编辑的内容）

yaml
config_root: .                    # Root for relative path resolution
log_folder: <path>                # Where logs are written
log_level: <1-5>                  # 1=Error, 2=Warn, 3=Info, 4=Debug, 5=Fine

ignores:                          # Files/folders excluded from scanning
  files: [<glob patterns>]

engines:                          # Per-engine settings
  <engine_name>:
    disable_engine: <bool>
    <engine_specific_keys>: ...

rules:                            # Per-rule overrides
  <engine_name>:
    <rule_name>:
      severity: <1-5>
      tags: [<strings>]
      disabled: <bool>

suppressions:                     # Bulk suppression configuration
  disable_suppressions: <bool>
  "<file_or_folder_path>":
    - rule_selector: "<selector>"
      max_suppressed_violations: <number|null>
      reason: "<why>"
yaml
config_root: .                    # 相对路径解析的根目录
log_folder: <path>                # 日志写入路径
log_level: <1-5>                  # 1=错误, 2=警告, 3=信息, 4=调试, 5=详细

ignores:                          # 排除在扫描外的文件/文件夹
  files: [<glob patterns>]

engines:                          # 各引擎的设置
  <engine_name>:
    disable_engine: <bool>
    <engine_specific_keys>: ...

rules:                            # 各规则的覆盖配置
  <engine_name>:
    <rule_name>:
      severity: <1-5>
      tags: [<strings>]
      disabled: <bool>

suppressions:                     # 批量抑制配置
  disable_suppressions: <bool>
  "<file_or_folder_path>":
    - rule_selector: "<selector>"
      max_suppressed_violations: <number|null>
      reason: "<why>"

Mapping Principle

映射原则

Any user request maps to one or more sections above. Parse the intent and edit the right section(s):
Intent CategoryMaps ToExamples of What User Might Say
Setup / InstallStep 2 (prerequisites + install)"set up", "install", "get started", "new laptop", "from scratch"
Diagnose / FixStep 2A (systematic debug)"not working", "broken", "fix my setup", "scan fails", "getting errors"
Engine control
engines.<name>.disable_engine
"disable X", "turn off Y", "only use Z", "enable all"
Engine tuning
engines.<name>.<property>
"increase memory", "change heap", "use my eslint config", "set tokens to 50"
File exclusions
ignores.files
"exclude", "ignore", "skip", "don't scan X"
Rule severity
rules.<engine>.<rule>.severity
"make X critical", "promote", "demote", "change severity"
Rule disable
rules.<engine>.<rule>.disabled
"disable rule X", "turn off Y rule", "remove Z"
Rule tags
rules.<engine>.<rule>.tags
"tag X as security", "add recommended tag"
Suppressions
suppressions
section		"suppress X in folder Y", "allow N violations"
CI/CDGenerate pipeline file (separate from config)"github actions", "CI", "quality gate"
View/inspectRead file + 
sf code-analyzer config
"show config", "what's configured", "current settings"
任何用户请求都会映射到上述一个或多个章节。解析意图并编辑对应章节：
意图类别映射到用户可能的表述示例
安装/设置步骤2（前置条件+安装）"set up"、"install"、"get started"、"new laptop"、"from scratch"
诊断/修复步骤2A（系统化调试）"not working"、"broken"、"fix my setup"、"scan fails"、"getting errors"
引擎控制
engines.<name>.disable_engine
"disable X"、"turn off Y"、"only use Z"、"enable all"
引擎调优
engines.<name>.<property>
"increase memory"、"change heap"、"use my eslint config"、"set tokens to 50"
文件排除
ignores.files
"exclude"、"ignore"、"skip"、"don't scan X"
规则严重程度
rules.<engine>.<rule>.severity
"make X critical"、"promote"、"demote"、"change severity"
规则禁用
rules.<engine>.<rule>.disabled
"disable rule X"、"turn off Y rule"、"remove Z"
规则标签
rules.<engine>.<rule>.tags
"tag X as security"、"add recommended tag"
抑制项
suppressions
章节		"suppress X in folder Y"、"allow N violations"
CI/CD生成流水线文件（与配置文件分离）"github actions"、"CI"、"quality gate"
查看/检查读取文件 + 
sf code-analyzer config
"show config"、"what's configured"、"current settings"

File Existence Decision

文件存在性判断

BEFORE editing anything, check if 
code-analyzer.yml
exists at project root:
bash
ls code-analyzer.yml code-analyzer.yaml 2>/dev/null
  • File does NOT exist → Create it at project root with ONLY the user's requested override(s)
  • File exists → Read it, then Edit to add/modify the requested section(s)
The CLI auto-discovers 
code-analyzer.yml
in the current directory. Since scans run from project root, the file must live there.
在编辑任何内容之前，检查项目根目录是否存在
code-analyzer.yml
：
bash
ls code-analyzer.yml code-analyzer.yaml 2>/dev/null
  • 文件不存在→在项目根目录创建该文件，仅包含用户请求的覆盖配置
  • 文件存在→读取文件，然后编辑以添加/修改请求的章节
CLI会自动识别当前目录下的
code-analyzer.yml
。由于扫描从项目根目录运行，该文件必须放在此处。

⚠️ Rule Name Resolution — ALWAYS Before Writing YAML

⚠️规则名称解析——写入YAML前必须完成

When a user references rules by partial, descriptive, or approximate names (e.g., "the doc rule", "CRUD violation", "console rule", "hardcoded values"), you MUST resolve to exact rule names using the lookup in Step 6.1 BEFORE writing any YAML. The 
code-analyzer.yml
file silently ignores rule names that don't exactly match — there is no error, the override just won't apply.
Examples of fuzzy → exact resolution needed:
  • "Disable the ApexDoc rule" → lookup confirms 
    ApexDoc
    (engine: 
    pmd
    )
  • "Demote no-console to low" → lookup confirms 
    no-console
    (engine: 
    eslint
    )
  • "Make CRUD violations critical" → lookup confirms 
    ApexCRUDViolation
    (engine: 
    pmd
    )
  • "Turn off the hardcoded values check" → lookup finds 
    @salesforce-ux/slds/no-hardcoded-values-slds2
    (engine: 
    eslint
    )
  • "Disable the injection rule" → multiple matches possible → ask user which one
Only skip the lookup when the user provides an unambiguous, exact, well-known name (e.g., "ApexDoc", "no-console", "no-unused-vars").
当用户通过部分描述性或近似名称引用规则时（例如："the doc rule"、"CRUD violation"、"console rule"、"hardcoded values"），你必须在写入任何YAML之前，使用步骤6.1中的查找方法解析为准确的规则名称。
code-analyzer.yml
文件会静默忽略不匹配的规则名称——不会报错，但覆盖配置不会生效。
模糊→准确解析示例：
  • "Disable the ApexDoc rule"→查找确认
    ApexDoc
    （引擎：
    pmd
    ）
  • "Demote no-console to low"→查找确认
    no-console
    （引擎：
    eslint
    ）
  • "Make CRUD violations critical"→查找确认
    ApexCRUDViolation
    （引擎：
    pmd
    ）
  • "Turn off the hardcoded values check"→查找发现
    @salesforce-ux/slds/no-hardcoded-values-slds2
    （引擎：
    eslint
    ）
  • "Disable the injection rule"→可能有多个匹配项→询问用户具体指哪一个
仅当用户提供明确、准确、知名的名称时（例如："ApexDoc"、"no-console"、"no-unused-vars"），可跳过查找步骤。

Handling Combined/Complex Requests

处理组合/复杂请求

Users will often combine multiple changes in one request. Handle ALL of them in a single edit:
  • "Disable PMD's ApexDoc rule and make CRUD violations critical" → edit two entries under 
    rules.pmd
  • "Exclude test files and vendor code, and increase SFGE memory" → edit 
    ignores.files
    + 
    engines.sfge.java_max_heap_size
  • "Set up code analyzer with only ESLint and PMD, ignore node_modules" → create file with 
    engines
    (disable others) + 
    ignores
  • "Make all security rules severity 1" → look up rules via 
    sf code-analyzer rules --rule-selector Security
    , then override each
  • "Configure code analyzer" (no specifics) → ask user what they want to customize before creating any file
用户通常会在一个请求中提出多个变更。需在一次编辑中处理所有请求：
  • "Disable PMD's ApexDoc rule and make CRUD violations critical"→编辑
    rules.pmd
    下的两个条目
  • "Exclude test files and vendor code, and increase SFGE memory"→编辑
    ignores.files
    + 
    engines.sfge.java_max_heap_size
  • "Set up code analyzer with only ESLint and PMD, ignore node_modules"→创建包含
    engines
    （禁用其他引擎）+ 
    ignores
    的文件
  • "Make all security rules severity 1"→通过
    sf code-analyzer rules --rule-selector Security
    查找规则，然后逐个覆盖
  • "Configure code analyzer"（无具体内容）→在创建任何文件之前，询问用户想要自定义的内容

Quick Reference: Common Requests → Config Output

快速参考：常见请求→配置输出

User SaysResulting YAML
"configure code analyzer"Ask user what to customize — don't create file until there's an actual override
"disable the ApexDoc rule"
rules: pmd: ApexDoc: disabled: true
"only scan Apex, no JavaScript"
engines: eslint: disable_engine: true
+ 
engines: retire-js: disable_engine: true
"ignore all test files"
ignores: files: ["**/test/**", "**/__tests__/**", "**/*.test.js"]
"make security rules critical"Look up rules, then 
rules: <engine>: <rule>: severity: 1
for each
"increase SFGE memory to 8g"
engines: sfge: java_max_heap_size: "8g"
"use my project's ESLint config"
engines: eslint: auto_discover_eslint_config: true
"suppress CRUD violations in legacy folder"
suppressions: "force-app/legacy/": [{rule_selector: "pmd:ApexCRUDViolation", reason: "..."}]
The AI must understand the YAML schema and write valid config for ANY request, not just the examples above.
用户表述生成的YAML
"configure code analyzer"询问用户想要自定义的内容——直到有实际的覆盖请求才创建文件
"disable the ApexDoc rule"
rules: pmd: ApexDoc: disabled: true
"only scan Apex, no JavaScript"
engines: eslint: disable_engine: true
+ 
engines: retire-js: disable_engine: true
"ignore all test files"
ignores: files: ["**/test/**", "**/__tests__/**", "**/*.test.js"]
"make security rules critical"查找规则，然后为每个规则添加
rules: <engine>: <rule>: severity: 1
"increase SFGE memory to 8g"
engines: sfge: java_max_heap_size: "8g"
"use my project's ESLint config"
engines: eslint: auto_discover_eslint_config: true
"suppress CRUD violations in legacy folder"
suppressions: "force-app/legacy/": [{rule_selector: "pmd:ApexCRUDViolation", reason: "..."}]
AI必须理解YAML模式，并能为任意请求编写有效的配置，而不仅仅是上述示例。

Step 2: Check Prerequisites and Install

步骤2：检查前置条件并安装

Run 
bash "<skill_dir>/scripts/check-prerequisites.sh"
or check manually:
bash
sf --version 2>&1                                    # sf CLI
sf plugins --core 2>&1 | grep -i "code-analyzer"    # Plugin
java -version 2>&1                                   # Java 11+ (PMD, CPD, SFGE)
node --version 2>&1                                  # Node 18+ (ESLint, RetireJS)
python3 --version 2>&1                               # Python 3 (Flow engine)
If anything is missing, install it (always ask user first):
bash
npm install -g @salesforce/cli                       # sf CLI
sf plugins install @salesforce/plugin-code-analyzer  # Code Analyzer plugin
For Java/Node/Python installs, read 
<skill_dir>/references/engine-prerequisites.md
. If install fails, read 
<skill_dir>/references/troubleshooting.md
.
运行
bash "<skill_dir>/scripts/check-prerequisites.sh"
或手动检查：
bash
sf --version 2>&1                                    # sf CLI
sf plugins --core 2>&1 | grep -i "code-analyzer"    # 插件
java -version 2>&1                                   # Java 11+（PMD、CPD、SFGE）
node --version 2>&1                                  # Node 18+（ESLint、RetireJS）
python3 --version 2>&1                               # Python 3（Flow引擎）
如果缺少任何项，先询问用户，再进行安装：
bash
npm install -g @salesforce/cli                       # sf CLI
sf plugins install @salesforce/plugin-code-analyzer  # Code Analyzer插件
关于Java/Node/Python的安装，请阅读
<skill_dir>/references/engine-prerequisites.md
。 如果安装失败，请阅读
<skill_dir>/references/troubleshooting.md
。

Step 2A: Diagnose and Fix a Broken Setup

步骤2A：诊断并修复故障设置

TRIGGER: User says "not working", "broken", "getting errors", "scan fails", "help me fix", etc.
Read 
<skill_dir>/references/diagnostic-flow.md
 for the complete layered diagnostic procedure, fix table, and anti-patterns.
Key principles (always apply):
  • Never search for binaries (
    which
    , 
    find
    , 
    ls /opt/homebrew/bin/
    )
  • Never use 
    sfdx
    as a workaround — only 
    sf
  • Fix layer by layer: CLI → Plugin → Engine deps → verify scan
  • Give user ONE command at a time, wait for confirmation before continuing
  • After fix succeeds, proceed to run the full scan automatically
触发条件： 用户提及“not working”“broken”“getting errors”“scan fails”“help me fix”等。
**阅读
<skill_dir>/references/diagnostic-flow.md
**获取完整的分层诊断流程、修复表和反模式说明。
核心原则（始终遵循）：
  • 切勿搜索二进制文件（
    which
    、
    find
    、
    ls /opt/homebrew/bin/
    ）
  • 切勿使用
    sfdx
    作为替代方案——仅使用
    sf
  • 逐层修复：CLI → 插件 → 引擎依赖 → 验证扫描
  • 一次只给用户一个命令，等待确认后再继续
  • 修复成功后，自动运行完整扫描

Step 3: Create or Edit 
code-analyzer.yml

步骤3：创建或编辑
code-analyzer.yml

Only triggered when user requests a customization. Never create proactively.
仅在用户请求自定义时触发。切勿主动创建。

Creating (file doesn't exist)

创建（文件不存在）

Choose one of the two approaches below — do not run both:
Option A — Auto-generate from project type (recommended for first-time setup):
Run 
bash "<skill_dir>/scripts/generate-config.sh"
. This detects Apex, LWC, and Flow markers and produces a minimal 
code-analyzer.yml
suited to the project. Skip to the "After any create/edit, validate" section.
Note: The script exits with an error if 
code-analyzer.yml
already exists. Delete the existing file first if you need to regenerate.
Option B — Write manually (when the user has specific customizations in mind):
Read the appropriate example config as a reference for structure:
  • For Apex-only projects, read 
    <skill_dir>/examples/apex-project-config.yml
  • For LWC-only projects, read 
    <skill_dir>/examples/lwc-project-config.yml
  • For full-stack (Apex + LWC + Flows), read 
    <skill_dir>/examples/fullstack-project-config.yml
Write the file at project root using the Write tool. Include ONLY the user's requested changes:
bash
undefined
选择以下两种方式之一——不要同时运行：
选项A——根据项目类型自动生成（首次设置推荐）：
运行
bash "<skill_dir>/scripts/generate-config.sh"
。该脚本会检测Apex、LWC和Flow标记，生成适合项目的最小化
code-analyzer.yml
。跳至“创建/编辑后验证”章节。
注意：如果
code-analyzer.yml
已存在，脚本会报错退出。如果需要重新生成，请先删除现有文件。
选项B——手动编写（用户有特定自定义需求时）：
读取相应的示例配置作为结构参考：
  • 仅Apex项目：读取
    <skill_dir>/examples/apex-project-config.yml
  • 仅LWC项目：读取
    <skill_dir>/examples/lwc-project-config.yml
  • 全栈项目（Apex + LWC + Flows）：读取
    <skill_dir>/examples/fullstack-project-config.yml
使用写入工具在项目根目录创建文件，仅包含用户请求的变更：
bash
undefined

Example: user said "ignore test files and increase SFGE memory"

示例：用户说“ignore test files and increase SFGE memory”

→ Write to project root (where sfdx-project.json lives):

→ 写入项目根目录（sfdx-project.json所在位置）：


```yaml
ignores:
  files:
    - "**/test/**"
    - "**/__tests__/**"

engines:
  sfge:
    java_max_heap_size: "4g"
Do NOT add 
config_root
, 
log_folder
, or any other field the user didn't ask for.

```yaml
ignores:
  files:
    - "**/test/**"
    - "**/__tests__/**"

engines:
  sfge:
    java_max_heap_size: "4g"
请勿添加
config_root
、
log_folder
或任何用户未提及的字段。

Editing (file already exists)

编辑（文件已存在）

Read the file, then use the Edit tool to add/modify only the relevant section. Preserve everything else.
读取文件，然后使用编辑工具添加/修改相关章节，保留其他所有内容。

After any create/edit, validate:

创建/编辑后验证：

Run 
bash "<skill_dir>/scripts/validate-config.sh"
to validate YAML syntax and schema correctness, or use the CLI directly:
bash
sf code-analyzer config
(No 
--config-file
needed — the CLI auto-discovers 
code-analyzer.yml
in CWD.)
运行
bash "<skill_dir>/scripts/validate-config.sh"
验证YAML语法和模式正确性，或直接使用CLI：
bash
sf code-analyzer config
（无需
--config-file
参数——CLI会自动识别当前目录下的
code-analyzer.yml
。）

If user says "configure code analyzer" with no specifics

如果用户仅说“configure code analyzer”无具体内容

Ask: "What would you like to customize? For example: ignore certain files, change rule severities, tune engine settings, or disable engines you don't need."
询问：“你想要自定义哪些内容？例如：忽略特定文件、更改规则严重程度、调优引擎设置，或禁用不需要的引擎。”

Step 4: Enable/Disable Engines

步骤4：启用/禁用引擎

Edit the 
engines
section in 
code-analyzer.yml
:
yaml
engines:
  pmd:
    disable_engine: true       # Disable PMD
  eslint:
    disable_engine: false      # Enable ESLint (default)
Valid engine names: 
pmd
, 
cpd
, 
eslint
, 
regex
, 
retire-js
, 
flow
, 
sfge
, 
apexguru
Always validate after editing:
bash
sf code-analyzer config --config-file code-analyzer.yml
编辑
code-analyzer.yml
中的
engines
章节：
yaml
engines:
  pmd:
    disable_engine: true       # 禁用PMD
  eslint:
    disable_engine: false      # 启用ESLint（默认）
有效的引擎名称：
pmd
、
cpd
、
eslint
、
regex
、
retire-js
、
flow
、
sfge
、
apexguru
编辑后始终验证：
bash
sf code-analyzer config --config-file code-analyzer.yml

Step 5: Ignore Patterns

步骤5：忽略模式

Edit the 
ignores
section in 
code-analyzer.yml
:
yaml
ignores:
  files:
    - "**/node_modules/**"
    - "**/.sfdx/**"
    - "**/.sf/**"
    - "**/vendor/**"
    - "**/*.min.js"
Common patterns:
PatternExcludes
**/node_modules/**
npm dependencies
**/.sfdx/**
, 
**/.sf/**
SF CLI internals
**/test/**
, 
**/__tests__/**
Test directories
**/*.test.js
, 
**/*.spec.js
Test files
**/jest-mocks/**
Jest mocks
**/vendor/**
, 
**/*.min.js
Third-party/minified
**/staticresources/**
Static resources
编辑
code-analyzer.yml
中的
ignores
章节：
yaml
ignores:
  files:
    - "**/node_modules/**"
    - "**/.sfdx/**"
    - "**/.sf/**"
    - "**/vendor/**"
    - "**/*.min.js"
常见模式：
模式排除内容
**/node_modules/**
npm依赖
**/.sfdx/**
、
**/.sf/**
SF CLI内部文件
**/test/**
、
**/__tests__/**
测试目录
**/*.test.js
、
**/*.spec.js
测试文件
**/jest-mocks/**
Jest模拟文件
**/vendor/**
、
**/*.min.js
第三方/压缩文件
**/staticresources/**
静态资源

Step 6: Rule Overrides

步骤6：规则覆盖

Edit the 
rules
section in 
code-analyzer.yml
. Each rule can have 
severity
, 
tags
, and 
disabled
overrides:
yaml
rules:
  pmd:
    ApexCRUDViolation:
      severity: 1              # Promote to Critical
    AvoidGlobalModifier:
      disabled: true           # Turn off entirely
    ApexDoc:
      severity: 5              # Demote to Info
      tags: ["Documentation"]
  eslint:
    no-console:
      severity: 4              # Demote to Low
    no-unused-vars:
      severity: 2              # Promote to High
Severity values: 
1
/Critical, 
2
/High, 
3
/Moderate, 
4
/Low, 
5
/Info
编辑
code-analyzer.yml
中的
rules
章节。每个规则可设置
severity
、
tags
和
disabled
覆盖项：
yaml
rules:
  pmd:
    ApexCRUDViolation:
      severity: 1              # 提升为Critical
    AvoidGlobalModifier:
      disabled: true           # 完全禁用
    ApexDoc:
      severity: 5              # 降级为Info
      tags: ["Documentation"]
  eslint:
    no-console:
      severity: 4              # 降级为Low
    no-unused-vars:
      severity: 2              # 提升为High
严重程度值： 
1
/Critical、
2
/High、
3
/Moderate、
4
/Low、
5
/Info

6.1 Rule Name Resolution (Fuzzy Matching)

6.1规则名称解析（模糊匹配）

⚠️ CRITICAL: A misspelled or partial rule name in 
code-analyzer.yml
is SILENTLY IGNORED — no error, the override just won't apply.
When users reference rules by approximate names (e.g., "the doc rule", "CRUD violation", "hardcoded values"), resolve to exact names BEFORE writing YAML:
bash
sf code-analyzer rules --rule-selector all 2>&1 | grep -i "<USER_KEYWORD>"
  • 1 match → use that exact name + its engine for the YAML path
  • Multiple matches → ask user which one they meant
  • 0 matches → try broader keywords or inform user
Skip the lookup only when the name is unambiguous and exact (e.g., "ApexDoc", "no-console", "no-unused-vars").
For detailed matching strategies, common fuzzy→exact mappings, and engine identification: Read 
<skill_dir>/references/rule-name-resolution.md
.
⚠️关键注意事项： 
code-analyzer.yml
中拼写错误或部分匹配的规则名称会被静默忽略——不会报错，但覆盖配置不会生效。
当用户通过近似名称引用规则时（例如："the doc rule"、"CRUD violation"、"hardcoded values"），在写入YAML之前解析为准确名称：
bash
sf code-analyzer rules --rule-selector all 2>&1 | grep -i "<USER_KEYWORD>"
  • 1个匹配项→使用该准确名称及其引擎作为YAML路径
  • 多个匹配项→询问用户具体指哪一个
  • 0个匹配项→尝试更宽泛的关键词或告知用户
仅当名称明确且准确时（例如："ApexDoc"、"no-console"、"no-unused-vars"），可跳过查找步骤。
关于详细匹配策略、常见模糊→准确映射以及引擎识别： 请阅读
<skill_dir>/references/rule-name-resolution.md
。

Step 7: Engine-Specific Settings

步骤7：引擎特定设置

Edit the 
engines
section. Most common overrides:
yaml
engines:
  sfge:
    java_max_heap_size: "4g"      # <200 classes→"2g", 200-500→"4g", 500+→"6g"/"8g"
    java_thread_count: 4
    java_thread_timeout: 900000
  eslint:
    auto_discover_eslint_config: true    # Use project's own ESLint config
    eslint_config_file: "./eslint.config.mjs"
  pmd:
    custom_rulesets: ["./config/custom-pmd-rules.xml"]
    java_classpath_entries: ["./lib/custom-rules.jar"]
  cpd:
    minimum_tokens: { apex: 100, javascript: 100 }
  apexguru:
    target_org: "my-org-alias"
  flow:
    python_command: "python3"
  regex:
    custom_rules:
      NoHardcodedIds:
        regex: "/[a-zA-Z0-9]{15,18}/"
        file_extensions: [".cls", ".trigger"]
        description: "Detects hardcoded Salesforce record IDs"
        severity: 2
        tags: ["Security"]
For full property list per engine, read 
<skill_dir>/references/config-schema.md
.
编辑
engines
章节。最常见的覆盖配置：
yaml
engines:
  sfge:
    java_max_heap_size: "4g"      # <200个类→"2g", 200-500个→"4g", 500+→"6g"/"8g"
    java_thread_count: 4
    java_thread_timeout: 900000
  eslint:
    auto_discover_eslint_config: true    # 使用项目自身的ESLint配置
    eslint_config_file: "./eslint.config.mjs"
  pmd:
    custom_rulesets: ["./config/custom-pmd-rules.xml"]
    java_classpath_entries: ["./lib/custom-rules.jar"]
  cpd:
    minimum_tokens: { apex: 100, javascript: 100 }
  apexguru:
    target_org: "my-org-alias"
  flow:
    python_command: "python3"
  regex:
    custom_rules:
      NoHardcodedIds:
        regex: "/[a-zA-Z0-9]{15,18}/"
        file_extensions: [".cls", ".trigger"]
        description: "Detects hardcoded Salesforce record IDs"
        severity: 2
        tags: ["Security"]
关于每个引擎的完整属性列表，请阅读
<skill_dir>/references/config-schema.md
。

Step 8: CI/CD Pipeline Setup

步骤8：CI/CD流水线设置

Detect CI system from workspace (
.github/workflows/
→ GitHub Actions, 
Jenkinsfile
→ Jenkins, etc.). Read 
<skill_dir>/references/ci-cd-templates.md
for templates. Use 
<skill_dir>/examples/ci-github-actions.yml
as GitHub Actions base. Key flags: 
--severity-threshold 2
(gate), 
--output-file results.sarif
(GitHub scanning), 
--config-file code-analyzer.yml
.
从工作区检测CI系统（
.github/workflows/
→GitHub Actions，
Jenkinsfile
→Jenkins等）。阅读
<skill_dir>/references/ci-cd-templates.md
获取模板。使用
<skill_dir>/examples/ci-github-actions.yml
作为GitHub Actions基础配置。关键参数：
--severity-threshold 2
（质量门）、
--output-file results.sarif
（GitHub扫描）、
--config-file code-analyzer.yml
。

Step 9: View Current Configuration

步骤9：查看当前配置

bash
sf code-analyzer config                               # Show effective config
sf code-analyzer config --rule-selector pmd:Security  # Specific rules
sf code-analyzer config --include-unmodified-rules    # All defaults
bash
sf code-analyzer config                               # 显示有效配置
sf code-analyzer config --rule-selector pmd:Security  # 特定规则
sf code-analyzer config --include-unmodified-rules    # 所有默认值

Cross-Skill Integration

跨技能集成

This skill works together with 
running-code-analyzer
. The AI agent should seamlessly hand off between them:
本技能与
running-code-analyzer
协同工作。AI代理应在两者间无缝切换：

When 
running-code-analyzer
delegates HERE:

当
running-code-analyzer
委托至本技能时：

If a user says "scan my code" / "run code analyzer" but it fails (CLI missing, plugin not installed, or scan errors out), 
running-code-analyzer
delegates to this skill. In that case:
  1. Run the diagnose and fix flow (Step 2A) — find what's broken, fix it
  2. After everything works, automatically proceed to run the scan — do not stop and ask. The user's original intent was to scan.
  3. Hand execution back to 
    running-code-analyzer
    behavior (build command, execute, parse results).
如果用户说“scan my code”/“run code analyzer”但运行失败（缺少CLI、未安装插件或扫描报错），
running-code-analyzer
会委托至本技能。此时：
  1. 执行诊断和修复流程（步骤2A）——找出故障点并修复
  2. 修复完成后，自动继续运行扫描——不要停止并询问。用户的原始意图是扫描。
  3. 将执行权交回
    running-code-analyzer
    （构建命令、执行、解析结果）。

When THIS skill hands off to 
running-code-analyzer
:

当本技能委托至
running-code-analyzer
时：

After any successful configuration action, offer to run a scan (e.g., "Setup complete! Want me to run a scan?", "Config updated — want to scan and verify?"). If user says yes, proceed with 
running-code-analyzer
behavior.
任何配置操作成功后，主动提出运行扫描（例如：“设置完成！需要我运行扫描吗？”“配置已更新——需要扫描验证吗？”）。如果用户同意，执行
running-code-analyzer
的操作流程。

When user intent spans BOTH skills:

当用户意图涉及两个技能时：

Handle end-to-end: "not working" → Diagnose → Fix → Scan. "Set up and scan" → Install → Scan. "Disable ESLint and scan Apex" → Edit config → Run with 
--rule-selector pmd
. Always follow through to the user's final intent.
端到端处理：“not working”→诊断→修复→扫描。“Set up and scan”→安装→扫描。“Disable ESLint and scan Apex”→编辑配置→使用
--rule-selector pmd
运行扫描。始终跟进至用户的最终意图。

Rules / Constraints

规则/约束

ConstraintRationale
Only create YAML when user requests a customizationDefaults work without any file — don't create boilerplate
Place YAML at project root onlyCLI auto-discovers 
code-analyzer.yml
from CWD
Write only overrides, never duplicate defaultsKeep file minimal and intentional
Use Write tool to create, Edit tool to modifyPreserves existing settings
Validate after every change
sf code-analyzer config
catches YAML errors
Ask before installing prerequisitesNever auto-install without consent
Never delete existing config without askingUser may have custom settings
After setup, offer to scanClose the loop — config without scan is incomplete
约束理由
仅在用户请求自定义时创建YAML默认设置无需文件即可生效——请勿创建模板文件
YAML仅放置在项目根目录CLI会自动识别当前目录下的
code-analyzer.yml
仅写入覆盖配置，绝不重复默认值保持文件精简且有针对性
使用写入工具创建，编辑工具修改保留现有设置
每次变更后验证
sf code-analyzer config
可捕获YAML错误
安装前置条件前先询问用户切勿未经同意自动安装
未经询问切勿删除现有配置用户可能有自定义设置
设置完成后主动提出扫描闭环流程——仅配置不扫描不完整

Gotchas

常见问题

IssueSolution
Config not picked upMust be 
code-analyzer.yml
in CWD or use 
--config-file
YAML validation failsSpaces only (no tabs), check colon spacing
SFGE out of memoryIncrease 
java_max_heap_size
in engines section
ESLint rules missingSet 
auto_discover_eslint_config: true
For full troubleshooting, read 
<skill_dir>/references/troubleshooting.md
.
问题解决方案
配置未被识别必须是当前目录下的
code-analyzer.yml
，或使用
--config-file
参数
YAML验证失败仅使用空格（不要用制表符），检查冒号后的空格
SFGE内存不足在engines章节增加
java_max_heap_size
ESLint规则缺失设置
auto_discover_eslint_config: true
完整故障排查内容，请阅读
<skill_dir>/references/troubleshooting.md
。

Reference File Index

参考文件索引

<skill_dir>
is the absolute path to the directory containing this SKILL.md file.
FilePurpose
<skill_dir>/scripts/check-prerequisites.sh
Environment check
<skill_dir>/scripts/generate-config.sh
Auto-detect project type and generate config
<skill_dir>/scripts/validate-config.sh
Validate YAML after changes
<skill_dir>/references/config-schema.md
Full YAML schema documentation
<skill_dir>/references/diagnostic-flow.md
Step 2A: layered diagnostic procedure and fix table
<skill_dir>/references/rule-name-resolution.md
Step 6.1: fuzzy rule name lookup strategies and mappings
<skill_dir>/references/engine-prerequisites.md
Install instructions per engine
<skill_dir>/references/ci-cd-templates.md
CI/CD pipeline templates
<skill_dir>/references/troubleshooting.md
Common setup issues and fixes
<skill_dir>/examples/apex-project-config.yml
Config for Apex-only project
<skill_dir>/examples/lwc-project-config.yml
Config for LWC-only project
<skill_dir>/examples/fullstack-project-config.yml
Config for Apex + LWC + Flows
<skill_dir>/examples/ci-github-actions.yml
GitHub Actions workflow
<skill_dir>
是包含本SKILL.md文件的目录的绝对路径。
文件用途
<skill_dir>/scripts/check-prerequisites.sh
环境检查
<skill_dir>/scripts/generate-config.sh
自动检测项目类型并生成配置
<skill_dir>/scripts/validate-config.sh
变更后验证YAML
<skill_dir>/references/config-schema.md
完整YAML模式文档
<skill_dir>/references/diagnostic-flow.md
步骤2A：分层诊断流程和修复表
<skill_dir>/references/rule-name-resolution.md
步骤6.1：模糊规则名称查找策略和映射
<skill_dir>/references/engine-prerequisites.md
各引擎安装说明
<skill_dir>/references/ci-cd-templates.md
CI/CD流水线模板
<skill_dir>/references/troubleshooting.md
常见设置问题及修复方案
<skill_dir>/examples/apex-project-config.yml
仅Apex项目的配置
<skill_dir>/examples/lwc-project-config.yml
仅LWC项目的配置
<skill_dir>/examples/fullstack-project-config.yml
Apex + LWC + Flows项目的配置
<skill_dir>/examples/ci-github-actions.yml
GitHub Actions工作流