القائمة
产品命名协作流程。当用户想给产品/项目/模块起名字时使用。通过"灵魂挖掘 → 约束提取 → 路线发散 → 方向选择 → 竞品验证 → 最终确认"的结构化流程，从模糊想法产出有品牌生命力的名字，避免拍脑袋起名。
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/yunshu0909/yunshu_skillshub --skill product-namingيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
带用户精读一篇文章/文档并真正学透（不是出摘要）。五步：抽干货 → 切讲次 → 每讲跑「学-考-讲」循环 → 对号入座 → 实操+测验+讲错题+蒸馏。每讲产出 HTML 课件 + 笔记落盘；讲完必考一次，用户复述后必须挑不精确处拧紧；抽象概念上可交互演示（能点能跑）；全程用用户自己的业务场景当案例；学完出多题型自动判分测验卷，最后把收获蒸馏回用户的工具。核心触发条件是用户要的是"学会"而不是"要一份结果"，例如"我们一起学这篇文章/这个链接"、"带我学"、"精读"、"我想学会 X"、"这篇我看不懂你给我讲讲"。有具体材料（链接、本地文件、PDF，或用户自己的 skill/文档/代码）时直接开跑；只有学习意图而没材料时仍走本 skill，但开工第一件事是和用户一起把材料定下来，禁止凭记忆开讲。不适用于：只要一份总结/摘要/教程长文，用户读完就完、不需要答题（用 readable-output）、只是搜集资料做调研（使用可用的网页/平台取材工具）、帮我写 PRD/测试用例（用 prd-test-writer）、以及用户其实是想让你直接把活干了（那就直接做）。
让 Codex 与 Claude Code 通过本机 CLI 组成“主执行者 + 独立审查者”的对称协作闭环。用于用户要求两个模型一起完成、交叉校核、独立审查、修到 ACK，或任务涉及产品需求收敛、复杂方案、跨模块开发、迁移、安全、重要重构和高质量交付时；无论从 Codex 还是 Claude Code 启动，都由当前模型主持，并完整调用另一方完成需求挑战、方案门禁、实现冷审和最终验收。
界面设计探索（开发范式 v1 · 仅限有 UI 的模块）。触发前两个硬条件必须同时成立：①这个东西有用户能看见的界面 ②界面尚不存在。通过"需求收敛 → 技术调研 → ASCII 批量出 5-8 个方案 → HTML 设计稿 → 全状态覆盖 → 需求总结"，产出 3 个交付文件：需求总结.md + {模块}-设计稿.html + {模块}-全状态设计参考.html，作为 PRD 阶段的输入。不适用于：无界面的流程/架构/数据结构/接口/方案设计——"设计"二字不等于本 skill（用 issue-pool 讨论拆解）、界面已经在代码里跑着要改样式（用 ui-design）、照着现成设计图或截图复刻（用 design-replica）、写 PRD 时给单个故事配线框图（用 prd-test-writer，它自带 ASCII 线框能力）、还没决定要不要做的模糊想法（先用 issue-pool 入池）、纯发散不收敛的终局愿景（用 vision-exploration）。
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | product-naming |
| description | 产品命名协作流程。当用户想给产品/项目/模块起名字时使用。通过"灵魂挖掘 → 约束提取 → 路线发散 → 方向选择 → 竞品验证 → 最终确认"的结构化流程，从模糊想法产出有品牌生命力的名字，避免拍脑袋起名。 |
用户想给产品、项目或模块起一个名字，但还没想好叫什么。通过结构化的协作流程，从产品本质出发推导名字，而不是直接列一堆候选词让用户挑。
这一步的目标是理解产品的本质，而不是收集功能列表。
主动了解项目背景（读代码、读文档），然后向用户追问以下问题：
关键：如果用户给出一个比喻（比如"像 Jarvis"），一定要深挖这个比喻背后的含义——它揭示的是用户对产品角色的想象。
禁止：
从第 1 步的回答中提取：
向用户展示你的分析，确认理解无误。
示例：
你的核心诉求：
- ✅ 让人知道跟团队协作有关
- ✅ 轻松不严肃，不像企业软件
- ⚡ 这两个有张力：协作类名字容易显得"企业味重"，轻松的名字又容易看不出用途
我的判断是"轻松感"优先，因为你要跟 Slack/钉钉竞争的是体验而非功能。对吗？
禁止：跳过分析直接出名字。这一步是从"感觉"到"逻辑"的关键桥梁。
基于约束分析，推导出 2-4 条命名路线，每条路线代表一种不同的命名策略。
每条路线包含：
示例：
路线 A：拟声/动作词
示意：Ping、Holler、Nudge
✅ 轻快、有画面感
❌ 不直接关联"站会"场景
路线 B：时间/节奏隐喻
示意：DayBeat、MorningSync、Cadence
✅ 暗示每日节奏，贴合站会频率
❌ 偏长，组合感强
路线 C：缩写/造词
示意：Stanly（standup + daily）、Asynco（async + co）
✅ 独特好注册
❌ 需要解释含义
禁止：
用户可以：
选定方向后，在该方向内深挖 3-5 个具体候选名字，每个附带一句话解释。
禁止：用户选了方向之后还在其他方向上发散。聚焦。
用户倾向某个名字后，做两件事：
搜索同赛道产品的命名规律：
基于调研结果，向用户建议：
示例：
调研发现同赛道的 Geekbot、Range、Standuply 都只用一个英文名。
建议：只用 Ping，不另起中文名。
理由：用户是开发团队，日常沟通已经用英文工具；一个音节最好记。
如果需要中文场景，加 slogan："Ping — 轻拍一下，站会搞定"
禁止：不做调研就建议命名策略，所有建议必须有数据支撑。
汇总整个过程的决策链路，输出最终结论：
📌 产品名称：Ping
📌 Slogan：轻拍一下，站会搞定
📌 命名策略：纯英文单品牌
📌 决策依据：
- 用户画像：远程开发团队
- 产品定位：替代每日站会的异步同步工具
- 核心约束：轻松不严肃，一看就想用
- 竞品惯例：同赛道主流为纯英文短名称
| 时机 | 问什么 |
|---|---|
| 第 1 步 | 用户画像、产品本质、产品边界、品牌气质、硬性约束 |
| 第 3 步 | 选哪条路线 |
| 第 4 步 | 倾向哪个具体名字 |
| 第 5 步 | 命名策略是否认同（几个名字、要不要 slogan） |
| 第 6 步 | 最终确认 |
| 事项 | 直接做 |
|---|---|
| 读项目文档了解背景 | 直接读，带着理解去问用户 |
| 竞品调研 | 直接搜索，带着数据给建议 |
| 分析诉求之间的张力 | 直接分析，向用户确认判断 |