$npx -y skills add forcedotcom/sf-skills --skill dx-code-analyzer-configureSet up, configure, and troubleshoot Salesforce Code Analyzer for any project. Handles installation, prerequisite checks, diagnosing broken setups, creating and editing code-analyzer.yml overrides, engine-specific settings, ignore patterns, severity overrides, and CI/CD pipeline s
| 1 | # Configuring Code Analyzer Skill |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | > **Ecosystem:** This skill is part of a 3-skill Code Analyzer suite — `dx-code-analyzer-run` (scans & results) · `dx-code-analyzer-configure` (setup, config, CI/CD) · `dx-code-analyzer-custom-rule-create` (custom rule authoring). |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## Scope |
| 12 | |
| 13 | **In scope:** |
| 14 | - Checking prerequisites (sf CLI, Java, Node.js, Python, org auth) |
| 15 | - Installing/updating the Code Analyzer plugin |
| 16 | - Creating `code-analyzer.yml` if it doesn't exist |
| 17 | - Editing `code-analyzer.yml` for all configuration changes |
| 18 | - Engine settings, rule overrides, ignore patterns, suppressions |
| 19 | - CI/CD pipeline setup (GitHub Actions, Jenkins, etc.) |
| 20 | - Environment validation and troubleshooting |
| 21 | |
| 22 | **Out of scope:** |
| 23 | - Running scans → use `dx-code-analyzer-run` skill |
| 24 | - Fixing violations, explaining rules, suppression management → use `dx-code-analyzer-run` skill |
| 25 | - Creating custom rules → use `dx-code-analyzer-custom-rule-create` skill |
| 26 | |
| 27 | --- |
| 28 | |
| 29 | ## Tool Usage Rules |
| 30 | |
| 31 | **Allowed:** Bash (sf, java, node, python3, git, npm), Read, Write, Edit |
| 32 | **Forbidden:** MCP tools, Agent tool, Web tools, other skills, `which`, `find`, `locate`, searching for binaries |
| 33 | |
| 34 | --- |
| 35 | |
| 36 | ## Core Principle: YAML Only When Customizing |
| 37 | |
| 38 | 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. |
| 39 | |
| 40 | **Rules:** |
| 41 | - **Do NOT create `code-analyzer.yml` proactively** — only when user asks to change something |
| 42 | - **Do NOT duplicate built-in defaults** — only write entries that intentionally override behavior |
| 43 | - **Always place at project root** — where `sfdx-project.json` or `sf-project.json` lives |
| 44 | - **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. |
| 45 | - User says "configure code analyzer" with no specifics? → **Ask what they want to customize**. Don't create an empty or boilerplate file. |
| 46 | |
| 47 | **Workflow:** |
| 48 | 1. User requests a customization (e.g., "disable PMD", "ignore test files", "increase SFGE memory") |
| 49 | 2. Check if `code-analyzer.yml` exists at project root |
| 50 | 3. If NO → create it at project root with ONLY the requested override |
| 51 | 4. If YES → read it, then edit in the requested change |
| 52 | 5. Validate with `sf code-analyzer config` |
| 53 | |
| 54 | --- |
| 55 | |
| 56 | ## Step 1: Understand Intent and Map to Config Sections |
| 57 | |
| 58 | The user can request ANY combination of configuration changes in natural language. Your job is to: |
| 59 | |
| 60 | 1. **Parse what they want** — may be one thing or many things combined |
| 61 | 2. **Map each request to the correct section(s) of `code-analyzer.yml`** |
| 62 | 3. **Create the file if it doesn't exist, then apply all changes** |
| 63 | |
| 64 | ### The `code-analyzer.yml` Structure (what you can write/edit) |
| 65 | |
| 66 | ```yaml |
| 67 | config_root: . # Root for relative path resolution |
| 68 | log_folder: <path> # Where logs are written |
| 69 | log_level: <1-5> # 1=Error, 2=Warn, 3=Info, 4=Debug, 5=Fine |
| 70 | |
| 71 | ignores: # Files/folders excluded from scanning |
| 72 | files: [<glob patterns>] |
| 73 | |
| 74 | engines: # Per-engine settings |
| 75 | <engine_name>: |
| 76 | disable_engine: <bool> |
| 77 | <engine_specific_keys>: ... |