Create Production-Quality Semgrep Rules

Semgrep Rule Creator guides writing production-quality Semgrep rules with mandatory testing and validation, iterating through problem analysis, test-first authoring, AST inspection, rule writing, and iteration until all tests pass before any optimization.

Use this for writing Semgrep rules targeting specific bug patterns, security vulnerabilities, data-flow issues via taint mode, or coding-standard enforcement. Do not use it for running existing Semgrep rulesets or general static analysis without custom rules - that is the separate static-analysis skill's job.

It enforces a strict workflow that will not skip steps: read the official Semgrep documentation first, write tests before the rule and never skip this, require 100% of tests to pass rather than "most," optimize only after all tests pass, keep patterns specific rather than generic, prefer taint mode for data-flow vulnerabilities, put exactly one rule per YAML file, avoid languages: generic when targeting a specific language, and never use the todoruleid/todook test annotations meant for deferred rule work. The seven-step checklist: analyze the problem, write tests first, analyze AST structure, write the rule, iterate with semgrep --test until all tests pass, optimize by removing redundancies and re-testing, then a final run. Output is exactly two files in a directory named after the rule ID: <rule-id>.yaml (the rule) and <rule-id>.<ext> (a test file using ruleid/ok annotations for vulnerable and safe cases respectively). A minimal taint-mode example:

rules:
  - id: insecure-eval
    languages: [python]
    severity: HIGH
    message: User input passed to eval() allows code execution
    mode: taint
    pattern-sources:
      - pattern: request.args.get(...)
    pattern-sinks:
      - pattern: eval(...)

It weighs two rule-writing approaches: taint mode, prioritized for data-flow issues since it tracks whether untrusted input actually reaches a dangerous sink, dramatically cutting false positives on injection bugs that plain pattern matching would flag on any safe usage too, and pattern matching for simple syntactic cases with no data-flow requirement - switching between the two mid-task is expected if one isn't working well. It rejects six common shortcuts, such as treating "the pattern looks complete" as sufficient without running semgrep --test, assuming matching the vulnerable case is enough without also verifying safe cases don't match, and optimizing patterns before all tests pass. Before writing any rule it requires fetching Semgrep's official rule-syntax, pattern-syntax, testing-handbook, and data-flow documentation via WebFetch.

Developers and security engineers writing custom Semgrep rules for vulnerability detection or coding-standard enforcement who need a disciplined, test-first process that catches both false negatives, meaning missed vulnerabilities, and false positives, meaning safe code incorrectly flagged, before a rule ships.