product-naming

製品名の命名

推奨される作業量： 調査および生成フェーズでは多め、利用可否のみの確認では中程度です。

ドメイン、ソーシャルメディア、商標を確認しながら、製品、スタートアップ、アプリの名前を調査、評価、検証します。競合分析と品質スコアリングには ultrathink を使用します。

ワークフロー

detect entry --> research --> present --> validate* --> report

暗黙の移行を伴う 2 つのフェーズで構成されます。エージェントが調査結果を提示し、ユーザーが検証に進むかどうかを決定します。

コンテキストの読み込み戦略

検出された開始地点に基づいて、参照資料を読み込みます。

• ユーザーが候補の提案を求めている場合：research.md を最初に読み込み、ユーザーの承認後に validation.md を読み込みます
• ユーザーが候補の品質評価を求めている場合：research.md のみを読み込みます（スコアリングのセクション）
• ユーザーが利用可否の確認を求めている場合：validation.md のみを読み込みます

validation.md は検証フェーズの一部として常に読み込まれます。

トリガー

トリガーパターン	開始地点	参照資料
名前を提案して、名前を探して、名前のアイデア、何と呼べばよいか	フェーズ 1（調査＋生成）--> フェーズ 2（検証）	research.md + validation.md
これらの名前を評価して（品質重視）	フェーズ 1 のみ（スコアリング、生成なし）	research.md
利用可否を確認して、ドメインが空いているか、この名前を確認して	フェーズ 2 のみ（ドメイン、ソーシャル、商標）	validation.md

注：

• 「評価」は柔軟に解釈します。文脈に応じてフェーズ 1 またはフェーズ 2 に進みます。品質評価はフェーズ 1、利用可否の確認はフェーズ 2 に進みます。
• tld-guide.md は直接のトリガーではありません。ドメイン確認時に validation.md によって読み込まれます。

相互参照

brainstorming  --> product-naming (direction feeds name generation context)
product-naming --> docs-writer    (validated name feeds into PRD/Brief)
product-naming --> design-builder (chosen name informs brand/logo direction)

ガイドライン

すること：

• 名前の候補すべてについてドメインの利用可否を確認する
• すべての名前について .com と .com.br を確認する（共通要件）。テクノロジー／モバイル製品では .io と .app も追加する
• 製品の種類に応じて追加の TLD を確認する（tld-guide.md を参照）
• 新たに作る名前は、PT と EN の両方で発音しやすいものを優先する
• 明らかに最有力の選択肢がある場合は、TOP PICK として示す
• 候補から除外した名前には、明確な理由を添える
• 名前を生成する前に競合分析を行う
• 最有力候補の名前のバリエーションを提案する

しないこと：

• ドメイン確認を省略する――最終決定には利用可否が重要です
• ドメインが利用できないことだけを理由に名前を除外する（代わりに注意点として記載する）
• ステータス表示以外で絵文字を使用する（利用可否の表示には信号機の絵文字のみを使用する）
• 候補を 20 個より多く生成する（絞り込んで提示する）

出力

レポートは .artifacts/docs/ に .md ファイルとして保存します（必要に応じてディレクトリを作成してください）。

• 調査フロー：.artifacts/docs/{product}-research.md -- templates/research-report.md を使用
• 検証フロー：.artifacts/docs/{product}-validation.md -- templates/validation-report.md を使用

ステータス表示：🟢 利用可能 🔴 利用不可 🟡 不確実

簡潔な指示

保持する情報：

• 現在のフェーズ（調査または検証）、製品のコンテキスト（機能、対象ユーザー、トーン）
• 生成した候補と品質スコア
• 検証する候補についてのユーザーの承認

省略する情報：

• 競合分析の生出力
• 生成途中の作業メモ

エラー処理

• 製品のコンテキストが提示されていない：製品の機能と対象ユーザーを尋ねる
• 候補が多すぎる（10 個以上）：効率化のため、利用可否の確認を複数回に分ける
• ドメイン確認が不確実：🟡 として記載し、その旨を明記する
• レート制限：リクエストの間に待ち時間を設ける
• ツールが利用できない：利用可否はすべて 🟡 不確実 として記載する
• すべての候補が除外された：条件を調整するか、新しい候補群を生成するようユーザーに提案する
• 商標検索で結果が得られない：🟡 として記載し、手動での確認を推奨する