Regex Pattern Validator

The Problem

You write an email validation regex that passes all your test cases. In production, a user submits a 10,000-character string with repeated @ characters and your Python API hangs for 30 seconds — catastrophic backtracking from a nested quantifier (a+)+ pattern. Meanwhile, your JavaScript frontend uses a different email regex that accepts addresses your backend rejects. Your Go service uses regexp.MustCompile which doesn't support lookbehinds, so a regex that works in Python fails silently in production. You have no systematic way to test regex patterns against adversarial inputs, verify cross-engine compatibility, or detect ReDoS vulnerabilities before deployment.

What You Get

• Pattern construction following best practices: explicit character classes over wildcards, anchored patterns for validation, non-capturing groups unless backreferences are needed, and \d/\w/\s shorthand only when cross-engine behavior is consistent
• Test case generation covering happy path (typical valid inputs), boundary cases (min/max length, empty strings), negative cases (similar-but-invalid inputs), edge cases (Unicode, newlines, null bytes, extremely long inputs), and ReDoS cases (inputs designed to trigger catastrophic backtracking) — reported in a structured pass/fail table
• ReDoS vulnerability analysis detecting nested quantifiers (a+)+, ambiguous alternation (a|a)*, and unbounded repetition on broad character classes — with a three-level rating: SAFE, CAUTION, or DANGEROUS, plus the specific worst-case input description
• Cross-engine compatibility matrix covering PCRE, JavaScript, Python re/regex, Go regexp, Java, and Ruby — flagging lookbehind support, named group syntax differences ((?P<name>) vs (?<name>)), atomic groups, possessive quantifiers, Unicode \p{L} support, and verbose mode availability
• Codebase audit mode that scans for regex patterns across Python (re.compile), JavaScript (/pattern/flags), Go (regexp.MustCompile), and Java (Pattern.compile), extracts each pattern, and flags ReDoS risks sorted by severity
• 30+ pre-tested pattern library covering email (RFC 5322 simplified), URLs, phone numbers (E.164), IPv4/IPv6, semantic versions, ISO 8601 dates, currency, UUIDs, credit cards (Luhn-valid), postal codes, HTML tags, markdown links, git commit hashes, Base64, and file paths — each with target engine, test cases, and performance rating

Why This Beats Prompting It Yourself

When you ask an LLM to "write a regex for email validation," it produces a pattern that handles common cases but contains nested quantifiers that trigger exponential backtracking on adversarial input. It doesn't test the pattern against ReDoS vectors. It doesn't check whether the pattern uses lookbehinds (unsupported in Go) or atomic groups (unsupported in JS). It gives you a single pattern and hopes it works everywhere. This skill builds the pattern, generates comprehensive test cases including adversarial inputs, runs ReDoS analysis, and checks cross-engine compatibility — producing a structured report with a performance rating, not just a regex string.

Example Session

You: "Build a regex for validating IPv4 addresses with optional CIDR notation."

Agent output:

PATTERN:
^((25[0-5]|2[0-4]\d|[01]?\d\d?)\.){3}(25[0-5]|2[0-4]\d|[01]?\d\d?)(\/([0-9]|[12]\d|3[0-2]))?$

EXPLANATION:
- (25[0-5]|2[0-4]\d|[01]?\d\d?) — validates each octet 0-255
- \.{3} — three literal dots between first three octets
- (\/([0-9]|[12]\d|3[0-2]))? — optional /0 through /32 CIDR suffix

TEST RESULTS:

Input Expected Actual Status ─────────────── ──────── ──────── ────── 192.168.1.1 Match Match PASS 192.168.1.1/24 Match Match PASS 255.255.255.255 Match Match PASS 256.1.1.1 No match No match PASS 192.168.1 No match No match PASS 192.168.1.1/33 No match No match PASS 01.01.01.01 No match No match PASS

PERFORMANCE RATING: SAFE
  No nested quantifiers, no unbounded repetition, no ambiguous alternation.
  Worst case: O(n) linear scan for a 15-character input.

COMPATIBILITY:
  Target engine: Python re, JavaScript, Go regexp, Java, PCRE
  Compatible with: ALL engines — uses only basic character classes and alternation
  Incompatible features: None

Use Cases

• Building regex patterns for input validation (email, phone, URL, IP, date, UUID)
• Fixing broken regex patterns that cause timeouts or incorrect matches
• Porting regex patterns between languages (Python → Go, JavaScript → Java)
• Auditing a codebase for ReDoS-vulnerable regex patterns before deployment
• Testing regex patterns against adversarial inputs designed to cause backtracking

Known Limitations

The performance analysis is heuristic-based — it identifies known ReDoS patterns (nested quantifiers, ambiguous alternation) but cannot prove absence of vulnerabilities through static analysis alone. For high-security contexts, pair this with dynamic ReDoS testing using a fuzzing tool. The cross-engine compatibility matrix covers the six most common engines but does not cover every version-specific behavior change. The pattern library provides simplified versions of complex patterns (e.g., RFC 5322 email) — production validation may require more comprehensive patterns with known trade-offs.