用途
simmer-setup 是 simmer 的安装配置子技能，负责在精炼循环开始前完成准备工作：检查产物或工作区，推断“更好”的含义与衡量方式，向用户提出完整评估，并产出驱动整个精炼循环的 setup brief。
其核心原则是：先检查、再推断、后提议、最后确认。由智能体完成思考，用户负责验证、调整或覆盖。不应要求用户描述智能体本就能读取的内容。
主要能力
阶段一：识别与检查
识别产物来源，包括上下文中提到的文件路径、用户粘贴的文本、目录路径或工作区，以及从零生成某物的描述（seedless 模式）。若存在歧义，只询问一次。
设置模式与产物类型：
- from-file / single-file：用户提供文件路径
- from-paste / single-file：用户粘贴内容
- from-workspace / workspace：用户提供目录路径
- seedless / single-file 或 workspace：用户描述要创建的内容
对单文件（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
- 否则若产物类型为 workspace 且发现评估器脚本或用户提到评估器 → pipeline/engineering
- 否则若发现评估器或产物为代码 → code/testable
- 否则 → text/creative
各类别推断内容：
- 文本/创意：仅推断标准，建议 2-3 条标准，无契约、无评估器、无搜索空间，路径应轻量。
- 代码/可测试：推断标准与评估。若发现评估器脚本则作为提议评估器；若代码产生结构化输出则推断输出契约；记录代码中可见的约束（模型引用、API 端点等）。
- 流水线/工程：推断全部内容，包括标准（来自评估器输出指标）、评估器（检查中发现的脚本）、输出契约（来自流水线输出格式、评估器预期或示例输出）、验证命令（发现的快速测试脚本或提议子集运行）、搜索空间（来自配置参数、可扩展点、提示词文件）、背景（来自配置值、目录结构）。
种子标准表（提议标准时使用，优先采用从实际产物推断的标准）：
- 文档/规格：清晰度、完整性、可操作性
- 创意写作：叙事张力、具体性、声音一致性
- 邮件/沟通：价值主张清晰度、语气匹配、行动号召强度
- 提示词/指令：指令精确度、输出可预测性、边界情况覆盖
- API 设计：契约完整性、开发者体验、一致性
- 代码（非 cookoff）：简洁性、健壮性、可读性
- 冒险钩子/游戏内容：叙事张力、玩家能动性、具体性
- 博客/文章：论点清晰度、参与度、结构
- 流水线/工作流：覆盖度、效率、噪声
- 配置/基础设施：正确性、资源效率、可维护性
阶段三：提议或继续
充分性检查：在提议前，检查用户初始提示与检查结果是否已提供 brief 所需全部字段——产物已识别、标准可确定、主要标准已说明、评估方法已知、迭代次数已知。若全部覆盖，跳过提议直接进入阶段五输出 brief（作为子智能体运行时常见）。
若部分字段缺失或模糊，将推断内容作为单条对话式评估呈现，用户确认、调整或覆盖。这是一条消息，而非一连串问题。
文本/创意评估示例格式：说明产物类型、采用仅评审评估、列出建议标准、说明迭代次数与种子描述，询问是否合适。
代码/可测试评估示例格式：说明代码用途、发现的评估器、列出标准、输出契约与约束、迭代次数，询问哪条标准最重要。
流水线/工程评估示例格式：说明这是流水线优化问题，列出评估器、输出契约、验证、搜索空间（模型、提示词、拓扑）、标准、约束、迭代次数，询问是否正确。
用户可执行的操作：按原样确认、调整细节、覆盖、补充信息、请求澄清。目标是一轮确认；若用户调整清晰，纳入后直接输出 brief，除非用户要求查看更新后的评估，否则不重新提议。
阶段四：补充缺失信息
提议后若用户确认但关键字段仍未知，只询问无法推断的内容，并说明为何需要。可能无法推断的内容包括：主要标准、文件中不可见的背景约束（预算、截止日期、可用硬件）、用户是否想探索可见参数之外的内容。不要询问已推断的内容。标准最多 3 条；若从评估器推断出超过 3 条，选取影响最大的 3 条；若用户初始请求中已提到标准，优先使用用户标准。每条标准需要 10/10 的描述；能从评估器推断则使用，否则询问。
阶段五：输出 setup brief
产出固定格式，供后续所有子技能消费，字段包括：ARTIFACT、ARTIFACT_TYPE、CRITERIA（含每条标准的 10/10 描述）、PRIMARY（若等权则省略）、EVALUATOR（仅评审则省略）、BACKGROUND（未提供则省略）、OUTPUT_CONTRACT（文本/创意省略）、VALIDATION_COMMAND（无廉价验证则省略）、SEARCH_SPACE（无约束则省略）、JUDGE_MODE、ITERATIONS、MODE、OUTPUT_DIR。
默认迭代次数为 3，用户指定则覆盖，不询问迭代次数。
评审模式自动选择（不询问用户，依据产物与标准推断）：
- 文本/创意且标准 ≤2 条且产物短（邮件、推文、标语、单段）→ single
- 文本/创意且 3 条标准或产物较长/复杂 → board
- 代码/可测试（任意）→ board
- 流水线/工程（任意）→ board
用户覆盖：用户说“单个评审”则用 single；说“评审团”或“小组”则用 board。用户意图优先，但检查不匹配：若用户要求 single 而产物复杂（工作区、存在评估器、3 条标准、代码/流水线），只提醒一次，询问是否改用 board；用户坚持则尊重。
OUTPUT_DIR 默认为 docs/simmer，用户指定其他位置或测试/临时环境则覆盖。
将 brief 返回给编排器，不继续生成或评审——那是编排器的职责。
使用方式
作为 simmer 的子技能被调用，通常由编排器传入意图与约束，本技能完成检查与推断后返回 setup brief。用户交互方式为：提供文件路径、粘贴内容、目录路径或描述；对评估进行确认、调整、覆盖或补充；指定迭代次数、评审模式、输出目录等。
适用场景
- 文本/创意精炼（如 DND 冒险钩子、邮件、博客）
- 代码/提示词优化（如提取提示词、测试工具）
- 流水线/工程优化（如实体提取流水线的模型、提示词、拓扑选择）
限制
- 本技能只产出 setup brief，不执行生成或评审。
- 标准最多 3 条。
- 文本/创意路径保持轻量，不做工作区检查、契约或验证。
- 不询问可推断的内容。
- 不编造评估器、契约或搜索空间，仅依据检查结果推断。
- 具体可用模型、预算、硬件等若资料未提供，需向用户询问。