用途
simmer-setup 是 simmer 的初始化子技能，用于在精炼循环开始前完成准备工作。它的职责是：检查目标产物或工作区，推断“更好”意味着什么以及如何衡量，向用户提出一份完整的评估方案，并生成驱动整个精炼循环的 setup brief。
核心原则：先检查、再推断、后提议、最后确认。智能体负责思考，用户负责验证、调整或覆盖。绝不要求用户描述智能体能够自行读取的内容。
主要能力
阶段一：识别与检查
识别产物来源，支持四种模式：
- from-file：用户提供文件路径，产物类型为单文件
- from-paste：用户粘贴内容，产物类型为单文件
- from-workspace：用户提供目录路径，产物类型为工作区
- seedless：用户描述要创建的内容，产物类型为单文件或工作区
若来源不明确，只询问一次，让用户选择文件、粘贴、工作区或从描述生成。
对单文件（from-file 或 from-paste）：读取文件/内容，识别产物类型（散文、代码、提示词、配置等），记录评估器引用（注释中提到的测试命令、基准脚本），记录内容中可见的输出格式预期。
对工作区（from-workspace）：列出目录内容，读取关键文件（配置文件、入口点、脚本、README），重点查找评估器脚本（evaluate.、test.、benchmark.* 或配置/README 中引用的脚本）、验证脚本（validate.、check. 或快速测试变体）、配置文件（config.json、config.yaml、.env 等，揭示可变化的参数）、输出示例（样本输出、预期输出或基准真值文件）、策略/插件目录（strategies/、plugins/、models/ 等可扩展点）、提示词文件（prompt.md、system.txt、模板文件等生成器可修改的内容）。
对 seedless：无需检查，直接依据用户描述工作，并从描述中分类产物类型。
阶段二：分类与推断
问题类别检测（绝不询问用户类别）：
- 若为 seedless 且描述为散文/创意 → text/creative
- 否则若产物类型为工作区且发现评估器脚本或用户提到评估器 → pipeline/engineering
- 否则若发现评估器或产物为代码 → code/testable
- 否则 → text/creative
各类别推断内容：
- 文本/创意：仅推断标准，建议 2-3 条标准，无契约、无评估器、无搜索空间，路径轻量。
- 代码/可测试：推断标准 + 评估。若发现评估器脚本则作为提议评估器；若代码产生结构化输出则推断输出契约；记录代码中可见的约束（模型引用、API 端点等）。
- 流水线/工程：推断全部内容，包括标准（来自评估器输出指标）、评估器（检查中发现的脚本）、输出契约（来自流水线输出格式、评估器预期或示例输出）、验证命令（发现的快速测试脚本或提议子集运行）、搜索空间（来自配置参数、可扩展点、提示词文件）、背景（来自配置值、目录结构）。
种子标准表（提议标准时使用，优先采用从实际产物推断的标准）：
- 文档/规格：清晰度、完整性、可操作性
- 创意写作：叙事张力、具体性、声音一致性
- 邮件/沟通：价值主张清晰度、语气匹配、行动号召强度
- 提示词/指令：指令精确度、输出可预测性、边缘情况覆盖
- API 设计：契约完整性、开发者体验、一致性
- 代码（非 cookoff）：简洁性、健壮性、可读性
- 冒险钩子/游戏内容：叙事张力、玩家能动性、具体性
- 博客/文章：论点清晰度、参与度、结构
- 流水线/工作流：覆盖度、效率、噪声
- 配置/基础设施：正确性、资源效率、可维护性
阶段三：提议或继续
充分性检查：在提议前，检查用户初始提示 + 检查结果是否已提供 brief 所需的全部内容（产物已识别、标准可确定、主要标准已说明、评估方法已知、迭代次数已知）。若全部覆盖，跳过提议直接进入阶段五输出 brief。
若部分字段缺失或模糊，将推断的一切作为单条对话式评估呈现。用户确认、调整或覆盖。这是一条消息，不是一连串问题。
文本/创意评估模板：说明产物类型、使用仅评判评估、建议标准、迭代次数与种子描述，询问是否合适。
代码/可测试评估模板：说明代码功能、发现的评估器/测试脚本、建议标准、输出契约（若推断出）、约束（若发现）、迭代次数，询问哪个标准最重要。
流水线/工程评估模板：说明这是流水线优化问题，列出评估器（脚本路径及衡量内容）、输出契约、验证（脚本路径或提议子集命令）、搜索空间（模型、提示词、拓扑）、标准（来自评估器指标，标注是否主要）、约束、迭代次数，询问是否正确。
用户可执行的操作：按原样确认、调整细节、覆盖、补充信息、请求澄清。目标是一轮确认。若用户调整清晰，纳入后直接输出 brief，除非用户要求查看更新后的评估，否则不重新提议。
阶段四：补充缺失信息
提议后，若用户确认但关键字段仍未知，只询问无法推断的内容，并说明为何需要。可能无法推断的内容包括：主要标准、文件中不可见的背景约束（预算、截止日期、可用硬件）、用户是否想探索可见参数之外的内容。不要询问已推断的内容。标准最多 3 条，若推断超过 3 条则选最具影响力的 3 条。若用户初始请求中提到了标准，优先使用用户提到的。每条标准需要描述 10/10 是什么样；若能从评估器推断则使用，否则询问。
阶段五：输出 Setup Brief
按固定格式输出，供后续所有子技能使用：
ARTIFACT: [from-paste 为完整内容，from-file 为文件路径，from-workspace 为目录路径，seedless 为描述] ARTIFACT_TYPE: [single-file | workspace] CRITERIA:
- [标准 1]: [10/10 是什么样]
- [标准 2]: [10/10 是什么样]
- [标准 3]: [10/10 是什么样] PRIMARY: [标准名称 — 若等权则省略] EVALUATOR: [要运行的命令 — 仅评判则省略] BACKGROUND: [约束与资源 — 未提供则省略] OUTPUT_CONTRACT: [有效输出格式描述 — 文本/创意则省略] VALIDATION_COMMAND: [快速检查命令 — 无廉价验证则省略] SEARCH_SPACE: [可探索范围 — 无约束则省略] JUDGE_MODE: [single | board — 自动选择] ITERATIONS: [N] MODE: [seedless | from-file | from-paste | from-workspace] OUTPUT_DIR: [路径，默认 docs/simmer]
默认迭代次数为 3，用户指定则覆盖。不要询问迭代次数。
评判模式自动选择（不询问用户，从产物和标准推断）：
- 文本/创意且 ≤2 条标准且产物短（邮件、推文、标语、单段）→ single
- 文本/创意且 3 条标准或产物较长/复杂 → board
- 代码/可测试（任意）→ board
- 流水线/工程（任意）→ board
用户覆盖：用户说“用单个评判”则用 single；说“用评判委员会”或“用小组”则用 board。用户意图优先，但检查不匹配：若用户请求 single 但产物复杂（工作区、有评估器、3 条标准、代码/流水线），提醒一次是否改用 board。只问一次，若用户坚持 single 则尊重并继续。
OUTPUT_DIR 默认为 docs/simmer，用户指定其他位置或在测试/临时环境运行时覆盖。
将 brief 返回给编排器。不要继续生成或评判——那是编排器的职责。
使用方式
作为 simmer 的子技能被调用。用户提供产物（文件路径、粘贴内容、目录路径或描述），simmer-setup 完成检查、推断、提议与确认，最终输出 setup brief。
适用场景
- 文本/创意精炼（如 DND 冒险钩子、创意写作），轻量路径，仅评判评估
- 代码/可测试精炼（如提取提示词优化），带测试框架
- 流水线/工程优化（如实体提取流水线的模型/提示词/拓扑选择），完整检查
限制
- 标准最多 3 条，超过则需用户优先排序
- 仅负责生成 brief，不执行生成或评判
- 文本/创意路径不涉及契约、评估器或验证
- 无法推断的字段需向用户询问，但不应询问已推断的内容
- 评判模式自动选择，用户可覆盖但复杂产物会收到一次提醒
- 具体收费、价格、平台等信息暂未提供