@salesforce/afv-skills 1.38.0 → 1.40.0

package/skills/design-systems-slds2-migrate/references/rule-no-hardcoded-values.md

@@ -10,7 +10,7 @@
 
 The linter detects hardcoded values and reports them as warnings. Here's real output for an icon component:
 
-```
+```text
   3:10  warning  Consider replacing the 32px static value with an SLDS 2 styling hook
                  that has a similar value: --slds-g-sizing-9.                              slds/no-hardcoded-values-slds2
 
@@ -72,7 +72,7 @@ The fallback must be the **exact original value** from the source CSS (e.g., `#0
 
 When examining a hardcoded value or deprecated token, follow this decision tree:
 
-```
+```text
 1. SLDS utility class available?
    └─ Yes → Remove CSS, add utility class to HTML
    └─ No  ↓

package/skills/design-systems-slds2-migrate/references/rule-no-slds-class-overrides.md

@@ -10,7 +10,7 @@
 
 The linter detects CSS classes that directly override SLDS classes and reports them as **warnings**. It does **not** auto-fix — all changes require manual work in both CSS and HTML.
 
-```
+```text
   1:1  warning  Overriding slds-button isn't supported. To differentiate SLDS and
                custom classes, create a CSS class in your namespace.
                Examples: myapp-input, myapp-button.                  slds/no-slds-class-overrides

package/skills/dx-apexguru-scan/SKILL.md

@@ -5,6 +5,7 @@ allowed-tools: Read, Bash(bash), Bash(node), Bash(curl), Bash(zip), Bash(unzip),
 argument-hint: "[project-path] [--org <alias>] [--fast]"
 metadata:
   version: "1.1"
+  domains: ["Developer Experience"]
   relatedSkills:
     - "dx-code-analyzer-run"
   cliTools:

package/skills/dx-app-analytics-query/SKILL.md

@@ -10,6 +10,7 @@ metadata:
     - "platform-metadata-deploy"
     - "platform-soql-query"
   version: "1.0"
+  domains: ["Developer Experience"]
   minApiVersion: "56.0"
 ---
 

package/skills/dx-code-analyzer-configure/SKILL.md

@@ -3,10 +3,13 @@ name: dx-code-analyzer-configure
 description: "Set 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 setup. TRIGGER when: user says 'set up code analyzer', 'configure code analyzer', 'install code analyzer', 'code analyzer not working', 'fix my setup', 'scan failing', 'check my setup', 'enable/disable engine', 'exclude files', 'change severity', 'set up GitHub Actions', 'set up CI/CD', 'add to pipeline', 'pipeline fail', 'update my workflow', 'quality gate', 'fail on violations', 'scan changed files only', 'add SARIF', 'code-analyzer.yml', 'ESLint config', 'increase SFGE memory', or reports errors running Code Analyzer. DO NOT TRIGGER when: user wants to run a scan (use dx-code-analyzer-run), fix violations, explain rules, create custom rules (use dx-code-analyzer-custom-rule-create), or suppress violations."
 metadata:
   version: "1.0"
+  domains: ["Developer Experience"]
   relatedSkills:
-    - "dx-code-analyzer-run"
     - "dx-code-analyzer-custom-rule-create"
+    - "dx-code-analyzer-run"
   cliTools:
+    - tool: ["sf"]
+      semver: ">=2.0.0"
     - tool: ["curl"]
       semver: ">=7.0.0"
     - tool: ["java"]
@@ -17,8 +20,6 @@ metadata:
       semver: ">=9.0.0"
     - tool: ["python3"]
       semver: ">=3.10.0"
-    - tool: ["sf"]
-      semver: ">=2.0.0"
 ---
 
 # Configuring Code Analyzer Skill
@@ -51,7 +52,7 @@ This skill manages the `code-analyzer.yml` configuration file — the single sou
 
 ## Tool Usage Rules
 
-**Allowed:** Bash (sf, java, node, python3, git, npm), Read, Write, Edit
+**Allowed:** Bash (sf, java, node, python3, npm), Read, Write, Edit
 **Forbidden:** MCP tools, Agent tool, Web tools, other skills, `which`, `find`, `locate`, searching for binaries
 
 ---
@@ -359,7 +360,7 @@ rules:
 
 ### 6.1 Rule Name Resolution (Fuzzy Matching)
 
-**⚠️ CRITICAL:** A misspelled or partial rule name in `code-analyzer.yml` is SILENTLY IGNORED — no error, the override just won't apply.
+**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:
 

package/skills/dx-code-analyzer-configure/references/ci-cd-templates.md

@@ -316,7 +316,7 @@ For monorepos where Salesforce code lives in a subdirectory, use `--target` to s
 ```
 
 For multiple packages:
-```
+```text
 --target packages/app-a/force-app --target packages/app-b/force-app
 ```
 
@@ -601,7 +601,7 @@ Build the `run-arguments` string by combining these independent flags as needed:
 
 ### Decision Tree for Template Selection
 
-```
+```text
 User wants CI/CD for Code Analyzer
 ├── Platform?
 │   ├── GitHub Actions → Use forcedotcom/run-code-analyzer@v2

package/skills/dx-code-analyzer-custom-rule-create/SKILL.md

@@ -3,9 +3,10 @@ name: dx-code-analyzer-custom-rule-create
 description: "Create custom Code Analyzer rules for Regex (pattern matching), PMD (XPath/AST for Apex and metadata XML), and ESLint (LWC/JavaScript/TypeScript). Use when users want to enforce coding standards, ban patterns, detect hardcoded values, govern metadata, or add rules not in the built-in set. TRIGGER when: user says 'create a rule', 'ban System.debug', 'enforce naming convention', 'detect hardcoded IDs', 'custom rule', 'xpath rule', 'regex rule', 'add a PMD rule', 'enforce a policy', 'create a check for', 'flag this pattern', 'make a rule that catches', 'metadata rule', 'check permissions', 'enforce API version', 'eslint rule', 'lwc rule', 'override rule threshold', 'customize complexity', or describes a pattern to enforce. DO NOT TRIGGER when: user wants to run a scan (use dx-code-analyzer-run), configure engines (use dx-code-analyzer-configure), or explain existing rules (use dx-code-analyzer-run)."
 metadata:
   version: "1.0"
+  domains: ["Developer Experience"]
   relatedSkills:
-    - "dx-code-analyzer-run"
     - "dx-code-analyzer-configure"
+    - "dx-code-analyzer-run"
   cliTools:
     - tool: ["git"]
       semver: ">=2.0.0"
@@ -102,7 +103,7 @@ These are non-negotiable rules. Violating any of them is a skill failure regardl
 
 \* **For ESLint:** ALWAYS check Tier 1 (built-in rules) and Tier 2 (configurable rules) BEFORE creating a custom plugin. See `references/eslint-rules-discovery.md`.
 
-⚠️ **"Both could work → Regex first" NEVER applies to JavaScript/LWC/TypeScript files.** JS/LWC/TS patterns MUST use ESLint — Regex cannot distinguish code from comments/strings in JS and produces false positives. Do NOT rationalize Regex for JS files based on "simplicity" or "no npm dependencies."
+**"Both could work → Regex first" NEVER applies to JavaScript/LWC/TypeScript files.** JS/LWC/TS patterns MUST use ESLint — Regex cannot distinguish code from comments/strings in JS and produces false positives. Do NOT rationalize Regex for JS files based on "simplicity" or "no npm dependencies."
 
 Tell the user which engine you chose and why. Respect their preference if they disagree.
 
@@ -116,7 +117,7 @@ When a rule should NOT apply to test classes, the approach differs by engine:
 | **Regex** | Use `ignores.files` in `code-analyzer.yml` with globs like `**/*Test.cls` | `regex_ignore` is per-LINE, not per-FILE — it CANNOT exclude entire test classes. Only use `regex_ignore` for per-line patterns like `// NOPMD` |
 | **ESLint** | Use `ignores` array in `eslint.config.js` | Standard ESLint file-level ignores |
 
-⚠️ **`regex_ignore` is NOT file-level exclusion.** It only skips matches on lines that ALSO match the ignore pattern. Example: `regex_ignore: "/@isTest/i"` only suppresses violations on lines containing `@isTest` — a SOQL query on line 50 of a test class still flags because line 50 doesn't contain `@isTest`. To exclude test files from regex rules entirely, use:
+**`regex_ignore` is NOT file-level exclusion.** It only skips matches on lines that ALSO match the ignore pattern. Example: `regex_ignore: "/@isTest/i"` only suppresses violations on lines containing `@isTest` — a SOQL query on line 50 of a test class still flags because line 50 doesn't contain `@isTest`. To exclude test files from regex rules entirely, use:
 ```yaml
 ignores:
   files:
@@ -124,7 +125,7 @@ ignores:
     - "**/*_Test.cls"
 ```
 
-⚠️ **`ignores.files` is GLOBAL** — it affects ALL engines and ALL rules. If you need test-class exclusion for some rules but not others (e.g., exclude tests from SOQL rules but still scan tests for @AuraEnabled), use **PMD with XPath** for the rules that need selective exclusion. PMD's XPath can structurally check `@Test = true()` per-method or per-class — Regex cannot.
+**`ignores.files` is GLOBAL** — it affects ALL engines and ALL rules. If you need test-class exclusion for some rules but not others (e.g., exclude tests from SOQL rules but still scan tests for @AuraEnabled), use **PMD with XPath** for the rules that need selective exclusion. PMD's XPath can structurally check `@Test = true()` per-method or per-class — Regex cannot.
 
 **Decision guide for Apex rules that should skip test classes:**
 - If the pattern is structural (method calls, annotations, nesting) → use PMD. XPath handles test-class exclusion natively.
@@ -180,7 +181,7 @@ When the user highlights a code block in their editor and asks to "catch this",
      --name "<RuleName>" --regex "<pattern>" --description "<desc>" \
      --severity <1-5> --file-extensions ".cls,.trigger"
    ```
-   ⚠️ **ALWAYS use the script.** Do NOT manually write regex patterns into `code-analyzer.yml` — regex characters (quotes, backslashes, braces) inside YAML cause parsing failures. The script handles serialization correctly.
+   **ALWAYS use the script.** Do NOT manually write regex patterns into `code-analyzer.yml` — regex characters (quotes, backslashes, braces) inside YAML cause parsing failures. The script handles serialization correctly.
 4. **Validate** — `sf code-analyzer rules --rule-selector regex:<RuleName>`
 5. **Test positive** — `sf code-analyzer run --rule-selector regex:<RuleName> --target <violation-sample>` — must find violations
 6. **Test negative** — `sf code-analyzer run --rule-selector regex:<RuleName> --target <clean-sample>` — must find 0 violations. If it flags clean code, your regex is too broad — go back and tighten the pattern.
@@ -190,10 +191,10 @@ When the user highlights a code block in their editor and asks to "catch this",
 ### For PMD/XPath Rules (Apex)
 
 1. **Write a minimal sample** (5-10 lines) demonstrating the violation. Write sample files inside the project workspace (e.g., a temporary `samples/` directory at the project root) so Code Analyzer can target them. **After both positive and negative tests pass, delete ALL sample files you created** — both the original samples and any copies made during testing. Do not leave temporary test fixtures in the user's project. For loop-based rules, the positive sample MUST include all 3 Apex loop types (`for-each`, traditional `for`, and `while`) — omitting any loop type means the XPath won't be validated against it and may silently miss violations.
-2. **⚠️ MANDATORY: Dump the AST** — `sf code-analyzer ast-dump --file <sample.cls> --output-file <ast.xml>` — this step is NOT optional. Do NOT skip it even if you "already know" the node names. Run it, read the output, confirm the exact node names and attributes.
+2. **MANDATORY: Dump the AST** — `sf code-analyzer ast-dump --file <sample.cls> --output-file <ast.xml>` — this step is NOT optional. Do NOT skip it even if you "already know" the node names. Run it, read the output, confirm the exact node names and attributes.
 3. **Read the AST output** — identify the target node and its attributes from the ACTUAL ast-dump output (not from memory). Use `references/apex-ast-reference.md` and `references/xpath-patterns.md` as supplementary context only.
 4. **Write XPath** — target the smallest stable node with discriminating attributes. Every node name in your XPath MUST appear verbatim in the ast-dump output you just read. Use `/Child` (direct child) vs `//Descendant` deliberately — check the ast-dump to understand which nodes are siblings vs nested.
-5. **⚠️ BEFORE creating the rule: Write a SEPARATE negative sample file** (5-10 lines) showing code that is CORRECT and must NOT be flagged. This MUST be a distinct file from the positive sample — do NOT combine positive and negative cases into one file. For loop-based rules, include `for (x : [SELECT...])` idiom. Run `sf code-analyzer ast-dump` on this negative sample file too. Read the output and trace your XPath against it — confirm it does NOT match any node in the negative AST. If it would match, go back to step 4 and tighten the XPath BEFORE proceeding. Do NOT skip this step or defer it until after rule creation. The negative file will be used again in step 9 for an explicit zero-violation confirmation.
+5. **BEFORE creating the rule: Write a SEPARATE negative sample file** (5-10 lines) showing code that is CORRECT and must NOT be flagged. This MUST be a distinct file from the positive sample — do NOT combine positive and negative cases into one file. For loop-based rules, include `for (x : [SELECT...])` idiom. Run `sf code-analyzer ast-dump` on this negative sample file too. Read the output and trace your XPath against it — confirm it does NOT match any node in the negative AST. If it would match, go back to step 4 and tighten the XPath BEFORE proceeding. Do NOT skip this step or defer it until after rule creation. The negative file will be used again in step 9 for an explicit zero-violation confirmation.
 6. **Create the rule** — run the script:
    ```bash
    node "<skill_dir>/scripts/create-pmd-rule.js" \
@@ -224,7 +225,7 @@ When the user highlights a code block in their editor and asks to "catch this",
        file_extensions:
          xml: [".xml"]
    ```
-   ⚠️ Do NOT add compound extensions like `.permissionset-meta.xml` — Code Analyzer's validator rejects them (`/^[.][a-zA-Z0-9]+$/` pattern). Just `.xml` covers all Salesforce metadata files automatically.
+   Do NOT add compound extensions like `.permissionset-meta.xml` — Code Analyzer's validator rejects them (`/^[.][a-zA-Z0-9]+$/` pattern). Just `.xml` covers all Salesforce metadata files automatically.
 6. **Write a SEPARATE negative sample file** — same as Apex rules: create a metadata file that is correct and must NOT be flagged. Verify the XPath does not match it BEFORE creating the rule. Both positive and negative samples should be `.xml` extension files in the workspace so PMD can scan them directly.
 7. **Create the rule** — run the script:
    ```bash
@@ -265,7 +266,7 @@ ESLint has 200+ built-in rules plus thousands more from plugins. DO NOT attempt
 
 ---
 
-0. **⚠️ MANDATORY: Run the ESLint discovery workflow FIRST.** 90% of ESLint requests are solved by built-in rules (Tier 1) or configurable rules like `no-restricted-syntax` (Tier 2). Creating a custom plugin (Tier 3) is a LAST RESORT. Before proceeding:
+0. **MANDATORY: Run the ESLint discovery workflow FIRST.** 90% of ESLint requests are solved by built-in rules (Tier 1) or configurable rules like `no-restricted-syntax` (Tier 2). Creating a custom plugin (Tier 3) is a LAST RESORT. Before proceeding:
    
    a) **Run:** `sf code-analyzer rules --rule-selector eslint`
    b) **Search** the output for keywords from the user's request (e.g., "console", "equal", "unused")
@@ -276,9 +277,9 @@ ESLint has 200+ built-in rules plus thousands more from plugins. DO NOT attempt
    
    **Validation:** After configuration, run `sf code-analyzer rules --rule-selector eslint:<ruleName>` to confirm it appears. If it doesn't, the config is wrong.
    
-   ⚠️ **Skipping this discovery workflow and creating a custom plugin when a built-in rule exists is a skill failure**, regardless of whether the custom plugin works.
+   **Skipping this discovery workflow and creating a custom plugin when a built-in rule exists is a skill failure**, regardless of whether the custom plugin works.
 
-⚠️ **Built-in ESLint rules vs. configurable ESLint rules:** Code Analyzer bundles a SUBSET of ESLint rules in its base config. Rules like `no-restricted-globals`, `no-restricted-syntax`, and `no-restricted-properties` are core ESLint rules but are NOT active until you enable them in an `eslint.config.js`. They WILL appear in `sf code-analyzer rules` output ONLY after you configure them. **Always validate** (step 4) to confirm the rule actually loaded — do NOT assume a rule exists just because it's a core ESLint rule.
+**Built-in ESLint rules vs. configurable ESLint rules:** Code Analyzer bundles a SUBSET of ESLint rules in its base config. Rules like `no-restricted-globals`, `no-restricted-syntax`, and `no-restricted-properties` are core ESLint rules but are NOT active until you enable them in an `eslint.config.js`. They WILL appear in `sf code-analyzer rules` output ONLY after you configure them. **Always validate** (step 4) to confirm the rule actually loaded — do NOT assume a rule exists just because it's a core ESLint rule.
 
 1. **Install the ESLint plugin** (skip if using a built-in/core ESLint rule) — `npm install --save-dev eslint-plugin-<name>`
 2. **Create/update `eslint.config.js`** — add plugin and rule configuration (or just enable the built-in rule with `"error"` severity). **The file MUST exist** before configuring `engines.eslint.eslint_config_file` in `code-analyzer.yml` — Code Analyzer validates the path and fails if the file is missing.
@@ -300,26 +301,26 @@ For `no-restricted-globals`, `no-restricted-syntax`, and `no-restricted-properti
 - User: "Ban console.log in LWC"
 - Discovery: `sf code-analyzer rules --rule-selector eslint | grep console` → finds `no-console`
 - Action: Enable `no-console` in eslint.config.js
-- Result: ✅ Done in 2 minutes (no custom plugin needed)
+- Result: Done in 2 minutes (no custom plugin needed)
 
 **Example 2: Configurable rule (Tier 2)**
 - User: "Ban setTimeout in LWC"
 - Discovery: No built-in `no-setTimeout` rule
 - Action: Use `no-restricted-globals` with custom message
-- Result: ✅ Done in 5 minutes (no custom plugin needed)
+- Result: Done in 5 minutes (no custom plugin needed)
 
 **Example 3: LWC plugin rule (Tier 1)**
 - User: "Ban innerHTML for XSS prevention"
 - Discovery: `@lwc/lwc/no-inner-html` already exists
 - Action: Enable `@lwc/lwc/no-inner-html` in config
-- Result: ✅ Done in 2 minutes (no custom plugin needed)
+- Result: Done in 2 minutes (no custom plugin needed)
 
 **Example 4: Custom plugin justified (Tier 3)**
 - User: "Flag imperative Apex calls without error handling"
 - Discovery: No built-in rule for this pattern
 - Analysis: Pattern requires checking `import` + `.then()` without `.catch()` — multi-node traversal
 - Action: Create custom plugin with visitor pattern
-- Result: ✅ Custom plugin is justified (20+ minutes effort)
+- Result: Custom plugin is justified (20+ minutes effort)
 
 See `references/eslint-rules-discovery.md` for complete discovery workflow.
 
@@ -375,11 +376,11 @@ When creating multiple PMD rules, use the `create-pmd-rule.js` script for the fi
 
 ### What NOT to do
 
-- ❌ Do NOT rewrite the entire `code-analyzer.yml` to reorganize it
-- ❌ Do NOT create all rules in parallel then validate all at once
-- ❌ Do NOT create a PMD rule with an unverified XPath from the reference docs — ast-dump each pattern
-- ❌ Do NOT mix engine types in one creation step (e.g., creating regex + PMD rules simultaneously)
-- ❌ Do NOT add `engines.eslint.eslint_config_file` to `code-analyzer.yml` before the file exists
+- Do NOT rewrite the entire `code-analyzer.yml` to reorganize it
+- Do NOT create all rules in parallel then validate all at once
+- Do NOT create a PMD rule with an unverified XPath from the reference docs — ast-dump each pattern
+- Do NOT mix engine types in one creation step (e.g., creating regex + PMD rules simultaneously)
+- Do NOT add `engines.eslint.eslint_config_file` to `code-analyzer.yml` before the file exists
 
 ---
 
@@ -393,7 +394,7 @@ When creating multiple PMD rules, use the `create-pmd-rule.js` script for the fi
 | Always validate after creation | `sf code-analyzer rules --rule-selector <engine>:<name>` catches config errors |
 | Always test against sample code | Catches XPath/regex mismatches before full scan |
 | Use `@FullMethodName` for method calls in XPath | More reliable than `@Image` or `@MethodName` alone |
-| **⚠️ NEVER skip `ast-dump`** | Run `ast-dump`, read output, THEN write XPath. No exceptions — even for "obvious" patterns. Using node names from memory without ast-dump verification is a skill failure. |
+| **NEVER skip `ast-dump`** | Run `ast-dump`, read output, THEN write XPath. No exceptions — even for "obvious" patterns. Using node names from memory without ast-dump verification is a skill failure. |
 | **PMD 7 boolean attributes: use `= false()` XPath function** | In PMD 7, boolean attributes like `@WithSharing`, `@Abstract`, `@Final` are ALWAYS present on the node (never absent). Compare with `= false()` (XPath boolean function), NOT string `'false'`. `@WithSharing = false()` works. `@WithSharing='false'` (string) does NOT. `not(@WithSharing)` does NOT (attribute is always present). |
 | `code-analyzer.yml` at project root | Auto-discovered by CLI — placing it elsewhere causes silent failures for rule authors |
 | **XML rules MUST use `local-name()`** | Salesforce metadata namespace breaks bare element names |
@@ -451,11 +452,11 @@ node "<skill_dir>/scripts/create-regex-rule.js" \
   --name "RuleName" --regex "/pattern/flags" ...
 ```
 
-⚠️ **DO NOT:**
-- ❌ Invent or generate script code yourself
-- ❌ Use bare relative paths like `node scripts/create-regex-rule.js` (won't resolve from user's CWD)
-- ❌ Use heredocs or inline script content
-- ❌ Skip resolving `<skill_dir>` — find the absolute path first
+**DO NOT:**
+- Invent or generate script code yourself
+- Use bare relative paths like `node scripts/create-regex-rule.js` (won't resolve from user's CWD)
+- Use heredocs or inline script content
+- Skip resolving `<skill_dir>` — find the absolute path first
 
 ---
 

package/skills/dx-code-analyzer-run/SKILL.md

@@ -3,6 +3,7 @@ name: dx-code-analyzer-run
 description: "Run Salesforce Code Analyzer to scan code for security, performance, best practice, and code style violations. Supports all engines (PMD, ESLint, CPD, RetireJS, Flow, SFGE, ApexGuru), targets (files, folders, git diff), categories, and severities. Also handles post-scan exploration: filtering results by engine/severity/category/file, and explaining what rules mean. TRIGGER when: user says 'scan my code', 'check security issues', 'run PMD/ESLint', 'find duplicates', 'analyze Flows', 'check vulnerable libraries', 'AppExchange review', 'lint my LWC', 'static analysis', 'code quality', 'show security violations', 'what is this rule', 'explain ApexCRUDViolation', 'filter results', or mentions engines/file types (.cls, .trigger, .js, .flow-meta.xml). Use this skill for scanning, exploring results, and listing rules. DO NOT TRIGGER when: user asks only about installation/configuration (use dx-code-analyzer-configure), or wants to create a custom rule (use dx-code-analyzer-custom-rule-create)."
 metadata:
   version: "1.0"
+  domains: ["Developer Experience"]
   relatedSkills:
     - "dx-code-analyzer-configure"
     - "dx-code-analyzer-custom-rule-create"
@@ -160,7 +161,7 @@ security/OWASP → `Security` · performance → `Performance` · best practices
 ### 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**:
+**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**:
 ```bash
 sf code-analyzer rules --rule-selector all 2>&1 | grep -i "USER_KEYWORD"
 ```
@@ -246,12 +247,12 @@ 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
+**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
 
@@ -328,7 +329,7 @@ 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.
+**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
 
@@ -346,7 +347,7 @@ node "<skill_dir>/scripts/summarize-fixes.js" "./code-analyzer-results-TIMESTAMP
 Then present:
 
 ```text
-### Engine-Provided Fixes Applied Successfully ✓
+### Engine-Provided Fixes Applied Successfully
 **Applied X auto-fixes across Y files.**
 
 | Severity | Fixes Applied |

package/skills/dx-code-analyzer-run/references/post-scan-workflows.md

@@ -82,7 +82,7 @@ When `--summary` is used, the `violations` array is omitted.
 
 Present query results using the same format as Step 5, but with a header indicating the active filter:
 
-```
+```text
 ## Filtered Results: [description of filter]
 
 **X matches** out of Y total violations.
@@ -192,7 +192,7 @@ node "<skill_dir>/scripts/describe-rule.js" "OperationWithLimitsInLoop"
 
 **For a successful lookup**, present:
 
-```
+```text
 ## Rule: ApexCRUDViolation
 
 | Property | Value |
@@ -219,7 +219,7 @@ Want me to show all violations of this rule in your scan results?
 
 **For multiple matches**, present:
 
-```
+```text
 I found multiple rules matching "CRUD":
 
 | # | Rule | Engine | Severity |
@@ -232,7 +232,7 @@ Which rule would you like details on?
 
 **For not found**, present:
 
-```
+```text
 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?
@@ -253,7 +253,7 @@ Offer next steps:
 
 Present available rules in this format:
 
-```
+```text
 ## Available Rules: Security
 
 **Found X rules** across Y engines.

package/skills/dx-code-analyzer-run/references/vendor-file-handling.md

@@ -123,7 +123,7 @@ UMD/AMD/CommonJS wrapper       → 70% vendor
 
 ### Final Score
 
-```
+```text
 Weighted Score = (PathScore × 0.3) + (NameScore × 0.3) + (ContentScore × 0.4)
 
 > 70% = Vendor file
@@ -133,7 +133,7 @@ Weighted Score = (PathScore × 0.3) + (NameScore × 0.3) + (ContentScore × 0.4)
 
 ## Example Output
 
-```
+```text
 === INTELLIGENT VENDOR FILE DETECTION ===
 
 Original violations: 9714

package/skills/dx-devops-pipeline-manage/SKILL.md

@@ -3,6 +3,7 @@ name: dx-devops-pipeline-manage
 description: "Use this skill to manage the full lifecycle of a DevOps Center pipeline — list all pipelines, get a single pipeline's details, create a new pipeline linked to a Git repository, add or remove stages, rename a stage, add or remove Salesforce environments on stages, attach or detach projects, and activate or deactivate the pipeline. Invoke when the user wants to set up a release pipeline, wire promotion stages across integration, UAT, staging, and production orgs, connect environments to stages, attach a project, or activate a continuous delivery pipeline. Uses sf devops pipeline and sf devops stage commands with --json output. DO NOT TRIGGER for work-item lifecycle, promotion or deployment execution, conflict detection, or standalone project creation (separate skills)."
 metadata:
   version: "1.0"
+  domains: ["Developer Experience"]
   minApiVersion: "58.0"
   relatedSkills:
     - "dx-devops-work-item-manage"

package/skills/dx-devops-promote/SKILL.md

@@ -3,6 +3,7 @@ name: dx-devops-promote
 description: "Use this skill to drive the full DevOps Center promotion workflow for work items and pipeline stages — validate preconditions, prepare work items, optionally combine work items that share metadata, promote one or more work items or an entire stage to a target pipeline stage, and complete the promotion to finalize the deployment. TRIGGER when the user wants to promote a work item, advance changes to the next environment or stage, combine work items for a single promotion, or move metadata through the release pipeline. The mandatory validate step runs automatically at the start. DO NOT TRIGGER for work item creation or status updates (use dx-devops-work-item-manage), for conflict detection, or for polling an existing promotion's status."
 metadata:
   version: "1.0"
+  domains: ["Developer Experience"]
   minApiVersion: "58.0"
   relatedSkills:
     - "dx-devops-work-item-manage"

package/skills/dx-devops-test-failures-analyze/SKILL.md

@@ -11,6 +11,7 @@ metadata:
     - "platform-apex-generate"
     - "platform-apex-test-generate"
   version: "1.0"
+  domains: ["Developer Experience"]
   minApiVersion: "67.0"
 ---
 

package/skills/dx-devops-test-pipeline-configure/SKILL.md

@@ -10,6 +10,7 @@ metadata:
     - "dx-devops-test-suite-assignments-configure"
     - "dx-devops-test-suite-run"
   version: "1.0"
+  domains: ["Developer Experience"]
   minApiVersion: "67.0"
 ---
 

package/skills/dx-devops-test-suite-assignments-configure/SKILL.md

@@ -12,6 +12,7 @@ metadata:
     - "platform-apex-test-generate"
     - "platform-apex-test-run"
   version: "1.0"
+  domains: ["Developer Experience"]
   minApiVersion: "67.0"
 ---
 

package/skills/dx-devops-test-suite-run/SKILL.md

@@ -11,6 +11,7 @@ metadata:
     - "dx-devops-test-suite-assignments-configure"
     - "platform-apex-test-run"
   version: "1.0"
+  domains: ["Developer Experience"]
   minApiVersion: "67.0"
 ---
 

package/skills/dx-devops-work-item-manage/SKILL.md

@@ -3,6 +3,7 @@ name: dx-devops-work-item-manage
 description: "Use this skill to manage the full lifecycle of DevOps Center work items — list, create, update, commit changes, perform status transitions, and create pull requests. Update fields like subject, description, and status. Commit and push code changes to work item branches. Create pull requests for work item branches via DevOps Center API. Invoke when the user wants to track, find, create, or update a work item, commit changes to a work item branch, advance a work item's status through the pipeline, or create a pull request for code review. Consolidates sf devops work-item and review operations. DO NOT TRIGGER for promotion or deployment operations, or conflict detection."
 metadata:
   version: "1.0"
+  domains: ["Developer Experience"]
   minApiVersion: "58.0"
   cliTools:
     - tool: ["sf"]

package/skills/dx-org-devhub-configure/SKILL.md

@@ -4,6 +4,7 @@ description: "Enable Dev Hub on a Salesforce org and view its scratch org alloca
 allowed-tools: Read, Bash(bash), Bash(sf api request rest), Bash(sf data query), Bash(sf org list), Bash(sf org login web), Bash(sf org login device), Bash(sf project deploy), Bash(sf config get), Bash(sf org display), Bash(sf org open), Bash(jq)
 metadata:
   version: "1.0"
+  domains: ["Developer Experience"]
   # DevHubSettings metadata + the Tooling API DevHubSettings endpoint require
   # API 47.0 or later (see scripts/devhub.sh SETTINGS_API_VERSION).
   minApiVersion: "47.0"

package/skills/dx-org-manage/SKILL.md

@@ -3,6 +3,7 @@ name: dx-org-manage
 description: "INVOKE this skill to execute Salesforce org operations: create scratch orgs, list/display/resume/delete scratch orgs, create org snapshots, open orgs in browser. This skill EXECUTES operations immediately - it does NOT generate scripts or code files. ALWAYS invoke this skill (do not execute SF CLI commands directly) when user requests to: create a scratch org (from edition, definition file (.json), snapshot, or org shape), list/display/resume/delete scratch orgs, create an org snapshot, or open a Salesforce org. Trigger phrases include: 'create a snapshot', 'take a snapshot', 'create scratch org', 'new scratch org', 'spin up an org', 'create 5 scratch orgs', 'create org from snapshot', 'scratch-def.json', 'project-scratch-def.json', 'list scratch orgs', 'display org', 'delete scratch org', 'resume scratch org', 'open my Salesforce org', 'open org in browser'. Do NOT use for switching default org (use dx-org-switch) or deploying metadata (use platform-metadata-deploy)."
 metadata:
   version: "1.2"
+  domains: ["Developer Experience"]
   minApiVersion: "60.0"
   relatedSkills:
     - "dx-org-switch"

package/skills/dx-org-permission-set-assign/SKILL.md

@@ -3,6 +3,7 @@ name: dx-org-permission-set-assign
 description: "ALWAYS USE THIS SKILL to assign permission sets to org users. Assign one or more permission sets to org users using the sf org assign permset command. TRIGGER when the user asks to assign, grant, give, add, or apply permission sets to users, admins, specific orgs, or specific users. Supports granting permissions, giving access, and adding permission sets to default admin or specific users via --on-behalf-of. DO NOT TRIGGER for listing permission sets or checking user permissions."
 metadata:
   version: "1.0"
+  domains: ["Developer Experience"]
   relatedSkills:
     - "platform-permission-set-generate"
   cliTools:

package/skills/dx-org-switch/SKILL.md

@@ -1,12 +1,12 @@
 ---
 name: dx-org-switch
 description: "Switches the active Salesforce org (default target-org) using the Salesforce CLI. Use whenever someone wants to change which org CLI commands run against — whether they say \"switch org\", \"change default org\", \"set my org to\", \"use alias\", \"point to\", or describe wanting to work against a specific org, scratch org, sandbox, or production."
-compatibility: Salesforce CLI (sf) v2+
 metadata:
   cliTools:
     - tool: ["sf"]
       semver: ">=2.0.0"
   version: "1.0"
+  domains: ["Developer Experience"]
 ---
 
 ## Steps

package/skills/dx-org-trial-expiration-check/SKILL.md

@@ -4,6 +4,7 @@ description: "Check when Salesforce orgs expire (or already expired) and what to
 allowed-tools: Read, Bash(bash), Bash(sf data query), Bash(sf org list), Bash(sf config get), Bash(jq), Bash(date)
 metadata:
   version: "2.0"
+  domains: ["Developer Experience"]
   cliTools:
     - tool: ["jq"]
       semver: ">=1.6.0"

package/skills/dx-pkg-post-install-configure/SKILL.md

@@ -3,6 +3,7 @@ name: dx-pkg-post-install-configure
 description: "Use this skill to automate managed package post-install configuration. Package-agnostic — works with any managed package (LMA, FMA, work.com, Certinia, etc.). TRIGGER when: user installs a managed package and needs post-install configuration, mentions LMA/FMA/work.com post-install setup, asks to configure permission sets/FLS/page layouts for an installed package, says 'post-install', 'package setup', 'configure LMA', 'set up FMA', 'post-install steps'. DO NOT TRIGGER for: standalone permission set assignment (use dx-org-permission-set-assign), generating permission set metadata XML (use platform-permission-set-generate), package installation, or org switching."
 metadata:
   version: "2.2"
+  domains: ["Developer Experience"]
   minApiVersion: "67.0"
   cliTools:
     - tool: ["sf"]

package/skills/experience-aura-lwc-migrate/SKILL.md

@@ -3,6 +3,7 @@ name: experience-aura-lwc-migrate
 description: "Use this skill to analyze a Salesforce Aura component bundle (.cmp, .app, .evt, .intf, Controller.js, Helper.js, Renderer.js) and produce a framework-agnostic migration blueprint (PRD.yaml / PRD.md / PRD.json) capturing public API, data requirements, slots, events, states, accessibility, styling, localization, and security posture. This is Phase 1 (analysis + PRD) only — it does NOT author or edit component code, wire adapters, or Jest tests, and does not write .html/.js/.css/.js-meta.xml. TRIGGER when the user says \"analyze this Aura component\", \"migrate Aura\", \"convert .cmp\", \"produce a migration blueprint\", \"generate a PRD for this Aura component\", or mentions aura:attribute, aura:handler, force:recordData, $Label, $Resource, component.get, cmp.find, or an input directory containing .cmp files. DO NOT TRIGGER when there is no Aura source (delegate downstream LWC authoring to experience-lwc-generate), for post-migration scoring, or for refactoring an existing modern component."
 metadata:
   version: "1.0"
+  domains: ["Experience"]
   relatedSkills:
     - experience-lwc-generate
 ---

package/skills/experience-cms-brand-apply/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: experience-cms-brand-apply
 description: "Extracts, retrieves, and applies CMS brand guidelines (voice, tone, style, colors, typography) to generated content. Use this skill ANY TIME a user request involves branding, brand voice, brand tone, brand guidelines, brand identity, brand styling, or applying a brand to content. Triggers for requests like \"apply my brand\", \"use our brand voice\", \"match our brand guidelines\", \"find my brand\", \"search for brand\", \"get brand instructions\", \"apply brand tone\". Handles the full workflow: searching for brands in Salesforce CMS, extracting brand instructions, and applying brand voice/tone/guidelines to generated content. Does not apply to media/image search (use experience-content-media-search skill), logo search, or creating new brand definitions."
-compatibility: "Requires get_brand_instructions and/or search_media_cms_channels MCP tools"
 metadata:
   version: "1.0"
+  domains: ["Experience"]
 ---
 
 # Applying CMS Brand