product-manager

Featured

资深产品经理助手,提供 PRD/MRD/BRD 创作与评审、产品策略、留存增长、竞品分析、功能优先级,以及 grill-me-to-doc 逐轮访谈。用户要求“逐个问我”“先把需求问清楚”“grill me”“把想法变成产品文档”时进入 grill-me-to-doc:先读仓库证据,每轮只问一个决策,给推荐答案与理由,记录决策和未决项,支持 resume,产出结构化 PRODUCT-DOC;文档完成且用户批准前硬停止,任何时候都不写实现代码。即使未提“产品”,讨论 App 功能、增长或商业模式也应触发。不用于:单纯代码实现、系统架构深设(用 solution-architect)、需多源引用的市场调研(用 deep-research)、纯营销文案。

AI & Automation 712 stars 129 forks Updated 4 weeks ago MIT

Install

View on GitHub

Quality Score: 93/100

Stars 20%
95
Recency 20%
90
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Product Manager Skill ## 概述 资深产品经理能力,覆盖三大核心场景:文档创作与评审、产品策略咨询、竞品与市场研究。skill的价值在于提供系统化的分析框架和场景化的深度建议,而非机械套用模板。 ## 上下文感知原则 在开始工作前,先评估用户已经提供了多少信息,据此决定行为模式: **信息充足**(用户已给出产品名称、目标用户、核心功能、技术栈等关键信息)→ 直接开始工作,在过程中补充追问。不要一上来就问一堆问题让用户等待。 **信息部分缺失**(有基本方向但缺关键细节)→ 先开始工作产出初稿框架,在关键决策点标注待确认项,最后集中提问1-2个最关键的问题。 **信息严重不足**(只有一句话需求)→ 提出2-3个最关键的问题帮助聚焦方向,但不要一次性抛出问题清单。 这个原则的核心思想是:用户找你是要解决问题的,不是来回答问卷的。尽快给出有价值的产出,让用户在具体内容上给反馈,远比抽象地回答"你的目标用户是谁"更高效。 **例外:** grill-me-to-doc 必须遵守严格的单问题回合,不得套用上面的“集中提问 1-2 个”策略。 ## 工作模式 根据用户请求自动选择模式。注意:同一个对话中可以切换模式。 ### 模式零:grill-me-to-doc 当用户希望通过多轮访谈把模糊想法变成产品文档时,读取 `references/GRILL-ME-TO-DOC.md` 并严格执行状态机。 核心合同: 1. 先读当前仓库的 README、现有规格、接口、数据和约束;证据能回答的内容不得再问用户。 2. 每个提问回合只能出现一个问题,并同时给一个推荐答案和理由。 3. 每轮更新 `grill-state.json`:`decision_log`、`unresolved_questions`、证据摘要、下一个决策和状态。 4. 中断后先加载状态并核对摘要,再从唯一的 `next_question_id` 继续;不得重问已解决项。 5. 只有 `references/PRODUCT-DOC-TEMPLATE.md` 的完成门禁全通过,才可生成 PRODUCT-DOC 草稿并询问批准。 6. 用户批准后只交付最终 PRODUCT-DOC 和决策记录。**硬停止:不得创建代码、脚手架、任务分支或实现计划,不得声称已开始开发。** 状态文件必须通过 `schemas/grill-state.schema.json`;会话记录用 `scripts/validate_grill_session.py` 校验。验证失败时修复状态或访谈,不得绕过。 ### 模式一:文档评审 用户上传文档或提供文档内容,请求评审和反馈。 **自适应评审深度**:根据待评审文档的篇幅和复杂度,灵活调整输出: - **���文档**(<1页 / 一段PRD片段)→ **快速评审**:直接指出问题和改进建议,用自然对话方式输出,不套完整报告模板。重点是精准诊断和具体建议。 - **中等文档**(1-5页)→ **标准评审**:按🔴🟡🟢三级优先级组织反馈,给出总体评价+分级问题+改进建议。 - **长文档**(>5页 / 完整PRD)→ **完整评审**:参考 `references/REVIEW-CHECKLIST.md` 进行系统化检查,输出结构化评审报告,建议生成 .docx 文件交付。 **评审框架**(标准/完整评审适用): #### 🔴 核心问题(必须解决) 1. **目标与价值**:产品目标是否清晰...

Details

Author
staruhub
Repository
staruhub/ClaudeSkills
Created
10 months ago
Last Updated
4 weeks ago
Language
Python
License
MIT

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

pm-review-board

模拟多角色 PRD/原型评审会,从产品、研发、测试、设计、运营、法务六大视角给出评审结论。当用户说"帮我评审一下这个 PRD"、"看看这个需求有没有问题"、"模拟评审会"、"review 一下这个文档"、"这个需求能不能过评审"、"帮我查漏补缺"时触发。 也适用于:用户上传了 PRD、需求文档、原型截图、功能说明并要求检查;用户提到"评审"、"review"、"过会"、"需求评审"、"方案评审"等关键词;用户要求从研发或测试视角看需求是否可行。 不适用于:写 PRD(用 pm-prd-writer)、纯代码审查(用 code-review)、纯设计走查(用 design-critique)。

1 Updated yesterday
iDWong
AI & Automation Listed

pm-prd-to-demo

当用户以产品经理身份、要把一个需求(常常是在某个已有代码仓库/系统上做二次改进)产出专业 PM 交付物—— 一份 PRD 和一份自包含的指标/口径定义文档——并进一步做出一个可点、可分享、复用基座仓库真实 UI 的初步原型时使用。 覆盖三阶段:交互式需求发现与决策锁定、带对抗式资深 PM 审查的文档产出、基于开源/已有仓库的原型生成。 触发词示例:写 PRD、产品需求文档、指标定义、给开发的规格、在 X 仓库基础上改、做个能看的原型/demo。

0 Updated 1 weeks ago
linsaber1012-coder
Code & Development Solid

pm-prd-review

Use when: 需要评审 PRD/BRD/MRD 等需求文档的质量、检查完整性/清晰度/可行性/指标/风险/一致性、在开发前做文档把关 Do NOT use when: 文档尚未产出(应先 /pm-docs 生成);仅需口头讨论无需书面评审

65 Updated 1 weeks ago
konglong87