naming-skill

name	naming-skill
description	日本語または英語の意図から、短い英語名の候補を作り、kebab-case、snake_case、camelCase、PascalCase、dot.case、path/case、CONSTANT_CASE など change-case 由来の形式へ整形する。ファイル、スラッグ、メモ、スクリプト、文書、短い技術成果物の命名に使う。ブランド名、商品名、長いタイトル、一般的な翻訳、命名形式の制約が関係しない用途には使わない。

命名スキル

日本語または英語の意図から、短く扱いやすい英語名の候補を作る。

ワークフロー

1. 希望する命名形式を確認する。

   • 単語の連結形式やケース形式が指定されていない場合は、候補を出す前に一度だけ聞き返す。
   • 選択肢は簡潔に提示する: kebab-case, snake_case, camelCase, PascalCase, dot.case, CONSTANT_CASE。
   • 指定形式が珍しい、曖昧、または説明が必要な場合だけ、references/change-case-formats.md を読む。
   • 変換仕様の細部が必要な場合だけ、references/change-case-spec.md を読む。

2. 命名対象の意図を抽出する。

   • 何を表す名前なのか、対象・用途・役割を特定する。
   • 日付、バージョン、拡張子、ディレクトリ指定は、ユーザーが含めたいと明示した場合だけ意味要素として扱う。
   • 拡張子付きの名前を決める文脈で拡張子が指定されている場合は、変換後にその拡張子を維持する。

3. 日本語入力は直訳ではなく、意味が自然に伝わる英語へ意訳する。

   • 辞書的な逐語訳より、用途が分かる自然な英語表現を優先する。
   • フォーマット前の英語語句は最大4語に収める。
   • file, document, memo, data, new のような汎用語は、区別に必要な場合だけ残す。

4. 候補を生成する。

   • アイデア出しを求められた場合は、3〜7個の候補を出す。
   • 1つだけ求められた場合は、最有力候補を1つ出す。
   • すべての候補は、連結される英単語を最大4語までにする。
   • 抽象語だけでなく、用途が分かる名詞・動詞を優先する。例: invoice-summary, model-audit, user-feedback, release-notes。

5. 候補生成と形式変換の責務を分ける。

   • エージェントは、日本語または英語の意図を最大4語の自然な英語語句へ圧縮する。
   • ローカルスクリプトは、その英語語句を指定された形式へ機械的に変換する。
   • 原則として、最終出力は scripts/format_name.py "english phrase" --style "requested-style" で作る。
   • 拡張子が指定されている場合だけ --extension EXT を付ける。
   • 数字分割、区切り文字上書き、先頭・末尾文字保持が必要な場合は、--separate-numbers, --delimiter, --prefix-characters, --suffix-characters を使う。
   • camelCase / PascalCase の数字結合が必要な場合だけ --merge-ambiguous-characters を使う。
   • スクリプトが「4語を超える」と拒否した場合は、英語語句を短くして再実行する。
   • 変換ロジックを変更した場合は、scripts/verify_format_name.py を実行して代表ケースを検証する。

6. 結果を返す。

   • 推奨名を最初に示す。
   • 必要に応じて、短い, 具体的, 移植性が高い などの理由を一言添える。
   • 拡張子、ディレクトリ、形式に関する仮定が結果へ影響する場合だけ、その仮定を書く。

形式判断ルール

• 形式指定がない場合は推測せず、必ず聞き返す。
• ハイフン, ケバブ, slug, URL向け は kebab-case と扱う。
• スネーク, Python向け, underscore は snake_case と扱う。
• JS風, lower camel, キャメル は camelCase と扱う。
• クラス名風, upper camel, パスカル は PascalCase と扱う。
• 環境変数風, 定数風, 大文字スネーク は CONSTANT_CASE と扱う。
• ドット区切り, 設定名風 は dot.case と扱う。
• ディレクトリに分ける, path case は path/case と扱う。ただし、これは1つの名前ではなくパスを作る可能性があるため注意を促す。

品質基準

• ひと目で用途が分かる名前を優先する。
• 一時的な作業メモより、後から見ても意味が残る安定した概念を優先する。
• 不要な装飾、句読点、絵文字、全角文字、形式を壊す文字は避ける。
• summary, notes, analysis, final のように広すぎる名前は、より具体的な名詞がある場合は避ける。
• 拡張子付きの名前を求められ、ユーザーが拡張子を明示している場合だけ拡張子を維持する。

エラーハンドリング

• 日本語テキストだけが与えられ、形式指定がない場合は、名前を生成する前に希望形式を聞く。
• 指定形式が未対応の場合は、references/change-case-formats.md を読み、近い対応形式を提示して選択を求める。
• 変換結果が直感とずれる場合は、references/change-case-spec.md を読み、ローカルスクリプトの仕様に基づいて説明する。
• 意味を表す英語語句が4語を超える場合は、修飾語を削って圧縮してから整形する。
• path/case が1つの名前として指定された場合は、ディレクトリ分割を意図しているか確認する。必要なら kebab-case を代案として提示する。