Use this skill when writing regular expressions, debugging pattern matching, optimizing regex performance, or implementing text validation. Triggers on regex, regular expressions, pattern matching, lookahead, lookbehind, named groups, capture groups, backreferences, and any task requiring text pattern matching.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Use this skill when writing regular expressions, debugging pattern matching, optimizing regex performance, or implementing text validation. Triggers on regex, regular expressions, pattern matching, lookahead, lookbehind, named groups, capture groups, backreferences, and any task requiring text pattern matching.
When this skill is activated, always start your first response with the 🧢 emoji.
Regex Mastery
Regular expressions are a compact language for describing text patterns, built into
virtually every programming language and text processing tool. They power input
validation, log parsing, data extraction, search-and-replace, and tokenization.
Used well, a single regex can replace dozens of lines of string manipulation code.
Used poorly, they become unreadable traps and can grind a server to a halt via
catastrophic backtracking.
When to use this skill
Trigger this skill when the user:
Asks to write or explain a regular expression
Wants to validate input format (email, URL, phone number, date, credit card)
Needs to extract data from structured or semi-structured text (logs, CSV, HTML)
Uses regex terminology: lookahead, lookbehind, named group, capture group, backreference
Wants to debug a pattern that isn't matching as expected
Asks about regex flags (i, g, m, s, u, x)
Needs to replace text using capture groups or back-references
Do NOT trigger this skill for:
Full HTML/XML parsing (use a proper parser like DOMParser or BeautifulSoup instead)
Complex natural language processing where ML models are a better fit
Key principles
Readability over cleverness - A regex that nobody can maintain is worse than
a slightly longer explicit approach. Break complex patterns into commented steps
or use the verbose (x) flag where supported. A named group costs nothing but
pays dividends every time someone reads the pattern.
Use named capture groups - (?<year>\d{4}) is self-documenting and immune
to positional breakage when the pattern changes. Always prefer named groups over
numbered groups for any regex that will be read or maintained by humans.
Test edge cases relentlessly - Empty string, Unicode characters, very long
input, malformed-but-close input (e.g., foo@bar for email), and adversarial
input designed to trigger backtracking. A regex that passes your happy path but
fails on a Unicode em-dash will cause production incidents.
Avoid catastrophic backtracking - Nested quantifiers ((a+)+) and overlapping
alternatives ((a|ab)+) cause exponential backtracking on non-matching input.
Use atomic groups or possessive quantifiers where available, or restructure
alternation so choices are mutually exclusive.
Use the right tool - Regex is not always the answer. Parsing emails to RFC 5321
compliance requires a full parser. Parsing JSON, HTML, or XML requires a DOM/SAX
parser. If a regex exceeds ~80 characters or requires >2 levels of nesting, pause
and ask whether a small state machine or parser would be clearer.
Core concepts
Greedy vs lazy quantifiers - *, +, ?, and {n,m} are greedy by default:
they match as much as possible while still allowing the overall pattern to succeed.
Add ? to make them lazy (*?, +?): they match as little as possible. In
<.+> matching <b>text</b>, greedy gives the whole string; lazy <.+?> gives
just <b>.
Backtracking engine - Most regex engines (NFA-based: JS, Python, Java, .NET,
PCRE) work by trying a path and backing up when it fails. The cost of a failed match
can be exponential if quantifiers are nested and the pattern allows too many
overlapping interpretations. POSIX (DFA-based) engines don't backtrack but lack
lookaheads and backreferences.
Character classes - [abc] matches any one of a, b, c. [^abc] is the negation.
Shorthand classes: \d (digit), \w (word char), \s (whitespace), \D, \W,
\S (their negations). The . metacharacter matches any character except newline
(unless the s/dotall flag is set). Always prefer \d over [0-9] for clarity,
and [^\n] over . when you mean "not newline".
Anchors - ^ and $ match start/end of string (or line with the m flag).
\b is a word boundary (zero-width). \A, \Z are absolute start/end of string
in Python (unaffected by multiline mode). Use anchors aggressively - an unanchored
pattern can match anywhere in the string, which is often not what you want.
Groups and alternation - (abc) is a capturing group; (?:abc) is
non-capturing (slightly faster, doesn't pollute $1/match.groups). Named groups:
(?<name>abc) in JS/Python/PCRE. Alternation a|b is left-to-right and short-circuits
put the most common or most specific branch first. Backreferences \1 or \k<name>
match the same text captured by a group.
Common tasks
Validate an email address (basic)
A practical email regex that catches most invalid formats without attempting full
RFC compliance (which would require a 6553-character pattern).
Never use regex alone as the authoritative email validator in security-sensitive
code. Always send a confirmation link. The only true validator is delivery.
Prefer the native URL constructor in JS/Node.js over regex for URL validation.
It handles edge cases like IPv6, IDN hostnames, and percent-encoded paths correctly.
Validate a phone number (E.164 format)
// E.164: +[country code][subscriber number], 7-15 digits totalconst e164Regex = /^\+[1-9]\d{6,14}$/// North American (NANP) with flexible formattingconst nanpRegex = /^(\+1[-.\s]?)?(\(?\d{3}\)?[-.\s]?)?\d{3}[-.\s]?\d{4}$/
e164Regex.test('+14155552671') // true
e164Regex.test('4155552671') // false (no + prefix)
nanpRegex.test('(415) 555-2671') // true
nanpRegex.test('415.555.2671') // true
Extract data with named capture groups
Named groups make extraction code self-documenting and resilient to group reordering.
Lookarounds are zero-width assertions - they check context without consuming characters.
// Positive lookahead: password must contain a digitconst hasDigit = /(?=.*\d)/// Negative lookahead: word not followed by "(deprecated)"const notDeprecated = /\bfoo\b(?!\s*\(deprecated\))/// Positive lookbehind: price value preceded by $const priceRegex = /(?<=\$)\d+(?:\.\d{2})?/g'Total: $49.99 and $5.00'.match(priceRegex) // ['49.99', '5.00']// Negative lookbehind: "port" not preceded by "trans"const portNotTransport = /(?<!trans)port/gi
Lookbehind ((?<=...) and (?<!...)) is supported in V8 (Node.js/Chrome),
.NET, and Python 3.1+, but NOT in Safari < 16.4 or older PCRE. Check target
environment before using.
Replace with capture groups
Use $1 / $<name> in the replacement string to insert captured text.
// Reformat date from MM/DD/YYYY to YYYY-MM-DDconst date = '03/14/2026'const reformatted = date.replace(
/^(?<month>\d{2})\/(?<day>\d{2})\/(?<year>\d{4})$/,
'$<year>-$<month>-$<day>'
)
// '2026-03-14'// Wrap all @mentions in an anchor tagconst text = 'Hello @alice and @bob'const linked = text.replace(/@(\w+)/g, '<a href="/user/$1">@$1</a>')
// 'Hello <a href="/user/alice">@alice</a> and <a href="/user/bob">@bob</a>'
Avoid catastrophic backtracking
The classic trap: alternation inside a repeated group where alternatives overlap.
// DANGEROUS - exponential time on non-matching inputconst bad = /^(a+)+$/
bad.test('aaaaaaaaaaaaaaaaaaaaaaab') // hangs// SAFE - remove the nested quantifierconst good = /^a+$/
good.test('aaaaaaaaaaaaaaaaaaaaaaab') // instant false// SAFE alternative using atomic-group emulation via possessive quantifier (PCRE)// In JS, restructure so the branches are mutually exclusive:const safe = /^(?:a|b)+$/// fine because a and b can't both match the same char
Any time you write (x+)+, (x|y)+ where x and y can match the same char, or
deeply nested quantifiers, stop and test with a 30-character non-matching string.
If it hangs, restructure.
Parse structured text (log lines)
Use exec in a loop with the g flag to iterate over all matches.
JavaScript requires the u flag for correct Unicode handling. The v flag (ES2024)
adds set notation and string properties.
// WITHOUT u flag - counts UTF-16 code units, breaks on emoji
/^.{3}$/.test('a😀b') // false (emoji is 2 code units, pattern sees 4 chars)// WITH u flag - counts Unicode code points correctly
/^.{3}$/u.test('a😀b') // true// Match any Unicode letter (requires u or v flag)const wordChars = /[\p{L}\p{N}_]+/u// Match emojiconst emoji = /\p{Emoji_Presentation}/gu// Named Unicode blocksconst cyrillicWord = /^\p{Script=Cyrillic}+$/u
cyrillicWord.test('Привет') // true
Anti-patterns / common mistakes
Mistake
Why it's wrong
What to do instead
Unanchored validation pattern
/\d+/ matches the digits inside "abc123def", so test() returns true for invalid input
Always add ^ and $ anchors for validation patterns
Numbered groups in maintained code
match[3] breaks silently when a group is added
Use named groups: match.groups.year
Using . to mean "any character"
. matches everything except newline; bugs appear on multiline input
Use [\s\S] or set the s (dotAll) flag when newlines should match
Greedy .* in the middle of a pattern
"<b>one</b><b>two</b>".match(/<b>.*<\/b>/) returns the whole string
Use lazy .*? or a negated class [^<]* when bounded by a delimiter
Rebuilding the same regex in a loop
new RegExp(pattern) inside a for loop re-compiles on every iteration
Hoist the regex to a constant outside the loop
Parsing HTML/XML with regex
Fails on nested tags, self-closing tags, CDATA, and valid edge cases
Use DOMParser, jsdom, BeautifulSoup, or an XML library
Gotchas
Lookbehind not supported in Safari < 16.4 - (?<=...) and (?<!...) are supported in Node.js, Chrome, and .NET but NOT in older Safari (pre-2023 iOS devices). If the regex runs in a browser context, either polyfill or restructure the pattern to avoid lookbehind.
Unanchored validation pattern silently passes invalid input - /\d{4}/ matches the digits inside "abc1234xyz", making test() return true for an invalid value. Always add ^ and $ anchors to any validation pattern.
Catastrophic backtracking on adversarial input - Patterns like (a+)+ or (a|ab)+ take exponential time on long non-matching strings. Test any pattern with quantifier nesting using a 30-character string that should not match. If it hangs for more than a millisecond, restructure.
u flag missing for Unicode input - Without the u flag in JavaScript, emoji and other multi-codepoint characters are counted as two characters by . and {n}. This causes off-by-one failures on strings containing emoji, CJK characters, or diacritics. Always use /pattern/u when processing user-supplied text.
Regex compiled inside a loop - new RegExp(pattern) inside a for loop re-compiles the pattern on every iteration, adding overhead proportional to loop count. Hoist regex literals or new RegExp() calls outside the loop.
References
For ready-to-use patterns across common domains, read:
references/common-patterns.md - 20+ production-ready regex patterns for email,
URL, phone, date, IP, UUID, passwords, slugs, semver, credit cards, and more
Only load the references file when you need a specific pattern - it is long and
will consume context.
Companion check
On first activation of this skill in a conversation: check which companion skills are installed by running ls ~/.claude/skills/ ~/.agent/skills/ ~/.agents/skills/ .claude/skills/ .agent/skills/ .agents/skills/ 2>/dev/null. Compare the results against the recommended_skills field in this file's frontmatter. For any that are missing, mention them once and offer to install:
