Running Code Analyzer

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.

❌ WRONG — never do this:

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

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

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

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

Also forbidden: run_code_analyzer and any mcp__* tool — Bash only.

✅ RIGHT — always do this:

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

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

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

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

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

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

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

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

<skill_dir> 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.

---

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 (→ configuring-code-analyzer), writing custom rules/engines, AI-generated fixes beyond engine-provided ones, deep refactoring, CI/CD setup (→ configuring-code-analyzer).

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.

---

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.

---

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 `configuring-code-analyzer` — 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.

---

Quick Start: Common Patterns

Match the request below; if it matches, jump to Step 3 (Build Command). Otherwise, walk Step 1.

---

Step 1: Parse the User's Intent

Analyze the request along these 7 dimensions; any can combine.

1.1 ENGINE

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

1.2 CATEGORY

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

1.3 SEVERITY

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

1.4 SPECIFIC RULE

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:

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.

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.

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.

1.7 COMPARISON / DELTA

"new since main" → git diff --name-only main...HEAD → scan those · "since last commit" → HEAD~1 · "vs develop" → develop...HEAD.

---

Step 2: Build the Rule Selector

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.

---

Step 3: Build the Full Command

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.

---

Step 4: Execute the Scan

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:

   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.

---

Step 5: Parse and Present Results

Run the parse script straight after the scan — do not pause to ask:

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

Presentation template

## Scan Complete

**Found X violations** across Y files.

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

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

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

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

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.

---

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

Engine-provided fixes are deterministic (not AI-generated). Flow: vendor filter (if needed) → discover → present → wait for user confirmation → apply → summarize.

6.1 Vendor file filter (when needed)

Run if the user said "fix my code" / "project source", or if top-violation files are vendor libs (jQuery, Bootstrap, *.min.js):

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.

6.2 Discover

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

6.3 Present + ASK (then STOP)

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

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

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

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

⚠️ 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.

6.4 Apply

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

(Filtered file if 6.1 created one.)

6.5 Summarize (MANDATORY immediately after 6.4)

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

Then present:

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

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

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

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

6.6 — Handling the user's choice

• 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.

6.7 — Optional re-scan for verification

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.

---

Step 7: Query and Filter Existing Results

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.

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.

How to execute

Run the query script against the same results file from Step 4 (no re-scan needed):

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

Output format and presentation templates: <skill_dir>/references/post-scan-workflows.md.

---

Step 8: Describe a Rule

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"

How to execute

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.

---

Step 9: List Available Rules

Triggers: "what security rules are available?", "list all PMD rules", "rules for JavaScript", "Recommended rules", "how many ESLint rules?", "rules for Apex".

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

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.

---

Constraints & Gotchas

---

Reference File Index

Scripts (always execute via node with the absolute <skill_dir>/ prefix, never Read):

References (read on demand):

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

Common Command Variations

Real-world command patterns with explanations. Use these as reference when building commands for specific scenarios.

---

Basic Scans

1. Scan Entire Workspace (Default)

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

When: User says "scan my code" with no specifics.

---

2. Security-Focused Scan

sf code-analyzer run \
  --rule-selector "all:Security:(1,2)" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "check for security issues", "find vulnerabilities", "AppExchange security review". Selector breakdown: all = all engines, :Security = Security category only, :(1,2) = Critical and High severity only.

---

3. Specific Engine

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

When: User says "run PMD", "check my Apex code".

---

4. Multiple Engines

sf code-analyzer run \
  --rule-selector "(pmd,eslint)" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "scan Apex and JavaScript", "run PMD and ESLint". Selector breakdown: Parentheses + comma = OR logic.

---

Target-Specific Scans

5. Scan Specific File

sf code-analyzer run \
  --rule-selector Recommended \
  --target "force-app/main/default/classes/AccountService.cls" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "scan AccountService.cls".

---

6. Scan Specific Folder

sf code-analyzer run \
  --rule-selector Recommended \
  --target "force-app/main/default/lwc" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "scan my LWC components", "check the lwc folder".

---

7. Scan Multiple Paths

sf code-analyzer run \
  --rule-selector Recommended \
  --target "force-app/main/default/classes,force-app/main/default/triggers" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "scan classes and triggers". Note: Comma-separated paths in a single --target value.

---

8. Scan Using Glob Pattern

sf code-analyzer run \
  --rule-selector Recommended \
  --target "**/*.cls,**/*.trigger" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "scan all Apex files", "check all classes and triggers". Note: Glob patterns must match from workspace root.

---

Diff-Based Scans

9. Scan Changed Files (Git Diff)

Step 1: Get changed files

git diff --name-only main...HEAD

Step 2: Filter to scannable types (.cls, .trigger, .js, .ts, .flow-meta.xml, etc.)

Step 3: Pass as --target

sf code-analyzer run \
  --rule-selector Recommended \
  --target "force-app/main/default/classes/AccountService.cls,force-app/main/default/lwc/accountCard/accountCard.js" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "scan my changes", "check what I modified", "analyze the diff".

---

Advanced Scenarios

10. Deep Analysis with SFGE (Data Flow)

sf code-analyzer run \
  --rule-selector "sfge" \
  --workspace "force-app" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "deep analysis", "data flow analysis", "path-based analysis", "find CRUD violations with certainty". Note: Requires Java 11+. May take 10-20 minutes. Use --workspace to avoid compiling template files. Timeout: Set to 1200000ms (20 minutes).

---

11. Find Code Duplicates (CPD)

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

When: User says "find duplicates", "check for copy-paste", "detect code clones".

---

12. Check Vulnerable Libraries (RetireJS)

sf code-analyzer run \
  --rule-selector "retire-js" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "check for vulnerable libraries", "scan dependencies", "find CVEs".

---

13. Analyze Flows

sf code-analyzer run \
  --rule-selector "flow" \
  --target "**/*.flow-meta.xml" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "analyze my Flows", "check Flow best practices". Note: Requires Python 3.

---

14. Performance Analysis (ApexGuru)

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

When: User says "performance analysis", "find slow code", "check governor limits". Note: Requires authenticated Salesforce org. See references/special-behaviors.md for auth setup.

---

Output Format Variations

15. HTML Report

sf code-analyzer run \
  --rule-selector Recommended \
  --output-file ./code-analyzer-results-20260519-101030.html \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User explicitly requests HTML format. Note: Extension determines format. JSON is default.

---

16. SARIF (GitHub/IDE Integration)

sf code-analyzer run \
  --rule-selector Recommended \
  --output-file ./code-analyzer-results-20260519-101030.sarif \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "SARIF format", "GitHub integration", "IDE integration".

---

17. CSV (Spreadsheet)

sf code-analyzer run \
  --rule-selector Recommended \
  --output-file ./code-analyzer-results-20260519-101030.csv \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "CSV format", "export to spreadsheet", "Excel format".

---

Complex Rule Selectors

18. Multiple Categories

sf code-analyzer run \
  --rule-selector "all:(Security,Performance):(1,2,3)" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

Selector breakdown: All engines, Security OR Performance categories, Severity 1-3 (Critical to Moderate).

---

19. Specific Rule by Name

sf code-analyzer run \
  --rule-selector "pmd:ApexCRUDViolation" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

When: User says "check for ApexCRUDViolation", "run the CRUD rule". Note: Must be exact full rule name. If uncertain, look up first: sf code-analyzer rules --rule-selector all 2>&1 | grep -i "CRUD"

---

20. Engine + Category + Severity

sf code-analyzer run \
  --rule-selector "(pmd,eslint):Security:(1,2)" \
  --output-file ./code-analyzer-results-20260519-101030.json \
  --include-fixes \
  2>&1 | tee ./code-analyzer-results-20260519-101030.log

Selector breakdown: (PMD OR ESLint) AND Security AND (Sev 1 OR Sev 2).

---

Key Patterns

---

Anti-Patterns (DO NOT USE)

❌ Using --format flag

# WRONG - v3 syntax, does not exist in v4+
sf code-analyzer run --format json

Why: The --format flag was removed in v4+. Use --output-file with extension instead.

---

❌ Using $TIMESTAMP variable in command

# WRONG - variable substitution fails in permission prompts
sf code-analyzer run --output-file "./results-${TIMESTAMP}.json"

Why: Generate timestamp first, then use literal string in command.

---

❌ Running in background for long scans

# WRONG - loses output stream
sf code-analyzer run --rule-selector sfge &

Why: Use foreground with high timeout (1200000ms). Backgrounding loses the output.

---

❌ Partial rule names

# WRONG - returns 0 results
sf code-analyzer run --rule-selector "no-hardcoded-values"

Why: Rule names must be exact. Look up first: sf code-analyzer rules --rule-selector all | grep -i "hardcoded" Correct: --rule-selector "@salesforce-ux/slds/no-hardcoded-values-slds2"

Fix Application: Before & After

This example demonstrates engine-provided auto-fix behavior on a small codebase.

Initial Scan Results

Command:

sf code-analyzer run --rule-selector Recommended --output-file ./results.json --include-fixes

Summary:

• Total violations: 248
• Fixable violations: 67 (27%)

Fixable Rules

---

Before Fix: Sample Violations

Violation 1: no-var

File: force-app/main/default/lwc/accountCard/accountCard.js:12

export default class AccountCard extends LightningElement {
    handleClick() {
        var accountId = this.recordId;  // ← violation
        var data = this.fetchData(accountId);  // ← violation
        this.processData(data);
    }
}

Violation 2: prefer-const

File: force-app/main/default/lwc/utils/dataProcessor.js:8

export function processRecords(records) {
    let result = [];  // ← violation (never reassigned)
    records.forEach(r => result.push(transform(r)));
    return result;
}

Violation 3: @salesforce-ux/slds/no-hardcoded-values-slds2

File: force-app/main/default/lwc/accountCard/accountCard.css:4

.account-card {
    border-radius: 4px;  /* ← violation */
    padding: 16px;  /* ← violation */
}

---

Apply Fixes

Command:

node <skill_dir>/scripts/apply-fixes.js ./results.json

Output:

{
  "success": true,
  "filesModified": 15,
  "fixesApplied": 67,
  "fixesSkipped": 0
}

---

After Fix: Corrected Code

Fix 1: no-var → let

File: force-app/main/default/lwc/accountCard/accountCard.js:12

export default class AccountCard extends LightningElement {
    handleClick() {
        let accountId = this.recordId;  // ✓ fixed
        let data = this.fetchData(accountId);  // ✓ fixed
        this.processData(data);
    }
}

Fix 2: let → const

File: force-app/main/default/lwc/utils/dataProcessor.js:8

export function processRecords(records) {
    const result = [];  // ✓ fixed
    records.forEach(r => result.push(transform(r)));
    return result;
}

Fix 3: Hardcoded values → SLDS tokens

File: force-app/main/default/lwc/accountCard/accountCard.css:4

.account-card {
    border-radius: var(--slds-c-card-radius-border);  /* ✓ fixed */
    padding: var(--slds-c-card-spacing-block);  /* ✓ fixed */
}

---

Verification Scan

Command:

sf code-analyzer run --rule-selector Recommended --output-file ./results-after.json --include-fixes

Summary:

• Total violations: 181 (↓ 67 from 248)
• Fixable violations: 0

Result: All 67 fixable violations resolved. Remaining 181 violations require manual fixes (e.g., ApexDoc comments, CRUD checks).

---

Key Takeaways

1. Engine-provided fixes are safe: They're deterministic transformations, not AI-generated code. 2. Apply, then verify: Always re-scan after applying fixes to confirm no regressions. 3. Not all violations are fixable: Security issues like CRUD violations require manual code review. 4. Files modified count ≠ fixes count: Multiple violations in one file count as one file modification.

Examples Directory

Sample outputs and command patterns for the running-code-analyzer skill.

Files

When to Use

As a User/Developer

• Validate your scan output matches expected format
• See real-world command examples for common scenarios
• Understand fix application before running it on your code

As the Agent

• Compare output structure when parsing scan results
• Verify fix format when applying auto-fixes
• Reference command patterns when building complex rule selectors
• Use as templates when explaining results to users

Usage from SKILL.md

These files are reference examples, not loaded by default. Reference them in specific scenarios:

**For large result sets (5000+ violations)**, compare against `examples/large-scan-output.json` to verify your summary format matches the expected structure.

**Before applying fixes**, show the user the before/after comparison from `examples/fix-application-before-after.md` to set expectations.

**For complex command construction**, reference `examples/command-variations.md` to find the pattern that matches the user's intent.

Command Construction Examples

Full command examples for common scanning scenarios.

Note: All commands use ${TIMESTAMP} which should be generated via TIMESTAMP=$(date +%Y%m%d-%H%M%S) before running the scan.

Engine Reference

Engine File Type Support

Common Rule Tags

These tags can be used in rule selectors:

Error Handling Guide

Common Code Analyzer errors and their resolutions.

Common Errors and Resolutions

Diagnosis Steps

If the scan command fails:

1. Check the error message for hints 2. Run sf --version to verify CLI 3. Run sf plugins --core | grep code-analyzer to verify plugin 4. Run java -version to verify Java 5. Run sf code-analyzer rules --rule-selector <selector> to verify the selector matches rules 6. If config error: run sf code-analyzer config to validate

Flag Reference for sf code-analyzer run

Complete reference for all flags available in the sf code-analyzer run command (v4+).

Valid Flags

Invalid Flags (DO NOT USE)

These flags existed in v3 but were removed in v4+. Using them causes errors:

Rule Selector Syntax

The --rule-selector flag uses a flexible expression syntax:

Complex Rule Selector Examples

# PMD OR ESLint, Security category, Severity 1 or 2
--rule-selector "(pmd,eslint):Security:(1,2)"

# All Security rules across all engines
--rule-selector "Security"

# Specific rule from PMD
--rule-selector "pmd:ApexCRUDViolation"

# All rules from CPD (duplicate detection)
--rule-selector "cpd"

# High and Critical severity across all engines
--rule-selector "(1,2)"

Output Format Extensions

The --output-file flag determines format by file extension:

You can specify multiple output files in a single run:

--output-file "./results.json" --output-file "./report.html"

Why These Constraints Exist

v4+ CLI redesign: The Code Analyzer plugin underwent a major redesign from v3 to v4+:

• Old flags (--format, --engine, --category) were removed for a more flexible --rule-selector expression syntax
• Output format is now determined by file extension rather than a separate flag
• Terminal display was separated into --view flag
• These changes provide more flexibility but require different syntax than v3 documentation shows

Always use `--output-file` for results: Terminal stdout can be truncated, interrupted, or mixed with other output. Writing to a file ensures complete, parseable results.

Foreground execution with timeout: SFGE (Salesforce Graph Engine) scans can take 10-20 minutes for large codebases. Running in foreground with timeout: 1200000 (20 minutes) ensures the scan completes and output is captured.

Post-Scan Workflows

After presenting initial scan results (Step 5), the user may ask follow-up questions to explore results or understand violations. This reference covers three post-scan workflows:

1. Result Querying — filter/drill into existing results without re-scanning 2. Rule Description — explain what a rule does and how to fix violations 3. Rule Listing — browse available rules without running a scan

---

Result Querying (Step 7)

When to Use

Trigger this workflow when the user asks to explore existing results:

• "Show me just the security violations"
• "What's in AccountService.cls?"
• "Show only PMD issues"
• "Filter to severity 1 and 2"
• "What ESLint rules fired?"
• "Show violations in the lwc folder"
• "Top 20 by file"

How It Works

The query-results.js script re-filters the SAME results JSON file (from Step 4) with different criteria. No re-scan is needed — it is instant.

Script Reference

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

Filter options (combine any):

Options can be combined freely:

# Security violations in PMD, top 5
node "<skill_dir>/scripts/query-results.js" "./results.json" --engine pmd --category Security --top 5

# All Critical+High in a specific file
node "<skill_dir>/scripts/query-results.js" "./results.json" --severity 1,2 --file AccountService.cls

# Summary of ESLint issues only
node "<skill_dir>/scripts/query-results.js" "./results.json" --engine eslint --summary

Output Format

The script outputs JSON with this structure:

{
  "query": { "engine": "pmd", "severity": [1,2], ... },
  "totalViolations": 500,
  "totalMatches": 23,
  "severityCounts": { "1": 5, "2": 18, "3": 0, "4": 0, "5": 0 },
  "topRules": [{ "rule": "ApexCRUDViolation", "engine": "pmd", "count": 12 }, ...],
  "topFiles": [{ "file": "AccountService.cls", "count": 8 }, ...],
  "violations": [
    { "rule": "...", "engine": "...", "severity": 1, "message": "...", "file": "...", "startLine": 42, "tags": [...] },
    ...
  ]
}

When --summary is used, the violations array is omitted.

Presentation Rules

Present query results using the same format as Step 5, but with a header indicating the active filter:

## Filtered Results: [description of filter]

**X matches** out of Y total violations.

| Severity | Count |
|----------|-------|
| Critical (1) | X |
| High (2) | X |
| ... |

### Matching Violations
| # | Rule | Engine | Sev | File | Line |
|---|------|--------|-----|------|------|
| 1 | ... | ... | ... | ... | ... |

### Top Rules (within filter)
| Rule | Engine | Count |
|------|--------|-------|
| ... | ... | ... |

Full results: `<original-results-file>`

Follow-Up Offers

After presenting filtered results, offer:

• "Want me to narrow further?" (add more filters)
• "Want me to explain any of these rules?" (→ Step 8)
• "Want me to apply fixes for these?" (→ Step 6, scoped to matched rules)

---

Rule Description (Step 8)

When to Use

Trigger this workflow when the user asks about a specific rule:

• "What is ApexCRUDViolation?"
• "Explain this rule"
• "What does no-var mean?"
• "How do I fix OperationWithLimitsInLoop?"
• "Tell me about the ApexSOQLInjection rule"
• "Why is this flagged?"

How It Works

The describe-rule.js script calls sf code-analyzer rules with a targeted selector to extract rule metadata including description and documentation links.

Script Reference

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

Arguments:

Examples:

node "<skill_dir>/scripts/describe-rule.js" "ApexCRUDViolation" --engine pmd
node "<skill_dir>/scripts/describe-rule.js" "no-var" --engine eslint
node "<skill_dir>/scripts/describe-rule.js" "OperationWithLimitsInLoop"

Output Format

Success — single rule found:

{
  "status": "success",
  "rule": {
    "name": "ApexCRUDViolation",
    "engine": "pmd",
    "severity": "2 (High)",
    "tags": ["Security", "Recommended", "Apex"],
    "description": "Validates that CRUD and FLS checks are performed before DML operations...",
    "resources": ["https://pmd.github.io/latest/pmd_rules_apex_security.html#apexcrudviolation"]
  }
}

Multiple matches (partial name):

{
  "status": "multiple_matches",
  "message": "Rule \"CRUD\" not found as exact match. Found 3 potential matches:",
  "candidates": [
    { "name": "ApexCRUDViolation", "engine": "pmd", "severity": "2", "tags": "Security, Recommended" },
    ...
  ]
}

Not found:

{
  "status": "not_found",
  "message": "Rule \"FakeRule\" not found. Verify the rule name with: sf code-analyzer rules ..."
}

Presentation Rules

For a successful lookup, present:

## Rule: ApexCRUDViolation

| Property | Value |
|----------|-------|
| Engine | pmd |
| Severity | 2 (High) |
| Tags | Security, Recommended, Apex |

### Description
Validates that CRUD and FLS checks are performed before DML operations. Without these
checks, data may be accessed or modified without proper user permissions, violating
the Salesforce security model.

### How to Fix
[Provide actionable fix guidance based on the description. If the description mentions
a fix pattern, elaborate. If resources are available, include the link.]

### Resources
- [PMD Documentation](https://pmd.github.io/...)

---
Want me to show all violations of this rule in your scan results?

For multiple matches, present:

I found multiple rules matching "CRUD":

| # | Rule | Engine | Severity |
|---|------|--------|----------|
| 1 | ApexCRUDViolation | pmd | 2 (High) |
| 2 | ... | ... | ... |

Which rule would you like details on?

For not found, present:

I couldn't find a rule named "FakeRule". Would you like me to:
- Search for similar rules? (I'll grep the full rule list)
- List all rules for a specific engine or category?

After Describing a Rule

Offer next steps:

• "Want me to show all violations of this rule in your results?" (→ Step 7 with --rule)
• "Want me to apply the engine fix for this rule?" (→ Step 6)
• "Want me to explain another rule?"

---

Rule Listing (Step 9)

Presentation Rules

Present available rules in this format:

## Available Rules: Security

**Found X rules** across Y engines.

| Engine | Count |
|--------|-------|
| pmd | 12 |
| eslint | 6 |

| Severity | Count |
|----------|-------|
| Critical (1) | 3 |
| High (2) | 15 |

### Rules (top 25)
| # | Rule | Engine | Severity | Tags |
|---|------|--------|----------|------|
| 1 | ApexCRUDViolation | pmd | 2 (High) | Security, Recommended |
| 2 | ApexSOQLInjection | pmd | 1 (Critical) | Security, Recommended |
| ... |

Want me to explain any of these rules? Or run a scan with this selector?

Follow-Up Offers

After listing rules:

• "Want me to explain any of these?" (→ Step 8)
• "Want me to scan with this selector?" (→ Steps 1-5 with the same selector)
• "Narrow to just high severity?" (re-run with --severity 1,2)

Quick Start: Minimum Viable Commands

If you're unsure about anything, use these EXACT commands as starting points.

IMPORTANT: Always generate a timestamp variable FIRST, then use it in the output filename:

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

Then use it:

# Simplest scan (entire workspace, recommended rules)
sf code-analyzer run --output-file "./code-analyzer-results-${TIMESTAMP}.json" --include-fixes

# Scan specific target
sf code-analyzer run --target "force-app/main/default" --output-file "./code-analyzer-results-${TIMESTAMP}.json" --include-fixes

# Scan for security
sf code-analyzer run --rule-selector Security --output-file "./code-analyzer-results-${TIMESTAMP}.json" --include-fixes

# Scan specific engine
sf code-analyzer run --rule-selector pmd --output-file "./code-analyzer-results-${TIMESTAMP}.json" --include-fixes

# Scan with HTML report (only if user explicitly asks for HTML)
sf code-analyzer run --output-file "./code-analyzer-results-${TIMESTAMP}.html" --include-fixes

After the command completes, read the output file and present a summary to the user.

Special Behaviors

Advanced scanning scenarios and engine-specific considerations.

SFGE (Salesforce Graph Engine) Scans

When --rule-selector sfge is requested:

• WARN the user: "SFGE performs deep data-flow analysis and can be resource-intensive. It may take several minutes and use significant memory. Proceed?"
• If project is large (>100 Apex classes), suggest increasing heap: "Consider setting engines.sfge.java_max_heap_size: '4g' in your code-analyzer.yml"
• SFGE only analyzes Apex (.cls, .trigger files)

SFGE Workspace Compilation Behavior

CRITICAL: SFGE compiles ALL .cls and .trigger files found anywhere in the --workspace directory (default: . = project root), NOT just files under --target. The --target flag only controls which files are used as entry points for data-flow analysis, but SFGE builds a complete inter-procedural call graph from the entire workspace.

This means: 1. If there are invalid/template Apex files ANYWHERE in the project (e.g., datasets/, scripts/, templates/), SFGE will try to compile them and CRASH with compilation errors. 2. The `--target` flag does NOT prevent this — even --target "force-app" still causes SFGE to compile files outside force-app/.

To avoid compilation failures, ALWAYS set `--workspace` explicitly for SFGE scans:

sf code-analyzer run --rule-selector sfge --workspace "force-app" --target "force-app" --output-file "./code-analyzer-results-${TIMESTAMP}.json" --include-fixes

Or if the user specifies a subfolder target like force-app/main:

sf code-analyzer run --rule-selector sfge --workspace "force-app" --target "force-app/main" --output-file "./code-analyzer-results-${TIMESTAMP}.json" --include-fixes

The --workspace flag restricts which files SFGE compiles into its graph. Set it to the narrowest directory that contains all valid, deployable Apex source code (typically force-app or src).

ApexGuru Scans

When --rule-selector apexguru is requested:

• Check org authentication: Run sf org display first
• If no org authenticated: Guide user to sf org login web or sf org login jwt
• Add --target-org <alias> flag if user has specified an org
• ApexGuru analyzes Apex performance patterns via cloud service

AppExchange Security Review Scans

When user mentions "AppExchange", "security review", "ISV", "partner":

• Use --rule-selector all to run comprehensive scan
• Output both JSON and HTML: --output-file "./code-analyzer-results-${TIMESTAMP}.json" --output-file "./code-analyzer-results-${TIMESTAMP}.html"
• In results, categorize violations as:
• Blockers (sev 1-2, Security tag): MUST fix before submission
• Warnings (sev 3, Security/BestPractices): Strongly recommended to fix
• Informational (sev 4-5): Good to fix but won't block review
• Highlight specific AppExchange-critical rules:
• ApexCRUDViolation (CRUD/FLS enforcement)
• ApexSharingViolations (sharing model)
• ApexSOQLInjection (injection prevention)
• ApexCSRF (CSRF protection)
• ApexXSSFromEscapeFalse / ApexXSSFromURLParam (XSS prevention)
• ApexInsecureEndpoint (HTTPS enforcement)
• ApexBadCrypto (crypto standards)
• ApexSuggestUsingNamedCred (credential management)

Diff-Based Scans

When user wants to scan only changed files: 1. Determine the base reference:

• "my changes" / "what I changed" → git diff --name-only (unstaged) or git diff --name-only --cached (staged)
• "branch changes" / "since main" → git diff --name-only main...HEAD
• "last commit" → git diff --name-only HEAD~1

2. Filter to scannable file types:

   git diff --name-only main...HEAD | grep -E '\.(cls|trigger|js|ts|html|css|xml|flow-meta\.xml)$'

3. If no scannable files changed: "No scannable files in your diff. Code Analyzer supports: .cls, .trigger, .js, .ts, .html, .css, .xml, .flow-meta.xml" 4. Pass filtered files as comma-separated --target value

Large Result Sets (500+ violations)

• Summarize: top 10 rules by frequency, top 10 files by violation count
• Offer: "Want me to export the full results? Or focus on a specific category/file?"
• Don't try to display all 500+ violations inline

Mega Result Sets (5000+ violations)

• Same as above, but also proactively suggest narrowing scope:
• "This is a very large number of violations. Want me to focus on just Critical/High severity, a specific category like Security, or a specific folder?"
• If the user originally said "scan and fix everything", still follow the full flow (scan → present → discover fixes → ask → apply → summarize) — do NOT shortcut any steps just because the result set is large

Vendor File Handling

Problem

Code Analyzer scans all JavaScript files, including third-party vendor libraries like jQuery, Bootstrap, Lodash, Handlebars, etc. These libraries often trigger thousands of violations, especially:

• no-var (legacy var declarations)
• prefer-const (variables that could be const)
• code style (indentation, quotes, semicolons)

A typical scan might find:

• 9,714 total violations
• 9,089 in vendor files (jQuery UI, Bootstrap, tablesorter)
• 634 in project source (your Aura/LWC components)

Why You Shouldn't Fix Vendor Files

Solutions

Solution 1: Re-scan with --target (Fastest)

If you know your project source locations upfront:

sf code-analyzer run --rule-selector <selector> \
  --target "force-app/main/default/aura,force-app/main/default/lwc" \
  --output-file "./results-project-only.json" \
  --include-fixes

Pros:

• Only scans what you need
• Faster execution
• Cleaner results

Cons:

• Must know target directories upfront
• Doesn't show you what violations exist in vendor files (for awareness)

Solution 2: Intelligent Filtering (Most Accurate)

Scan everything first, then use the intelligent filter script to separate vendor from project:

# 1. Run full scan
sf code-analyzer run --rule-selector <selector> \
  --output-file "./results-all.json" --include-fixes

# 2. Filter to project files only
node "<skill_dir>/scripts/filter-violations.js" \
  "./results-all.json" \
  "./results-project.json" \
  --report

# 3. Apply fixes to filtered results
node "<skill_dir>/scripts/apply-fixes.js" "./results-project.json"

Pros:

• Intelligent classification using multiple heuristics
• Shows you vendor vs project breakdown
• Handles uncertain files (30-70% confidence)
• No manual pattern maintenance

Cons:

• Scans more files than necessary
• Takes longer for large codebases

How the Intelligent Filter Works

The filter-violations.js script uses a multi-heuristic confidence scoring system:

1. Path-Based Signals (30% weight)

// High confidence vendor indicators
node_modules/          → 100% vendor
bower_components/      → 100% vendor
vendor/                → 95% vendor
third-party/           → 95% vendor
StaticResourceSources/ → 70% vendor

// Project source indicators
force-app/main/default/aura/    → Project
force-app/main/default/lwc/     → Project

2. Name-Based Signals (30% weight)

// Filename patterns
*.min.js               → 95% vendor (minified)
*-1.12.1.js           → 85% vendor (version in name)
jquery*.js            → 85% vendor (known library)
bootstrap*.js         → 85% vendor (known library)

// Checked against package.json dependencies

3. Content-Based Signals (40% weight)

// License headers
MIT License, Apache, BSD, GPL → 80% vendor

// Minification indicators
Average line length > 500 chars → 90% vendor
< 10 lines but > 5KB file     → 85% vendor

// Library patterns
UMD/AMD/CommonJS wrapper       → 70% vendor
@version x.x.x                 → 65% vendor
@author (non-project)          → 50% vendor

Final Score

Weighted Score = (PathScore × 0.3) + (NameScore × 0.3) + (ContentScore × 0.4)

> 70% = Vendor file
< 30% = Project file
30-70% = Uncertain (manual review)

Example Output

=== INTELLIGENT VENDOR FILE DETECTION ===

Original violations: 9714
Filtered violations: 634
Reduction: 9080 (93.5%)

📦 Vendor files excluded: 127
   610 violations | 95% confidence | jquery-ui-1.12.1.js
        located in vendor directory, version number in filename, minified file
   525 violations | 98% confidence | jquery-ui-1.12.1.min.js
        located in vendor directory, minified file (.min.js)
   ... and 125 more vendor files

✅ Project files included: 39
   157 violations | CRLP_RollupHelper.js
   103 violations | HH_ContainerHelper.js
   84 violations | CRLP_FilterGroupHelper.js
   ...

⚠️  Uncertain files: 2
    These files have 30-70% vendor confidence - review manually:
   45 violations | 55% vendor | customUtility.js
        located in vendor directory

✓ Filtered results written to: ./results-project.json

Workflow Integration

When to Use Each Approach

Step-by-Step Workflow

1. Run Code Analyzer scan
2. Parse results
3. **Check violation distribution:**
   - If 50%+ are in vendor files → offer intelligent filtering
   - If user said "my code" or "project" → automatically filter
4. Discover fixes (on filtered or unfiltered results)
5. Apply fixes
6. Summarize

Edge Cases

Case 1: Vendored Modified Libraries

Scenario: Your org has modified a copy of jQuery

Solution: The intelligent filter will classify it as vendor, but violations may be legitimate. Options: 1. Fix manually after filter identifies it 2. Re-run with --target excluding that specific file 3. Add to project exceptions in filter script

Case 2: Project Code in Static Resources

Scenario: Your custom JavaScript is in staticresources/ alongside vendor libs

Solution: The filter checks content + name, not just path. Custom code without vendor markers scores as "project" or "uncertain" for manual review.

Case 3: Uncertain Classifications

Scenario: File scores 30-70% vendor confidence

Action: Filter script reports these separately. Review manually:

• Check file purpose
• Look for original source/documentation
• Decide whether to fix or exclude

Configuration (Future Enhancement)

The filter script could accept custom patterns:

node filter-violations.js results.json filtered.json \
  --exclude-patterns "*.min.js,jquery*,bootstrap*" \
  --include-patterns "force-app/main/default/aura/**,force-app/main/default/lwc/**"

Currently uses intelligent defaults and doesn't require configuration.

Testing the Filter

# Run with detailed report
node scripts/filter-violations.js \
  ./code-analyzer-results-20260519-133252.json \
  ./filtered-output.json \
  --report

# Check the output
node scripts/parse-results.js ./filtered-output.json

Compare before/after violation counts to verify filtering accuracy.