用途：把模糊的产品机会转化为有文档、有证据支撑的决策。该技能将当前代码、测试、契约、分析和运营视为产品事实，将创意文档与 Git 历史视为决策背景。使用任何路由模式前需先阅读 references/idea-workflow.md。
主要能力与模式：按请求选择最窄的适用模式——原始或模糊创意用 GRILL；创建或修订创意文档用 DOCUMENT；审查创意组合用 AUDIT；提出新方向用 GENERATE；决定下一步做什么用 SELECT；构建已批准的创意用 REALIZE。组合请求按 AUDIT → GENERATE → GRILL → DOCUMENT → SELECT → REALIZE 顺序仅使用适用模式。
使用方式：先检查可用的仓库、产品、客户和运营证据；每次只问一个未解决的产品决策，并附推荐答案及其主要权衡；等待用户回答；若请求了文档变更则立即更新创意文档；持续到关键决策解决且双方理解一致。不要询问可用来源能回答的事实，不要抛出问卷，关键分支未解决时不要评分、选择、规划或实现。创建文件前先发现仓库已有的产品创意约定；若不存在且请求了文档，默认使用 docs/product-ideas/<slug>.md，不要无故创建并行层级。
决策质量：区分事实、假设、建议、置信度和下一步行动；在提议恢复已移除能力前先弄清其消失原因；优先有界的第一步有用成果，而非没有具体客户案例的平台工作；置信度低于 70% 时选择验证步骤而非实现；默认最多生成三个候选，仅持久化用户选择的候选；不要将数值评分视为强于其证据。
落地门槛：实现前要求定义用户与问题、有意义的证据或明确验证假设、可衡量结果与停止条件、有界首个版本与非目标、已识别的依赖、信任边界、风险、发布与回滚、已解决的关键产品规则。实现、提交、推送和拉取请求需正常授权；被选中的创意或计划本身不授权代码变更。
交接：返回当前决策、置信度、最强证据、最大未知、下一步行动及任何已更改文档；比较候选时说明次优选项为何落选，而非只给分数。限制：资料未提供具体安装命令、收费或平台支持信息。