pattern-matching

パターンマッチング

概要

すべてのコードベースには独自の指紋があります。あなたの役割は、その指紋を極めて正確に再現し、どこまでが元のコードで、どこからがあなたの貢献なのか、レビュー担当者に見分けがつかないようにすることです。

基本原則： 行動する前に観察しましょう。作成する関数、ファイル、フォルダーのすべてに、リポジトリ内に実例がなければなりません。手本にしたものを示せないなら、すでに一貫性を損なっています。

例外なし。回避策なし。近道なし。

最優先の指針

EVERY ADDITION MUST MIRROR AN EXISTING PRECEDENT

リポジトリで snake_case が採用されているなら、あなたも snake_case を使います。サービスが src/domain/ の下に配置されているなら、あなたのサービスもそこに配置します。エラーがカスタムの Result<T> 型を通じて伝播するなら、何も問わずそれに従います。個人の好みを差し挟む余地はありません。

適用する場面

必須となる場面：

• 既存のリポジトリ内のファイルを変更する場合
• 確立されたアーキテクチャに新しいモジュール、ルート、コンポーネントを追加する場合
• 自分が立ち上げたのではないプロジェクトに機能を追加する場合
• 既存のロジックを組み替えるリファクタリングを行う場合

不要な場面：

• 新規プロジェクトを立ち上げる場合（godmode:project-bootstrap を参照）
• バージョン管理に追加されることのない使い捨てスクリプトを作成する場合

導入手順

BEFORE producing any code in an existing repository:

1. SURVEY: Locate 2-3 files or functions that solve a comparable problem
2. CATALOG: Record every convention they share
   - Identifier formatting (camelCase, snake_case, PascalCase)
   - Directory taxonomy (where do peers of this file reside?)
   - Import conventions (relative paths, aliases, barrel files)
   - Error propagation strategy (exceptions, Result types, error codes)
   - State access patterns (global store, context injection, parameter passing)
   - Test co-location and framework choices
3. REPLICATE: Produce your code using the identical conventions
4. AUDIT: Hold your output beside the originals — does it pass as native?

Omit any step = drift introduced

準拠すべき各側面

ファイルレベルの規約

BEFORE placing a new file:

1. Where do its siblings reside? (directory hierarchy)
2. How are filenames formed? (kebab-case.ts, PascalCase.tsx, snake_case.py)
3. What internal structure does each file follow? (imports, types, constants, logic, exports)
4. How are exports surfaced? (default export, named exports, re-export indexes)

関数レベルの規約

BEFORE writing a new function, class, or component:

1. Identify an existing function that addresses a similar concern
2. Mirror its shape:
   - Argument style (destructured object vs positional args)
   - Return envelope (Promise<T>, Result<T, E>, nullable)
   - Error strategy (try/catch, .catch(), explicit error returns)
   - Observability (logger.info(), structured JSON, console methods)
   - Validation technique (Zod, Joi, manual guards, type narrowing)
3. Rely on the SAME libraries and utilities the project already depends on
   - Do not introduce ramda if the project uses native array methods
   - Do not pull in got if the project wraps fetch
   - Do not add a competing ORM when one is already wired in

アーキテクチャレベルの規約

BEFORE inserting a new module or layer:

1. How is the codebase stratified?
   - Routes -> Controllers -> Services -> Repositories?
   - Pages -> Components -> Hooks -> Helpers?
   - Handlers -> Domain -> Infrastructure?
2. Which way do imports flow?
3. Where does business logic concentrate?
4. How do cross-cutting concerns surface? (auth middleware, logging wrappers, error boundaries)

そっくり踏襲する方法

規約に準拠する最速の方法は、最も近い類似例を見つけて、一挙手一投足までそっくり踏襲することです。

1. LOCATE: "Find the file most similar to what I need to create"
2. STUDY: Absorb its structure, imports, error handling, naming, export style
3. DUPLICATE: Use it as a skeleton
4. SPECIALIZE: Swap in only the logic unique to your feature
5. COMPARE: Place them side by side — can you spot the newcomer?

効果的なプロンプトのパターン：

"Here is our existing payment service (src/services/payment.ts).
Produce the new subscription service using identical structure, patterns, and naming."

具体的な例を示すほうが、規則を文章で説明するよりも常に効果的です。

よくある逸脱パターン

AI の傾向	プロジェクトの規約	修正方法
console.log()	winston を使った構造化ロガー	プロジェクトのロギングパイプラインに従う
汎用的な try/catch	ドメイン固有の ServiceError クラス	プロジェクトのエラー階層に沿ってスローおよびキャッチする
インラインの Tailwind クラス	CSS Modules / styled-components	プロジェクトのスタイル設定方法に従う
HTTP 通信に axios を使う	lib/http にあるカスタムの fetch ラッパー	チームが構築したラッパーを使う
新しいヘルパー関数	既存の utils/ にあるユーティリティ群	新たに作成する前に utils/ を調べる
フラットなファイル構成	機能ごとにフォルダーをネストする構成	既存のディレクトリ設計に従う
デフォルトエクスポート	すべて名前付きエクスポート	リポジトリのエクスポート規約に合わせる
緩い any 型	ジェネリクスを使った厳密な TypeScript	プロジェクトの型付け方針に合わせる
let 宣言	原則として const	既存の変数宣言の習慣を踏襲する
生の SQL 文字列	ORM のクエリビルダー	プロジェクトのデータアクセス層を使う

コミット前の確認

最終確定する前に、次の点を確認してください。

• ファイルが適切なディレクトリにある（同種のファイルと同じ場所にある）
• ファイル名が一般的な命名規則に従っている
• インポート順序とエイリアスの使用方法が既存のスタイルに合っている
• すべての識別子（変数、関数、型）が既存の命名規則に従っている
• エラー処理がリポジトリの標準的なパターンを踏襲している
• 新しい依存関係が既存のものと重複していない
• テストが既存のテストと同じフレームワーク、構成、命名規則に従っている
• ロギングにプロジェクトのロガーを使用している
• 元の作者が書いたかのようにコードが読める

認知の落とし穴

合理化	真実
「自分のアプローチのほうが客観的に優れている」	個人の好みより統一性が優先されます。コードベースに合わせてください。
「こちらのほうが現代的な手法だ」	現代的だからといって、このリポジトリに適しているとは限りません。既存の実情に合わせてください。
「たった1つのファイルにすぎない」	逸脱したファイルが1つあるだけで、さらに10個の前例になります。エントロピーは積み重なります。
「後で全体を統一する」	そうはなりません。一貫性のあるレガシーコードより、部分的な移行のほうが有害です。
「現在のパターンには問題がある」	まず人間に相談してください。一方的な規約の変更は禁止です。
「この依存関係のほうが明らかに優れている」	単体で優れていても、重複を正当化する理由にはなりません。プロジェクトではすでに解決済みです。

ガードレール

禁止事項：

• すでに使用中のライブラリと機能が重複するライブラリをインポートする
• コードベースに馴染みのない命名規則を適用する
• 既存のディレクトリ構造に反する場所にファイルを配置する
• 人間から明示的な承認を得ずに、確立された規約を変更する
• 周囲のコードと見た目で区別できるコードを書く

必須事項：

• 書き始める前に、類似するファイルを2～3個確認する
• 新しいものを考案する前に、プロジェクトに既存のユーティリティを徹底的に活用する
• エラー処理、ロギング、検証のパターンをそのまま再現する
• 逸脱する前に許可を求める（「コードベースではXを使っています。Xのまま進めますか、それともYに移行しますか？」）

統合

補完的なスキル：

• godmode:ux-patterns -- UI コンポーネントの規約に適用される一貫性
• godmode:design-integration -- デザインシステムの使用に適用される一貫性
• godmode:quality-enforcement -- 乖離を検出する自動チェック

関連するスキル：

• godmode:codebase-research -- 外部のパターンを見つけます。このスキルは内部のパターンを徹底します
• godmode:system-design -- グリーンフィールドの構造を導きます。このスキルは確立されたコードベースを管理します