协作校准 / 认知校准 / 问题脑暴：当用户有模糊感受说不清问题、方案越补越复杂、想挑战假设、 想重新定义问题、想知道成熟领域里怎么叫这个问题时使用。 可用中文唤起："帮我想想""先聊一下""一起脑暴""我感觉有问题但不清楚是什么" "先别执行，帮我看清问题""挑战我的假设""这个方案是不是想错了""帮我做认知校准"。 也适用于：用户直接说"帮我做 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。