ai-product-manager-skills

协作校准 / 认知校准 / 问题脑暴：当用户有模糊感受说不清问题、方案越补越复杂、想挑战假设、 想重新定义问题、想知道成熟领域里怎么叫这个问题时使用。 可用中文唤起："帮我想想""先聊一下""一起脑暴""我感觉有问题但不清楚是什么" "先别执行，帮我看清问题""挑战我的假设""这个方案是不是想错了""帮我做认知校准"。 也适用于：用户直接说"帮我做 X 功能""接入 Y 平台"但背景复杂、或对话早期感觉方向可能跑偏时， AI 主动识别并建议进入脑暴模式。 这里的“挑战假设”主要指问题定义、目标、约束和领域定位层面的假设；如果问题已确认且用户已有具体方案、 计划、架构或决策要压力测试，应转用 grill-me。不用于翻译、摘要、格式整理、单文件小改等简单执行任务。

AI 工作资产化诊断器 / Assetization Router：当用户提供 AI 协作会话、重复任务、prompt、工作流描述、 团队 AI 使用场景或一次成功交付过程，并要求判断应该沉淀成 Prompt、Context Pack、Workflow、Skill、 Loop、System，或根本不值得沉淀时使用。它只做诊断、分层和下一步资产建议，不替代具体 Skill 创建、 PRD 起草、调研、实现或自动化执行。不用于普通事实查询、一次性文案、trace 根因分析或高责任专业判断。

设计脑暴 / 实现前方案校准：当用户想把已基本成立的想法、功能方向或产品问题，在写 PRD、画 mockup 或进入开发计划前，先比较方案、确认取舍、对齐 UI/视觉约束，并收敛成可执行设计 spec 时使用。 可用中文唤起：“先脑暴一下方案”“先不要写 PRD，帮我设计几种路径”“参考 brainstorming 把这个需求变成设计 spec” “实现前先讨论设计”。问题还没定义清楚时先用 ai-collaboration-calibration；已有方案要压力测试时用 grill-me； 直接写 PRD 时用 prd-architect。

竞品决策分析 / Competitive Decision Brief：当用户要调研竞品、替代方案、新产品、SaaS/AI 产品或市场信号， 并希望把官网、定价、评论、文档、更新日志、登录态走查、截图或浏览器取证转成产品定位、路线图、定价、 功能优先级、差异化、Go/No-Go 或 PRD 输入时使用。核心行为是先锚定产品决策，再选择证据渠道， 最后输出可行动的 Product Decision Brief；不要把它降级成泛泛功能清单、纯 UX 走查或“点完所有按钮”报告。

复杂探索资产化 / Complex Exploration：当用户面对复杂、不确定、多轮迭代的产品策略、Roadmap、商业化定价、竞品定位、复杂 PRD 前置探索、项目复盘或方法论沉淀任务时使用。它先判断任务类型，暴露隐含假设，重构真正问题，规划探索路径和中间产物，并在结束后沉淀认知、结构、方法论、工具和影响力资产。不用于简单润色、翻译、摘要、明确执行任务；问题只需早期认知校准时优先用 ai-collaboration-calibration，已有方案要压力测试时用 grill-me，系统专题研究用 research-topic-compiler。

决策调研 / Decision-Driven Research：当用户面对一个具体决策需要找信息时使用——「有没有现成方案」 「怎么接入 X 平台」「这个技术可行吗」「业界怎么做 Y」「选 A 还是 B」「桌面端应该怎么定位」 「高级版和基础版怎么拉开差异」「这个产品方向对不对」。 核心行为：先框定研究层级和问题类型，再锚定决策问题，枚举竞争假设，主动找反对证据， 用排除逻辑给出有立场的结论。支持技术选型、产品策略、商业判断、竞品定位等所有需要做决定的调研。 可用中文唤起：「帮我调研」「有没有现成方案」「这个怎么接」「技术上可行吗」「帮我选一个」 「这个产品方向对不对」「我们应该怎么定位」「行业怎么做」。 与 research-topic-compiler 的边界：需要最终选择、推荐、排除理由、置信度和颠覆条件时用这个； 如果目标是长期学习、候选池沉淀或 Research Project，用 research-topic-compiler，再把 Candidate Backlog 交回本 Skill 做最终决策。 不用于：问题还没定义清楚时（先用 ai-collaboration-calibration L4-fuzzy 脑暴）。

方案拷问 / 压力测试：当用户有一个产品方案、架构设计、计划或决策，想被连续追问、反方挑战、 压测取舍和失败模式时使用。可用中文唤起：“拷问我的方案”“压力测试这个设计”“帮我问 hard questions” “这个方案哪里会翻车”“grill me”。目标是一问一答把决策树走清楚，不是直接替用户写最终方案。 如果用户还不知道真正问题是什么，先用 ai-collaboration-calibration；如果用户要标准 PRD 交付准备度评审， 用 prd-review。

PRD 评审 / 需求评审：当用户已有 PRD 初稿、handoff、需求文档或产品方案，需要从 PM、研发、测试视角找缺口、 冲突、不可实现点和不可测试点时使用。可用中文唤起：“帮我审 PRD”“从研发和测试视角挑问题” “这个需求文档能不能交付开发”“帮我给 PRD 出修改草案”“检查 PRD 图示是否缺失或不可编辑”。 不用于凭空生成 PRD 初稿、直接写代码，或对 PRD 背后的成熟方案做一问一答压力测试；方案压测用 grill-me。

PRD 到研发 Issue 拆解 / implementation issues：当用户已有 PRD、需求文档、handoff、产品方案或 GitHub PRD issue， 需要拆成可独立领取、可验收、适合 GitHub Issues 承接的开发任务时使用。可用中文唤起： “把 PRD 拆成 issue”“需求文档拆任务”“生成 GitHub issues”“PRD 拆工单”“拆 implementation issues” “按 vertical slice 拆开发票”。不用于从零写 PRD；那类请求用 prd-architect。不用于评审 PRD 是否完整； 那类请求先用 prd-review。

专题研究编译器 / Persona-Adaptive Research-to-Learning Compiler：当用户要围绕一个主题做系统学习、 专题研究、行业调研、最佳实践提炼、轻量概念解读、概念源流、语义演化、PM 技术评审提问脚本或行业演进看板时使用。 当用户只有大白话、模糊方向、业务愿望或 Roadmap/PRD 前置材料想法，需要先转成清晰研究目标、研究问题和输出要求时也使用。 适合把研究转成 Research Project、学习报告、证据矩阵、PM 决策看板、候选池、模板、实践任务、业务判断、商业化输入或高门槛应用研究前置。适合“系统研究一个主题” “整理到 Obsidian”“做深度专题”“研究行业最佳实践”“概念解读”“概念源流”“PM 技术评审提问脚本” “行业演进看板”“这个主题对我的业务有什么用”。不适合创建 Skill、评审 SKILL.md、普通即时搜索或一次性摘要。 当用户已经要在明确候选项中选一个、需要最终推荐和排除理由时，应使用 decision-research。

PRD 到高保真 UI 交付对齐 / 桌面工作台 UI mockup：当用户已有 PRD、UI 规范、真实前端项目路径、截图或页面状态清单， 需要先从 PRD 提炼 UI 结构、状态模型和 ASCII 布局，再进入高保真 mockup、项目原生 preview 或开发交付 handoff 时使用。 优先输出项目原生 preview route/component；只有早期概念确认或无法接入真实项目时才输出 standalone HTML。 必须包含结构阶段产物、screen contract、component map、implementation notes、截图/验证结果和 HTML/preview 的迁移边界。

PRD 到 UI 线框 / 结构阶段：当需要把 PRD 的界面定义先转成 screen inventory、状态模型、ASCII 布局、低保真 HTML mockup， 并先确认结构/状态而不是视觉 polish 时使用。这个 Skill 只负责 UI mockup 的结构阶段；如果用户要高保真、真实前端项目对齐、 project-native preview、component map、implementation notes 或“开发完全复刻”，必须转用 ui-mockup-desktop-workbench。

PRD 架构师 / 需求文档起草：当用户要把一个产品想法、需求草稿、脑暴结果或功能说明整理成 PRD 时使用。 可用中文唤起：“帮我写 PRD”“帮我选 PRD 模板”“把这个需求整理成 PRD”“判断该用轻量 PRD 还是标准 PRD” “补一张可编辑 Draw.io 核心流程图”“PRD 里加架构图”。 会在 PRD-lite、PRD-standard、PRD-ai-native 中选择一个模板资产按需加载，并在需要时加载 mockup handoff、 Draw.io 图示或开发 handoff 附录。不用于直接编码、单纯画 UI，或评审一份已经写好的 PRD。