Regex prompts for ChatGPT, Claude and Codex

These 13 regex prompts help ChatGPT, Claude, Claude Code and Codex write, explain, test and debug regular expressions in JavaScript, Python, Go, PCRE and grep. They cover patterns inferred from real data, named groups, find and replace, readable verbose patterns, test tables, porting between flavors and catastrophic backtracking.

For the basic "write a regex from match and no-match examples" prompt, see the coding prompts collection. The prompts below handle the rest of the job.

How to use these prompts

Copy a prompt into ChatGPT, Claude, Claude Code or Codex and fill the blanks in double braces. A blank with a colon has a default: {{flavor:JavaScript}} means JavaScript unless you change it.

Always name the flavor. JavaScript, Python, Go, Java, .NET, PCRE and POSIX grep all disagree on details. Go, for example, uses RE2 syntax, which does not support backreferences or lookahead, and the Go regexp package guarantees matching in time linear in the size of the input. A pattern that works in one engine can fail to compile, or quietly match something else, in another.

Give real examples. Ten real lines from your log file beat any description. Include the awkward cases you already know about: empty values, unicode, extra spaces, very long input.

Ask for a test every time. A regex looks right until you run it. The prompts below ask for a runnable test so you can see every example pass or fail.

How do you write a regex with AI?

1. Infer a pattern from real data

When you have sample data but no clear rule. The model finds the rule and tells you where it had to guess.

Here are real samples of {{what:order IDs from our logs}}:

{{samples}}

Infer the format and write a {{flavor:JavaScript}} regex that matches all of
them. Then:
- Describe the format in plain words
- List the parts where the samples were ambiguous and the choice you made
- Give five strings that look similar but should NOT match, and confirm the
  regex rejects them

2. Extract fields with named groups

Named groups make the code that uses the match readable and survive changes to the pattern.

Write a {{flavor:Python}} regex that extracts {{fields:timestamp, level, request ID and message}} from lines like these:

{{sample_lines}}

Use named groups for each field. Show the code that runs it over a file and
returns a list of dicts. Explain how lines that don't match are handled, and
point out any field whose format varies across the samples.

3. Validate input without over-matching

Validation regexes fail in two ways: missing anchors, so junk passes, or being so strict that real users get rejected.

Write a {{flavor:JavaScript}} regex to validate {{input:a UK postcode}} in a
form field.

Requirements: {{requirements:allow lowercase and an optional space, reject everything else}}

Make sure it matches the whole value, not a substring. Show valid inputs
real users type that a stricter pattern would wrongly reject, and invalid
inputs a looser pattern would wrongly accept. Say whether a regex is
enough here or whether part of the check belongs in code.

4. Find and replace with capture groups

For bulk edits in an editor, sed or a script. Replacement syntax differs by tool, so the prompt names it.

I need to change text across many files in {{tool:VS Code search and replace}}.

Before: {{before_example}}
After: {{after_example}}

Write the search regex and the replacement string for {{tool:VS Code search and replace}}, using capture groups to keep the parts that don't change.
Show three more before and after pairs from the same pattern to prove it
works, and one case where it would change something it shouldn't.

How do you understand an existing regex?

5. Explain a regex token by token

For the pattern you found in old code and are afraid to touch.

Explain this {{flavor:JavaScript}} regex:

{{regex}}

1. One sentence on what it is meant to match.
2. A table: each token or group, what it matches, and why it's there.
3. What the flags do.
4. Three strings that match, and three that nearly match but don't, with the
   reason each fails.
5. Any bug or edge case it gets wrong.

6. Rewrite a regex so people can read it

Long patterns become maintainable when they're split into named, commented parts. Python's re module supports this with the VERBOSE flag, which ignores whitespace and allows comments.

Rewrite this regex so the next developer can read and change it:

{{regex}}

Language: {{language:Python}}

Use verbose mode with comments if the language supports it. If not, build
the pattern from named string constants. Keep behavior identical, and add a
test that runs the old and new pattern against the same inputs and asserts
the results are equal.

How do you test a regex?

7. Build a table of edge cases

Before trusting a pattern, see what it does with the inputs you didn't think of.

Here is a regex for {{purpose:matching semantic version numbers}}:

{{regex}}

Generate a table of 25 test inputs that probe the edges: empty string,
leading or trailing spaces, unicode look-alike characters, very long input,
partial matches inside longer text, line breaks and each optional part
present or missing. For each input give the expected result based on the
purpose, the actual result of the regex, and flag every mismatch.

8. Write a test file for a regex

Lock a pattern down so a future edit can't break it silently.

Write a {{framework:Vitest}} test file for this regex:

{{regex}}

It should match: {{should_match}}
It should not match: {{should_not_match}}

Use a table-driven test so adding a case is one line. If the regex captures
groups, assert the captured values too, not just whether it matched. Add any
edge case you think is missing and mark it as your addition.

How do you debug a regex that doesn't work?

9. Find why a regex doesn't match

Paste the exact input. Invisible characters, line endings and escaping are behind many of these bugs.

This {{flavor:JavaScript}} regex doesn't do what I expect.

Regex (exactly as it appears in my code, including quotes):
{{regex_in_code}}

Input: {{input}}
Expected: {{expected}}
Actual: {{actual}}

Find the cause. Check escaping in the string literal, flags (global,
multiline, dotall, unicode), anchors, greedy versus lazy quantifiers,
line endings and invisible characters. Show the fixed regex and why it
works.

10. Check a regex for catastrophic backtracking

OWASP's page on ReDoS shows how patterns like (a+)+$ can hang a backtracking engine on crafted input. Run this on any regex that sees user input.

Check this {{flavor:JavaScript}} regex for catastrophic backtracking
(ReDoS). It runs on {{input_source:user-submitted form text}} on our server.

{{regex}}

1. Is it vulnerable? Point to the nested or overlapping quantifiers if so.
2. Give an input that makes it slow and explain why.
3. Rewrite it to match the same strings without the risk, and prove they
   match the same test inputs.
4. Suggest a length limit or a linear-time engine if a rewrite isn't
   possible.

11. Port a regex between flavors

For moving validation from the frontend to the backend, or a grep command into code.

Convert this regex from {{from:Python}} to {{to:Go}}:

{{regex}}

List every feature it uses that {{to:Go}} doesn't support or treats
differently (lookarounds, backreferences, named group syntax, possessive
quantifiers, unicode classes, flag syntax). For each, give the closest
equivalent or show how to do that part in code instead. Then give a test in
{{to:Go}} with the same inputs and expected results as the original.

12. Handle multiline and unicode text

Line anchors, dots and character classes behave differently on multiline and non-English text.

My {{flavor:JavaScript}} regex works on single lines of English text but
breaks on {{problem:multiline input and names with accents}}.

Regex: {{regex}}
Sample input: {{input}}

Explain how ^, $, . and \w behave here with the current flags, and which
flags or classes fix it (for example multiline, dotall, unicode, or Unicode
property escapes like \p{L}). Show the corrected regex and test it on the
sample.

13. Decide whether it should be a regex at all

Some jobs only look like regex jobs. HTML, JSON, CSV with quoted commas and nested structures need a parser.

I'm about to use a regex to {{task:pull links out of HTML emails}}.

Sample input: {{input}}

Tell me honestly whether a regex is the right tool. If not, show the parser
or library call in {{language:Python}} that does it correctly, and the input
that would break the regex version. If a regex is fine, write it with a
test.

How do you reuse a regex workflow?

The explain prompt and the ReDoS check are worth running every time you meet a pattern in code review. Turn them into a skill and the agent will apply them whenever it sees a regex. Paste one into the SKILL.md generator to get a valid SKILL.md. For writing the tests around a pattern, see the unit test prompts; for input validation in a broader security pass, see the security review prompts.

To keep these prompts one search away, save them in Kipt. Each prompt lives as Markdown in a private GitHub repo you own, the {{flavor:JavaScript}} style blanks stay fillable, and Cmd+K finds one by name or tag.