PANGKAIFENG
UserAI product manager skills for Codex/Claude: brainstorming, product research, PRD workflows, requirements review, and planning handoff.
Categories
Indexed Skills (27)
research-topic-compiler
专题研究编译器 / Persona-Adaptive Research-to-Learning Compiler：当用户要围绕一个主题做系统学习、 专题研究、行业调研、最佳实践提炼、轻量概念解读、概念源流、语义演化、PM 技术评审提问脚本、行业演进看板、 本地 HTML 研究看板、可视化研究报告或跨职能 Dashboard 时使用。 当用户只有大白话、模糊方向、业务愿望或 Roadmap/PRD 前置材料想法，需要先转成清晰研究目标、研究问题和输出要求时也使用。 适合把研究转成 Research Project、学习报告、证据矩阵、PM 决策看板、候选池、模板、实践任务、业务判断、商业化输入或高门槛应用研究前置。适合“系统研究一个主题” “整理到 Obsidian”“做深度专题”“研究行业最佳实践”“概念解读”“概念源流”“PM 技术评审提问脚本” “行业演进看板”“这个主题对我的业务有什么用”。不适合创建 Skill、评审 SKILL.md、普通即时搜索或一次性摘要。 当用户已经要在明确候选项中选一个、需要最终推荐和排除理由时，应使用 decision-research。
ai-collaboration-calibration
协作校准 / 认知校准 / 问题脑暴：当用户有模糊感受说不清问题、方案越补越复杂、想挑战假设、 想重新定义问题、想知道成熟领域里怎么叫这个问题时使用。 可用中文唤起："帮我想想""先聊一下""一起脑暴""我感觉有问题但不清楚是什么" "先别执行，帮我看清问题""挑战我的假设""这个方案是不是想错了""帮我做认知校准"。 也适用于：用户直接说"帮我做 X 功能""接入 Y 平台"但背景复杂、或对话早期感觉方向可能跑偏时， AI 主动识别并建议进入脑暴模式。 这里的“挑战假设”主要指问题定义、目标、约束和领域定位层面的假设；如果问题已确认且用户已有具体方案、 计划、架构或决策要压力测试，应转用 grill-me。不用于翻译、摘要、格式整理、单文件小改等简单执行任务。
brainstorming
设计脑暴 / 实现前方案校准：当用户想把已基本成立的想法、功能方向或产品问题，在写 PRD、画 mockup 或进入开发计划前，先比较方案、确认取舍、对齐 UI/视觉约束，并收敛成可执行设计 spec 时使用。 可用中文唤起：“先脑暴一下方案”“先不要写 PRD，帮我设计几种路径”“参考 brainstorming 把这个需求变成设计 spec” “实现前先讨论设计”。问题还没定义清楚时先用 ai-collaboration-calibration；已有方案要压力测试时用 grill-me； 直接写 PRD 时用 prd-architect。
prd-architect
PRD 架构师 / 需求文档起草：当用户要把一个产品想法、需求草稿、脑暴结果或功能说明整理成 PRD 时使用。 可用中文唤起：“帮我写 PRD”“帮我选 PRD 模板”“把这个需求整理成 PRD”“判断该用轻量 PRD 还是标准 PRD” “补一张可编辑 Draw.io 核心流程图”“PRD 里加架构图”。 会在 PRD-lite、PRD-standard、PRD-ai-native 中选择一个模板资产按需加载，并在需要时加载 mockup handoff、 Draw.io 图示或开发 handoff 附录；页面型 PRD 默认联动生成项目 UI 对齐的 HTML、关键截图和正文证据。 不用于直接编码、单纯画 UI，或评审一份已经写好的 PRD。
prd-review
PRD 评审 / 需求评审：当用户已有 PRD 初稿、handoff、需求文档或产品方案，需要从 PM、研发、测试视角找缺口、 冲突、不可实现点和不可测试点时使用。可用中文唤起：“帮我审 PRD”“从研发和测试视角挑问题” “这个需求文档能不能交付开发”“帮我给 PRD 出修改草案”“检查 PRD 图示是否缺失或不可编辑”。 不用于凭空生成 PRD 初稿、直接写代码，或对 PRD 背后的成熟方案做一问一答压力测试；方案压测用 grill-me。
prd-to-issues
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。
dingtalk-prd-publisher
Use when publishing a local PRD Markdown file to DingTalk Docs or Drive with version-history preflight and read-back, or when validating an approved Product Delivery Package through its fail-closed dry-run path. Package mode real writes require a trusted host approval capability and are unavailable in the current Agent runtime.
solution-to-delivery
方案到交付 Workflow：当用户显式调用 `$solution-to-delivery`，或明确要求运行“方案到交付”完整流程时使用。 把已确认产品方案转成经过独立 Review 的 PRD、适用的 UI/HTML/截图、版本拆分和 Product Delivery Package；当前 Agent Runtime 只做 Package 发布 dry-run，真实写入保持 authorization_required。
ai-work-assetization-diagnoser
AI 工作资产化诊断器 / Assetization Router：当用户提供 AI 协作会话、重复任务、prompt、工作流描述、 团队 AI 使用场景或一次成功交付过程，并要求判断应该沉淀成 Prompt、Context Pack、Workflow、Skill、 Loop、System，或根本不值得沉淀时使用。它只做诊断、分层和下一步资产建议，不替代具体 Skill 创建、 PRD 起草、调研、实现或自动化执行。不用于普通事实查询、一次性文案、trace 根因分析或高责任专业判断。
competitive-analysis
竞品决策分析 / Competitive Decision Brief：当用户要调研竞品、替代方案、新产品、SaaS/AI 产品或市场信号， 并希望把官网、定价、评论、文档、更新日志、登录态走查、截图或浏览器取证转成产品定位、路线图、定价、 功能优先级、差异化、Go/No-Go 或 PRD 输入时使用。核心行为是先锚定产品决策，再选择证据渠道， 最后输出可行动的 Product Decision Brief；不要把它降级成泛泛功能清单、纯 UX 走查或“点完所有按钮”报告。
complex-exploration
复杂探索资产化 / Complex Exploration：当用户面对复杂、不确定、多轮迭代的产品策略、Roadmap、商业化定价、竞品定位、复杂 PRD 前置探索、项目复盘或方法论沉淀任务时使用。它先判断任务类型，暴露隐含假设，重构真正问题，规划探索路径和中间产物，并在结束后沉淀认知、结构、方法论、工具和影响力资产。不用于简单润色、翻译、摘要、明确执行任务；问题只需早期认知校准时优先用 ai-collaboration-calibration，已有方案要压力测试时用 grill-me，系统专题研究用 research-topic-compiler。
decision-research
决策调研 / Decision-Driven Research：当用户面对一个具体决策需要找信息时使用——「有没有现成方案」 「怎么接入 X 平台」「这个技术可行吗」「业界怎么做 Y」「选 A 还是 B」「桌面端应该怎么定位」 「高级版和基础版怎么拉开差异」「这个产品方向对不对」。 核心行为：先框定研究层级和问题类型，再锚定决策问题，枚举竞争假设，主动找反对证据， 用排除逻辑给出有立场的结论。支持技术选型、产品策略、商业判断、竞品定位等所有需要做决定的调研。 可用中文唤起：「帮我调研」「有没有现成方案」「这个怎么接」「技术上可行吗」「帮我选一个」 「这个产品方向对不对」「我们应该怎么定位」「行业怎么做」。 与 research-topic-compiler 的边界：需要最终选择、推荐、排除理由、置信度和颠覆条件时用这个； 如果目标是长期学习、候选池沉淀或 Research Project，用 research-topic-compiler，再把 Candidate Backlog 交回本 Skill 做最终决策。 不用于：问题还没定义清楚时（先用 ai-collaboration-calibration L4-fuzzy 脑暴）。
ui-mockup-desktop-workbench
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 的迁移边界。
ui-wireframe-to-html
PRD 到 UI 线框 / 结构阶段：当需要把 PRD 的界面定义先转成 screen inventory、状态模型、ASCII 布局、低保真 HTML mockup， 并先确认结构/状态而不是视觉 polish 时使用。这个 Skill 只负责 UI mockup 的结构阶段；如果用户要高保真、真实前端项目对齐、 project-native preview、component map、implementation notes 或“开发完全复刻”，必须转用 ui-mockup-desktop-workbench。
stylework-yunxiao-workitem-submitter
StyleWork 云效工作项提报 / 需求与缺陷创建：当用户要把讨论结论、排查记录、日志、代码、接口结果、截图或复现过程整理成云效需求或缺陷，并要求预览后通过云效 MCP 提交时使用��也适用于判断工作项颗粒度、生��证据化描述和回读创建结果；不用于批量排期、导出到钉钉、静默修改已有工作项，或在未确认时产生外部写入。
agent-trace-diagnoser
Agent trace 诊断器：当用户提供 trace、日志 JSON、agent 执行记录、工具调用序列，或说“看下这个日志/trace，定位根因”“只说��问题不要改文件”时使用；用中文输出核心根因、可视化执行流程图、trace 证据链、可能文件/行和修复建议，默认只读。不用于没有日志证据的新功能设计、普通代码解释或直接修复代码。
customer-requirement-discovery
客户需求发现与澄清助手：当用户是销售、客户成功或售前，拿到客户模糊、宽泛、缺少产品边界的需求，需要先在内部最多五轮补齐关键事实，再生成一次性客户澄清问题清单、需求摘要与通用技术可行性判断时使用；当确认需求将落入 StyleWork 时加载可选产品与 UI 上下文，并可在信息足够或明确要求时输出带假设标记的轻量 Demo。不要用于直接报价、承诺交期、替代正式 PRD 或在信息不足时假装已有能力。
project-context-steward
Use when / 当用户进入一个新项目或跨仓库工作区，需要扫描产品、用户、业务工作流、技术架构、仓库边界、领域语言、阅读入口和历史踩坑，并生成或持续维护全局 PROJECT_CONTEXT.md。适合用户说“先完整看下项目并沉淀上下文”“给这个项目建上下文文档”“把这次踩坑更新到项目上下文”。不用于单个 PRD 起草、纯目录治理或一次性代码实现。
skill-reviewer
Skill 评审 / Skill 审计：当用户要检查、评审、优化 Codex/Agent Skill �� SKILL.md 时使用。 可用中文唤起：“帮我 review 这个 Skill”“检查这个 SKILL.md”“这个能力适不适合做成 Skill” “优化 Skill 触发描述”“看下这个 Skill 有没有问题”。重点检查触发边界、输入输出、工作流门槛、 工具边界、context budget、资源拆分、评估准备度和治理风险。
stylework-requirement-planning
StyleWork 需求排期共创 / 需求优先级讨论：当用户给出云效导出、钉钉 Sheet、Excel、截图或一批需求标题，希望先汇总这一批在解决什么，再识别重复、依赖、前置能力和模糊项，并结合领导重点、客户承诺、阶段方向、技术难度与容量讨论建议迭代和优先级时使用。适用于信息不完整但仍需要临时排期建议的场景。只读分析，不用于导出到钉钉、自动修改云效/钉钉、替用户作最终排期决定或承诺交期。
team-skill-creator
Skill 生命周期治理 / 能力沉淀判断：当用户要新建、导入、合并、发布、更新、弃用、退役或删除一个 可复用 Skill，或要决定它应进入统一公开仓、项目、本地 Agent 或 Multica 时使用。 可用中文唤起：“帮我创建一个 Skill”“把这个流程固化成 Skill”“导入这个 GitHub Skill” “这个 Skill 应该放哪里”“把 Skill 发布到多个 Agent”。只评审现有 SKILL.md 时改用 skill-reviewer。
stylework-yunxiao-requirement-sync
StyleWork 云效需求同步 / 云效导出到钉钉表格：当用户要把云效某个月或某批需求导出为 Excel，并复制到已有钉钉在线表格的新 Sheet，按迭代排序、分组留空、设置黄色加粗表头、冻结首行和置顶时使用。也适用于登录过期后扫码继续、用户直接提供本地 Excel、或检查本次同步结果。V1 只做云效到钉钉，不用于需求排期判断、钉钉反向写回云效、创建新的钉钉文件或修改已有 Sheet。
decision-loop
决策闭环：当用户显式调用 `$decision-loop`，或明确要求进入“决策闭环”时使用。 面向一个已经明确、但因关键证据不足而无法下结论的产品或技术决策，在研究与决策之间最多循环三轮，直到决策成立或进入 Human Gate；不适合开放式领域学习。
delivery-loop
交付闭环：当用户显式调用 `$delivery-loop`，或明确要求进入“交付闭环”时使用。 面向已有 PRD、UI/HTML、截图或 Product Delivery Package 但仍有 Review 缺口的场景，在独立评审与定点修订之间最多循环三轮，直到 package_ready 或进入 Human Gate；不用于从模糊问题开始。
solution-loop
方案闭环：当用户显式调用 `$solution-loop`，或明确要求进入“方案闭环”时使用。 面向已经存在候选方案、但需要反方挑战和定点修订的场景，在 brainstorming Maker 与 grill-me Critic 之间最多循环三轮，直到方案确认或进入 Human Gate；不用于从零脑暴方案。
problem-to-solution
问题到方案 Workflow：当用户显式调用 `$problem-to-solution`，或明确要求运行“问题到方案”完整流程时使用。 把模糊产品问题经过校准、必要的研究/决策、方案生成和挑战，推进为一个可进入 PRD 的已确认方案；不负责 PRD 交付或外部发布。
grill-me
方案拷问 / 压力测试：当用户有一个产品方案、架构设计、计划或决策，想被连续追问、反方挑战、 压测取舍和失败模式时使用。可用中文唤起：“拷问我的方案”“压力测试这个设计”“帮我问 hard questions” “这个方案哪里会翻车”“grill me”。目标是一问一答把决策树走清楚，不是直接替用户写最终方案。 如果用户还不知道真正问题是什么，先用 ai-collaboration-calibration；如果用户要标准 PRD 交付准备度评审， 用 prd-review。
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.