What this prompt does
This prompt uses Copilot to generate, explain, and test regular expressions for your [language] project, treating regex as code that deserves comments and tests rather than a one-line incantation. It produces a regex for [primary_pattern] with named capture groups and inline comments, validation regexes for [validation_targets] that handle international characters and edge cases, and a parser regex for [parsing_task] that extracts structured data from unstructured text.
The structure works because it pairs each pattern with a test suite and a performance review. For every regex it generates [test_count] test cases spanning valid matches, invalid inputs, edge cases such as empty string, Unicode, and maximum length, and partial matches. It also shows each regex in both raw and verbose or extended form for readability, analyzes performance characteristics to flag patterns at risk of catastrophic backtracking and provides safer alternatives, wraps each regex in a utility function that fails with meaningful error messages, and provides the patterns in [additional_languages] syntax for codebases that span more than one language. Checking for catastrophic backtracking up front is exactly what spares you a production CPU spike when an adversarial input arrives.
When to use it
- You need a non-trivial regex and want it documented and tested, not cargo-culted from a forum.
- You are validating fields like emails, phone numbers, or URLs across locales.
- You are parsing unstructured text such as log lines into structured fields.
- You worry a pattern might cause catastrophic backtracking under bad input.
- You want the same regex expressed in multiple languages' syntax.
- You want validation wrapped in functions that fail with clear, actionable messages.
Example output
Expect, per pattern, a small tested regex module rather than a single line. You get the regex with named groups and inline comments, a verbose or extended version for readability, a set of test cases covering valid, invalid, edge, and partial inputs, a note on backtracking risk with a safer alternative where relevant, a utility function wrapping it with error messages, and equivalents in your [additional_languages]. The result reads like something you can drop into a codebase and maintain, not a brittle one-liner nobody dares touch.
Pro tips
- Describe
[primary_pattern]by the structure you want to extract, such as timestamp, level, service, and message, so the named groups come out meaningful. - For
[validation_targets], accept that a "perfect" email or phone regex does not exist and aim instead for a pragmatic, well-tested pattern. - Set
[test_count]high enough to cover the nasty inputs, since Unicode and empty strings are where regexes quietly break in production. - Always keep the catastrophic-backtracking review, because a single greedy nested quantifier can spike CPU under adversarial input.
- Use the verbose or extended form in your codebase, since a commented regex is far easier to maintain than a dense one-liner.
- Verify the
[additional_languages]variants actually run, as regex flavors differ in lookbehind, named groups, and Unicode support.
