Static Analysis Toolkit

Comprehensive static code analysis framework that detects bugs, security vulnerabilities, code quality issues, and style violations without executing the code, supporting multiple languages and custom rule creation.

When to Use This Skill

Choose Static Analysis Toolkit when:

• Setting up automated code quality checks in CI/CD pipelines
• Finding bugs and security issues before code review
• Enforcing coding standards across large codebases
• Migrating between language versions (detecting deprecated patterns)
• Creating custom lint rules for project-specific conventions

Consider alternatives when:

• Need runtime behavior analysis — use dynamic analysis/profiling
• Testing business logic — use unit/integration tests
• Need type checking — use language-native type systems (TypeScript, mypy)

Quick Start

Copy
# Activate static analysis
claude skill activate precision-static-analysis-toolkit-engine

# Analyze a project
claude "Run static analysis on the src/ directory and prioritize findings"

# Create custom rules
claude "Create a custom ESLint rule to prevent direct database calls outside the repository layer"

Example Analysis Setup

Copy
# JavaScript/TypeScript - ESLint
npx eslint --init
npx eslint src/ --format json --output-file eslint-report.json

# Python - pylint + bandit (security)
pylint src/ --output-format=json > pylint-report.json
bandit -r src/ -f json -o bandit-report.json

# Go - staticcheck + golangci-lint
golangci-lint run ./... --out-format json > lint-report.json

# Rust - clippy
cargo clippy --message-format=json > clippy-report.json

# Multi-language - Semgrep
semgrep scan --config auto --json --output semgrep-report.json

Core Concepts

Analysis Categories

Category	Description	Examples
Bug Detection	Logic errors, null dereferences, race conditions	Dead code, unreachable branches, use-after-free
Security	Vulnerabilities and insecure patterns	SQL injection, XSS, hardcoded secrets, weak crypto
Code Quality	Maintainability, complexity, duplication	High cyclomatic complexity, copy-paste code, god classes
Style	Formatting, naming, conventions	Inconsistent naming, line length, import ordering
Performance	Inefficient patterns that affect runtime	N+1 queries, unnecessary allocations, blocking I/O
Type Safety	Type-related errors and unsafe casts	Any type usage, unsafe assertions, implicit conversions

Tool Selection by Language

Language	Recommended Tools	Focus
TypeScript/JS	ESLint, Biome, TypeScript strict	Types, patterns, security
Python	Ruff, mypy, Bandit	Style, types, security
Go	golangci-lint (staticcheck, gosec)	Bugs, security, performance
Rust	Clippy, cargo-audit	Correctness, idioms, deps
Java/Kotlin	SpotBugs, Detekt, SonarQube	Bugs, complexity, security
C/C++	clang-tidy, cppcheck, Coverity	Memory, undefined behavior
Multi-language	Semgrep, CodeQL, SonarQube	Security, custom rules

Copy
// Custom ESLint rule example: prevent direct DB calls outside repository layer
module.exports = {
  meta: {
    type: 'problem',
    docs: { description: 'Disallow direct database calls outside repository files' },
  },
  create(context) {
    const filename = context.getFilename();
    const isRepository = filename.includes('/repositories/') ||
                         filename.includes('/repos/');

    return {
      CallExpression(node) {
        if (isRepository) return;

        const callee = node.callee;
        if (callee.type === 'MemberExpression') {
          const objectName = callee.object.name;
          if (['db', 'prisma', 'knex', 'sequelize'].includes(objectName)) {
            context.report({
              node,
              message: `Direct database call "${objectName}" not allowed outside repository layer`,
            });
          }
        }
      },
    };
  },
};

Configuration

Parameter	Description	Default
languages	Languages to analyze	Auto-detect
severity_threshold	Minimum severity to report: error, warning, info	warning
include_style	Include style/formatting issues	false
max_complexity	Cyclomatic complexity threshold	10
custom_rules	Path to custom rule definitions	null
exclude_patterns	File patterns to exclude	["node_modules", "dist", "*.test.*"]
fix_mode	Auto-fix safe issues	false

Best Practices

1. Start strict, then relax selectively — Enable all rules initially, then disable specific rules with documented justifications. Starting permissive and trying to tighten later is much harder because existing violations create noise that masks new issues.

2. Separate blocking and advisory rules — Configure rules that indicate real bugs or security issues as errors (CI-blocking), while code quality and style suggestions are warnings (non-blocking). This prevents over-zealous linting from blocking critical deployments.

3. Use Semgrep for custom security rules — Semgrep's pattern syntax is more intuitive than AST-based rule creation. Write rules that match your specific framework patterns (e.g., detecting unvalidated user input flowing into specific function calls).

4. Run analysis incrementally on changed files — Full-project analysis on every commit is slow for large codebases. Run analysis only on changed files in PR checks, with periodic full scans scheduled nightly to catch cross-file issues.

5. Track metrics over time, not just pass/fail — Monitor total issue counts, complexity trends, and security finding categories over time. Trending metrics reveal whether code quality is improving or degrading and justify investment in tooling and refactoring.

Common Issues

Hundreds of existing violations make it impossible to enforce new rules. Use baseline files to suppress existing violations while enforcing rules on new code. ESLint supports inline suppression, Semgrep supports --baseline-commit, and most tools support ignore files. Schedule gradual cleanup of baseline violations as tech debt.

Different developers get different analysis results on the same code. Pin tool versions in package.json or CI configuration. Use editor integrations that respect the project's configuration files. Run analysis in CI as the source of truth, treating local analysis as a convenience for fast feedback.

Analysis runs are too slow for pre-commit hooks. Move full analysis to CI and run only fast, targeted checks in pre-commit. Use lint-staged to analyze only staged files. For large projects, consider running different rule sets at different stages: fast rules in pre-commit, thorough rules in CI.