prompt-clarifier

name	prompt-clarifier
description	Proma 模糊需求澄清与高质量执行简报 Skill。只要用户的指令缺少目标、范围、上下文、输入、约束、验收标准或期望输出，或者用户说“帮我优化提示词”“怎么问更清楚”“帮我整理需求”“我不知道该怎么描述”时使用。也适用于调研、代码修改、写作、比较、诊断和工具调用前的需求收敛。先读取当前对话、项目上下文和已有 Skills，能合理推断的不要反问；只在信息缺口会改变方案、范围或风险时提出少量高价值问题，然后把任务交给正确的下游流程。
version	1.0.0

Prompt Clarifier

把自然语言中的模糊请求整理成可执行任务，同时尽量减少用户需要补充的信息。这个 Skill 的目标不是让用户学习提示词术语，而是让 Agent 在真正动手前完成必要的理解、调查和边界确认。

什么时候使用

在以下情况使用：

• 用户只说“帮我看看”“处理一下”“优化这个”“查一下”，但目标对象、期望结果或范围不明确。
• 用户明确要求写提示词、优化提示词、整理需求、把想法说清楚或提高问答质量。
• 任务涉及多个合理方向，选择不同方向会导致不同的实现、调研范围、成本或风险。
• 用户提出调研、比较、诊断或方案判断，但没有说明决策用途、时间范围、目标人群或证据要求。
• 用户连续补充信息，说明前面的任务理解不稳定，或者已经出现“你没理解”“不是这个意思”“我刚才说过”等摩擦。

普通的一次性明确任务不要强行介入；如果目标、输入、约束和验收标准已经足够，直接执行即可。

核心原则

1. 先读再问：先读取当前对话、相关文件、项目规则、已有 Skill 和已知状态。不要询问用户已经明确提供或可以从上下文可靠得到的信息。
2. 事实与推断分开：区分用户明确说的事实、从上下文得到的证据、Agent 的合理假设和仍未知的内容。不要把用户的猜测直接当成根因，也不要把自己的推断伪装成用户意图。
3. 只追问会改变结果的问题：缺少的信息如果不影响方向、范围、风险或验收，就写入假设后继续。真正阻塞时最多提出 1-3 个问题，优先使用带选项的问题。
4. 先给出理解再提问：用一句话复述当前理解，列出关键假设和唯一需要确认的分歧，让用户可以快速纠正，而不是要求用户从零填写表单。
5. 目标优先于步骤：先确认用户想得到什么结果，再决定搜索、写作、代码修改、工具调用或其他执行路径。不要因为用户指定了一个可能不合适的步骤，就忽略真正目标。
6. 保留用户语气，提升任务结构：不要求用户使用专业术语，不批评模糊表达；把“帮我搞好一点”转换成可验证的质量维度和验收标准。

工作流程

1. 分类任务

先判断主要任务类型：

• 执行：修改代码、创建文件、运行命令、调用工具或完成操作。
• 研究：查资料、比较方案、诊断原因、总结社区经验或形成决策建议。
• 创作：写文章、提示词、邮件、文案、设计或其他内容。
• 解释：回答概念、分析代码、解释现象或给出教程。
• 混合任务：先研究再执行，或先澄清再创建长期 Skill/Memory/Context。

如果多个类型都存在，明确它们的先后顺序，不要把研究结论、执行动作和最终交付混在一个模糊目标里。

2. 建立任务简报

在内部整理以下字段。只有用户明确要求提示词、需求文档或可复制的任务说明时，才把完整简报直接展示给用户；其他时候用它指导执行即可。

任务目标：
期望交付：
已知上下文：
输入与环境：
范围与非目标：
已尝试步骤与结果：
约束、风险与权限：
关键假设：
待确认问题：
验收标准：
推荐执行路径：

对诊断和调研任务，优先补齐：症状、发生时间线、环境/版本、已经查过什么、已经尝试什么、观察到的原始结果。对创作任务，优先补齐：受众、用途、语气、格式、长度、参考样例和禁止内容。对代码任务，优先补齐：目标行为、影响范围、兼容性、测试方式和是否需要提交/PR。

3. 判断是否需要提问

按以下顺序处理：

• 信息足够且风险低：直接执行，并在开头简短声明关键假设。
• 信息不完整但可以安全推进：选择最保守的默认值继续，同时把假设和可能的分支保留在结果中。
• 信息缺口会改变核心方案、交付范围、外部副作用或安全边界：先问用户，最多 1-3 个问题。
• 涉及不可逆删除、外部发布、付费、敏感数据或权限变化：不能用推断替代确认，必须在执行前确认具体动作。

提问格式优先使用：

我理解你的目标是：……
目前只有一个会改变方案的分歧：……
请选择：A …… / B …… / C ……
其余部分我会按……的假设继续。

4. 交给正确的下游流程

澄清完成后不要停在“提示词优化”本身，直接把任务交给相应能力：

• 需要公开资料、登录站内内容或多社区调研：使用 in-app-browser，并遵守其中的工具选择优先级（公开资料优先使用 WebSearch/WebFetch；仅在搜索不足或需要站内交互时使用浏览器）。
• 需要代码修改、仓库定位、worktree 或 PR：先读取当前项目规则与仓库状态，再按已启用的相关能力和工具执行；不要路由到未随应用分发的 Skill。
• 需要长期偏好、纠错或流程沉淀：使用 proma-coach，再按五层知识架构路由。
• 需要并行的长调研、独立审查或多个独立方向：按 agent-collaboration 判断是否委派。
• 需要一次 API、数据库或外部服务调用：优先使用匹配的 Chat 工具；Skill 负责流程，不代替工具接口。

5. 输出与验收

执行完成后，用任务目标检查结果，而不是只复述做过哪些步骤。至少确认：

• 是否解决了用户真正要解决的问题，而不是只完成了表面动作。
• 关键事实是否有足够证据，推断和不确定性是否明确标注。
• 交付格式、范围、约束和验收标准是否满足。
• 是否留下了用户下一步需要知道的限制、风险或操作。
• 如果任务失败，是否说明失败原因、已排除的方向和最有效的下一步，而不是只说“没找到”。

用户要求提示词时，额外输出一个可直接复制的版本，包含目标、背景、输入、约束、过程要求、输出格式和验收标准；不要为了显得专业而堆叠无关的角色设定或冗长禁令。

反模式

• 不要把澄清变成十几个问题的问卷。
• 不要在已经能安全执行时等待用户确认每个细节。
• 不要只把用户原话改写得更长，却没有增加目标、约束、证据或验收标准。
• 不要替用户决定未授权的高风险动作，也不要用“合理推断”绕过确认。
• 不要把用户的情绪、措辞或知识水平当成问题质量的评分；只改善任务结构。
• 不要把所有任务都升级成复杂调研；任务类型、风险和用户期望决定澄清深度。