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.
**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)
```yaml
config_root: . # Root for relative path resolution
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.
- Give user ONE command at a time, wait for confirmation before continuing
- After fix succeeds, proceed to run the full scan automatically
---
## Step 3: Create or Edit `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
# Example: user said "ignore test files and increase SFGE memory"
# → Write to project root (where sfdx-project.json lives):
```
```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.
### 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.)
### If user says "configure code analyzer" with no specifics
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
Edit the `engines` section in `code-analyzer.yml`:
description: "Detects hardcoded Salesforce record IDs"
severity: 2
tags: ["Security"]
```
For full property list per engine, read `<skill_dir>/references/config-schema.md`.
---
## Step 8: CI/CD Pipeline Setup
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`.
---
## Step 9: View Current Configuration
```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
```
---
## Cross-Skill Integration
This skill works together with `dx-code-analyzer-run`. The AI agent should seamlessly hand off between them:
### When `dx-code-analyzer-run` delegates HERE:
If a user says "scan my code" / "run code analyzer" but it fails (CLI missing, plugin not installed, or scan errors out), `dx-code-analyzer-run` 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 `dx-code-analyzer-run` behavior (build command, execute, parse results).
### When THIS skill hands off to `dx-code-analyzer-run`:
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 `dx-code-analyzer-run` behavior.
### 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.
---
## Rules / Constraints
| Constraint | Rationale |
|-----------|-----------|
| Only create YAML when user requests a customization | Defaults work without any file — don't create boilerplate |
| Place YAML at project root only | CLI auto-discovers `code-analyzer.yml` from CWD |
| Write only overrides, never duplicate defaults | Keep file minimal and intentional |
| Use Write tool to create, Edit tool to modify | Preserves existing settings |
| Validate after every change | `sf code-analyzer config` catches YAML errors |
| Ask before installing prerequisites | Never auto-install without consent |
| Never delete existing config without asking | User may have custom settings |
| After setup, offer to scan | Close the loop — config without scan is incomplete |
---
## Gotchas
| Issue | Solution |
|-------|----------|
| Config not picked up | Must be `code-analyzer.yml` in CWD or use `--config-file` |
| YAML validation fails | Spaces only (no tabs), check colon spacing |
| SFGE out of memory | Increase `java_max_heap_size` in engines section |
| ESLint rules missing | Set `auto_discover_eslint_config: true` |
For full troubleshooting, read `<skill_dir>/references/troubleshooting.md`.
---
## Reference File Index
`<skill_dir>` is the absolute path to the directory containing this SKILL.md file.
