The prompt
Score 10 of 10, Excellent
Use it when You need a pattern to find, check or pull out text, and want it explained and tested against strings that should and should not match.
- {{reader}}
- {{language}}
- {{goal}}
- {{should_match}}
- {{should_not_match}}
- {{flavor}}
Full prompt and why it works
Prompt
Write a regular expression for the job below, for {{reader}} to paste into {{language}} and understand well enough to change later. What it must do: {{goal}} Strings it must match, with what to capture from each, if anything: """ {{should_match}} """ Strings it must not match: """ {{should_not_match}} """ Regex flavor and where it runs: {{flavor}} Produce: 1. The pattern on its own line in a code block, exactly as it goes in the code, with any flags. 2. A breakdown: each part of the pattern on its own line, next to a plain description of what it matches. 3. A test table with the columns String, Should match, Does match, Captured, covering every string above plus up to 6 edge cases you add, such as an empty string, extra spaces, mixed case or a very long input. Mark the edge cases you added. 4. A short snippet in {{language}} that runs the pattern against all the test strings, so I can confirm the table myself. Keep the pattern as simple as the examples allow, and prefer a readable pattern over a clever one. Say so if a plain string method or a real parser would do the job better, for example for HTML, nested brackets or full email address validation, where a regular expression is the wrong tool. For example, the form of one breakdown line: "\d{4} matches exactly four digits, the year." A good answer is one I can check line by line against the test table. Avoid nested quantifiers such as (a+)+ that can run for a very long time on some inputs, and point out any part that could be slow on long strings. Use only syntax that {{flavor}} supports; lookbehind, named groups and Unicode classes differ between flavors, so say which of these you used. If the examples conflict or leave a case open, such as whether a trailing period counts, list the question and the choice you made instead of deciding silently. Do not claim a string matches unless you have traced it through the pattern; if you cannot be sure, write "check" in the Does match column.
Variables
- {{reader}}
- Who will maintain the code, for example "me" or "the team that owns the import job".
- {{language}}
- The language or tool it goes into, for example Python, JavaScript or a Google Sheets formula.
- {{goal}}
- What the pattern must do, for example "pull the order number out of email subject lines" or "check a field is a US ZIP code, with or without the four-digit extension".
- {{should_match}}
- Real strings that must match, one per line, with what to capture from each if anything.
- {{should_not_match}}
- Real strings that must not match, one per line. Near misses are the most useful.
- {{flavor}}
- The regex engine, for example "Python re", "JavaScript in the browser", "grep -E on macOS" or "Google Sheets (RE2)".
Why it works
- An example. Strings that must and must not match are the specification, and the test table checks the pattern against every one of them plus labeled edge cases.
- What to avoid. Nested quantifiers that can hang on long input are ruled out, and the model must say when a regex is the wrong tool, as it is for HTML.
- If unsure. Cases the examples leave open become listed questions, and a match the model cannot trace is marked "check", so the table never claims more than it knows.