| name | prompt-clarifier |
| description | Proma 模糊需求澄清与高质量执行简报 Skill。只要用户的指令缺少目标、范围、上下文、输入、约束、验收标准或期望输出，或者用户说“帮我优化提示词”“怎么问更清楚”“帮我整理需求”“我不知道该怎么描述”时使用。也适用于调研、代码修改、写作、比较、诊断和工具调用前的需求收敛。先读取当前对话、项目上下文和已有 Skills，能合理推断的不要反问；只在信息缺口会改变方案、范围或风险时提出少量高价值问题，然后把任务交给正确的下游流程。 |
| version | 1.0.0 |
Prompt Clarifier
把自然语言中的模糊请求整理成可执行任务，同时尽量减少用户需要补充的信息。这个 Skill 的目标不是让用户学习提示词术语，而是让 Agent 在真正动手前完成必要的理解、调查和边界确认。
什么时候使用
在以下情况使用：
- 用户只说“帮我看看”“处理一下”“优化这个”“查一下”，但目标对象、期望结果或范围不明确。
- 用户明确要求写提示词、优化提示词、整理需求、把想法说清楚或提高问答质量。
- 任务涉及多个合理方向，选择不同方向会导致不同的实现、调研范围、成本或风险。
- 用户提出调研、比较、诊断或方案判断，但没有说明决策用途、时间范围、目标人群或证据要求。
- 用户连续补充信息，说明前面的任务理解不稳定，或者已经出现“你没理解”“不是这个意思”“我刚才说过”等摩擦。
普通的一次性明确任务不要强行介入；如果目标、输入、约束和验收标准已经足够，直接执行即可。
核心原则
- 先读再问：先读取当前对话、相关文件、项目规则、已有 Skill 和已知状态。不要询问用户已经明确提供或可以从上下文可靠得到的信息。
- 事实与推断分开：区分用户明确说的事实、从上下文得到的证据、Agent 的合理假设和仍未知的内容。不要把用户的猜测直接当成根因，也不要把自己的推断伪装成用户意图。
- 只追问会改变结果的问题：缺少的信息如果不影响方向、范围、风险或验收，就写入假设后继续。真正阻塞时最多提出 1-3 个问题，优先使用带选项的问题。
- 先给出理解再提问：用一句话复述当前理解，列出关键假设和唯一需要确认的分歧，让用户可以快速纠正，而不是要求用户从零填写表单。
- 目标优先于步骤：先确认用户想得到什么结果，再决定搜索、写作、代码修改、工具调用或其他执行路径。不要因为用户指定了一个可能不合适的步骤，就忽略真正目标。
- 保留用户语气，提升任务结构：不要求用户使用专业术语，不批评模糊表达；把“帮我搞好一点”转换成可验证的质量维度和验收标准。
工作流程
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. 输出与验收
执行完成后，用任务目标检查结果，而不是只复述做过哪些步骤。至少确认：
- 是否解决了用户真正要解决的问题，而不是只完成了表面动作。
- 关键事实是否有足够证据，推断和不确定性是否明确标注。
- 交付格式、范围、约束和验收标准是否满足。
- 是否留下了用户下一步需要知道的限制、风险或操作。
- 如果任务失败，是否说明失败原因、已排除的方向和最有效的下一步，而不是只说“没找到”。
用户要求提示词时，额外输出一个可直接复制的版本，包含目标、背景、输入、约束、过程要求、输出格式和验收标准；不要为了显得专业而堆叠无关的角色设定或冗长禁令。
反模式
- 不要把澄清变成十几个问题的问卷。
- 不要在已经能安全执行时等待用户确认每个细节。
- 不要只把用户原话改写得更长，却没有增加目标、约束、证据或验收标准。
- 不要替用户决定未授权的高风险动作，也不要用“合理推断”绕过确认。
- 不要把用户的情绪、措辞或知识水平当成问题质量的评分；只改善任务结构。
- 不要把所有任务都升级成复杂调研；任务类型、风险和用户期望决定澄清深度。
