v0.1.0 to v0.1.0
1 added, 0 removed. Audit A to A.
---
id: 'existing-pattern-conformance'
name: 'Existing-Pattern Conformance 既存パターン準拠の確認'
description: '新実装が、同種の先行実装（同レイヤ・同責務・同概念）に在る防御 / バリデーション / エラー処理 / 規約 / 共通化ロジック / 概念定義を、欠落・重複・食い違いなく継承しているかを grep で先行特定して確認する'
version: 0.1.0
category: midstream
phase: midstream
applyTo:
- '**/*.{ts,tsx,js,jsx,mjs,cjs,py,rb,go,php,java}'
- '**/migrations/**/*'
tags: [conformance, prior-art, consistency, maintainability, midstream]
severity: major
inputContext: [diff]
outputKind: [findings, questions]
modelHint: high-accuracy
dependencies: [code_search]
---
## Pattern declaration
Primary pattern: Reviewer
Secondary patterns: Inversion
Why: 先行実装との突合は grep による決定論的特定が主だが、同種の先行実装が存在しない新規領域では実行を止めるゲートが必要。
## Goal / 目的
- 新しい追加 / 変更が、**同種の先行実装をまず grep で特定**し、そこに在る防御・バリデーション・エラー処理・定数 / 規約・共通化ロジック・概念定義を**欠落・重複・食い違いなく継承**しているかを確認する。
- 「既存に同じことをする実装があるのに、それを参照せず独自に書いて防御やバリデーションが抜けた / 重複した / 規約から外れた」パターンを検出する。
## Non-goals / 扱わないこと
- 設計の良し悪しそのもの（既存が間違っていれば従う必要はない。意図的差分は根拠の明文で許容）。
- リファクタ後の caller 残骸（`cross-file-leakage` の領域）。
- 宣言と実装の自己矛盾（`self-contradiction` の領域）。
## Pre-execution Gate / 実行前ゲート
このスキルは以下の条件がすべて満たされない限り `NO_REVIEW` を返す。
- [ ] 差分に、リポジトリ内で**同レイヤ・同責務・同概念の先行実装が grep で実在確認できる**追加 / 変更を含む（防御・バリデーション・エラー処理・規約・共通化ロジック・概念定義を持つ同種コード / 設計 / migration）。「存在しうる」という推測では発火させず、**先行実装を grep で1件以上特定できたときのみ**レビューに進む
- [ ] inputContext に diff が含まれ、`code_search`（grep）が利用可能である
ゲート不成立時の出力: `NO_REVIEW: existing-pattern-conformance — 先行実装と突合すべき変更が検出されない`
## False-positive guards / 抑制条件
- grep で同種の先行実装が見つからない（真に新規領域）の場合は指摘しない。
- **grep ヒットが同名でも、別スコープ・別責務・別概念であれば「先行実装」ではない**。同名の関数 / 定数 / 型でも、別レイヤ・別ドメイン・別用途なら突合対象から除外する。同レイヤ・同責務・同概念であることを確認できた先行実装のみを参照とする（同名・文字列一致だけを根拠に「先行はこうしている」と断定してはならない）。
- 既存パターンから外れることが**差分内で根拠とともに明記**されている場合は抑制（意図的な逸脱）。
- 既存実装側が deprecated / 移行中で、新実装が新方針に従っている場合は抑制。
- **整形 SSoT（フォーマッタ）管理下の空白・列整列・末尾スペースは指摘しない**（#1451）。表の列幅ズレ・末尾スペース調整・インデント整列など `prettier` / フォーマッタが決める体裁は、`npx prettier --check <file>` が通る限り正典であり、手動整形の提案はかえって整形結果を壊す。整形の指摘前に `prettier --check` の結果を確認する（整形は lint の領域で、本スキルはロジック・規約の継承に集中する）。
+ - **型検査対象外の `scripts/` 配下で、JSDoc の `unknown` を `any` へ緩める提案はしない**（#1476）。`scripts/` 配下は `runners/node-api/tsconfig.json` の `include`（`src/` 以下のみ）に含まれず tsc の型検査対象外であり、JSDoc の型注釈はエディタ表示補助のための文書目的に留まる。`unknown` は呼び出し側にプロパティアクセス前の絞り込みを強制する意図的で保守的な選択である。同レイヤの先行実装（`scripts/validate-agent-skills.mjs` の `@param {unknown} value` / `@returns` の `applyTo: unknown` 等）も同じ規約に従っている。「`any` にすれば静的解析エラーを避けられ DX が上がる」という理由での変更提案は、型安全性を後退させたうえ既存パターンからも逸脱するため指摘しない。
## Rule / ルール
### 検出ロジック
1. **先行実装の特定**: 追加 / 変更された機能の概念（バリデーション対象・エラー処理・定数・共通関数・概念名）を抽出し、**repo 全体を grep** して同レイヤ・同責務・同概念の先行実装を特定する。
2. **継承の突合**: 先行実装に在る次を新実装が継承しているか比較する。
- 防御 / 入力バリデーション / 認可チェック
- エラー処理・例外方針（型・ラップ・再 throw 慣習）
- 定数 / 規約 / 命名 / 共通化ロジック（再実装でなく共通関数の再利用）
- 概念定義（同名概念の意味のズレがないか）
3. **逸脱の分類**: 欠落（先行にあるが新実装に無い）/ 重複（共通化せず再実装）/ 食い違い（同概念で挙動が違う）を判定。意図的なら根拠の明文を確認。
4. **報告**: 先行実装と新実装を両方 `<file>:<line>` + grep 検索語で示す。
### 制約
- 検出は最大 5 件。防御・バリデーション欠落など実害の大きいものを優先。
- 各指摘に「先行実装（参照）」「新実装」「欠落 / 重複 / 食い違いの別」を必ず含める。
- 先行実装の特定は grep で再現可能にする（検索語を明示）。
## Evidence / 根拠の取り方
- 先行実装と新実装は両方 `<file>:<line>` と grep 検索語で示し、推測しない。
- 「先行はこうしている / 新実装はこう」を対比し、欠落 / 重複 / 食い違いを具体的に説明する。
## Output / 出力フォーマット
すべて日本語。
```text
(existing-pattern-conformance):1: [要約] 最も重大な既存パターンからの逸脱は〈1文〉
<file>:<line>: [パターン逸脱1] <タイトル>
先行実装: <参照>(検索語: `<grep pattern>`, <file>:<line>)
新実装: <該当箇所>(<file>:<line>)
逸脱: <欠落 / 重複 / 食い違い> — <何を継承し損ねたか>
Fix: <既存の防御・共通関数・規約を継承する最小修正、または逸脱の根拠を明文化>
```
## 評価指標（Evaluation）
- 合格基準: 先行実装が grep 再現可能な検索語 + `<file>:<line>` で示され、欠落 / 重複 / 食い違いが具体的に説明されている。
- 不合格基準: 先行実装を grep で再現できない、新規領域への難癖、設計の好み論、根拠ある意図的逸脱への指摘。
## 人間に返す条件（Human Handoff）
- 既存パターンに従うべきか、新方針へ移行すべきかが設計判断を要する場合。
- 先行実装が複数あり、どれを正典とするかの合意が必要な場合。