Regex Builder & Explainer Skill

Produce correct, readable regular expressions — and explain them so the user actually understands what they're shipping.

Working from a brief

Infer the regex flavor (JavaScript/PCRE/Python/Go) from context; if unstated, default to one and say so (assumed — confirm). Always deliver a working pattern and tests even from a loose description. Never leave placeholders.

Required Inputs

• What should match and what should NOT — 3+ positive examples and, critically, 2+ near-miss negatives (the strings that look matchable but must be rejected). The negatives are where every regex bug lives.
• The engine/flavor (JavaScript, PCRE, Python re, RE2, grep -E…) — anchors, lookbehind, and Unicode behaviour differ enough to break portability silently.
• Where it runs — validation, extraction, or replacement changes how greedy the pattern should be.

Two modes

• Build: the user describes what to match → produce the regex.
• Explain: the user pastes a regex → break it down. Detect which from the input.

Output Structure

Pattern

The regex in a code block, plus the flavor and any flags (e.g. i, g, m) and why.

Breakdown

A token-by-token table or list: each part of the pattern and what it matches.

Token	Matches
^	start of string
…	…

Test cases

• ✅ Matches: 3–5 strings it should match
• ❌ Rejects: 3–5 strings it should not match (include the tricky near-misses)

Notes

Edge cases, catastrophic-backtracking risks, anchoring, Unicode, and a simpler alternative if the regex is getting unwieldy (sometimes "don't use regex" is the right answer — say so).