Write a regex from a description

Why this prompt works

• →Positive AND negative examples turn a vague description into a testable spec — most bad generated regex comes from prompts that only said what should match.
• →"Verify before answering" makes the model run its own pattern against your examples, which catches the majority of first-draft errors.
• →Asking for deliberate limits up front beats discovering them in production — every practical regex has them.

Part by part

It MUST match all of these

Positive examples as a specification. A description alone is ambiguous; examples pin down what was actually meant.

It must NOT match any of these

The negative set, which is what stops an overly permissive pattern passing. Most bad regexes match everything they should and much more.

Verify it against every example above before answering

Asks for the check to happen before the answer. Models produce plausible patterns that fail their own examples, and this catches a good share of it.

if the requirements conflict

Some example sets cannot be satisfied together, and saying so is far more useful than a pattern that quietly fails two of them.

Prefer a readable pattern over a maximally clever one

Optimises for the person maintaining it. A dense regex nobody can modify is a liability regardless of correctness.

Common mistakes

• Write a regex to match email addresses.

  Produces one of several conventional patterns with no way to know which edge cases it handles. Without examples you cannot tell whether it does what you need.

• Supplying only positive examples.

  The easiest pattern satisfying any set of positives is one matching almost anything. Negative examples are what constrain it, and they are the half people leave out.

• Write the most robust regex possible for this.

  Robust is read as covering every theoretical case, producing something unreadable and slow. Most tasks want a pattern handling your data, with the limits written down.

Questions