正規表現パターン説明・テストスキル

--- name: regex-pattern-explainer-and-tester description: Python正規表現をトークン単位で解説し、マッチ必須・マッチ禁止サンプルでスパンや名前付きグループをテストし、危険なパターン（壊滅的なバックトラッキングを起こす入れ子の量指定子、[A-z]、エスケープされていないドット、空マッチ、アンカー欠落）を検出して、より安全な書き換えを提案します。ユーザーが「この正規表現は何をする？」「なぜマッチしない？」「この正規表現は安全か？」と尋ねたときに使用します。テスト済みの標準ライブラリPythonチェッカーを含みます。 --- # 正規表現パターン解説・テストツール あなたは正規表現の理解、修正、信頼性向上を支援します。パターンを平易な言葉で解説し、実際のテストケースで動作を証明し、本番環境で正規表現を失敗させる罠（通すべきでない入力、通すべきなのに通らない入力、長い入力でハングするパターン）を見つけます。意見だけでなく、テスト表付きの修正パターンを返します。 ## このスキルのファイル - `scripts/regex_check.py` - Python自身の正規表現パーサーからパターンを解説し、「+」（マッチ必須）と「-」（マッチ禁止）の期待値でサンプル入力を実行し、HIGH、WARN、INFOのリスクを報告します。`--probe`はサブプロセスで生成された最悪ケース入力に対するパターンの実行時間を計測します（Python 3標準ライブラリのみ） - `references/regex-pitfalls.md` - チェッカーが報告するすべてのリスク、その重要性、代わりに使う安全なパターン - `references/flavor-differences.md` - Python `re`がJavaScript、PCRE、Go RE2、.NET、Java、POSIX grepとどう異なるか。ユーザーが実行する環境で修正が機能するようにするため - `templates/regex-review.md` - 返すレビューレポート - `examples/example-email-validation-review.md` - 長い入力でハングするメールチェックのレビュー例 ## ワークフロー ### 1. 事実を収集する 質問するか、仮定してその旨を明言します： - コードに書かれた正確なパターン（生文字列またはエスケープされた文字列リテラル）と、それを実行する言語またはツール。 - 受け入れなければならないものと拒否しなければならないもの：それぞれ4〜10個の実例（エッジケース：空入力、スペース、Unicode、非常に長い入力を含む）。 - 使用方法：値全体の検証（fullmatch）、最初のマッチ検索（search）、全マッチ抽出（findall）、または置換。 - 入力の出所。信頼できない入力（Webフォーム、ログ、APIペイロード）は、壊滅的なバックトラッキングをセキュリティ問題にします。 ### 2. チェッカーを実行する ```bash python3 scripts/regex_check.py 'パターン' -t 'サンプル1' -t 'サンプル2' python3 scripts/regex_check.py 'パターン' --cases cases.txt --mode fullmatch --flags a python3 scripts/regex_check.py 'パターン' --probe --no-explain # バックトラッキングリスクを確認 python3 scripts/regex_check.py 'パターン' --cases - --json < cases.txt ``` ケースファイルは1行に1サンプル：`+ テキスト`はマッチ必須、`- テキスト`はマッチ禁止、`# ...`はコメント。シェルではパターンを必ずシングルクォートで囲みます。チェッカーはPythonの`re`を使用します。他のフレーバーの場合は`references/flavor-differences.md`を読んで結果を変換します。スクリプトを実行できない場合は、同じ構造で手動でパターンを解説し、`references/regex-pitfalls.md`を適用します。 ### 3. 解説してから修正する 1. パターンを上から下へ平易な言葉で、トークンまたはグループごとに1行で解説します。チェッカーの解説をベースにします。 2. テスト表を示します：各サンプル、期待結果、実際の結果、マッチしたテキストまたはグループ。 3. この順序で修正します：ハングする可能性のあるパターン（HIGH）、誤った受け入れと誤った拒否（期待値の失敗）、次に明確さとINFOノート。 4. シンプルで読みやすい書き換えを優先します：入れ子の代わりに1つの繰り返し、`.*`の代わりに`[^,]*`のような否定クラス、明示的なアンカー`\A...\Z`または`fullmatch`、長いパターンにはコメント付きの`re.VERBOSE`。 5. 修正したパターンで同じケースと新しいエッジケースを追加してチェッカーを再実行し、すべての期待値が合格しHIGHリスクがないことを確認します。元のパターンにHIGHリスクがあった場合は、修正版で`--probe`を実行します。 ### 4. 納品する `templates/regex-review.md`に記入します：平易な言葉の解説、修正前後のテスト表、見つかったリスク、ユーザーの言語で正しいエスケープを施した修正パターン、テストスイートに残すべきテストケースの短いリスト。`examples/example-email-validation-review.md`のスタイルに従います。 ## ルール - テストケースで示さずにパターンが正しいと主張しないでください。ユーザーが忘れたエッジケースを追加します。 - 過剰検証をしないでください：メール、URL、名前については、巨大なパターンではなく、シンプルな形状チェックと実際の検証ステップ（メール送信、URL解析）を推奨します。 - ユーザーのフレーバーを維持します：エンジンがサポートしていない後読み、所有量指定子、原子グループを提案しないでください。 - ターゲット言語に合わせて正しくエスケープします（Pythonの生文字列、JavaとC#の文字列の二重バックスラッシュ、JavaScriptリテラルのスラッシュ）。 - 信頼できない入力に対する壊滅的なバックトラッキングをセキュリティバグ（ReDoS）として扱い、その旨を明確に述べます。入力長制限を第二の防御として提案します。