dx-code-analyzer-custom-rule-create

Name: dx-code-analyzer-custom-rule-create
Author: forcedotcom

1.3kinstalls272forks

How to install dx-code-analyzer-custom-rule-create?

forcedotcom/sf-skills/dx-code-analyzer-custom-rule-create

$npx -y skills add forcedotcom/sf-skills --skill dx-code-analyzer-custom-rule-create

Installs into the current project.

Summary

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 buil

Files · 1

View on GitHub

SKILL.md

1	# dx-code-analyzer-custom-rule-create: Custom Code Analyzer Rule Authoring
2
3	> 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).
4
5	Use this skill when the user needs to create a custom rule that enforces a pattern not covered by Code Analyzer's built-in rules. Supports Regex engine (text pattern matching) and PMD engine (structural XPath queries against the AST).
6
7	## When This Skill Owns the Task
8
9	Use `dx-code-analyzer-custom-rule-create` when the work involves:
10	- Creating a new custom rule for Code Analyzer (any engine)
11	- Enforcing team-specific coding standards via static analysis
12	- Banning specific patterns (System.debug, hardcoded IDs, TODOs)
13	- Writing XPath expressions for PMD rules (Apex or metadata XML)
14	- Writing regex patterns for the Regex engine
15	- Setting up custom ESLint rules/plugins for LWC/JavaScript
16	- Enforcing metadata governance (API versions, field descriptions, dangerous permissions)
17	- Overriding built-in rule thresholds (CyclomaticComplexity, ExcessiveParameterList, etc.)
18	- Organizing multiple rules into shared rulesets
19	- Iterating on a custom rule that isn't matching correctly
20
21	Delegate elsewhere when the user is:
22	- Running a scan against existing rules → `dx-code-analyzer-run` skill
23	- Configuring engines, prerequisites, CI/CD → `dx-code-analyzer-configure` skill
24	- Explaining what an existing built-in rule means → `dx-code-analyzer-run` skill
25	- Writing Apex code or tests → `generating-apex` / `running-apex-tests` skills
26
27	---
28
29	## Required Context to Gather First
30
31	Ask for or infer:
32	- What pattern to catch — what code should be flagged? (If user selected code in their IDE, the selection IS the answer — do not re-ask.)
33	- What to allow — any exceptions? (test classes, specific contexts)
34	- File scope — which file types? (.cls, .trigger, .js, all?)
35	- Severity — how critical? (default: 3/Moderate)
36
37	If the user selected code (IDE selection context present), treat it as the pattern definition. Skip clarification unless genuinely ambiguous about what aspect of the selection to target.
38
39	If the request is vague with NO selection ("add a rule for best practices"), ask ONE clarifying question:
40	> "What specific pattern should this rule flag?"
41
42	---
43
44	## Hard Constraints
45
46	These are non-negotiable rules. Violating any of them is a skill failure regardless of whether the output happens to work.
47
48	1. ALWAYS run `ast-dump` before writing XPath. No exceptions. Do not use node names from memory, references, or prior conversations. The AST is the source of truth — run `sf code-analyzer ast-dump`, read the output, then write XPath that matches what you see. Even for "well-known" patterns like SOQL-in-loop, run ast-dump first. If you skip this step and the rule works, it is still a process failure.
49
50	2. ALWAYS use the scripts to create rules. For regex rules, ALWAYS use `create-regex-rule.js`. For PMD rules, ALWAYS use `create-pmd-rule.js`. Do NOT manually edit `code-analyzer.yml` to add rule definitions — regex patterns in YAML cause escaping failures (quotes inside quotes, backslashes getting eaten). The scripts handle YAML serialization correctly every time.
51
52	3. NEVER manually edit `code-analyzer.yml` after a script writes to it — even to fix a bad value. The scripts produce correctly-escaped YAML. If you then rewrite or restructure the file, you WILL break the escaping. If the user added top-level config (like `ignores.files`), leave it alone too — only touch what you wrote.
53
54	If a script's output looks wrong (rule fails to validate, YAML parse error, stray characters in the regex):
55	- DO N

People who liked this also viewed

6 picks

Type

dx-code-analyzer-custom-rule-create

1.3kinstalls272forks

View on GitHub

How to install dx-code-analyzer-custom-rule-create?

forcedotcom/sf-skills/dx-code-analyzer-custom-rule-create

$npx -y skills add forcedotcom/sf-skills --skill dx-code-analyzer-custom-rule-create

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# dx-code-analyzer-custom-rule-create: Custom Code Analyzer Rule Authoring
2
3	> 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).
4
5	Use this skill when the user needs to create a custom rule that enforces a pattern not covered by Code Analyzer's built-in rules. Supports Regex engine (text pattern matching) and PMD engine (structural XPath queries against the AST).
6
7	## When This Skill Owns the Task
8
9	Use `dx-code-analyzer-custom-rule-create` when the work involves:
10	- Creating a new custom rule for Code Analyzer (any engine)
11	- Enforcing team-specific coding standards via static analysis
12	- Banning specific patterns (System.debug, hardcoded IDs, TODOs)
13	- Writing XPath expressions for PMD rules (Apex or metadata XML)
14	- Writing regex patterns for the Regex engine
15	- Setting up custom ESLint rules/plugins for LWC/JavaScript
16	- Enforcing metadata governance (API versions, field descriptions, dangerous permissions)
17	- Overriding built-in rule thresholds (CyclomaticComplexity, ExcessiveParameterList, etc.)
18	- Organizing multiple rules into shared rulesets
19	- Iterating on a custom rule that isn't matching correctly
20
21	Delegate elsewhere when the user is:
22	- Running a scan against existing rules → `dx-code-analyzer-run` skill
23	- Configuring engines, prerequisites, CI/CD → `dx-code-analyzer-configure` skill
24	- Explaining what an existing built-in rule means → `dx-code-analyzer-run` skill
25	- Writing Apex code or tests → `generating-apex` / `running-apex-tests` skills
26
27	---
28
29	## Required Context to Gather First
30
31	Ask for or infer:
32	- What pattern to catch — what code should be flagged? (If user selected code in their IDE, the selection IS the answer — do not re-ask.)
33	- What to allow — any exceptions? (test classes, specific contexts)
34	- File scope — which file types? (.cls, .trigger, .js, all?)
35	- Severity — how critical? (default: 3/Moderate)
36
37	If the user selected code (IDE selection context present), treat it as the pattern definition. Skip clarification unless genuinely ambiguous about what aspect of the selection to target.
38
39	If the request is vague with NO selection ("add a rule for best practices"), ask ONE clarifying question:
40	> "What specific pattern should this rule flag?"
41
42	---
43
44	## Hard Constraints
45
46	These are non-negotiable rules. Violating any of them is a skill failure regardless of whether the output happens to work.
47
48	1. ALWAYS run `ast-dump` before writing XPath. No exceptions. Do not use node names from memory, references, or prior conversations. The AST is the source of truth — run `sf code-analyzer ast-dump`, read the output, then write XPath that matches what you see. Even for "well-known" patterns like SOQL-in-loop, run ast-dump first. If you skip this step and the rule works, it is still a process failure.
49
50	2. ALWAYS use the scripts to create rules. For regex rules, ALWAYS use `create-regex-rule.js`. For PMD rules, ALWAYS use `create-pmd-rule.js`. Do NOT manually edit `code-analyzer.yml` to add rule definitions — regex patterns in YAML cause escaping failures (quotes inside quotes, backslashes getting eaten). The scripts handle YAML serialization correctly every time.
51
52	3. NEVER manually edit `code-analyzer.yml` after a script writes to it — even to fix a bad value. The scripts produce correctly-escaped YAML. If you then rewrite or restructure the file, you WILL break the escaping. If the user added top-level config (like `ignores.files`), leave it alone too — only touch what you wrote.
53
54	If a script's output looks wrong (rule fails to validate, YAML parse error, stray characters in the regex):
55	- DO N

People who liked this also viewed

6 picks

Type