product-naming

产品命名

**建议投入：**研究和生成阶段投入较多；仅检查可用性时投入适中。

通过域名、社交媒体和商标检查，研究、评估并验证产品／初创公司／应用名称。竞品分析和质量评分请使用 ultrathink。

工作流

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

分为两个阶段，阶段之间隐式过渡：Agent 展示研究结果，用户决定是否继续验证。

上下文加载策略

根据检测到的入口点加载参考资料：

• 用户需要名称建议：先加载 research.md，用户批准后再加载 validation.md
• 用户已有候选名称，需要质量评审：仅加载 research.md（评分部分）
• 用户需要检查可用性：仅加载 validation.md

tld-guide.md 始终作为验证阶段的一部分加载。

触发条件

触发模式	入口点	参考资料
建议名称、寻找名称、名称创意、我该怎么称呼	阶段 1（研究 + 生成）--> 阶段 2（验证）	research.md + validation.md
评估这些名称（侧重质量）	仅阶段 1（评分，不生成）	research.md
检查可用性、域名是否可用、检查这个名称	仅阶段 2（域名、社交媒体、商标）	validation.md

说明：

• “Evaluate”含义灵活，可根据上下文进入阶段 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）
• 虚构名称优先采用兼具葡萄牙语和英语特点的发音
• 如果某个选项明显突出，将最强选项标记为 TOP PICK
• 清楚说明淘汰名称的原因
• 生成名称前进行竞品分析
• 为优先候选名称建议变体

不应该：

• 跳过域名检查——可用性对最终决策至关重要
• 仅因域名不可用就淘汰名称（应将其作为注意事项说明）
• 在状态指示符之外使用表情符号（可用性状态仅使用红绿灯表情符号）
• 生成超过 20 个候选名称（保持精简）

输出

报告以 .md 文件形式保存到 .artifacts/docs/（如有需要，创建该目录）：

• 研究流程：.artifacts/docs/{product}-research.md——使用 templates/research-report.md
• 验证流程：.artifacts/docs/{product}-validation.md——使用 templates/validation-report.md

状态指示符：🟢 可用 🔴 不可用 🟡 不确定

精简说明

保留：

• 当前阶段（研究或验证）、产品背景（功能、受众、风格）
• 已生成的候选名称及质量评分
• 用户批准进行验证的候选名称

省略：

• 竞品分析原始输出
• 生成过程中的临时草稿

错误处理

• 未提供产品背景：询问产品的功能及目标用户
• 候选名称过多（10 个以上）：分批检查可用性以提高效率
• 域名检查结果不确定：标记为 🟡 并说明情况
• 遇到速率限制：在请求之间增加延迟
• 没有可用工具：将所有可用性标记为 🟡 不确定
• 所有候选名称均被淘汰：建议用户调整限制条件或重新生成一批
• 商标搜索没有结果：标记为 🟡 并建议人工核实