Code Static Analysis Rules and Semgrep Patterns

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Static analysis rules and patterns let agents turn recurring code risks into repeatable checks instead of one-off review comments.

## Core Explanation

Agents can use static analysis rules to search for insecure APIs, framework anti-patterns, migration leftovers, and project-specific conventions. Rule languages such as Semgrep patterns or CodeQL queries give agents a structured way to describe what code shape should be flagged.

Rules need calibration. A rule that catches real bugs but produces too many false positives will be ignored. Agents should record examples, expected matches, expected non-matches, severity, and whether an autofix is safe.

## Source-Mapped Facts

- Semgrep documentation describes rule syntax for writing patterns that match code. ([source](https://semgrep.dev/docs/writing-rules/rule-syntax))
- CodeQL documentation describes queries as files that contain a select clause defining the query result. ([source](https://codeql.github.com/docs/writing-codeql-queries/about-codeql-queries/))
- ESLint documentation describes custom rules as plugins that can define project-specific linting behavior. ([source](https://eslint.org/docs/latest/extend/custom-rules))

## Further Reading

- [Semgrep Rule Syntax](https://semgrep.dev/docs/writing-rules/rule-syntax)
- [CodeQL Queries](https://codeql.github.com/docs/writing-codeql-queries/about-codeql-queries/)
- [ESLint Custom Rules](https://eslint.org/docs/latest/extend/custom-rules)