nomen

Nomen

このスキルを使って、プロジェクト、製品、アプリ、パッケージ、CLI、機能、チーム、ブランドの名前を生成、批評、検証します。

名前の使用可能状況は時間とともに変わります。実際の候補を検証するときは、競合、パッケージ名、ドメイン、商標について判断を示す前に、最新の情報源を検索してください。使用可能状況の確認結果は証拠として扱い、法的助言とはみなさないでください。

参考資料

候補の生成、命名アプローチの説明、または名前の検証を行う際は、references/name-strategies.md を読み込んでください（「Validation Caveats」セクションは検証モードに適用されます）。

開始

呼び出されたときは、次の手順に従います。

1. nomen スキルを使用していることを伝えます。
2. ユーザーが名前の生成、検証、改名、批評のどれを希望しているかを判断します。
3. コードベースを扱う場合は、まず関連するコンテキストを調べます。
   • README.md
   • package.json
   • docs/vision.md
   • docs/brand-system.md
   • アプリ、パッケージ、コマンド、ドメインのフォルダー名
   • 既存の公開名、製品の説明文、環境変数のプレフィックス
4. 名前の候補範囲を大きく左右する制約に限り、不足している情報を尋ねます。

質問の例：

• 何に名前を付けますか？
• 誰を対象としていますか？
• 技術的、編集的、高級感のある、遊び心のある、実用的、組織的な印象のうち、どれを望みますか？
• 避けるべき単語、音、言語、カテゴリーはありますか？
• ドメイン、パッケージ名、CLI バイナリ、SNS のハンドル名、法的確認が必要ですか？

判断に必要な情報が不足している場合は、一度に一つの質問をします。情報が足りている場合は、明示した前提に基づいて進めます。

生成モード

ユーザーが少数の候補を求めていない限り、真剣に検討できる候補を8〜12個生成します。一つのパターンに偏らず、複数の戦略を使います。

• 動詞の名前
• メタファーを使った名前
• 複合語の名前
• 短い単語の名前
• 混成語の名前
• 接頭辞や接尾辞を変えた名前
• 分野固有の表現を使った名前
• 響きやリズムを重視した名前

各候補について、次の内容を含めます。

• 使用した戦略
• 製品に適している理由
• 発音や綴りに関するリスク
• トーンとカテゴリーへの適合性
• 詳細な検証前に把握できる明らかな競合リスク

水増しは避けてください。ユーザーから求められない限り、冗談めいた名前は含めないでください。

検証モード

名前を検証するときは、依頼に適した最新の情報源を確認します。各プロバイダーやレジストリで、ネットワーク、認証、レート制限に関するエラーが発生した場合、使用可能とは判断せず、不明として扱います。信頼できる情報源による「見つからない」という応答と、検索の失敗を区別します。

• 正確な名前と関連語を使って、ウェブ全般を検索します。
• 開発者向けの名前の場合は、GitHub リポジトリと組織との競合を確認します。具体的には、完全一致するオーナー名とリポジトリ名に対して gh api "repos/OWNER/NAME" を実行します（200 = 既存のリポジトリ、404 = この認証情報からは確認できない。非公開リポジトリが含まれる場合があります）。また、名前の混雑度を把握するため、gh search repos NAME --limit 20 を実行します。
• 関連する場合はパッケージレジストリを確認します。具体的には、npm view NAME name を実行します（レジストリ固有の「見つからない」という応答を確認してください。ネットワーク、認証、レート制限のエラーは、未公開ではなく不明を意味します）。または、pip index versions NAME、cargo search NAME、gem list -r -e NAME を実行します。レジストリの404は、その名前を登録できることを意味しません。npm は既存のパッケージに酷似した名前（句読点やタイポスクワッティングに関するルール）を拒否し、スパム対策で予約された名前や未公開の名前も404になります。404は「現在公開されていない」と解釈し、「自分が取得できる」とはみなさないでください。
• 指定されたTLDについて、ドメインとDNSの状況を確認します。
• アプリストア — 名前を付ける対象がモバイルアプリまたはデスクトップアプリである、あるいはその可能性がある場合は、必ず確認します（以下の「アプリストアの確認」を参照）。これは忘れやすく、見落とした場合の損失も大きくなります。App Storeで名前が重複していると一般公開できなくなります。また、npmやドメインでは使える名前でも、すでに公開済みのアプリに使われている場合があります。
• 競争の激しい場合は、製品ディレクトリ（Product Hunt、アプリストアのカテゴリー一覧）を確認します。
• ユーザーが明示的にそのレベルの確認を必要としている場合に限り、商標データベースを確認します。

App Store の確認

Apple の公開 iTunes Search API にキーは不要です。対象に応じてエンティティを選択してください。iPhone アプリには software、iPad アプリには iPadSoftware、Mac アプリには macSoftware を指定し、該当する各プラットフォームを検索します。プラットフォーム、国、検索日を報告してください。検索結果は競合の兆候であり、登録可能であることの証明ではありません。結果が指定した上限に達した場合は、検索範囲を広げるか条件を絞り込んでください。網羅的に検索できたと主張してはいけません。検索語を URL エンコードしてください（スペースをそのまま指定すると、クエリは警告なしに途中で切り詰められます）。アプリが他の地域を対象とする場合は、country を us 以外にも広げてください。地域限定アプリは、そうしないと表示されません。

curl -s -G "https://itunes.apple.com/search" \
  --data-urlencode "term=NAME" \
  --data "entity=software&limit=20&country=us"

JSON の results[] から各 trackName / sellerName を確認し、次の内容を報告してください。

• 名前が完全一致する場合（trackName が名前と一致するかを、大文字と小文字を区別せずに比較します。App Store では「Clipper」と「clipper」は同じ名前の競合として扱われます）→ App Store でその名前は使用されています。
• 前方一致する場合（trackName が NAME 、NAME:、NAME - で始まる）→ 類似した名前の競合です。
• カテゴリの飽和状態（名前にその単語が含まれるだけのアプリが多数ある場合。例：「clipping」アプリが十数個ある場合）。単独の名前が空いていても、カテゴリが飽和していれば名前の独自性に乏しいため、注意点として挙げる価値があります。

Android については、NAME site:play.google.com をウェブ検索するのが実用的な代替手段です。

1 件の検索結果をうのみにせず、検証する

登録状況の確認には、信頼できるレジストリの RDAP またはレジストラの検索を利用し、失敗した応答をすべて「見つからない」と見なさず、エラーの内容も確認してください。DNS と HTTP は利用実績を示す補助的な証拠であり、登録可能性の確認にはなりません。サイトが稼働していれば、そのドメインが使用中であることを強く示します。dig +short NAME.TLD NS の結果が空でも、未登録であるとは判断できません。登録済みのドメインでも、委任されていないことがあります（ICANN のステータス定義）。兆候が食い違う場合や、レジストリの検索に失敗した場合は、ステータスを未解決として報告し、既存の利用を示す証拠を残してください。未登録のドメインであっても、予約済みであるなどの理由により登録できない場合があります。

慎重な表現を使ってください。

• 検索で問題が見つからない場合は、「明らかな競合は見つかりませんでした」と述べてください。
• ドメイン、パッケージ、またはアプリストアの名前が使用されているように見える場合は、「利用できない可能性が高い」と述べてください。
• 有資格者による商標調査が行われていない限り、名前が法的に使用可能であるとは述べないでください。
• ユーザーの明示的な承認なしに、購入、登録、予約、または権利の主張を行ってはいけません。

出力

候補を順位付けしたショートリストとして提示してください。最終候補ごとに、以下を含めてください。

• 名前。
• 根拠。
• 適合性。
• リスク。
• 検証の証拠。
• 次に推奨するアクション。

最後に、単なる候補一覧ではなく、明確な推奨を示してください。

改名モード

既存プロジェクトの名前を変更する場合：

1. パッケージ名、CLI コマンド、ドキュメント、環境変数のプレフィックス、API 識別子、アプリのタイトル、リポジトリ名など、変更が必要になる可能性のある公開箇所を特定します。
2. ブランド名の変更作業と技術的な移行作業を分けます。
3. ユーザーが実装を明示的に依頼しない限り、識別子を変更してはいけません。
4. 実装を依頼された場合は、対象範囲内の使用箇所を選択した名前に更新してください。移行が承認されるまでは、サポート対象の外部契約を維持してください。ブランド名を変更するだけでは、公開済みの識別子を破壊的に変更する許可にはなりません。

完了前の確認

完了する前に、以下を確認してください。

• 候補が製品と対象ユーザーに合っている。
• 少なくとも 3 つの命名戦略を使用した。
• 検証結果が最新で、適切な留保が付されている。
• 対象がアプリである、またはアプリになる可能性がある場合、npm やドメインだけでなく、App Store（該当する場合は Play Store も）を確認した。
• 利用可能性の主張を、複数の情報源で照合した（特に「利用可能」という判定を、単一の RDAP/WHOIS 検索結果だけに頼っていない）。
• 推奨でトレードオフを説明している。
• 未解決の法務、ドメイン、またはパッケージに関する問題が明記されている。