메뉴
产品命名协作流程。当用户想给产品/项目/模块起名字时使用。通过"灵魂挖掘 → 约束提取 → 路线发散 → 方向选择 → 竞品验证 → 最终确认"的结构化流程，从模糊想法产出有品牌生命力的名字，避免拍脑袋起名。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Issue 池全生命周期管理（开发范式 v1 规划段）：记 issue 入池+关联检查、合并同源需求、讨论拆解（引导讲出真需求）、转成可开工 task 或滚动 plan、拆不动就 pending。复杂 plan 的框架计划正文流程已内置（原 plan-report 并入 references/plan-writing.md）。当用户说"记个 issue""新增/汇总 issue""拆 issue / 拆解
把用户的模糊诉求、粗糙 goal、handoff prompt 或任务想法收敛成 AI 可以自主执行且可验收的 goal。用于用户要求写 goal、优化 goal、制定交给 AI/subagent/Codex 执行的目标、明确 scope/non-goals/success criteria/verification/stop conditions，或需要把“今天做完、尽量优化、帮我研究并执行”等不清晰请求变成可执行任务契约时。
帮助梳理一份"框架计划报告"(项目 v1.0 计划、版本路线、阶段方案等)。通过"摸现实 → 定文档类型 → 搭骨架 → 填内容 → 统一结构 → 语言精修 → 自检" 7 步引导,产出"讲为什么做 / 做到什么程度算完 / 分几步走"的框架计划,而不是功能清单或技术方案。当用户说"写计划报告"、"项目计划"、"框架计划"、"v1.0 计划"、"版本路线"、"阶段方案"、"plan-report"、"/plan-report"时触发。
陪伴型 AI 人设生成与优化流程。当用户想给 Hermes Agent（或任意 AI 陪伴角色）做一个"有感情、聊久不掉、像真人"的人设时使用。通过"定调子 → 名字 → 外形 → 性格 → 背景 → 关系 → 说话节奏 → 生成 SOUL.md → 迭代"的结构化对话，从一句模糊想法（如"我想要个JK女友""年上男友""高冷御姐"）产出可直接贴进 Hermes SOUL.md 的第一人称人设文本。支持女友/男友/各种气质的陪伴角色，并让用户选择"一句一句发"还是"整段说"的输出风格。当用户说"做个人设/捏个AI女友男友/给Hermes弄个角色/优化人设/换个人设"时触发。
PRD + 可执行测试用例双文档一体化协作。与用户共同写并迭代。理解需求后自主读代码再写；故事驱动 + 分阶段单点确认；每个 PRD 产出 PRD-MD 与 测试用例-MD（给 AI 的事实源）+ 两份套模板的 review HTML（给人查阅，与 MD 严格 1:1）。触发：梳理/撰写/完善 PRD、需求文档、用户故事、验收标准、测试用例、测试基准、测试方案。
系统化学习材料生成器。给一个新领域/技术/概念，AI 自主调研、搭体系、产出 HTML 学习材料（含骨架/案例/工程化/争议+盲区）。当用户说"我要学 X / 帮我系统拆解 X / 我想吃透 X 这个领域 / 给我整理 X 的全貌 / 深度调研 X 给我系统讲讲 / 把 X 搞透"时触发。不适用于"X 行不行/为什么 Y"（用 long-research）、"X 有哪些好玩案例"（用 case-radar 给散点）、"把这堆素材整理成 HTML"（用 readable-output 处理已有素材）、文章写作（用 writing-assistant）、设计稿（用 design-exploration）。
| 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 步 | 最终确认 |
| 事项 | 直接做 |
|---|---|
| 读项目文档了解背景 | 直接读，带着理解去问用户 |
| 竞品调研 | 直接搜索，带着数据给建议 |
| 分析诉求之间的张力 | 直接分析，向用户确认判断 |