用途：帮助用户通过对话塑造想法，包括生成选项、在选项间做选择、压力测试假设，或把想法转成结构化文档。技能分两种模式，需先判断用户需要哪一种。
模式A 对话：不产出文件，适合探索或分析。按开场信号匹配四种动作：发散（生成8–10个选项，含显而易见、非显而易见和一个“疯狂但也许可行”的选项，先不评判）；收敛（按可行性×影响力×热情度打分，给出明确推荐并说明取舍与被否选项理由）；压力测试（先强化想法到最强版本，再攻击：最危险假设、规模化后最先崩溃之处、现有替代方案、反向激励，不软化结论）；规格（输出问题、方案、成功指标、V1范围、下一步，V1最多3–5个功能）。硬性规则：不为避免冲突而附和弱想法；不知问题不写规格；一次只做一个动作。
模式B 流水线：把零散输入转成实现产物，经审批门控。流程为 INTAKE → CONTRACT（置信度≥95%）→ PRD → SPEC，低于95%需提问。阶段1接收任意杂乱输入并暴露矛盾与缺失的项目名；阶段2加载 references/confidence-rubric.md 保守打分，达到95%后确认项目名，加载 references/contract-template.md 并写入 ./docs/ideation/{project-name}/contract.md，获批准后继续；阶段3按实现阶段加载 references/prd-template.md，写 prd-phase-{n}.md，含用户故事、需求与验收标准；阶段4对已批准阶段加载 references/spec-template.md，写 spec-phase-{n}.md，含技术方案、文件变更、代码模式与验证命令，最终回复列出所有生成文件路径。
边界：仅记录想法用 obsidian/ideas；要构建或交付 MVP 用 prototype；实现范围已定、只需技术规格用 dev/spec。
限制与注意：置信度容易虚高，需保守评分；85–94 分不要跳过提问；矛盾要显式指出而非默默解决；合同未批准前不要生成 PRD。具体安装方式、收费与平台支持暂未提供。