一貫性のある命名

一貫性のある命名 は何をしますか？

ランダムな名前は禁止です。すべての新しい名前は、まるでそれがすでにターゲットツリーに属していたかのように見える必要があります。ファイルも含めて。

ハードルール

新しい名前を提案または記述する前に、次の手順を実行します：

1. 命名スコープを選択します（references/scope.md）： 兄弟要素 → パッケージ → gitルート → ディスク上の兄弟プロジェクト → ハウスデフォルト。
2. そのスコープで scripts/survey-names.sh を実行します（新しいプロジェクトの場合は --siblings フラグも）。
3. 名前の種類に応じて references/rules.md を読みます。
4. 1つのプライマリ名と、最大2つの代替案を提案します。それぞれ、調査結果からの具体的な例で正当化します。
5. パターンが競合する場合は、ローカルネイバーフッドを優先し、その理由を一文で説明します。

周囲を無視した可愛い名前、ミーム、一回限りの名前を採用してはいけません。リポジトリBのスタイルを、リポジトリBを調査せずにリポジトリA内で再利用してはいけません。

ワークフロー

1. 名前の種類を分類します（references/kinds.md）： プロジェクト、パッケージ、ディレクトリ、ファイル、システム/設定ファイル、コンポーネント、テスト、環境変数、ブランチ、スキル、CLI、API/ルート。

2. 所有パスを調査します（ランダムなワークスペースルートではありません）：

   scripts/survey-names.sh [path]
   # 新しいプロジェクト/プロダクトのステムの場合も：
   scripts/survey-names.sh --siblings [parent-of-projects]
   

3. そのフォルダ内のその種類に合わせて、ケースとセパレータを一致させます （kebabのディレクトリ、PascalCaseのコンポーネント、SCREAMING_SNAKEの環境変数、固定ツールファイル名）。

4. そのツリー内にすでにある語彙と一致させます。語幹を再利用し、同義語フォークを避けます （auth/ と authentication/ を隣接させない）。

5. 衝突をチェックします。調査結果、兄弟リポジトリ、PATH/パッケージ名と照合します。 2、final、new、copy のような接尾辞は禁止です。

6. 出力：

   プライマリ: <名前>
   スコープ: <調査したパス>
   パターン: <ルール + 1〜2つの実際の例>
   却下された案: <代替案とその理由>
   

ファイルとシステムファイル

• 通常のソースファイル：兄弟のベース名スタイル + 拡張子を正確に一致させます。
• システム/設定/ツーリングファイル：慣用的な固定名を優先します （.env.example、docker-compose.yml、AGENTS.md、flake.nix、ワークフローkebab名）。references/scope.md を参照してください。

空の場合のデフォルト

調査でほとんど何も見つからなかった場合は、references/defaults.md を使用し、最初の名前から一貫性を保ちます。

アンチパターン

• そのスコープ内にすでにそのテーマが存在しない限り、ランダムな動物/食べ物のコードネーム
• 新しいパス内のスペース；kebabの兄弟の横にあるTitle Caseフォルダ
• 同じフォルダ内での camelCase と kebab-case ファイルの混在
• 調査せずに、このワークスペースのハウススタイルを無関係なリポジトリに適用すること
• 必須のシステムファイル名の「改善」（package.json → pkg.json）
• utils2.ts、helpers-new.ts、tmp-final.tsx

バンドルリソース

パス	使用タイミング
scripts/survey-names.sh	命名前には常に
references/scope.md	マルチリポジトリ、ファイル、システム/設定名
references/rules.md	種類ごとのケース/セパレータ
references/kinds.md	要求の分類
references/defaults.md	グリーンフィールドのみ