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.