regex-build

name	regex-build
description	Sanook constructs, explains, and tests regular expressions for a stated matching goal — building the pattern, generating positive/negative test cases, and validating against them, while flagging catastrophic-backtracking (ReDoS) risk.
when_to_use	User asks to write/fix/explain a regex, validate input (email/URL/slug/date), extract or replace by pattern, or debug why a pattern over/under-matches.

When to Use

Trigger this skill when the user wants to write, fix, explain, or debug a regular expression. Concrete cues:

• "write a regex that matches X" / "match a valid email|URL|slug|UUID|date|phone|hex color"
• "validate this input" / "extract all X from this text" / "replace X with Y by pattern"
• "why does my regex also match Z" (over-matching) or "why doesn't it match W" (under-matching)
• "is this regex safe / why is it slow / will this hang on big input" (ReDoS)

Do NOT use for: literal string find/replace (use a plain string op), glob/shell patterns (*.js is not regex), or SQL LIKE patterns. Redirect those to the right tool instead of forcing a regex.

Steps

1. Pin down two things before writing anything: the exact match goal and the engine flavor. Flavor changes syntax, so never assume:

   • JS (RegExp) — no \A/\Z, no possessive quantifiers, no atomic groups (pre-ES2018), lookbehind needs modern V8, named groups (?<name>...).
   • PCRE / Python re — full feature set: lookbehind, named groups (?P<name>...) in Python, atomic groups (?>...), possessive *+.
   • Go / RE2 (regexp) — linear-time, no backtracking: no lookaround, no backreferences at all. If the user needs those, RE2 cannot do it — say so and propose a split-step approach.
   • .NET — has balancing groups; rarely needed but available. If the user didn't say, ask once or infer from the surrounding code/file extension, then state the flavor you're targeting.

2. Clarify ambiguous scope with the smallest set of edge questions, not a generic "give me examples." For an "email" ask: subdomains? plus-addressing (a+b@)? unicode local part? trailing dots? For a "date" ask: which separators, zero-padded, real calendar validation or shape-only? Lock the boundary before coding — most regex bugs are spec bugs.

3. Build incrementally, not as one blob. Compose from named fragments and assemble:

   • Anchor when validating a whole string: ^...$ (JS/PCRE) — and remember $ matches before a trailing \n; use \z (PCRE/Python) or check length if a trailing newline must be rejected.
   • Default to specific character classes over . ([^@\s] beats . for an email local part). . is the #1 over-match cause.
   • Make quantifiers non-greedy (*?/+?) only when greedy genuinely over-reaches (e.g. matching <.+?> in HTML-ish text). Greedy is the correct default otherwise.
   • Escape regex metacharacters in literal segments: . ^ $ * + ? ( ) [ ] { } | \ /.
   • Use non-capturing groups (?:...) for grouping-only; reserve capture groups for values you actually extract, and name them.

4. Generate a should-match / should-NOT-match table and actually run it — do not eyeball. Build a table of ~5–10 positives and ~5–10 negatives that probe the boundaries you clarified in step 2 (empty string, leading/trailing whitespace, near-miss, unicode, max length). Run it in the target engine and show the pass/fail grid:

   • Node: node -e "const re=/.../; for(const s of [...]) console.log(re.test(s), JSON.stringify(s))"
   • Python: python3 -c "import re; ... [print(bool(re.fullmatch(p,s)), repr(s)) for s in cases]" — note fullmatch vs search vs match is itself a frequent bug; pick deliberately.
   • Go: go run a tiny regexp.MatchString loop. Every negative must return False and every positive True. If any cell is wrong, fix the pattern and re-run — never ship an unverified regex.

5. Give a token-by-token plain-language breakdown so the user can maintain it. One line per meaningful token/group. For non-trivial patterns, also provide the x/verbose (extended) form with inline comments ((?x) in PCRE/Python, or a commented build-up in JS) as the maintainable artifact.

6. Run a ReDoS check and state the verdict explicitly. Scan for the dangerous shapes:

   • Nested quantifiers: (a+)+, (a*)*, (.+)+
   • Quantified alternation with overlap: (a|a)*, (\d+|\w+)*
   • Adjacent overlapping quantifiers around an optional/repeatable seam, e.g. \s*\s*, (\w+\s?)*$ These cause exponential backtracking on a long non-matching input. If found: demonstrate the risk conceptually, then rewrite — use atomic groups (?>...) / possessive *+ (PCRE), anchor and tighten classes to remove overlap, or recommend a linear-time engine (RE2/re2) when the pattern stays untrusted-input-facing. State "ReDoS: safe" or "ReDoS: vulnerable → use " — don't leave it implicit.

7. Deliver the final artifact in the user's engine syntax, including the language-literal form (JS /.../flags, Python raw string r"...", Go backtick string) and the correct flags (i, m, s/DOTALL, u/unicode, g for global). If they need more than one flavor, give each variant separately — don't hand them a PCRE pattern to paste into JS.

Common Errors

• . over-matching. . excludes newline by default (except with s/DOTALL) but matches everything else including the very char you wanted to stop at. Replace with a negated class.
• $ and trailing newline. In most engines ^abc$ matches "abc\n". Use \z (PCRE/Python) for strict end, and remember $ is line-end under m/MULTILINE.
• Unescaped delimiter / metachar. Forgetting to escape / in a JS literal, or treating ./-/| inside a class as special when they often aren't (- is literal at class edges; . is literal inside [...]). Over-escaping inside [...] is also a smell.
• Wrong match function. re.match anchors only at start, re.search is unanchored, re.fullmatch anchors both ends — using search for validation lets "abc evil" pass. JS .test() is unanchored too; anchor the pattern.
• Greedy capture swallowing. ".*" across multiple quoted spans grabs the whole line; ".*?" or "[^"]*" is what you meant.
• \d/\w are unicode-wide. With u flag (JS) or by default (Python 3, PCRE UCP), \d can match non-ASCII digits and \w matches accented letters/underscore. Use [0-9]/[A-Za-z0-9_] when you mean ASCII.
• RE2/Go has no lookaround or backreferences — at all. A pattern that compiles in PCRE will fail to compile in Go. Don't port blindly.
• Backreference ≠ named group reference confusion across flavors (\1 vs \k<name> vs (?P=name)).
• Catastrophic backtracking shipped to prod. A regex that passes on your 10 test strings can hang for seconds/minutes on a crafted 50-char input. The test table won't catch it — the explicit ReDoS scan in step 6 is what catches it.

Verify

Before declaring done, confirm all of:

1. Every positive test case returns a match and every negative returns no match, shown as runnable output (not asserted by hand). Boundary cases (empty, whitespace-padded, near-miss, max-length, unicode) are present in the table.
2. The pattern is anchored correctly for the task (whole-string validation vs. scan/extract) and the right match function is used.
3. The ReDoS verdict is stated explicitly ("safe" or "vulnerable → rewrite given"), with no nested/overlapping quantifiers left in a shippable pattern that faces untrusted input.
4. The final artifact is in the user's actual engine flavor and language-literal form, with the correct flags listed.
5. A token-by-token (or verbose-mode) breakdown is included so the user can maintain it.