regex-architect

Regex Architect

Overview

Build correct, readable, and safe regular expressions, then prove they work. Keywords: regex, regular expression, pattern matching, ReDoS, catastrophic backtracking, validation, extraction, capture group, named group, lookahead, lookbehind, anchor, Unicode, PCRE, RE2, flavor portability.

This skill exists because regex is easy to write and hard to write well. Naive patterns silently accept bad input, reject good input, or hang a server when fed an adversarial string. The job is not just "produce a pattern" — it is to produce a pattern that is anchored correctly, scoped to the right flavor, free of exponential backtracking, and accompanied by a test plan.

Use this skill whenever a task involves matching, extracting, replacing, splitting, or validating text with a pattern — or explaining/debugging an existing one.

Core Principles

1. Clarify before constructing. Know the flavor, the input source, whether you are validating (whole string) or searching (substring), and what counts as valid. Ambiguity here produces wrong regexes.
2. Anchor on purpose. Validation almost always needs ^...$ (or \A...\z). Search/extract usually must NOT be anchored. Mismatched anchoring is the #1 correctness bug.
3. Prefer explicit character classes over . . is greedy, matches almost anything, and is a backtracking magnet. Use [^"], [^\n], \d, etc.
4. Make quantified subpatterns mutually exclusive. Overlapping alternations or nested quantifiers ((a+)+, (a|a)*, (.*)*) cause catastrophic backtracking.
5. Readability is a feature. Use named groups, verbose/extended mode, and comments for anything non-trivial. A regex nobody can edit is a liability.
6. Validate with structured logic when regex is the wrong tool. Do not regex HTML, nested brackets, or full email RFC 5322. Say so and offer a parser.

Workflow

1. Gather requirements (see references/clarifying-questions.md):
   • Target flavor / language runtime.
   • Validation vs. search vs. replace vs. split.
   • Exact set of valid and invalid examples (ask for at least 2 of each).
   • Multiline? Unicode? Case sensitivity? Performance constraints / untrusted input?
2. Choose a strategy. Pick character classes, anchoring, and grouping. Consult references/patterns-cookbook.md for vetted building blocks rather than inventing from scratch.
3. Draft the pattern in the requested flavor. Use named capture groups and, for non-trivial patterns, provide a verbose/commented version too.
4. Audit for ReDoS using the checklist in references/redos-guide.md. Rewrite nested/overlapping quantifiers; prefer atomic groups, possessive quantifiers, or bounded {0,n} quantifiers. If the runtime is RE2/Go/Rust, note it is already linear-time and lookarounds/backrefs are unsupported.
5. Explain it. Provide a token-by-token breakdown so the user can maintain it.
6. Test it. Run scripts/regex_test.py with positive and negative cases. It also runs a lightweight ReDoS timing probe. Report pass/fail per case.
7. Note portability. If the user may switch flavors, flag flavor-specific constructs (lookbehind, named-group syntax, \d Unicode semantics, inline flags) per references/flavor-portability.md.