Engineering

Explain a Regex

Build a prompt that breaks a regular expression down piece by piece in plain language — what it matches, what each part does, and what it rejects.

Open in Code Explanation Prompt

Overview

A regex is the code people most often paste and least often understand. This builds a prompt that explains one the way a patient teacher would: what it matches overall, then each token broken down, with concrete examples of strings it accepts and rejects — terminology defined on first use for a developer still building their pattern vocabulary. The example loads an email-validation regex. Open it in the Code Explanation Prompt and paste your own pattern.

How to use this resource

Open the example in the tool

It loads with realistic inputs already filled in.
Swap in your own details

Adjust the inputs and options to match your case.
Generate and copy

Produce the output and paste it where you need it.

Why This Works

A regex is dense and unforgiving — a part-by-part breakdown is exactly what understanding it requires
Beginner framing defines each token on first use instead of assuming pattern fluency
Concrete accept/reject examples turn an abstract pattern into something you can verify

Best for

Understanding a regex you inherited or found
Learning what each part of a pattern does
Checking what a regex accepts and rejects

Not for

Writing a new regex from scratch
Debugging why a regex fails at runtime — use the Debugging Prompt Generator

FAQ

How do I use this to explain my own regex instead of the email validation pattern?

Open the preset in the Code Explanation Prompt and replace the loaded pattern ^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$ inside the CODE CONTEXT block with your own regex, then edit the 'System context' line so it names where your pattern actually runs. The tool rebuilds the prompt around your pattern; you copy it and run it in your assistant.

Can this prompt tell me why my regex fails to match certain strings at runtime?

It will not diagnose runtime failures. The NON-GOALS section states 'Do not debug failures — explain the behavior that exists without diagnosing it,' so the generated prompt explains what the pattern accepts and rejects rather than troubleshooting a bug. For failing matches, the notFor list redirects you to the Debugging Prompt Generator instead.

Are the accept and reject examples this prompt produces guaranteed correct?

They are not automatically verified. The EXECUTION FLOW section tells the assistant to pick example values and follow them through every step, but NewPrompt does not run the regex or check those examples. Run the generated prompt in your assistant and confirm the accept and reject cases against a real regex tester before trusting them.

Customize This Resource

Opens this setup in Code Explanation Prompt. Generate to get the full understanding contract — then adjust the mode, audience, and depth.

Open in Code Explanation Prompt

Prompt Template

Copy it as-is, or use Open in Code Explanation Prompt to load it pre-filled and customize it with your own context.

EXPLANATION OBJECTIVE
Explain what this regular expression matches, and break down what each part does.
Explanation mode: beginner friendly — teach the code, the terminology, and the reasoning, with concrete examples.
The goal is understanding, not judgment: explain what this code does and why it is built this way — and clearly separate what the code shows from what you infer.

CODE CONTEXT
System context: A validation pattern used on a signup form's email field.
Code to explain:
```
^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$
```

AUDIENCE PROFILE
Audience: a junior developer — fluent in basic syntax, still building a pattern vocabulary.
- Assume: basic language syntax is known; design patterns, idioms, and domain terms are not.
- Define every term of art on first use, in one sentence, in plain words.
- Prefer concrete examples over abstract descriptions — show a real value flowing through the code.

EXPLANATION STRATEGY
1. Teach, don't narrate: every explanation answers "why", not just "what".
2. Introduce one concept at a time; never use a term before defining it in plain words.
3. Anchor every abstraction in a concrete example with real values.
4. Simplify the reasoning without falsifying it — say "simplified" when simplifying, and note what the full story adds.
- Depth: detailed explanation — thorough coverage of behavior and structure.
- Cover every section of this contract with real content — no skipped or token sections.
- Go as deep as the code requires, but no deeper: detail serves understanding, not completeness theater.

KEY CONCEPTS
- Maintain a small glossary as you go: each new term gets a one-line plain-language definition the first time it appears.
- Order concepts by how load-bearing they are for understanding this code — not by where they appear in the file.

EXECUTION FLOW
- Walk the code with a concrete scenario: pick example values and follow them through every step, showing what each line does to them.
- Where the flow depends on state or configuration, say which, and what each setting changes.

DESIGN DECISIONS
- Explain the code's choices as lessons: what general principle each choice illustrates.
- Discuss only decisions actually visible in the code; rationale you cannot evidence belongs under ASSUMPTIONS, labeled as inference.

ASSUMPTIONS
- Separate what the code DOES (verifiable from the source) from why it might be that way (inference).
- Label every statement about intent, history, or rationale as an INFERENCE unless the code itself evidences it — a comment, a test, a telling name.
- Where behavior cannot be determined from the provided code, say "cannot be determined from this code" — never fill the gap with a plausible story.

TRADEOFFS
- Identify the tradeoffs this code embodies: what it optimizes for, and what it sacrifices for that.
- Tie each tradeoff to its visible consequence in the code.

LEARNING NOTES
- End with three short "what you learned" takeaways and one suggested exercise to confirm the understanding.

NON-GOALS
- Do not review code quality — no findings, no severities, no verdicts.
- Do not debug failures — explain the behavior that exists without diagnosing it.
- Do not refactor the code or propose rewrites.
- Do not generate tests.
- Do not invent requirements or unstated intentions.
- If something looks defective, note it as a question for the team — investigating or fixing it is out of scope.
- Clearly separate facts from assumptions throughout.

OUTPUT REQUIREMENTS
- Structure the explanation with headings that mirror the sections above — a reader should be able to navigate it without reading all of it.
- Anchor every claim about behavior in the code: name the function, branch, or line it comes from when precision matters.
- Calibrate every section to the stated audience — too basic wastes their time, too advanced loses them.
- End with the open questions: what could not be determined from the provided code, and who or what could answer it.

More resources from Code Explanation Prompt

Resource

Explain Code Prompt — the Understanding Contract

"Explain this code" gets line-by-line narration. The understanding contract gets strategy, audience-fit, design decisions, and inference labeled as inference.

Prompt Engineering

Resource

Legacy Code Analysis — Likely Intent, Hidden Assumptions

For code whose authors are gone: reconstruct likely intent as labeled inference, hunt undocumented assumptions, and end with a maintenance brief — what's safe to touch.

Prompt Engineering

Resource

Algorithm Explanation Prompt — Idea, Steps, Complexity, Tradeoffs

Explain the idea before the implementation: numbered steps with their contribution, honest best/worst-case complexity, and the alternatives each decision point rejected.

Prompt Engineering

Resources that pair well

Resource

Code Review Prompt — the Review Contract

"Review this code" gets shallow comments. The review contract gets findings with severities, a checklist, and a verdict.

Prompt Engineering

Resource

Refactor Prompt — the Behavior Preservation Contract

"Refactor this code" invites silent behavior changes. The refactoring contract preserves business rules, outputs, and side effects — and flags uncertainty instead of deciding it.

Prompt Engineering

Resource

Debugging Prompt — the Investigation Contract

"Fix this error" gets guesses. The investigation contract gets a ten-stage diagnosis: facts separated from assumptions, alternatives weighed, fixes justified.

Prompt Engineering

Related tools

Tool

Code Explanation Prompt

Build code explanation prompts — mode, audience, and depth turn into an understanding contract that teaches, not narrates.

Coding Workflows

Tip: Save time by exploring related resources and tools that integrate with this resource.