fix(#667): add regex pattern decomposition guidance to review sub-agents

skills/pr-review/sub-agents/challenger.md

@@ -35,6 +35,16 @@ For each finding:
    - "Missing error handling" when the error is handled by a caller
    - "Race condition" when access is serialized by design
    - "Missing test" when the test exists in a different file
+   - "Regex pattern misread" when a character class boundary is
+     confused with adjacent literals (e.g., `[Cc]lose` read as
+     having a double `c` instead of character class `[Cc]` followed
+     by literal `lose`)
+
+   When a finding cites a regex pattern as incorrect, independently
+   decompose the pattern element by element — identify character
+   classes (`[...]`), quantifiers, anchors, alternations, escape
+   sequences, and literals — before confirming or removing the
+   finding.
 2. **Assess severity calibration.** Is the severity proportionate to
    the actual risk? Downgrade findings whose severity is inflated
    relative to the codebase context.

skills/pr-review/sub-agents/correctness.md

@@ -106,3 +106,25 @@ based on common patterns — read it.
 If the file cannot be read (e.g., it is in another repository or
 inaccessible), state that you were unable to verify the contents.
 Never present unverified file contents as fact in a finding.
+
+### Regex pattern verification
+
+When a finding asserts that a regex pattern is incorrect (malformed,
+redundant, or logically wrong), you MUST decompose the pattern element
+by element before reporting it. Explicitly identify:
+
+- **Character classes** (`[...]`) and their contents
+- **Quantifiers** (`*`, `+`, `?`, `{n,m}`)
+- **Anchors** (`^`, `$`)
+- **Alternations** (`|`)
+- **Escape sequences** (`\d`, `\s`, `\.`, etc.)
+- **Literal characters** outside any special construct
+
+Do not treat the contents of a character class as part of the adjacent
+literal. For example, `[Cc]lose` is character class `[Cc]` (matches
+`C` or `c`) followed by literal `lose` — it is not a double `c`.
+
+If your decomposition shows the pattern is correct, do not report a
+finding. If the pattern is genuinely wrong, include the element-by-element
+breakdown in the finding description so reviewers can verify your
+reasoning.