namekit

namekit

空白のページからではなく、規約に基づいてプロジェクトに名前を付け、実際に空いている名前だけを返します。明確に分かれた2つのモードがあります。

• generate。 プロジェクトの説明をもとに、ユーザーの命名規約に沿った候補を優先順位付きで絞り込みます。その後、ユーザーが選んだ2つか3つの候補について、ドメイン、npm、GitHubの名前空間を確認し、1つを選びます。
• check。 ユーザーがすでに考えている名前を受け取り、それぞれが空いているかを報告します。名前の生成は行いません。

これが一言で済む依頼ではなく、スキルである理由は、モデルに任せきりにすると、1つのアイデアの表記違いを10個返し、誰も使っていない規約をでっち上げ、候補がすでに使われているかを確認しないためです。namekitは、この3つすべてをその順番どおりに解決します。

どのようなときに使うか

• generate。 「このプロジェクトに名前を付けて」「何と呼べばいい？」「名前のアイデアを出して」「Xの名前を考えて」「新しいSaaSの名前が必要」。
• check。 「growaloyは使われている？」「この名前が使えるか確認して」「このnpmパッケージは誰かに取られている？」

説明が示された依頼にはgenerateを使います。名前が示された依頼にはcheckを使います。ユーザーが両方を示した場合は、まずその名前をcheckし、次にgenerateを提案します。ユーザーがすでに気に入っている名前は、こちらが考案する名前より優先されるためです。

確認方法（両モード共通）

3つの名前空間を、3つのコマンドで確認します。それぞれが公開HTTPコントラクトなので、安全に固定できます。

# domain registration: 404 = not registered, 200 = registered
curl -s -o /dev/null -w '%{http_code}' -L --max-time 10 https://rdap.org/domain/<name>.com

# npm package: 404 = free
curl -s -o /dev/null -w '%{http_code}' --max-time 10 https://registry.npmjs.org/<name>

# GitHub org or user handle: exit 0 = taken; "HTTP 404" on stderr = free
gh api /users/<name> --silent

判定として扱うのは、一覧に記載された応答だけです。 ドメインまたはnpmのステータスが200でも404でもない場合（429、5xx、タイムアウト時の000など）は、不明です。gh apiの場合、終了コードが0なら使用中、標準エラーにHTTP 404と記載された終了コードが0以外の場合に限り、空いています。それ以外の失敗は不明です。gh help exit-codesには、1はあらゆる失敗、2はキャンセル、4は認証情報の不足を示すと記載されており、いずれもハンドルが空いている証拠にはなりません。不明な確認は1回再試行してください。再試行後も結果が不明な名前は、候補から外すことも、空いている名前として選ぶこともできません。該当する名前空間を不明と報告し、その理由を示してください。

.comに加え、プロジェクトの用途に合った2つ目のTLDを確認します（開発者向けツールなら.dev、モデル製品なら.ai、地域のユーザーが対象なら国別TLD）。プロジェクトで使わない名前空間は確認を省略します。CLI専用ツールにnpmの名前は不要で、内部向けツールにドメインは不要です。

一度に確認する名前は2つか3つにしてください。 RDAPは少数の一括問い合わせに応答し、短時間に集中して問い合わせると429を返します。429は判定ではありません。数十個の名前を一括で確認すると、ドメインに関する結果を自ら台無しにします。

それぞれの結果は、確認方法が示す範囲内で報告してください。 RDAPの404は、そのドメインが登録されていないことを意味します。そのドメインが販売中であること、手頃な価格であること、商標上の問題がないことを意味するわけではありません。「登録されていません」と伝え、価格はユーザー自身に確認してもらってください。

確認できない場合は、そこで止めずに続けてください。 シェル、ネットワーク、またはghを利用できない場合は、省略した確認項目を伝え、4つの評価基準だけに基づく優先順位付き候補を返してください。制約を明記した候補リストのほうが、候補が何もないより役に立ちます。

---

モード：generate

1. 言い換えてから、ヒアリングする

質問する前に、プロジェクトの説明を1文で言い換えてください。読み違いをしても、ここなら訂正の1行で済みますが、後になれば候補のショートリスト全体を作り直すことになります。

続いてヒアリングします。候補のプールは6項目です。説明から答えがわからない項目だけを尋ねてください。説明が完全に見えても、ヒアリングを省略するのではなく、各項目を説明と照らし合わせて確認してください（「SMB向けAIグロースプラットフォーム」とあっても、対象者、トーン、用途が明示されているわけではありません）。質問は最大5つとし、まとめて一度に尋ねてください。

1. 何をするものか。 分野と成果。
2. 誰向けで、どの言語で読むか。 ベンガル語を読む人々が対象なら、その言語の語根が候補になります。英語のみの対象者なら除外されます。
3. トーン。 親しみやすい、技術的、または遊び心のあるもの。
4. 含めたい言葉、避けたい言葉。 創業者には通常、それぞれ1つずつあります。
5. 名前をどこに入力するか。 ドメイン、パッケージ名、CLI コマンド、組織ハンドル。これにより、許容できる長さと実行する検証方法が決まります。
6. どれほど長く使うか。 一時的な社内ツールと、10年間守り続ける製品では、かけるべき労力が異なります。

完了の条件：未回答のプール項目すべてに回答があるか、明示的に「重要ではない」とされており、言い換えに対する訂正がないこと。

2. 命名規則を決める

以下の順に確認し、答えが見つかった最初の段階で止めてください。

1. 明示されている。 ユーザーが規則をはっきり指定している（「すべてに aloy を接尾辞として付ける」など）。
2. 例から導き出せる。 ユーザーが自身の名前を例に挙げている（codealoy、growaloy、saasaloy のように）。共通する末尾が規則です。
3. 依頼があった場合に、リポジトリから読み取る。 ユーザーがリポジトリを参照するよう求めた場合に限ります：gh repo list <owner> --limit 100 --json name。フォークではなくプロジェクトを確認してください。フォークの名前は、別の人の命名規則だからです。
4. 尋ねる。 接尾辞、接頭辞、かばん語、または規則なしを提示してください。

実行するたびに、命名規則をあらためて確認してください。 保存したり、kit のような標準規則で代用したりしないでください。ユーザーが考えを変えれば保存した規則は古くなりますが、すでに公開した名前はそのまま使われます。

決定した命名規則を出力に明記してください。 読み違いがあっても、候補のショートリストを破棄するのではなく、訂正の1行で済みます。

完了の条件：命名規則が接辞とその位置として書き留められているか、規則を使わずに進めることがユーザーによって選択されていること。

3. 語根を集め、候補を作る

4つの異なる情報源から語根を集めてください。1つのアイデアの言い換えばかりではなく、本当に多様な候補を揃えるためです。

• 分野を表す名詞。 何に関するものか：code、saas、ledger。
• 成果を表す動詞。 誰かに何をもたらすか：grow、ship、learn。
• ユーザー、またはユーザーが扱うもの。 誰が使うか：dev、shop、desk。
• メタファー、または非英語の語根。 ヒアリングで非英語を使う対象者が挙がった場合。

非英語の語根は、1つの条件を満たす必要があります。一般的な使用において、ラテン文字での表記が1つに定まっていることです。実際に2通りの綴りがどちらも使われている語根は、評価を下げるのではなく除外してください。対象者が名前を3通りに入力するようでは、名前に求められる唯一の役割を果たせないからです。

各語根を連結ルールに従って接辞と組み合わせ、評価基準に沿って採点してから絞り込んでください。生の候補を25個以上作成し、上位12個をショートリストにまとめてください。幅を持たせるのは意図的です。ユーザーは1回につき2〜3個の名前を検討するため、リストを複数回使ってから再生成できるだけの候補が必要です。

完了の条件：順位付けされた12個に、4つの情報源のうち少なくとも3つから語根が使われており、それぞれに1行の根拠と、評価基準に基づく判定が付いていること。

4. 候補リストを提示してから、ユーザーが選んだ名前を調べる

調査を始める前に、順位付けした12件を提示してください。 名前を先に、名前、ルート、出典、境界ケース、評価基準の判定を含む表にまとめます。この時点では利用可能かどうかの列はありません。ユーザーはリスト全体を読んでアイデアに反応でき、作業の創造的な部分に集中できます。

次に、調べたい名前を2つか3つ選んでもらいます。AskUserQuestion が使える場合はそれを使い、使えない場合は一行で尋ねてください。調べるのはユーザーが選んだ名前だけです。 選ばれなかった名前は、評価基準のスコアがどれだけ高くても調べません。

選ばれた名前について調査を実行します。該当があれば、その名前を除外します。 ここでの利用可能性は評価ではなく判定です。ユーザーが取得できない名前は候補にならないためです。

例外は1つです。ユーザーがすでに所有している名前空間は通過し、「あなたのもの」と判定されます。 リポジトリがある場合は Git のリモートから所有者を特定し（gh repo view --json owner）、そうでない場合はその規約の出典となったリポジトリから特定します。どちらでも特定できない場合は、一度だけ尋ねてください。この例外がなければ、独自の命名規約が自社のポートフォリオを拒否してしまいます。これが、codealoy が codealoy のフィルターで失敗する理由です。

あるバッチで利用可能な名前が1つもなかった場合は、各候補について、除外の原因となった調査結果を報告し、まだ調べていない候補を再掲して、次の2つか3つを選んでもらいます。利用可能な名前が見つかるか、ユーザーが中止するまで、この手順を繰り返してください。次のバッチを自動選択してはいけません。選ぶのはユーザーです。

リストを使い切った場合に限り、候補を再生成します。 12件すべてを調べて取得済みだった場合は、取得済みのルートを除外してルートを抽出し、候補を作成するをもう一度実行し、同じ方法で新しいリストを提示してください。生成は最大2回までです。

完了条件は、調べたすべての名前空間で利用可能な名前が少なくとも1つあること、またはユーザーがループを中止することです。また、調べた名前すべてに、実施した各調査の結果として利用可能、取得済み、または不明のいずれかが付いている必要があります。

5. 最有力候補を決めてから、検索を1回だけ行う

評価基準で最も上位の利用可能な名前を最有力候補にします。次に、その名前だけを対象に、レジストリでは見つからない既存の製品や有効な商標がないか、ウェブ検索を1回実行します。検索結果だけでは対象が何なのか曖昧な場合は、上位の検索結果を取得してください。

該当があれば、次に利用可能な名前を新たな最有力候補とし、1行で競合を説明します。新たな最有力候補についても、報告する前に個別に検索してください。最有力候補が検索を通過するまで繰り返します。利用可能な次点候補が残っていない場合は、その旨を伝えて、候補選択のループに戻します。検索するのは最有力候補だけです。レジストリ検索は完全一致で低コストですが、ウェブ検索は曖昧で高コストです。そのため、結果が判断を変える段階になって初めて検索を行います。

完了条件は、最終的な最有力候補が検索済みで、問題が見つからないこと、または最有力候補にできる利用可能な名前が残っていないことです。

6. 引き継ぎ

このスキル内の引き継ぎはすべて、手順を示す文体で記述してください。1文につき1つの指示とし、能動態、現在形を使い、比喩は使わないでください。

3つの要点の前に、調査した名前をランキング表で出力します。

名前	語根（由来）	接合部	評価基準	.com	npm	GitHub
growaloy	grow（成果を表す動詞）	明確な接合	4/4	空きあり	空きあり	空きあり

変更点。 解決した命名規則、選出した名前、その理由を1文で報告し、ユーザーが調査したバッチ数と、2回目の生成パスを実行したかどうかを伝えます。レジストリで取得済みだった、調査対象の各名前と、それを除外した調査結果を記載します。未調査のまま残った候補を列挙し、ユーザーが後から選べるようにします。

保存先。 namekit はデフォルトではファイルを書き込みません。ユーザーが依頼した場合に限り、docs/names/NNNN-names-<slug>-YYYY-MM-DD.md に書き込みます。<slug> はプロジェクト名を短くしたケバブケース形式で、日付はファイルの作成日です。連番 NNNN を取得するには、現在のワークツリー、git worktree list に記載されたすべての他のワークツリー、および origin/HEAD（git fetch origin の後に git ls-tree --name-only origin/HEAD docs/names/ を実行）で、docs/names/ 内の先頭4桁の最大連番を調べ、それに1を加えます。該当する連番がない場合は 0001 から始めます。並行しているワークツリーが同じ連番を取得しないよう、3つすべてを調べます。リモートがない場合など、失敗するソースはスキップします。git がない場合は、そのディレクトリだけを一覧表示します。連番はディレクトリごとに管理し、再利用しません。後から編集する場合も、名前全体は変更しません。ホストリポジトリに独自の成果物規約が記載されている場合は、それに従います。ファイルシステムがない場合は、ドキュメントをコードブロックで出力し、ファイル名を示します。

次の手順。 次のアクションを1つ選びます。名前は決まりましたが、まだ誰にも所有されていないため、次はプロジェクトが実際に必要とする名前空間を取得します。その順序は、インタビューでの型付きサーフェスに関する回答に従います。インストールされている場合は repokit で新しいリポジトリの About パネルとトピックを設定し、それ以外の場合は gh repo create を使います。名前がアイデア出しのセッションで生まれた場合は、次点の候補として ideakit を挙げ、そのアイデアの記録に決定を残します。namekit はドメインを登録せず、パッケージを公開せず、組織を作成しません。

接合部のルール

不適切な名前は接合部から生まれます。どの命名規則も3つのケースで扱えます。これは特定の接辞ではなく、接合部で文字がどうつながるかに関するルールだからです。

• 明確な接合。 語根の末尾と接辞の先頭が重ならないため、そのまま連結します。code + aloy → codealoy。接頭辞形式：open + forge → openforge。
• 音の省略。 文字が重なるため、重複部分を省きます。data + aloy → dataloy。dataaloy にはしません。接頭辞形式：auto + optimize → autoptimize。
• 却下。 接合部で母音が連続したり、声に出して読みにくい音節ができたりし、省略しても解消できない場合は却下します。idea + aloy は省略すると idealoy になりますが、「ideal-oy」のように読めます。語根を捨てて別の候補を選びます。

評価基準

評価項目は4つで、それぞれ「合格」「弱い」「不合格」で評価します。合格の数で順位を付け、同数の場合は意味の適合度で決めます。

• 意味の適合度。 語根が、そのものの働きを表しています。
• 響き。 3〜4音節で、初見でも正しく読めます。
• 接合部の品質。 接合部のルールに従い、明確な接合または自然な省略になっています。
• 聞いてつづれること。 名前を聞いた人が、1通りのつづりで書けます。

空き状況は意図的に評価対象から外しています。空き状況は候補を絞ってから、ユーザーが選んだ名前を調査する段階で判断するものであり、まだ調査していない名前の順位を付ける評価基準に含めるべきではないため、5つ目の基準にはしません。

---

モード：check

ユーザーが指定した名前に対して、調査を実行します。候補は生成せず、順位付けも絞り込みもしません。絞り込む候補リストがないためです。

同じ所有者の例外を適用します。名前空間の解決先がユーザー自身の所有者であれば、「取得済み」ではなく「自分のもの」と判断します。ユーザーはすでに半分ほど所有している名前を確認することが多いため、これはよくあるケースです。

引き継ぎ

変更内容。 各名前について、各名前空間での結果（空き、使用中、不明、自分が所有）を1行ずつ報告します。不明の場合は、その理由を記載します。スキップしたプローブを明記します。

反映先。 何も書き込まれておらず、何も登録されていません。その旨をはっきり伝えます。

次の手順。 結果をもとに、次のアクションを1つ決めます。名前が空いている場合は、確保するのが次のアクションです。そのため、新しいリポジトリでrepokitがインストールされている場合は、そのメタデータにrepokitを指定し、そうでなければgh repo createを実行します。すべての名前が使用中の場合は、同じアイデアを軸に新しい語幹を探すgenerateが次のアクションです。

---

注記

• namekitは名前を付けるだけです。 ロゴ、タグライン、ポジショニング、ブランドアイデンティティの作成や、既存のコードベースの識別子の変更は行いません。
• ソーシャルメディアのハンドルは対象外です。 ソーシャルプラットフォームへのヘッドレスチェックはレート制限があり、誤った結果を返すこともあるため、誤った「使用中」は、回答が得られないよりも問題です。
• ページをスクレイピングするより、プローブのステータスコードを優先します。ステータスコードは安定した仕様ですが、ページはそうではないためです。