Configuring Code Analyzer

Configuring Code Analyzer Skill

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.

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

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

Core Principle: YAML Only When Customizing

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

Step 1: Understand Intent and Map to Config Sections

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

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

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>"

Mapping Principle

Any user request maps to one or more sections above. Parse the intent and edit the right section(s):

File Existence Decision

BEFORE editing anything, check if code-analyzer.yml exists at project root:

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.

⚠️ Rule Name Resolution — ALWAYS Before Writing 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").

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

Quick Reference: Common Requests → Config Output