Explain and Write a Regex From Plain English

This prompt builds a regular expression from a plain-English description and, crucially, grounds it in concrete should-match and should-not-match examples so the result is actually tested against your intent rather than the model's guess. It returns the pattern, a line-by-line breakdown, edge cases to test, and an honest 'maybe don't use regex' alternative, which protects you from the classic trap of using a fragile regex where a real parser belongs. Use it when you know what you want to match but writing the pattern yourself would take twenty frustrating minutes.

What you can expect back

1) Regex:
/^\d{5}(-\d{4})?$/

2) Breakdown:
- ^ and $ anchor to the whole string so partial matches are rejected
- \d{5} requires exactly five digits
- (-\d{4})? optionally allows a hyphen plus exactly four more digits

3) Edge cases to test:
- Leading/trailing whitespace (' 90210 ') — anchors will reject it; trim first if needed
- Non-ASCII digits — \d in JS matches only 0-9 by default, which is what you want here
- Empty string — correctly fails

4) Simpler alternative:
For input this structured, /^\d{5}(-\d{4})?$/ is appropriate. No need for a parser, but validate that the ZIP exists via a lookup table if correctness matters beyond format.

Illustrative example — your results will vary by tool and inputs.

Get sharper results

• 01Give as many should-NOT-match examples as should-match ones, since the negative cases (like '90210 1234' with a space) are what catch an overly permissive pattern.
• 02Always state the flavor, because a pattern that works in PCRE may need different escaping or lack lookbehind support in JavaScript, and the model tailors anchors and classes accordingly.
• 03Ask it to show the regex both with and without anchors and explain when each is right, since forgetting ^ and $ is the most common cause of false matches.
• 04Take the 'safer alternative' section seriously for things like email, HTML, or nested structures, where a regex is famously the wrong tool and a parser is more robust.
• 05Have it generate a quick test snippet in your language that runs all your examples through the pattern, so you can verify the claims rather than trusting the breakdown.

Adapt it for your case