regex-builder

非推奨 — 最新の Claude モデルは、エッジケースのテストスイートや複数言語での使用例を含め、正確で説明の行き届いた正規表現パターンを標準で生成できます。このスキルによる改善効果はほぼゼロです。アーカイブとしての参照用にのみ保持されています。

正規表現ビルダー

マッチング要件（肯定例と否定例）を、コンポーネントごとの説明、キャプチャグループのドキュメント、エッジケースの特定、Python と JavaScript ですぐに使えるコードを備えた、テスト済みの正規表現パターンに変換します。

リファレンスファイル

ファイル	内容	読み込むタイミング
references/character-classes.md	文字クラスのリファレンス、Unicode カテゴリー、POSIX クラス	常に
references/quantifiers.md	量指定子の動作、貪欲・遅延・強欲、バックトラッキング	パターンで繰り返しが必要な場合
references/common-patterns.md	メールアドレス、URL、電話番号、IP、日付、UUID などの検証済みパターン	一般的な検証が求められる場合
references/flavor-differences.md	Python、JavaScript、PCRE、POSIX 間の構文の違い	複数言語での使用が必要な場合

前提条件

• 明確な仕様：マッチすべき内容と、マッチすべきでない内容
• 対象の正規表現フレーバー（Python re、JavaScript、PCRE）— デフォルトは Python です

ワークフロー

フェーズ 1：例を収集する

肯定例（マッチすべき例）と否定例（マッチすべきでない例）を集めます。

1. ユーザーから — 明示的に提示された例
2. コンテキストから — ユーザーが「メールアドレスにマッチさせたい」と述べた場合は、一般的な肯定例と否定例を推測します
3. データから — サンプルデータが提示された場合は、その中からパターンを特定します

最低でも肯定例を 3 つ、否定例を 3 つ用意します。例が少ないと、特定のケースにパターンを過剰適合させるリスクがあります。

フェーズ 2：パターンを推定する

例を分析してパターンを組み立てます。

1. 固定リテラルを特定する — すべての肯定例で同じ位置に現れる文字
2. 文字クラスを特定する — 文字は異なるものの、パターンに従う位置（数字、英字、英数字）
3. 繰り返しを特定する — 可変回数で現れる要素
4. 任意要素を特定する — 一部の肯定例にはあるが、ほかの例にはない部分
5. アンカーの要否を特定する — パターンは文字列全体にマッチする必要があるか、それとも部分文字列でもよいか

フェーズ 3：パターンを説明する

パターンをコンポーネント表に分解します。

コンポーネント	意味
^	文字列の先頭
[A-Za-z]	英字 1 文字（大文字または小文字）
\d{3,5}	3～5 桁の数字
$	文字列の末尾

パターンでキャプチャグループを使用する場合は、別途ドキュメント化します。

フェーズ 4：エッジケースを生成する

各パターンについて、問題を引き起こしやすい入力を特定します。

1. 空文字列 — パターンは正しく処理できますか？
2. ほぼマッチする文字列 — 有効なマッチと 1 文字だけ異なる文字列
3. 境界の長さ — 有効な長さの最小値と最大値
4. 特殊文字 — 入力に含まれるピリオド、角括弧、バックスラッシュ
5. Unicode — マルチバイト文字、絵文字、ダイアクリティカルマーク
6. 破滅的なバックトラッキング — マッチングに指数関数的な時間がかかる入力

フェーズ 5：出力する

パターン、説明、テストケース、使用例を出力します。

出力形式

## Regex Pattern: {Brief Description}

### Requirements
- **Must match:** {description of valid inputs}
- **Must reject:** {description of invalid inputs}
- **Flavor:** {Python re | JavaScript | PCRE}

### Pattern
```regex
{pattern}

説明

コンポーネント	意味
{component}	{何にマッチするか、またその理由}

キャプチャグループ

グループ	名前	キャプチャ対象	例
1	{name}	{what}	{example value}

テストケース

#	入力	一致するか	理由
1	{input}	はい	{理由 — 正常系}
2	{input}	はい	{理由 — 境界条件}
3	{input}	いいえ	{理由 — 無効}
4	{input}	いいえ	{理由 — 惜しい不一致}
5	`` (空)	いいえ	空の入力

エッジケース

• {エッジケース 1}: {注意すべき点}
• {エッジケース 2}: {注意すべき点}

使い方

Python:

import re

pattern = re.compile(r'{pattern}')

# Match entire string
if pattern.fullmatch(text):
    ...

# Search within string
match = pattern.search(text)
if match:
    captured = match.group(1)

# Find all matches
matches = pattern.findall(text)

JavaScript:

const pattern = /{pattern}/;

// Test
if (pattern.test(text)) { ... }

// Match
const match = text.match(pattern);
if (match) {
    const captured = match[1];
}

// Find all
const matches = [...text.matchAll(/{pattern}/g)];

## Calibration Rules

1. **Correctness over cleverness.** A readable, slightly longer pattern is better than
   a cryptic short one. `[A-Za-z0-9]` is clearer than `\w` when you specifically mean
   alphanumeric without underscores.
2. **Test negatives as rigorously as positives.** A pattern that matches everything
   technically matches all positive examples. Negative examples prevent over-matching.
3. **Anchor when appropriate.** `^\d{3}$` matches exactly 3 digits. `\d{3}` matches
   3 digits anywhere in the string. State the anchoring intent explicitly.
4. **Avoid catastrophic backtracking.** Nested quantifiers like `(a+)+` cause exponential
   time on non-matching input. Test with adversarial inputs.
5. **Named groups over numbered groups.** `(?P<year>\d{4})` (Python) or `(?<year>\d{4})`
   (JS) is self-documenting. Use numbered groups only for simple patterns.
6. **Specify the flavor.** Python `re`, JavaScript, and PCRE have different feature sets.
   Lookaheads, lookbehinds, and Unicode support vary.

## Error Handling

| Problem | Resolution |
|---------|------------|
| Insufficient examples | Ask for more. Minimum 3 positive, 3 negative. |
| Contradictory examples | Flag the contradiction. Ask which examples are correct. |
| Requirements too complex for regex | Suggest a parser instead. Regex cannot handle recursive structures (nested brackets, HTML). |
| Pattern causes backtracking | Rewrite with atomic groups or possessive quantifiers. Test with worst-case input. |
| Unicode requirements unclear | Ask if the pattern needs to handle non-ASCII. Default to ASCII unless specified. |
| Multiple valid patterns | Present the simplest one. Mention alternatives if they have meaningful tradeoffs (performance vs readability). |

## When NOT to Build Regex

Push back if:
- The input requires parsing a recursive grammar (HTML, JSON, nested expressions) — use a parser
- The validation is for a standard format with a library (email validation, URL parsing) — use the standard library
- The pattern is for security-critical input validation as the sole defense — regex is a first filter, not a security boundary
- The user wants to modify matched content in complex ways — regex replacement has limits; suggest code instead