pm-skills
一个能思考的人，才真是一个力量无边的人。——巴尔扎克
https://github.com/phuryn/pm-skills
当产品经理开始拥有一座技能市场
很多工具都在告诉你，AI 很聪明。
但 phuryn/pm-skills 这个项目更像是在认真告诉你另一件事：聪明不够，做产品这件事，真正稀缺的是判断力、结构化思考和一条能把混乱问题一步步带到可执行答案的路径。
这正是 PM Skills Marketplace 想做的事。
它不是一个只会“吐字”的提示词仓库，也不只是几个零散的模板集合。它更像一座专门为产品经理搭建的技能市场，一边站着发现机会、梳理战略、定义指标、推进执行、规划上市的各路方法论角色，另一边站着 Claude Code、Claude Cowork、Codex 这类 AI 助手。它们在这里握手，分工，开始像一个真的产品团队那样协作起来。
项目在仓库描述里把自己定义得很明确：
PM Skills Marketplace: 100+ agentic skills, commands, and plugins — from discovery to strategy, execution, launch, and growth.
这句话很短，却很有力量。因为它没有停留在“帮你写文档”这种浅层承诺，而是直接把产品工作的主线拎了出来：从发现，到战略，到执行，到发布，到增长。
如果说通用 AI 像一个反应很快、知识很广的实习生，那么 PM Skills Marketplace 更像是把一整个训练有素的产品组织请进了你的工作台。
它解决的，不是不会写，而是不知道怎么想
README 里有一句很抓人：
Generic AI gives you text. PM Skills Marketplace gives you structure.
这句话几乎点中了现在很多人使用 AI 的真实感受。
你问一个普通 AI：“帮我写个 PRD。”
它往往真的会写。
你问它：“帮我做产品战略。”
它也会给你几段看上去很像答案的内容。
你再问：“我们该先验证什么假设？”
它还是能说几句。
但问题在于，这些回答很可能都是“像”，而不是“是”。
产品管理最怕的不是没有输出，而是输出很多，看起来很满，实际上没有抓住真正关键的判断点。一个好产品经理从来不是文档制造机，而是一个在迷雾中不断做选择的人。要决定先探索什么、先否定什么、先验证什么、先做什么、为什么做、怎么衡量是不是做对了。
而 PM Skills Marketplace 做的事情，是把这些关键动作拆成了一个个可以被 AI 调用、组合、衔接的技能与命令。
它不只是帮你生成内容，而是在提醒 AI：
- 现在先别急着写结论，先做 discovery
- 现在先别拍脑袋排优先级，先识别风险假设
- 现在先别讨论功能，先回到 North Star
- 现在先别说可以上线，先把安全、性能、测试和意图文档补齐
换句话说，它让 AI 不再只是“会说”，而是开始“按产品方法工作”。
这不是一个插件包，而是一套产品工作的操作系统
项目标题很有野心：
PM Skills Marketplace: The AI Operating System for Better Product Decisions
“AI Operating System” 这个说法用得很妙。
因为当你继续看 README，就会发现它的设计不是零散堆砌，而是有明显分层的：
- Skills
- Commands
- Plugins
这三层关系非常像一家公司里的能力组织方式。
Skills 像一个个训练有素的专家
Skills 是最底层的构建单元。每个 skill 对应一个具体的产品任务、分析框架或工作流节点。
它们像一群各有专长的同事：
- 有的人擅长做产品战略
- 有的人擅长设计实验
- 有的人擅长用户访谈
- 有的人擅长优先级判断
- 有的人擅长市场分析
- 有的人擅长写 PRD
- 有的人擅长看 A/B test
- 有的人擅长做 GTM
- 有的人擅长把“AI 写出来但没人敢发”的代码补成一份可审阅的交付材料
这些 skill 并不是空泛标签，而是把成熟的方法论编码进了 AI 的工作方式里。
Commands 像带节奏的项目经理
如果说 skill 是能力点，那么 command 就是把多种能力串起来的“工作流导演”。
README 里写得很清楚，命令是以 /command-name 触发的，它们会把一个或多个 skill 连接成完整流程。
比如 /discover，不是只做一件事，而是串起：
- 创意发散
- 假设识别
- 风险优先级排序
- 实验设计
它很像一位经验丰富的 PM 对团队说：
“先别急着定方案，我们按步骤来，先把可能性摊开，再找最危险的假设，再决定先测什么。”
这种感觉，和普通提示词的最大不同在于：它自带顺序感、自带节奏感、自带工作链路。
Plugins 像职能团队
再往上一层是插件。
插件把相关 skill 和 command 打包成某个 PM 领域的工作套件，比如：
- 产品发现
- 产品战略
- 执行管理
- 市场研究
- 数据分析
- 增长营销
- Go-to-market
- 实用工具
- AI Shipping
这就像把产品组织拆成不同部门，每个部门都有自己的专业兵种，也有自己的标准作战流程。
最终，PM Skills Marketplace 并不是让你拿到几个“会说话的模板”，而是让你得到一整套可以被 AI 调度的产品组织能力。
一打开门，它就会问你：你现在处在哪个阶段
这个项目很聪明的一点，是它没有把用户扔进一个巨大的功能列表里，而是先在 README 的 Start Here 里给出一组很像路标的入口：
- New idea? →
/discover - Need strategic clarity? →
/strategy - Writing a PRD? →
/write-prd - Planning a launch? →
/plan-launch - Defining metrics? →
/north-star
这种设计很像一个成熟的产品顾问站在门口迎接你。
它不会上来就丢给你 100 多个能力点，要求你自己消化。它先看你手上现在拿的是什么问题。
你是有个新点子，但不知道有没有价值？
那先走 /discover。
你心里有方向，但战略还模糊？
那就走 /strategy。
你准备推进落地，需要把需求说清楚？
那就 /write-prd。
你快要面向市场了，发布动作没串起来？
那就 /plan-launch。
你做了一堆事情，却没有一个能对齐团队的核心指标？
那就 /north-star。
这种入口设计，本身就体现出这个项目的产品意识：不要让用户理解系统，要让系统先理解用户所处的任务阶段。
安装这件事，它也尽量做得像铺路，而不是设门槛
这个项目对不同使用者很友好。
它知道，并不是所有 PM 都写代码，也不是所有人都在同一种 AI 环境里工作。所以 README 给出了几种清晰路径。
Claude Cowork
README 里把 Claude Cowork 标成了推荐给非开发者的方案，安装步骤非常直接：
- 打开 Customize
- 进入 Browse plugins → Personal → +
- 选择 Add marketplace from GitHub
- 输入
phuryn/pm-skills
所有 9 个插件会自动安装。
这一步很像把一整支产品智囊团请进你的办公室，连座位都帮你安排好了。
Claude Code CLI
如果你更习惯在命令行里工作，README 也给出了完整命令：
1 | # Step 1: Add the marketplace |
这段命令很有画面感。每执行一行，就像又有一个角色走进团队会议室：
“战略顾问到了。”
“用户研究到了。”
“数据分析到了。”
“增长负责人到了。”
“发布负责人也到了。”
一个人打开终端，背后却像组起了一支虚拟产品团队。
Codex CLI
更有意思的是，README 专门说明了 Codex 也能原生使用同一套 plugin marketplace 文件，不需要转换，不需要复制文件。
1 | # Step 1: Add the marketplace |
这点非常关键。
它意味着这个项目不是绑定在某个单一工具上的“生态孤岛”，而是在努力成为跨 AI 助手的产品能力层。工具可以变，接口可以换，但产品工作的框架与方法本身是可迁移的。
README 还特别说明了一点：在 Codex 里，slash commands 不会像 Claude Code 那样作为命令直接运行，但你依然可以用自然语言触发同样的工作流。
比如这一句示例非常有代表性：
Run product discovery on [your idea]: brainstorm options, map assumptions, prioritize the risky ones, then design experiments — pause between each step.
这就像你不是在敲一个命令，而是在对一位训练有素的 PM 搭档说：
“来，我们不要跳步，把 discovery 这套流程完整走一遍，每一步都停下来确认。”
它最迷人的地方，是把产品工作拆成了九个会说话的房间
PM Skills Marketplace 当前包含 9 个插件。与其把它们看成菜单，不如把它们想象成九个房间。每推开一扇门，里面都坐着一类最懂这件事的人。
第一间房：pm-product-discovery
这是“点子还没长骨头”时最该去的房间。
这里关心的不是你想做什么，而是你凭什么做、先验证什么、风险在哪里、怎么用最小成本知道自己是不是在自嗨。
它覆盖了：
- 新产品和已有产品的创意发散
- 假设识别
- 假设优先级排序
- 实验设计
- 特性请求分析
- Opportunity Solution Tree
- 访谈脚本
- 访谈总结
- 指标仪表盘设计
命令里最有代表性的就是 /discover。
这个命令像一个很冷静的探索教练。它不会被你的激情带着跑，而是会先让想法变多，再让假设浮现，再把高风险部分拎出来，最后逼你把验证方案设计清楚。
很多产品死得并不晚，往往死在一开始“太笃定”。而这个插件像那个总会追问一句的人：
“你最怕哪件事其实不成立？”
这很宝贵。
第二间房：pm-product-strategy
如果说 discovery 解决的是“值不值得做”，那 strategy 更像是在问：
“如果做，我们到底要赢在哪里？”
这个插件覆盖了：
- 产品战略画布
- Startup Canvas
- 产品愿景
- 价值主张
- Lean Canvas
- Business Model Canvas
- 变现策略
- 定价策略
- SWOT
- PESTLE
- 波特五力
- 安索夫矩阵
这里的 AI 不再像内容助手，而像一个坐在会议室白板前的战略顾问。它会帮你把愿景、市场、差异化、商业模式、防御性这些问题一层层拆出来。
比如 /strategy，并不是让你写几句“我们要成为行业第一”的口号，而是去构建一个完整的九部分 Product Strategy Canvas。
它像一个不吃口号的人。你说梦想，它会问路径；你说机会，它会问护城河；你说市场，它会问竞争；你说增长，它会问为什么是你。
这类能力在今天尤其重要，因为 AI 可以让“产出战略幻觉”的成本变得极低，而 PM Skills Marketplace 在努力做的，是把战略重新拉回有框架、有推理、有约束的地面。
第三间房：pm-execution
这是最像产品经理日常主战场的一间房。
PRD、OKR、roadmap、sprint、retro、release notes、stakeholder map、user stories、test scenarios，这些工作并不总是性感，但它们决定了团队能不能真的把事推进下去。
这里给人的感觉像一位非常能控场的项目总导演。
你脑子里有个模糊想法，它会帮你写成 PRD。
你有一堆 feature list，它会逼你转成 outcome roadmap。
你开完会只剩一地语音和笔记，它会帮你抽出决策和 action items。
你要开 sprint，它会开始算容量、挑故事、看风险。
你要 retro，它又能把情绪和事实整理成结构。
这个插件里我特别喜欢 /red-team-prd 和 strategy-red-team 这种设计。
很多工具都擅长帮你“把方案说得更像样”，但很少有工具主动帮你“把方案拆得更彻底”。而 red team 的意义，就在于它愿意扮演那个不合群但极其重要的角色：专门找你方案里最脆弱的承重墙。
一个成熟的产品系统，不应该只有生成器，还应该有质疑者。这个插件把这件事也考虑进去了。
第四间房：pm-market-research
这一间房更像用户研究员和市场分析师的联合办公室。
它会处理：
- 用户画像
- 市场细分
- 用户分群
- 客户旅程地图
- 市场规模测算
- 竞品分析
- 用户反馈情感分析
很多产品讨论之所以容易飘，是因为大家讨论的是“想象中的用户”。而这个插件像一个总会把你拽回现实的人：
“你说的用户，到底是谁？”
“他们在什么场景下真的会用？”
“卡在哪里？”
“市场到底有多大？”
“竞品的强项和空白是什么？”
“这些反馈背后到底是抱怨、期待，还是误解？”
这类 skill 的价值在于，它让 AI 不只是帮你总结信息，而是把用户研究和市场分析这些原本容易被跳过的工作，重新纳入标准流程。
第五间房：pm-data-analytics
这一间房不像前几间那么热闹，但它非常硬。
因为很多产品判断最后都要回到数据。
这个插件只列了 3 个 skill，却都很实用：
- SQL 查询生成
- Cohort Analysis
- A/B Test Analysis
它像团队里那个不太说废话、但每次开口都能让人安静下来的分析师。
你说“我想看 Q4 各国家的月活”，它可以写 SQL。
你说“1 月和 2 月用户留存差异怎么解释”，它可以看 cohort。
你说“实验结果能不能上”，它会看显著性、样本量、置信区间，再告诉你该 ship、extend 还是 stop。
这类能力最大的意义，不是替代分析师，而是让 PM 能更快把问题结构化，减少在“怎么问数据”这一步上的摩擦。
第六间房：pm-go-to-market
很多产品团队做产品时很认真，到了发布时却像临时抱佛脚。
而 pm-go-to-market 这间房里坐着的是一群对“怎么把东西送到市场面前”很敏感的人。它关注：
- GTM strategy
- beachhead segment
- ICP
- growth loops
- GTM motions
- competitive battlecard
这里的命令 /plan-launch 很像一位 launch 指挥官。
它不会只问“什么时候发”，还会问：
- 第一批最该打的细分市场是谁
- 理想客户画像长什么样
- 信息该怎么讲
- 渠道怎么选
- 成功指标怎么设
- 上市动作如何编排
很多团队以为发布是“最后一步”，但这个插件像在提醒你：发布不是收尾，而是产品开始接受市场审判的那一刻。
第七间房：pm-marketing-growth
这一间房比 GTM 更偏产品营销与增长表达。
它负责：
- marketing ideas
- positioning
- value prop statements
- product naming
- north star metric
它像团队里那个既懂用户又懂传播的人。
你想不清自己到底和 Notion 有什么区别，它能帮你找 positioning angle。
你不知道产品叫什么更贴近品牌气质，它能帮你 brainstorm 名字。
你在增长会议里反复争论哪个指标最重要，它会帮你定义 North Star Metric 以及配套 input metrics。
这类能力很容易被低估，因为大家总觉得“文案、命名、定位”好像没有架构设计那么硬核。但现实是，很多产品不是死在不会做，而是死在说不清、讲不透、记不住。
这个插件像一个会给产品穿衣服、起名字、找舞台光的人。
第八间房：pm-toolkit
这间房像产品组织里的万能后勤部。
它不一定总在聚光灯下，但经常在关键时刻突然站出来说：“这事我也能帮。”
包括：
- 简历评审
- NDA 起草
- 隐私政策
- 语法与逻辑润色
这让整个项目显得更完整。因为 PM 的工作从来不只是需求与路线图，它还包括大量跨边界的文本工作、合规工作、对外表达工作。
pm-toolkit 的存在让这个市场不只是“核心 PM 方法库”，而更像“围绕 PM 实际工作场景的辅助工具带”。
第九间房：pm-ai-shipping
如果说前面八间房已经很强，那第九间房是让我觉得这个项目很有时代感的关键所在。
因为它直接面对一个正在越来越普遍的新现实：
AI 代码写得越来越快，但人越来越不敢随便发。
README 对它的描述非常明确：这是给那些要对 AI 构建代码负责的 PM 和创始人的。
这一部分特别关注：
- 给 vibe-coded app 补齐文档
- 审查实现与预期的偏差
- 静态安全审计
- 静态性能审计
- 测试覆盖映射
- 最终形成 reviewer-ready shipping packet
这太重要了。
今天很多团队的问题已经不是“做不出来”，而是“做出来了，但没人能说清楚它到底该做什么、权限怎么流转、密钥在哪里、规则是否被实现、测试覆盖到了没有”。
AI 会写代码，但它不会天然留下“意图的记录”。
而没有意图记录，就没有真正的可审查性；没有可审查性，就没有值得信任的上线。
/ship-check 这个命令，本质上像一个非常挑剔但负责任的发布门卫。它不会因为代码跑起来了就让你过去，它还要看：
- 文档齐了吗
- 规则讲清楚了吗
- 安全边界查了吗
- 性能热点看了吗
- 测试缺口标出来了吗
- 最终材料能让 reviewer 看懂了吗
这是一个很成熟的意识：AI 时代的产品交付，不只是 build，更是 auditability。
一个项目，为什么会同时吸引 PM、创始人和 AI 使用者
PM Skills Marketplace 的有趣之处，在于它踩中了三个群体的共同痛点。
对产品经理来说
它把那些本来存在于脑子里的框架，变成了可调用、可重复、可衔接的外部能力。你不再只是“记得有个模型”，而是真的可以在工作流中把模型用起来。
对创始人来说
它像一个低成本但高密度的产品顾问团。尤其是独立开发者、AI 创业者、小团队创始人，常常既要想战略、又要做 discovery、又要写文档、又要推 launch。这个项目等于给他们配了一组不会累的专业角色。
对重度 AI 用户来说
它展示了一种很有启发性的方向：不要只让 AI 更会回答，而要让 AI 更会按领域流程办事。真正有价值的不是更多 token，而是更好的工作结构。
它背后站着的，不只是插件，而是一整条产品方法论血脉
README 最后列出的参考来源很能说明问题。
你能看到 Teresa Torres、Marty Cagan、Alberto Savoia、Dan Olsen、Roger Martin、Ash Maurya、Strategyzer、Christina Wodtke、Anthony Ulwick、Lean Analytics、Sean Ellis、Maja Voje 这些名字。
这让整个项目多了一层可信度。
因为它不是凭空捏出一套“AI 时代 PM 方法”，而是把过去那些已经被反复验证的方法论，重新翻译成 AI 能够执行、调用、串联的技能体系。
这件事很像把一屋子经验丰富的老师傅，请进了一个数字工坊里。
他们不再只是书架上的名字，而开始以 skill 的形式参与具体工作。
我最喜欢它的一点，是它让产品工作重新有了流程感
很多人以为 AI 的意义是“更快”。
PM Skills Marketplace 让我感受到的，反而是另一种价值：让速度重新服从流程，让输出重新服从判断。
它并不是在鼓励你把产品工作压缩成几条 prompt，恰恰相反，它在提醒你：
- discovery 不该被跳过
- strategic clarity 不能靠口号代替
- PRD 不只是文档，而是对齐工具
- launch 不是发公告，而是完整 GTM 设计
- metrics 不是贴数字，而是建立判断坐标
- AI 写出的代码，最终也必须回到可审查、可解释、可交付
这种设计其实很“反浮躁”。
当很多人还在把 AI 当作一台会加速输出的机器时，这个项目已经在尝试把 AI 训练成一个更懂产品工作秩序的协作者。
如果你第一次用它，可以这样开始
如果你现在就想感受这个项目的味道，最适合的方式不是先研究全部插件，而是拿一个真实问题直接上手。
场景一：你有个新点子
1 | /discover AI-powered meeting summarizer for remote teams |
这时候，整个 discovery 流程会像一支小队一样动起来：先发散方向，再识别假设，再找最危险的部分，再设计实验。
场景二：你要写 PRD
1 | /write-prd Smart notification system that reduces alert fatigue |
这会很适合那些已经有明确问题、准备推进落地的阶段。AI 不再只是帮你“写点像 PRD 的东西”，而是按照结构化模板把问题、目标、需求、验收等内容逐步拉直。
场景三：你要规划发布
1 | /plan-launch AI code review tool targeting mid-size engineering teams |
这时，GTM、beachhead、ICP、信息表达、成功指标这些问题就会开始排队出现。
场景四：你想定义北极星指标
1 | /north-star Two-sided marketplace connecting freelancers with clients |
当团队所有人都在忙，但没人知道到底在朝哪个数字负责时，这种命令尤其像一盏灯。
场景五：你手里有一堆 AI 写的代码，但不敢发
1 | /ship-check the payments service |
这时候，pm-ai-shipping 就像一个严肃的发布审核官，开始帮你补文档、查风险、看性能、盘测试、整理成可审阅交付包。
它也在悄悄说明，未来的竞争不是谁更会提问，而是谁拥有更好的技能编排
过去我们常说，AI 时代要学会 prompt。
但像 PM Skills Marketplace 这样的项目会让你意识到，prompt 只是入口，不是终点。
真正拉开差距的，是谁能把一个领域里的知识、方法、流程、判断节点和行动顺序，封装成一套可复用的技能编排系统。
在这个意义上，这个仓库不只是一个 PM 工具集，它还是一个很鲜明的信号：
未来的 AI 协作，不会止于聊天，而会走向角色化、技能化、工作流化。
谁先把自己的专业方法封装成这种结构，谁就更可能在 AI 时代拥有更强的生产杠杆。
结尾
phuryn/pm-skills 最打动我的地方，不是它有 100+ 个 skills、commands 和 plugins，也不是它支持 Claude、Cowork、Codex 这些入口。
而是它在认真对待一个常被忽略的问题：
当 AI 已经能做很多事时，我们怎样让它做事的方式也变得专业。
它没有试图把产品管理神化，也没有把 AI 神化。
它只是搭了一座很实用的桥。
桥的一边，是产品世界里那些被证明有效的框架、模型、经验和节奏。
桥的另一边，是越来越能干、越来越会执行的 AI 助手。
而 PM Skills Marketplace 就站在桥中央，像一个热情但很有秩序的组织者，一边招呼方法论入场，一边安排 AI 各就各位，然后拍拍手说：
“好了，现在别只会写了，我们认真做产品吧。”