Why include must-match and must-not-match strings?

They turn regex generation into a test-driven task. The prompt instructs the model to build a table proving the pattern passes every example and to fix it if any case fails, which catches most hallucinated patterns.

Does it handle different regex flavors?

Yes. You choose JavaScript, Python, PCRE, Java, or Go. The prompt tells the model to use idiomatic syntax and to avoid features that flavor lacks, such as lookahead in Go's RE2 engine.

Will the regex always be correct?

Test-driven prompting greatly reduces errors but does not guarantee correctness. Always run the returned pattern against your real data before relying on it.

What edge cases does it surface?

The prompt requires the model to list at least three tricky inputs, such as Unicode characters, anchoring assumptions, or catastrophic-backtracking risks, so you understand the pattern's limits.

Does this tool run the regex?

No. It builds the prompt locally. You paste it into your LLM, which generates and explains the pattern. Test the result in your own environment.

Regex Generation Prompt Builder

Regex generation prompt builder

LLMs are notoriously confident and wrong about regular expressions — they hand back patterns that look plausible but quietly fail on the third example. The fix is test-driven prompting: give the model concrete strings that must match and must not match, and require it to prove the pattern against them. This builder assembles exactly that prompt, plus requests for an explanation and a list of edge cases.

How it works

You describe the pattern, pick a regex flavor, and list must-match and must-not-match strings. The tool builds a prompt that asks the model to return four sections: the pattern in idiomatic syntax for your flavor, a token-by-token explanation including every capture group, a test table that confirms the expected result for each of your strings (with instructions to fix and re-table if any fail), and at least three edge cases or limitations. It also warns the model away from features your flavor does not support.

Tips and notes

More test strings, fewer surprises. Add the awkward real-world inputs you actually expect — that is where naive patterns break.
Pick the right flavor. Go’s RE2 has no lookahead or backreferences; declaring the flavor stops the model from using them.
Read the edge-case section. It often reveals an assumption (like anchoring) you will want to change.
Always test for real. Test-driven prompting reduces errors but does not eliminate them — validate against production data.