Write a regular expression

A regex specified by its accept and reject cases, so the model has something concrete to match against instead of a vague description.

When to use it

Any pattern where getting it subtly wrong is expensive — validation before a write, parsing security-relevant input, anything where a false match slips bad data through.

What it prevents

The regex that matches the examples in your head but not the ones you forgot. Specifying the accept and reject cases up front gives the model a target it can hit exactly, instead of a description it interprets loosely — and gives you a test table to check the result against.

The prompt

Write a regular expression that matches the accepted cases below and rejects the rest.

### Context
JavaScript, used with String.prototype.test. It validates an internal ticket ID before a database lookup, so a false match costs more than a false reject.

### Requirements
- Output format: A single code block with the regex, then a two-column table of each test string and whether it matches.
- Match: AC-1, AC-10432. Reject: ac-1 (lowercase), AC-, AC-01 (leading zero), XAC-1.
- Anchor the pattern to the whole string, not a substring.
- Explain each part of the pattern in one line below the table.
- Avoid: catastrophic backtracking and unnecessary capture groups.

### Rule
"""
Prefix is always uppercase AC, a hyphen, then a positive integer with no leading zero.
"""

Why each part is there

Every section of that prompt exists because a specific failure happens without it. These are the checks it passes, and what each one is protecting you from:

• States a concrete task — why this matters
• Avoids vague language — why this matters
• Specifies an output format — why this matters
• Gives context or audience — why this matters
• Avoids dangling references — why this matters
• Avoids over-aggressive phrasing — why this matters
• Defines what a good answer looks like — why this matters

How to adapt this one

Replace the accept and reject lists with your own real cases, and include the near-misses — the lowercase version, the one with a leading zero, the substring that should not match. Those edge cases are the specification. Keep the instruction to anchor the pattern and to explain each part, so you get a regex you can actually maintain rather than a write-only incantation.

The mistake this prompt avoids

Describing the pattern in prose and hoping. “Match a valid ID” means something precise to you and something vaguer to the model, and the gap is exactly the edge cases. List what must match and what must not; a regex is defined by its boundaries, and the boundaries are the cases you would otherwise leave to chance.

A variation

Need the pattern to be readable by the next person as much as correct? Ask for a commented, extended-mode regex (or a small parser instead) and a note on why a regex is or is not the right tool. Some “regex” problems are really parsing problems in disguise, and a model told to flag that will sometimes save you from a pattern nobody can ever safely change.

Check your version

Once you have adapted it, run it through the checker. The same nine checks that graded this page will grade yours, free and in your browser — paste it in, or build one from scratch by answering a few questions.