AgentTools: Skill for Claude Code

Add a Custom CodeInspector Rule

Follow this workflow to implement a new code inspection rule. The rule system lives in Kernel/Tools/CodeInspector/Rules.wl with tests in Tests/CodeInspectorTool.wlt.

Step 1: Understand the Rule

$ARGUMENTS

Clarify these details (ask the user if not clear):

• What code pattern should be detected? Get an example of the problematic code.
• Why is it problematic? This becomes the inspection message.
• Severity: Fatal (code will not run, parse etc.), Error (almost certainly a mistake), Warning (likely a mistake), Remark (suggestion), Formatting (style).
• Confidence: 0.95 for highly certain rules, 0.9 for confident, 0.7-0.9 for likely.

Step 2: Choose the Rule Type

Type	When to Use	Add To
Abstract	Match simplified AST patterns (most common)	$customAbstractRules in Rules.wl
Concrete	Need whitespace/comments (e.g., comment content)	$concreteRules in Rules.wl
Aggregate	Analyze relationships between multiple AST nodes	$aggregateRules in Rules.wl
Text-level	Raw source text (line length, file size, etc.)	textLevelInspections function in Rules.wl

Step 3: Explore the AST Structure

Use the WolframLanguageEvaluator tool to parse example code and understand its AST:

Needs["CodeParser`"];
(* For abstract rules: *)
CodeParser`CodeParse["problematic code here"]
(* For concrete rules: *)
CodeParser`CodeConcreteParse["problematic code here"]

Study the output to determine which node types and patterns to match. Key node types:

• CodeParser`CallNode — function calls like f[x]
• CodeParser`LeafNode — atoms like 42, "hello", Symbol
• CodeParser`InfixNode — infix ops like a + b
• CodeParser`PrefixNode — prefix ops like -x

Note: If you want to use symbols defined in Rules.wl in the WolframLanguageEvaluator tool during your exploration, you'll need to use their fully qualified names: