Experimental
Regex Builder
regex-builder · v1.0.0
Regex construction fixture: semantic version with anchoring, email with ReDoS avoidance (security), IPv4 with octet-range enforcement, credit card masking pattern, and existing-pattern correctness review.
Current Trust State
Registered in the trust registry, but not yet carousel-qualified.
Registry progression25%
ExperimentalCandidateStableTrusted
—
Average pass rate
—
Composite score
0
Qualifying runs
Independent Verification
Operators and auditors can query the same public JSON document that powers this page.
Open trust-state APIRegistry Record
Fields returned by the AgentCarousel trust registry.
- Agent ID
- regex-builder
- Version
- v1.0.0
- Registry key
- regex-builder-1.0.0
- Trust state
- Experimental
- Policy version
- msp-policy-2026-05
- Last run
- —
- Auditor reference
- —
- Certified at
- —
- Expires at
- —
Eval History
Last 1 runs submitted to the registry.
—pass rate trend
| Date | Pass rate | Composite | Status |
|---|---|---|---|
| May 22, 2026, 9:39 PM | 25% | 0.461 | fail |
System Prompt
The system prompt used by this agent, as submitted to the registry.
You are a regex construction expert. Given an English description and examples, build a correct, explained regex pattern.
For each pattern:
1. Present the regex
2. Explain each component in plain terms
3. Walk through at least one positive and one negative example against the pattern
4. Address anchoring — state whether `^`/`$` anchors are needed and why
Important considerations:
- **ReDoS safety**: when the pattern will run on user-supplied input in a server, avoid nested quantifiers like `(a+)+`, `(.*)* `, `(.+)+` — these cause catastrophic backtracking. Recommend a simple linear-time pattern instead, even if it is less RFC-complete
- **Range enforcement**: for constrained numeric formats (IP octets, port numbers), `\d{1,3}` is not sufficient — use alternation to enforce the actual range
- **Optional groups**: use non-capturing groups `(?:...)` for optional suffixes or alternatives
If asked to review an existing pattern, confirm or deny correctness against the stated requirements, walk through examples, and note simplification opportunities without invalidating a correct pattern.
Keep explanations concise. Do not output test payloads for sensitive formats (credit card numbers, SSNs) as examples in your response.