prompt-clarifier

# Prompt Clarifier 把自然语言中的模糊请求整理成可执行任务，同时尽量减少用户需要补充的信息。这个 Skill 的目标不是让用户学习提示词术语，而是让 Agent 在真正动手前完成必要的理解、调查和边界确认。 ## 什么时候使用 在以下情况使用： - 用户只说“帮我看看”“处理一下”“优化这个”“查一下”，但目标对象、期望结果或范围不明确。 - 用户明确要求写提示词、优化提示词、整理需求、把想法说清楚或提高问答质量。 - 任务涉及多个合理方向，选择不同方向会导致不同的实现、调研范围、成本或风险。 - 用户提出调研、比较、诊断或方案判断，但没有说明决策用途、时间范围、目标人群或证据要求。 - 用户连续补充信息，说明前面的任务理解不稳定，或者已经出现“你没理解”“不是这个意思”“我刚才说过”等摩擦。 普通的一次性明确任务不要强行介入；如果目标、输入、约束和验收标准已经足够，直接执行即可。 ## 核心原则 1. **先读再问**：先读取当前对话、相关文件、项目规则、已有 Skill 和已知状态。不要询问用户已经明确提供或可以从上下文可靠得到的信息。 2. **事实与推断分开**：区分用户明确说的事实、从上下文得到的证据、Agent 的合理假设和仍未知的内容。不要把用户的猜测直接当成根因，也不要把自己的推断伪装成用户意图。 3. **只追问会改变结果的问题**：缺少的信息如果不影响方向、范围、风险或验收，就写入假设后继续。真正阻塞时最多提出 1-3 个问题，优先使用带选项的问题。 4. **先给出理解再提问**：用一句话复述当前理解，列出关键假设和唯一需要确认的分歧，让用户可以快速纠正，而不是要求用户从零填写表单。 5. **目标优先于步骤**：先确认用户想得到什么结果，再决定搜索、写作、代码修改、工具调用或其他执行路径。不要因为用户指定了一个可能不合适的步骤，就忽略真正目标。 6. **保留用户语气，提升任务结构**：不要求用户使用专业术语，不批评模糊表达；把“帮我搞好一点”转换成可验证的质量维度和验收标准。 ## 工作流程 ### 1. 分类任务 先判断主要任务类型： - **执行**：修改代码、创建文件、运行命令、调用工具或完成操作。 - **研究**：查资料、比较方案、诊断原因、总结社区经验或形成决策建议。 - **创作**：写文章、提示词、邮件、文案、设计或其他内容。 - **解释**：回答概念、分析代码、解释现象或给出教程。 - **混合任务**：先研究再执行，或先澄清再创建长期 Skill/Memory/Context。 如果多个类型都存在，明确它们的先后顺序，不要把研究结论、执行动作和最终交付混在一个模糊目标里。 ### 2. 建立任务简报 在内部整理以下字段。只有用户明确要求提示词、需求文档或可复制的任务说明时，才把完整简报直接展示给用户；其他时候用它指导执行即可。 ```text 任务目标： 期望交付： 已知上下文： 输入与环境： 范围与非目标： 已尝试步骤与结果： 约束、风险与权限： 关键假设： 待确认问题： 验收标准： 推荐执行路径： ``` 对诊断和调研任务，优先补齐：症状、发生时间线、环境/版本、已经查过什么、已经尝试什么、观察到的原始结果。对创作任务，优先补齐：受众、用途、语气、格式、长度、参考样例和禁止内容。对代码任务，优先补齐：目标行为、影响范围、兼容性、测试方式和是否需要提交/PR。 ### 3. 判断是否需要提问 按以下顺序处理： - 信息足够且风险低：直接执行，并在开头简短声明关键假设。 - 信息不完整但可以安全推进：选择最保守的默认值继续，同时把假设和可能的分支保留在结果中。 - 信息缺口会改变核心方案、交付范围、外部副作用或安全边界：先问用户，最多 1-3 个问题。 - 涉及不可逆删除、外部发布、付费、敏感数据或权限变化：不能用推断替代确认，必须在执行前确认具体动作。 提问格式优先使用： ```text 我理解你的目标是：…… 目前只有一个会改变方案的分歧：…… 请选择：A …… / B …… / C …… 其余部分我会按……的假设继续。 ``` ### 4. 交给正确的下游流程 澄清完成后不要停在“提示词优化”本身，直接把任务交给相应能力： - 需要公开资料、登录站内内容或多社区调研：使用 `in-app-browser`，并遵守其中的工具选择优先级（公开资料优先使用 WebSearch/WebFetch；仅在搜索不足或需要站内交互时使用浏览器）。 - 需要代码修改、仓库定位、worktree 或 PR：先读取当前项目规则与仓库状态，再按已启用的相关能力和工具执行；不要路由到未随应用分发的 Skill。 - 需要长期偏好、纠错或流程沉淀：使用 `proma-coach`，再按五层知识架构路由。 - 需要并行的长调研、独立审查或多个独立方向：按 `agent-collaboration` 判断是否委派。 - 需要一次 API、数据库或外部服务调用：优先使用匹配的 Chat 工具；Skill 负责流程，不代替工具接口。 ### 5. 输出与验收 执行完成后，用任务目标检查结果，而不是只复述做过哪些步骤。至少确认： - 是否解决了用户真正要解决的问题，而不是只完成了表面动作。 - 关键事实是否有足够证据，推断和不确定性是否明确标注。 - 交付格式、范围、约束和验收标准是否满足。 - 是否留下了用户下一步需要知道的限制、风险或操作。 - 如果任务失败，是否说明失败原因、已排除的方向和最有效的下一步，而不是只说“没找到”。 用户要求提示词时，额外输出一个可直接复制的版本，包含目标、背景、输入、约束、过程要求、输出格式和验收标准；不要为了显得专业而堆叠无关的角色设定或冗长禁令。 ## 反模式 - 不要把澄清变成十几个问题的问卷。 - 不要在已经能安全执行时等待用户确认每个细节。 - 不要只把用户原话改写得更长，却没有增加目标、约束、证据或验收标准。 - 不要替用户决定未授权的高风险动作，也不要用“合理推断”绕过确认。 - 不要把用户的情绪、措辞或知识水平当成问题质量的评分；只改善任务结构。 - 不要把所有任务都升级成复杂调研；任务类型、风险和用户期望决定澄清深度。