Product Naming 是一个用于研究、评估和验证产品/创业/应用名称的技能。推荐投入程度：研究和生成阶段为高，仅做可用性检查时为中等。使用 ultrathink 进行竞品分析和质量评分。
工作流程：检测入口 → 研究 → 展示 → 验证* → 报告。包含两个阶段，中间为隐式过渡：智能体展示研究结果，用户决定是否进入验证。
上下文加载策略：根据检测到的入口点加载参考资料。用户需要建议时，先加载 research.md，用户批准后再加载 validation.md；用户已有候选名称需要质量评审时，只加载 research.md 的评分部分；用户需要可用性检查时，只加载 validation.md。tld-guide.md 始终作为验证阶段的一部分加载。
触发方式：
- “建议名称、找名字、命名想法、我该叫它什么” → 第一阶段（研究+生成）→ 第二阶段（验证），加载 research.md + validation.md。
- “评估这些名称（质量优先）” → 仅第一阶段（评分，不生成），加载 research.md。
- “检查可用性、域名可用、检查这个名称” → 仅第二阶段（域名、社交媒体、商标），加载 validation.md。 注意：“评估”可灵活进入第一阶段或第二阶段，取决于上下文。质量评估进入第一阶段；可用性检查进入第二阶段。tld-guide.md 不是直接触发项，由 validation.md 在域名检查时加载。
交叉引用：brainstorming → product-naming（方向为名称生成提供上下文）；product-naming → docs-writer（已验证名称用于 PRD/Brief）；product-naming → design-builder（选定名称影响品牌/Logo 方向）。
指南（应做）：为每个候选名称检查域名可用性；每个名称都检查 .com 和 .com.br（通用要求）；技术/移动产品增加 .io 和 .app；根据产品类型增加额外 TLD（见 tld-guide.md）；自造名称偏向 PT+EN 双语发音；当某个选项明显突出时标记为 TOP PICK；展示被淘汰名称并给出明确原因；生成名称前先做竞品分析；为最佳候选建议名称变体。
不应做：跳过域名检查——可用性对最终决策至关重要；仅因域名不可用而淘汰名称（应记为注意事项）；在状态指示符之外使用 emoji（可用性仅用交通灯 emoji）；生成超过 20 个候选（保持聚焦）。
输出：报告保存为 .md 文件，位于 .artifacts/docs/（如不存在则创建）。研究流程：.artifacts/docs/{product}-research.md，使用 templates/research-report.md。验证流程：.artifacts/docs/{product}-validation.md，使用 templates/validation-report.md。状态指示符：🟢 可用 🔴 不可用 🟡 不确定。
紧凑指令（保留）：当前阶段（研究或验证）、产品上下文（功能、受众、语气）、带质量评分的生成候选、用户对要验证候选的批准。丢弃：竞品分析原始输出、中间生成草稿。
错误处理：未提供产品上下文时，询问产品功能和目标用户；候选过多（10+）时，批量检查可用性以提高效率；域名检查不确定时，标记 🟡 并注明；遇到限流时，在请求之间增加延迟；无可用工具时，所有可用性标记为 🟡 不确定；所有候选均被淘汰时，建议用户调整约束或生成新一批；商标搜索无结果时，标记 🟡 并建议人工核实。