mcpField
C
clarify:vague

clarify:vague

github.com/team-attentionAgent 工作流773 次安装34 周前更新
代码仓库

关于 clarify:vague

clarify:vague 是一项通过假设驱动提问，将模糊需求转化为可执行规格的技能。它引导 Agent 将可能的解释列为选项供选择，随后总结明确后的目标与范围。

主要功能

  1. 01诊断含糊需求
  2. 02以假设形式提供选项
  3. 03批量提出相关澄清问题
  4. 04限制澄清轮次
  5. 05总结澄清前后内容

适用场景

  1. 01明确描述不足的功能需求
  2. 02补全缺少细节的错误报告
  3. 03界定宽泛性能任务的范围

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/team-attention/workshop-upstage --skill clarify:vague

安装后在 Claude Code 中输入/clarify:vague确认已加载。

详细介绍

Vague：需求澄清

通过基于假设的问题，将模糊或含义不明的需求转化为精确、可执行的规格。始终使用 AskUserQuestion 工具——绝不要用纯文本提问以澄清问题。

适用场景

  • 含义模糊的功能请求（“添加登录功能”）
  • 不完整的错误报告（“导出功能坏了”）
  • 规格不明确的任务（“让应用更快”）

对于策略/规划中的盲点分析，请使用 unknown 技能。对于内容与形式的重构，请使用 metamedium 技能。

核心原则：将假设作为选项

将合理的解释作为选项呈现，而不是提出开放式问题。每个选项都是一个可验证的假设，用于判断用户的实际意图。

BAD:  "What kind of login do you want?"           ← open question, high cognitive load
GOOD: "OAuth / Email+Password / SSO / Magic link" ← pick one, lower load

流程

阶段 1：记录并诊断

逐字记录原始需求。找出其中的歧义：

  • 哪些内容不清楚或规格不足？
  • 需要做出哪些假设？
  • 哪些决定留待解释？
阶段 2：迭代澄清

使用 AskUserQuestion 解决歧义。**每次调用最多批量提出 4 个相关问题。**每个选项都是关于用户意图的假设。

**上限：总计 5–8 个问题。**当所有关键歧义都已解决，或用户表示“差不多就行”，或达到上限时，停止提问。

AskUserQuestion 调用示例：

questions:
  - question: "Which authentication method should the login use?"
    header: "Auth method"
    options:
      - label: "Email + Password"
        description: "Traditional signup with email verification"
      - label: "OAuth (Google/GitHub)"
        description: "Delegated auth, no password management needed"
      - label: "Magic link"
        description: "Passwordless email-based login"
    multiSelect: false
  - question: "What should happen after registration?"
    header: "Post-signup"
    options:
      - label: "Immediate access"
        description: "User can use the app right away"
      - label: "Email verification first"
        description: "Must confirm email before access"
    multiSelect: false
阶段 3：前后对比摘要

展示需求的转换过程：

## Requirement Clarification Summary

### Before (Original)
"{original request verbatim}"

### After (Clarified)
**Goal**: [precise description]
**Scope**: [included and excluded]
**Constraints**: [limitations, preferences]
**Success Criteria**: [how to know when done]

**Decisions Made**:
| Question | Decision |
|----------|----------|
| [ambiguity 1] | [chosen option] |
阶段 4：保存选项

询问是否要将澄清后的需求保存到文件。默认位置：requirements/ 或适合该项目的目录。

歧义类别

类别假设示例
范围所有用户 / 仅管理员 / 特定角色
行为静默失败 / 显示错误 / 自动重试
接口REST API / GraphQL / CLI
数据JSON / CSV / 两者
约束<100ms / <1s / 无要求
优先级必须实现 / 有则更好 / 未来实现

规则

  1. 提出假设，而非开放式问题：每个选项都应是合理的解释
  2. 不做假设：先提问，不要自行假定
  3. 保留意图：细化需求，而非改变方向
  4. 最多 5–8 个问题：再多就会让人疲惫
  5. 批量提出相关问题：每次 AskUserQuestion 调用最多 4 个
  6. 追踪变更：始终展示前后对比

评论

支持 Markdown