project-naming

プロジェクト名

名前はリストではなく、表から選びます。候補はすべて、レジストリの行、意味の確認、オーナーがすでに気に入っている名前との比較スコアとともにオーナーに提示されます。まずオーナーの好みを尋ね、決して推測しません。

1 interview -> 2 brief -> 3 lanes (parallel) -> 4 machine check -> 5 meaning check
                   ^                                                      |
                   |                                                      v
              7 rejection round  <--  6 one table to the owner  <--  verdicts
                                              |
                                              v  (owner picks)
                                8 re-verify same day -> 9 record and "not checked"

適用する場面

• 「このプロジェクトに名前を付けて」／「もっといい名前はある？」／「パッケージの名前は何がいい？」
• 名前が却下された：発音しにくい、すでに使われている、または読者に誤った印象を与える
• 論文、ツール、データセットを公開する前に名前が必要

ワークフロー

1. ヒアリング

何かを生成する前に質問します。オーナーの回答がブリーフになります。回答なしで進めると、各レーンは生成側の好みに収束します。

Which two or three existing names do you like the SOUND of? (any product, any field)
What killed the last name, in your words?
What must this project be able to grow into?
Where will the name be claimed? (PyPI, npm, crates, Homebrew, Docker Hub, Maven, Hugging Face, GitHub, Bluesky, which domains, arXiv)
Which languages do your users read?

2. ブリーフ

回答を、すべてのレーンが参照する1ページにまとめます。名前を生成する前に、オーナーの承認を得ます。

exemplars:   <the names the owner likes>, scored 1 to 5 by closeness
vector:      <per exemplar: letters, syllables, stress, open or closed vowels, Latinate or Germanic, hard letters>
grows into:  <scope in one line>
claims:      pypi npm docker hf github dns:com,ai
languages:   <the languages the users read, from the interview>
hard gate:   the table under Conditions, plus anything the owner added
soft scores: exemplar closeness, elegance, room to grow

必須条件は共通です。オーナーの好みは参考例に反映されるため、同じスキルでもオーナーが異なれば、検索結果も異なります。

ベクトルは各参考例を一度ずつ分解し、各レーンが独自の印象ではなく、同じ6つの事実に基づいて類似度を評価できるようにします。たとえば、vercel と linear が好きなオーナーの場合：

vercel:  6 letters, 2 syllables, stress on the first, closed vowels, Latinate, no hard letters
linear:  6 letters, 3 syllables, stress on the first, open vowels, Latinate, no hard letters

3. レーン

スタイルごとに1つのレーンを並行して実行します（/orchestrator-mode スキルがインストールされている場合は、ファンアウトを担当します）。各レーンで名前を50〜100個ブレインストーミングし、条件を満たさないものを目視で除外したうえで、上位20個をステップ4のスクリプトで確認します。

レーン	生成する名前
実在する単語	よく知られたもの、珍しいものを問わず、既存の単語を1つ
造語	参考例に似た響きの造語
ラテン語またはロマンス諸語	ラテン語、イタリア語、スペイン語、ポルトガル語の語根から作った語形
比喩	その作業を連想させる物や場所
短い単語2つ	実在する2語を組み合わせた複合語
借用語	指定した言語から借用した、明確な意味を持つ単語

ブリーフのルールに合わないレーンは除外します。オーナーの参考例に、表にはない共通のスタイルがある場合はレーンを追加します。

ハーネスにパイプラインまたはワークフローツールがある場合、ステップ3〜6はエージェント間のやり取りではなく、1回の実行として処理します。各レーンは固定の形式（name、say it、3つのスコア、レジストリ、意味の判定、最終判定）で行を返し、除外した項目も報告します。候補が残らなかったレーンは、プロンプトを絞り込んで1回だけ再実行します。

統合時には、ブリーフの却下リストと照合して重複を取り除き、arXiv 列と github-repo 列を1回だけ実行します。

却下後の再検討（ステップ7）は実行の間に行います。ブリーフを書き直し、変更したレーンだけを再実行します。メッセージとして受け渡されるレーンの報告は切り捨てられますが、スキーマに沿った行は切り捨てられません。

4. 機械的なチェック

bun "<skill-dir>/scripts/check-name.mts" <name> <name> ...
bun "<skill-dir>/scripts/check-name.mts" --registries pypi,npm,docker,hf,github-user,dns-com,dns-ai <name>   # the brief's claims except github-repo

usage: check-name.mts [--domain <tld>]... [--registries <id,id,...>] [--no-arxiv] [--json] <name>...
       check-name.mts --list-registries
  --domain <tld>          a DNS column per zone (default: com, ai, dev; the list replaces the default)
  --registries <id,...>   the availability columns to run; the gate columns run on every name regardless
  --no-arxiv              skip the arXiv column (one request every three seconds)
  --json                  one JSON object, rows and failures, instead of the table
  --list-registries       the live column table: id, label, taken control, gate
exits: 0 every row printed and every control answered as expected;
       1 a control answered wrongly: the named columns are not evidence; 2 usage error

名前ごとに1行、レジストリごとに1列です。レジストリは scripts/columns/registries/table.mts の1つの表にまとめられており、--list-registries で一覧を表示できます。各セルの値は free、taken(<why>)、unknown(<why>) のいずれかです。ただし say 列の値は note(<reading>) です。

name    pypi  npm                 crates  homebrew                        docker                  maven  hf    github-user           github-repo  bluesky                arxiv  dns-com                     dns-ai  wiktionary                    urban                typosquat                                                         say
lumera  free  taken(npm package)  free    free                            taken(docker hub user)  free   free  taken(github handle)  free         taken(bluesky handle)  free   taken(lumera.com resolves)  free    taken(word in Italian,Latin)  free                 free                                                              note(ok(3s))
tarnix  free  free                free    taken(homebrew formula tarnix)  free                    free   free  free                  free         free                   free   free                        free    free                          taken(1 entry: ...)  free                                                              note(flag(2s; hard x))
numpi   free  free                free    free                            free                    free   free  free                  free         free                   free   free                        free    free                          free                 taken(1 edit from numpy on claimed pypi (top 5000 by downloads))  note(ok(2s))

• --registries は利用可否の列を選択します。ゲート列の say、typosquat、wiktionary、urban は、名前が何を指すかにかかわらず、すべての名前に対して実行されるため、対象を絞った実行でも省略できません。ハードゲートでは最初の2列を、ステップ5では意味に関する2列を、すべての名前について読み取ります。
• 各バッチでは、2種類の制御チェックも必ず実行されます。レジストリ列ごとに、そこで取得済みと分かっている名前（DNSではゾーン自体の委任先を表す @、Wiktionaryでは要注意の語義がある単語）と、どこでも未取得であるべきランダムな文字列を使います。どちらかに誤った応答を返す列は、stderr に制御チェック失敗として報告され、終了コードは 1 になります。その列の結果は読み取らないでください。
• unknown は free ではありません。レート制限された arXiv や 5xx は、テーブルでは unknown のままです。後で再実行するか、--no-arxiv で列を除外してください。
• arXiv は3秒に1回のリクエストを許可しており、スクリプトも同じ間隔を空けます。レーンでは --no-arxiv を指定し、リードがステップ6でマージ済みのショートリストに対して arXiv 列を1回実行します。
• Maven Central の検索では、一部のリクエストが30秒以上保留されます。そのため、スクリプトは検索を1件ずつ実行し、短い待機の後に再試行します。unknown(maven TimeoutError ...) のセルは、3回連続で保留されたことを示します。後で再実行してください。
• Docker Hub の ID は小文字の英字と数字で4～30文字です。この範囲外の名前は、Docker に拒否されるため unknown となります。未取得であることを意味するわけではありません。
• GitHub では、完全一致する名前のリポジトリは、スターが20個以上ある場合に取得済みと判定されます。トークンごとの検索制限に対応するには、GH_TOKEN を渡すか、gh にログインしてください。
• GitHub の検索上限は、トークンがある場合は1分あたり30回、ない場合は10回で、すべてのレーンで共有されます。そのため、スクリプトはトークンがある場合は検索の間隔を2秒、ない場合は6秒空けます。20件のバッチでは、github-repo 列の処理に約1分かかり、トークンがない場合は3分かかります。レート制限の応答は unknown(github search rate-limited; retry later) です。
• レーンでは --registries から github-repo を除外します。arXiv と同様に、リードがステップ6でマージ済みのショートリストに対してこの列を1回実行します。
• Homebrew の名前ごとのページが応答するのはエントリー自体の名前だけです（python は [email protected] のエイリアスで、ページはありません）。そのため、スクリプトはフォーミュラとキャスクのインデックス全体を読み取り、typosquat リストと同じキャッシュに1日間保存します。セルにはフォーミュラ名またはキャスク名が記載され、その名前がエイリアス、旧名、旧トークンのいずれかである場合は via alias、via old name、via old token が付きます。
• typosquat 列は、人気パッケージの名前から1文字編集（文字の追加、削除、変更、または2文字の入れ替え）した名前を調べます。セルにはパッケージ名、レジストリが claimed または unclaimed のどちらか（--registries で claimed のレジストリを指定し、指定しない場合はすべてのレジストリが claimed）、および該当するリストが記載されます。リストは OS の一時ディレクトリ内の check-name-cache に1日間保存されます。
• 読み取れなかったリストは、該当がある場合はその結果と同じセルに記載され（taken(1 edit from lumeras on unclaimed pypi (...); claimed crates lookup failed (crates ranking page 1 HTTP 503))）、該当がない場合はセルに表示されます。該当リストの取得元に失敗がある場合、そのリストは完全ではありません。それだけを衝突判定の根拠にする前に、再実行してください。
• 対象リストは次のとおりです。PyPI はダウンロード数上位5000件（公開されている top-pypi-packages JSON）、npm は npm-high-impact データセットのダウンロード数上位5000件（npm はランキングを公開しておらず、検索もあいまい検索ではありません）、crates.io はダウンロード数上位2000件（100件ずつのクレートリストから取得します。ランキングファイルは公開されておらず、検索で返るのは名前に一致するものだけで、1文字編集した先にある人気クレートではありません）。
• 公開元が提供する件数より短いリストは、短いランキングではなく、途中で切れたリストです。100件未満の crates ページや、この列が読み取る5000件未満の PyPI または npm リストは、同様にその取得元の失敗となります（claimed crates lookup failed (crates ranking page 7 reply malformed: page has 40 entries, expected 100)）。切り捨てられた後の名前は比較されていないためです。
• crates.io は自動化されたクライアントに1秒あたり1リクエストを求めています。プロセス内では、スクリプトはクレートの検索とランキングの20ページ取得の間隔を同じにします。20件のバッチでは、crates 列の処理にプロセスあたり約20秒かかります。
• プロセスをまたいだランキングの取得は1日1回です。ページに最初に到達したプロセスが、取得中はキャッシュエントリーの横にあるロックファイルを保持します。他のプロセスはそのロックを待ってから、書き込まれた内容を読み取ります。そのため、キャッシュが空の状態で6つのレーンを実行しても、ランキングの取得は1回だけで、約20秒です。
• say 列は綴りだけを読み取るため、結果は note であり、free や taken にはなりません。また、制御チェックも実行しません。結果は ok(<syllables>s) または flag(<syllables>s; <reasons>) です。Conditions の「綴りどおりに発音」の行に、各理由が記載されます。
• --json は、行と制御チェックの判定をレーンレポート用の1つのオブジェクトとして出力します。

5. 意味の確認

スクリプトはウィクショナリー列でページのウィキテキストを読み取り、すべての言語のすべての語義を調べ、そのいずれかにレジスターラベル（下品、侮辱的、差別語、軽蔑的）があればフラグを立てます。アーバンディクショナリー列では完全一致する項目だけを読み取ります。これで綴りが完全に一致する場合を確認できます。類音語や音訳については判断が必要なため、ステップ4を通過した名前について確認します。

for each survivor:
  say it aloud in every language the brief lists, then in Spanish, Portuguese, French,
    Italian, German, Hindi, Turkish, Arabic, Japanese, Mandarin, Russian, Korean:
    which word is it one sound away from?
  is it a drug, a perfume, a car, a company, an ML method? (one web search: "<name>" AI OR company OR app)
verdict per name: SERIOUS (the word named), MILD (the word named), NONE, each with its source

ネーミング会社では、ネイティブスピーカーがこのステップを行います。レポートには、モデルによって実施されたことが記載され、ステップ9の「未確認」項目に分類されています。

6. オーナーに渡す表は1つ

すべてのレーンの結果を、順位付けした1つの表にまとめます。各名前には必ず行が付き、行のない名前がオーナーに渡ることはありません。

名前	読み方	代表例 1～5	洗練度 1～5	成長性 1～5	登録簿	意味	判定
<name>	<stress and vowels>	<score>	<score>	<score>	<free, or the taken cells named>	<NONE, MILD: word, SERIOUS: word>	CLEAR / MINOR: <the one collision> / TAKEN

• CLEAR：申告対象の登録簿すべてで空きがあり、意味は NONE です。
• MINOR：オーナーが事情を理解したうえで受け入れられる衝突が1つあり、その内容をセルに記載します。
• TAKEN：必須条件を満たしません。除外した候補も見たいとオーナーが求めた場合に限り、表示します。

表を提出する前に、最終候補それぞれについてさらに2つの確認を行い、その結果を読み方と意味のセルに反映します。

• 知らない人に読んでもらう。 名前を一文字ずつ、予備知識のない新しいエージェントに伝え、名前を発音してもらい、聞いたとおりに綴り返してもらいます。発音が行の読み方セルと異なる場合、または綴りが名前と異なる場合は、MILD とし、知らない人の読み方を引用します。
• 見た目を確認する。 名前を小文字、タイトルケース、ターミナルコマンド（<name> --help）、短いアイコンラベルの4通りで書きます。誤読される表記（Iが小文字のlに見える、タイトルケースで単語の区切りを間違えるなど）があれば、その表記を行に記載します。

7. 却下後のラウンド

「どれも違う」という回答も情報であり、失敗ではありません。何が気に入らなかったのか、どの行が最も近かったのかを尋ねます。新しい代表例を使ってブリーフを書き直し、あと一歩だった候補を出したレーンを再実行します。通常は2～3ラウンドです。

8. 再確認

選ばれた名前だけを対象に、同じスクリプトで同じ日に、候補を提案したレーンではなく責任者が実行します。登録簿は毎週変わるため、判断記録の行には日付を付けます。

9. 記録

chosen:       <name>, claimed at <registries> on <date>
why it won:   <the exemplar it matched, the gate it passed>
not checked:  trademark offices, app stores, social handles, native-speaker review, <anything the brief skipped>

条件

いずれかの行でハードゲートに該当すると、その名前は失格です。

ゲート	失格となる条件
綴りどおりに発音される	say 列に次のいずれかが記載されている場合：hard x,q,z,k、doubled ll、cluster str（子音が3つ連続）、two readings（ch、gh、ough、ea、語尾の e、または e、i、y の前の c と g に2通りの読み方がある）、spoken digits 1,2,3（数字が発音され、1音節として数えられる）
短い	音節が3つを超える、文字数が約8文字を超える、または単語が複数ある
空いている	ブリーフで対象としているいずれかのレジストリですでに取得されている、または完全一致する名前のリポジトリに20以上のスターがある
近隣で使われていない	AI 企業、製品、または ML 手法ですでに使われている（ウェブ検索）
悪い意味がない	いずれかの言語で重大な意味が見つかった
誤った印象を与えない	その名前に意味があり、その意味がプロジェクトの内容と一致しない
タイポスクワッティングではない	typosquat 列に、ブリーフで対象としているレジストリ上のパッケージが記載されている。対象外のレジストリでの一致は軽微な注記とする

意味は、一目で明らかであるか、存在しないかのどちらかです。意味のない名前は合格です。誤った意味を持つ名前は失格です。読み手が意味を解読する必要がある名前（しゃれ、引用、何段階もの連想が必要なもの）は、原則として却下されます。

ソフトスコアはそれぞれ1〜5で、表に表示されます。ゲートでの失格を覆すためには使いません。

• 手本との近さ：主要スコアです。ステップ1でオーナーが挙げた名前にどれだけ似ているかを評価します。
• 上品さ：柔らかい子音、開いた母音、小文字とタイトルケースのどちらでも読みやすいことを評価します。
• 成長の余地：プロジェクトが成長しても、特定の機能に縛られないことを評価します。

ブリーフに別段の記載がない限り、次のものは原則として却下されます：頭字語、x q k z の文字、重複文字、子音の連続、接尾辞 -lens -scope -lux -ly -ify、バージョン番号、使い古された引用（jarvis、alfred、hal）。

スクリプトで確認しない項目

商標登録簿、アプリストア、Bluesky 以外のソーシャルハンドル、登録済みで未解決のドメインは確認しません。オーナーが後から主張に遭う可能性がある項目を把握できるよう、判断記録には毎回「未確認」として記載します。

Go モジュール：モジュールパスは URL（github.com/<owner>/<name>）なので、単独の名前はそこで取得できません。また、pkg.go.dev は検索結果を HTML としてのみ提供します。GitHub の列では、そのパスが指すリポジトリを確認します。

関連項目

• /verify-with-controls：ステップ4の対照行は、ルール2（ゼロを信頼する前に陽性対照を確認する）とルール6（チェッカーが失敗する様子を確認する）に対応します。
• /orchestrator-mode：インストールされている場合、ステップ3のレーンを並列サブエージェントとして実行します。