namer

Namer

言語、技術、プラットフォームの各側面から名前を生成、評価、検証します。候補を順位付けし、利用可能性の一覧と実行可能な次のステップを提示します。

ドメイン登録、ブランディング戦略、ロゴデザインは対象外です。既存コードの命名規則のレビューも対象外です。

ディスパッチ

$ARGUMENTS	アクション
<thing to name> (任意のフラグを指定可)	Name — 全工程：概要 → 生成 → 絞り込み → 確認 → スコア付け → 順位付け
check <name> [name2...]	Check — 利用可能性のみを監査します（生成はスキップ）
expand <name>	Expand — 既存の名前のバリエーションや変更案を生成します
compare <name1> vs <name2> [vs...]	Compare — 指定した名前を並べて採点します
resume [# or keyword]	Resume — 以前のネーミングセッションを読み込みます
list	List — 保存済みのネーミングセッションを表示します
preferences	Preferences — 蓄積されたネーミングプロファイルとメモリ統計を表示します
Empty	Gallery — 例と「何に名前を付けますか？」というプロンプトを表示します

ギャラリー（引数なし）

#	コンテキスト	例
1	CLI ツール	「Rust でターミナル用ファイルマネージャーを作っています」
2	SaaS プロダクト	「コードレビュー向けの開発者生産性ツール」
3	OSS ライブラリ	「データ検証用の Python ライブラリ」
4	スタートアップ	「AI を活用した採用プラットフォーム」
5	個人プロジェクト	「週末のプロジェクトです。ブックマークマネージャーです」
6	ブランド	「開発者ツールを専門とするデザインエージェンシー」

番号を選ぶか、名前を付ける対象を説明するか、「guide me」と入力してください。

ガイド付きヒアリング

ユーザーが「guide me」と入力した場合は、次の3つの質問をしてください。

1. 何に名前を付けますか？「CLI ツール、SaaS プロダクト、OSS ライブラリ、スタートアップ、ブランド、またはその他の何かですか？」
2. それは何をしますか？「1文で説明してください。」
3. どんな雰囲気にしますか？「遊び心のある、真面目な、技術的な、温かみのある、エッジの効いた、ミニマルなもの、またはご自身の言葉で説明してください。」

動的コンテキスト分類

ユーザーの説明から自動検出します。プラットフォームの優先順位とスコアリングの重みの両方を調整します。

コンテキストのシグナル	カテゴリー	主なプラットフォーム	副次的なプラットフォーム
"CLI tool", "command", "binary"	CLI ツール	GitHub, npm/PyPI/Crates, Homebrew, .dev	ソーシャル
"package", "library", "framework", "SDK"	OSS ライブラリ	GitHub, npm/PyPI/Crates, .dev/.io	ソーシャル
"app", "product", "startup", "SaaS"	プロダクト	.com, X/Twitter, LinkedIn, GitHub	開発者向けレジストリ
"company", "brand", "agency", "studio"	ブランド	.com, X/Twitter, Instagram, LinkedIn, YouTube	開発者向けレジストリ
"game", "content", "media", "community"	クリエイティブ	.com, YouTube, TikTok, X/Twitter, Reddit, Discord	開発者向けレジストリ
"open source", "OSS", "contrib"	OSS プロジェクト	GitHub, npm/PyPI/Crates, .dev, Discord	ソーシャル
あいまい	バランス型	.com, GitHub, X/Twitter, npm/PyPI	その他すべて

スコアリングのプリセット — コンテキストごとに、内在的／外在的な各次元の重みと、内在的／外在的の配分比率が異なります。重みの一覧は references/scoring-rubric.md § Context Presets を参照してください。主な違いは次のとおりです。

• CLI ツール：内在的／外在的の配分は 30/70。外在的要素では入力のしやすさ（30%）とレジストリ（35%）を重視します
• ブランド：配分は 50/50。発音（30%）とドメイン（35%）を最優先します
• 個人プロジェクト：配分は 25/75。利用可能性を優先し、外在的要素では入力のしやすさ（40%）とレジストリ（20%）を重視します

分類とプリセットをユーザーに提示してください。ユーザーは --style で上書きするか、重みを手動で調整できます。

コアワークフロー（6 フェーズ）

フェーズ -1：メモリの読み込み（セッションごとに 1 回実行）

!uv run python scripts/memory.py load

メモリが存在する場合は、セッションに反映します。

• アーキタイプの傾向 → フェーズ 1 の生成分布に反映します（例：ユーザーが好む場合、喚起型を 35% にする）
• 音声面での好み／苦手な音 → フェーズ 1 のハードフィルター（苦手な音）とソフトスコアの加点（好みの音）に加えます
• 長さの好み → フェーズ 1 の長さの制約を調整します
• 重みの上書き設定 → フェーズ 3 のスコアリングの重みに事前入力します
• コンテキストのデフォルト → フェーズ 0 の概要でコンテキストを提案します（「前回は CLI ツールの名前を付けました。同じコンテキストですか？」）
• インスピレーション → フェーズ 1 の生成で、スタイルの参考として使用します
• 過去に選ばれた候補 → ユーザーがすでに選んだ名前の再生成を避けます

メモリが存在しない場合は、通常どおり進めます。メモリは補助的なものです。メモリがないことを理由にフェーズを中断しないでください。

フェーズ 0：概要（順次進行、対話形式）

1. 命名対象、コンテキスト、制約を解析します
2. 命名コンテキストを自動分類し、プリセットを選択します
3. 分類と調整後の重みをユーザーに提示します
4. 上書き設定を受け付けます：--style、--thorough、重みの手動調整
5. インスピレーションを受け付けます：「Vercel、Stripe、Neon のような名前が好きです」

フェーズ 1：生成と絞り込み（インライン、1 回のパス）

references/naming-strategies.md を読み込み、命名パターンの詳細と音象徴ガイドを確認します。

6 つの命名パターンで、40～60 個の候補を生成します。

命名パターン	説明	例
創作語	音韻的に構成された新語	Kodak, Xerox, Hulu, Roku
メタファーの転用	他の領域から取り入れた概念	Amazon, Safari, Slack, Rust
複合語の融合	かばん語、形態素の組み合わせ	Instagram, Pinterest, YouTube
古典語の語根	ラテン語、ギリシャ語、サンスクリット語の語源	Nike, Astra, Veritas, Lumen
印象的な断片	短く、力強く、抽象的な印象	Figma, Sumo, Neon, Zed
説明的で創造的な名前	明確な意味に個性を加えたもの	Cloudflare, Datadog, Fastly

厳格なフィルター（合否判定。利用可能性の確認前に実行）：

自動フィルターには !uv run python scripts/generate.py filter --input candidates.json を実行し、その後、AI のみで判定するフィルターをインラインで適用します。

1. 英語での卑語・下品な表現（スクリプト：generate.py filter）
2. 世界の主要 10 言語における侮辱的な意味（AI のみ：brave_web_search を使用）
3. 同じカテゴリの上位 1000 ブランドとの完全一致（AI のみ：brave_web_search を使用）
4. 文字数制限を超過（製品名は 15 文字、CLI は 8 文字、ライブラリは 12 文字）（スクリプト：generate.py filter）
5. 発音できない子音の連続（スクリプト：generate.py filter）
6. 主要なプログラミング言語の予約語（スクリプト：generate.py filter）
7. ハイフンや特殊文字を含む（パッケージ名の場合）（スクリプト：generate.py filter）

固有の評価項目（音韻、意味、記憶しやすさ、形態論的な柔軟性、視覚的な品質）を採点します。音韻の内訳を確認して音韻品質の採点に活用するには、!uv run python scripts/generate.py analyze <name> を使用します。利用可能性の確認には、上位 20～25 個を選びます。

--thorough モード：プロンプトを変えて複数回生成し、候補の多様性を高めます。

フェーズ 2：利用可能性の一括確認（並列サブエージェント）

プラットフォームごとの確認方法を参照するため、references/platform-checks.md を読み込みます。

並列サブエージェント 4 つを起動し、それぞれが担当カテゴリの候補をすべて確認します。

サブエージェント A — ドメイン確認：

• .com/.net は RDAP で確認：GET https://rdap.verisign.com/com/v1/domain/{name}.com → 404 = 利用可能
• .dev/.io/.ai/.app は brave_web_search で確認
• 料金：上位 5 候補について brave_web_search で確認

サブエージェント B — 開発者向けレジストリ確認（直接 API）：

• GitHub：GET https://api.github.com/users/{name} → 404 = 利用可能
• npm：GET https://registry.npmjs.org/{name} → 404 = 利用可能
• PyPI：GET https://pypi.org/pypi/{name}/json → 404 = 利用可能
• Crates：GET https://crates.io/api/v1/crates/{name} → 404 = 利用可能

サブエージェント C — ソーシャルメディアとハンドル名の確認：

• Reddit：GET https://www.reddit.com/api/username_available.json?user={name}
• Bluesky：AT Protocol のハンドル解決
• X/Twitter、YouTube、Instagram、LinkedIn：site: プレフィックスを付けて brave_web_search で確認

サブエージェント D — 競合と識別性の確認：

• 検索結果の競合件数：brave_web_search '"{name}" software'
• 商標（--thorough）：brave_web_search "USPTO TESS {name}"

または、スクリプトで決定的な確認を実行します。 !uv run python scripts/availability.py check-all candidate1 candidate2 ...

規模に応じた対応：

• 候補が 10 個以下：並列サブエージェント 4 つ
• 候補が 11～25 個：.com の RDAP で簡易確認して事前に絞り込み、上位 10～15 個を詳細に確認
• --thorough：すべてのソーシャルメディア、商標、Wikipedia を確認

フェーズ 2.5：バリエーションの生成（条件付き）

固有評価の上位 5 候補のうち、利用可能性の確認に失敗したものについて：

• それぞれ 3～5 個のバリエーションを生成：接頭辞（go-、un-）、接尾辞（-kit、-lab、-ify）、母音の削除（namr）、綴りの変更（nomer）、スコープ指定（@scope/name）
• バリエーションの利用可能性を確認（同じサブエージェントのパターンを使用し、候補数を減らす）

フェーズ 3：スコア付けとランキング（インライン）

詳細な基準については、references/scoring-rubric.md を読み込んでください。

10 個のスコアリング基準（0〜10 点、コンテキストに応じて重み付け）：

基準	方法
ドメインの利用可能性	.com=10、.dev/.io=7、.ai/.app=5、パーク済み=3、なし=0
レジストリの利用可能性	対象レジストリのうち利用可能なものの割合
ハンドルの一貫性	対象ソーシャルプラットフォームのうち利用可能なものの割合
覚えやすさ	文字数ボーナス＋音節数＋イメージ性
音声上の品質	子音と母音の流れ、アクセント、音象徴
意味の適合性	ドメインとの関連性、感情的なトーン、メタファーの豊かさ
入力のしやすさ	文字数、キーボード上の配置、特殊文字の有無
検索での識別性	検索結果数の逆数
形態上の柔軟性	動詞・名詞・複合語にできるか？製品ファミリーに対応できるか？
視覚的な品質	文字のバランス、アセンダーとディセンダー、URL の見栄え

複合スコア：(0.4 × intrinsic_avg) + (0.6 × extrinsic_avg) — ユーザーは比率を調整できます。

決定論的なスコアリングを実行するには、!uv run python scripts/score.py score --input candidates.json を実行してください。入力 JSON には {"candidates": [{"name": "...", "intrinsic": {...}, "availability": {...}}], "preset": "cli-tool"} を指定する必要があります。

フェーズ 4：提示（インライン）

テンプレートについては、references/output-formats.md を読み込んでください。

3 つのランキング表示：

1. 最良の名前 — 内在的な品質順にランキング（利用可能性は表示しますが、スコアには反映しません）
2. 利用可能な最良の名前 — 複合スコア順にランキング（デフォルトの推奨）
3. バリエーション付きの最良の名前 — 内在的な品質が高い名前のうち、変更版が利用可能なもの

各表示には、利用可能性マトリックス（✅ ❌ ⚠️ ❓）、スコア、根拠を含むランキング表を表示します。

詳細カード：各表示の上位 3 件について、スコアの詳細、強み、リスク、次のステップを示します。

実行可能な次のステップ：「neon.dev を年 $12 で登録する」、「GitHub で @neon を取得する」、「npm init neon」

インタラクティブな絞り込み：「#3 に似たもの」、「もっと短く」、「もっと技術的に」、「X の音を避ける」

ダッシュボード：すべての表示とカードを作成した後、セッション全体を references/output-formats.md § Structured Output Schema の JSON スキーマに組み立てます。templates/dashboard.html を読み込み、<script id="data" type="application/json">{}</script> の {} を JSON に置き換え、結果を ~/.{gemini|copilot|codex|claude}/namer/{session-slug}-dashboard.html に書き込みます。開くコマンドを表示します：open ~/.{gemini|copilot|codex|claude}/namer/{slug}-dashboard.html

セッションの保存

フェーズ 1（候補）、フェーズ 2（利用可能性）、フェーズ 4（ランキング）の後に、YAML フロントマターを付けて ~/.{gemini|copilot|codex|claude}/namer/{YYYY-MM-DD}-{context}-{slug}.md に保存します。再開に対応しています。

メモリーの保存トリガー

自然な意思決定のタイミングでメモリーを保存します。メモリーの書き込みのためにフェーズを遅らせないでください。必ず主要な出力を提示した後に保存します。

トリガー	コマンド
フェーズ 0：ユーザーがスタイルの好みを述べる	memory.py save-preference --type vibe --value "..."
フェーズ 0：ユーザーがインスピレーションの源となる名前を挙げる	memory.py save-inspiration --name "..." --context "..."
フェーズ 0：ユーザーが重みを調整する	memory.py save-weights --intrinsic-split F --extrinsic-split F
フェーズ 1：ユーザーが「X のような響きは避けて」と言う	memory.py save-rejection --pattern "X" --type phonetic --reason "..."
フェーズ 4：ユーザーが名前を選ぶ	memory.py save-selection --name "..." --archetype "..." --context "..." --score N --query "..."
調整：「#N にもっと似せて」	memory.py save-preference --type archetype --value "..." --like
調整：「もっと短く」／「もっと長く」	memory.py save-preference --type length --value "max=5" または "min=8"
任意：ユーザーがスタイルを却下する	memory.py save-rejection --pattern "..." --type archetype --reason "..."

1 回のセッションで複数のメモリーが生じた場合は、複数の保存を 1 つのメッセージにまとめます。すべての memory.py コマンドには !uv run python scripts/ を前置します。

用語集

用語	定義
brief	命名要件：対象、コンテキスト、スタイル、制約
candidate	利用可能性の確認前に生成された名前
archetype	命名戦略：創作、隠喩、複合、古典、喚起、説明的
intrinsic score	言語的・創造的な観点からの品質（I/O なし）
extrinsic score	プラットフォームのチェックによる利用可能性（I/O を多用）
composite score	intrinsic と extrinsic の加重合計
hard filter	合否を判定するゲート：不適切な表現、長さ、発音のしやすさ
variant	候補の変更：接頭辞、接尾辞、綴りの変更
namespace report	すべてのプラットフォームにおける、候補ごとの利用可能性マトリクス
context preset	命名対象に応じて重みとプラットフォームを自動設定
memory	`~/.{gemini
archetype affinity	選択結果から算出される、ユーザーが好む命名 archetype の加重分布
selection	ユーザーが選んだ名前。好みの学習用に保存される
rejection	明示的に望ましくないとされたパターン（音声、archetype、または特定の名前）

参照ファイル一覧

ファイル	内容	読み込むタイミング
references/naming-strategies.md	6 つのアーキタイプ、音象徴、音声ガイド、形態素ライブラリ	フェーズ 1（生成）
references/platform-checks.md	プラットフォームごとの URL、方法、レスポンスの解析、レート制限	フェーズ 2（利用可能性）
references/scoring-rubric.md	10 項目の詳細、6 つのプリセット、ハードフィルター、合成スコアの計算式	フェーズ 3（スコアリング）
references/output-formats.md	3 種類の表示形式のテンプレート、名前カード、バリエーション表、次のステップ	フェーズ 4（提示）
templates/dashboard.html	自己完結型 GUI — § 構造化出力スキーマの構造化 JSON を挿入します	フェーズ 4（ダッシュボードの描画）
scripts/memory.py	命名設定を永続化する CLI（読み込み、保存、整理、統計）	フェーズ -1（読み込み）、セッション終了時（保存）

「読み込むタイミング」列に従って、一度に読み込む参照ファイルは 1 つだけにしてください。

重要なルール

1. 利用可能性の確認を決して省略しないでください。確認していない名前は、価値のない推奨候補です
2. スコアリング基準は常に透明性をもって提示してください。ブラックボックスの順位付けは避けてください
3. 利用可能性のデータを決して捏造しないでください。確認に失敗した場合は「❓ unknown」と表示し、「✅ available」と表示しないでください
4. 利用可能性を確認する前に、必ずハードフィルターを実行してください。除外対象の名前に API 呼び出しを浪費しないでください
5. 利用可能性の確認パイプラインを最後まで通す候補は、最大 25 件にしてください。ツール呼び出しの予算を守ってください
6. 商標や競合に関するリスクは常に明示してください。法的問題は名前の品質より優先されます
7. ユーザーファイルは決して変更しないでください。namer が読み取り専用の例外とするのは、~/.{gemini|copilot|codex|claude}/namer/ 内のセッションジャーナルのみです
8. 3 種類の出力形式（Best Names、Best Available、Best with Variants）を必ずすべて提示してください
9. 実行可能な次のステップを必ず示してください。「X は利用可能です」だけでなく、「Y で X を $Z で登録する」と提示してください
10. 生成では複数のアーキタイプを必ず使用してください。1 つの戦略だけから候補を生成しないでください
11. 生成前にコンテキストを分類してください。重み付けとプラットフォームは分類結果によって変わります
12. 内在スコアと外在スコアは分けて表示してください。ユーザーがトレードオフを把握できるようにしてください
13. フェーズ 0 の前にユーザーメモリを読み込んでください（フェーズ -1）。主要な出力を提供した後にメモリを保存してください。メモリの書き込みを理由にフェーズを中断しないでください