Port Semgrep Rules to New Languages

Semgrep Rule Variant Creator ports existing Semgrep rules to new target languages with proper applicability analysis and test-driven validation, for expanding rule coverage across a polyglot codebase or creating language-specific variants of a universal vulnerability pattern. It takes an existing Semgrep rule (YAML path or content) and one or more target languages, and for each applicable target language produces a directory named <original-rule-id>-<language>/ containing the ported rule YAML and a test file with ruleid/ok annotations.

Each target language runs through an independent, strict four-phase cycle that must fully complete before moving to the next language: Phase 1 Applicability Analysis determines whether the vulnerability class exists in the target language, whether an equivalent construct exists, and whether the semantics are similar enough for meaningful detection, producing a verdict of APPLICABLE, APPLICABLE_WITH_ADAPTATION, or NOT_APPLICABLE (with the reason documented if skipped); Phase 2 Test Creation writes tests before the rule, with a minimum of 2 vulnerable (ruleid:) and 2 safe (ok:) cases plus language-specific edge cases; Phase 3 Rule Creation dumps the target language's AST (semgrep --dump-ast -l <lang>), translates patterns to that language's syntax, updates the language key/message/rule ID, and adapts for language-specific idioms; Phase 4 Validation runs semgrep --validate on the YAML and semgrep --test on the rule plus test file, requiring the checkpoint output "All tests passed" - with semgrep --dataflow-traces available for debugging taint rules specifically.

The skill explicitly rejects several porting shortcuts: assuming pattern structure is identical across languages (ASTs differ, always dump the target AST); assuming the same vulnerability implies the same detection approach (data flow differs between languages, so target-language idioms must be analyzed); skipping new tests because the original rule worked (language edge cases differ, write new tests for the target); skipping applicability analysis because a pattern "obviously applies" (some vulnerability classes are language-specific); batching all language variants before testing any of them (errors compound and become hard to debug - complete the full cycle per language); assuming a library equivalent is "close enough" without verifying API semantics match; and translating syntax 1:1 without researching target-language idioms.

It defers to a companion semgrep-rule-creator skill as the authoritative reference for core rule-writing principles - taint mode vs. pattern matching selection, test-first methodology, anti-patterns, and rule optimization - since porting applies the same quality principles in a new language context rather than replacing them.

Use this skill when porting an existing Semgrep rule to one or more target languages, creating language-specific variants of a universal vulnerability pattern, or expanding rule coverage across a polyglot codebase.

Do not use it for creating a brand-new Semgrep rule from scratch (use semgrep-rule-creator instead), running existing rules against code, porting to a language where the vulnerability pattern fundamentally doesn't apply, or handling minor syntax variations within the same language.

Input: an existing Semgrep rule (YAML file or content) and a list of target languages to port it to.

Output: one rule-plus-test directory per applicable language, for example porting a SQL injection rule to Go:

// ruleid: sql-injection-golang
db.Query("SELECT * FROM users WHERE id = " + userInput)

// ok: sql-injection-golang
db.Query("SELECT * FROM users WHERE id = ?", userInput)

validated via semgrep --validate --config rule.yaml and semgrep --test --config rule.yaml test-file, requiring "All tests passed" before completion.

Security engineers maintaining Semgrep rule coverage across a multi-language codebase who need a disciplined, per-language applicability and testing process rather than assuming a rule translates cleanly across languages.