mcpField
V
vague

vague

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

关于 vague

vague 是用于澄清含糊需求的技能，通过假设选项逐步提问，将需求整理为可执行规格。它要求使用 AskUserQuestion，并在澄清后展示前后对照。

主要功能

  1. 01识别需求中的歧义
  2. 02以假设选项组织问题
  3. 03每次最多批量提出 4 个问题
  4. 04总结澄清前后的需求
  5. 05询问是否保存结果

适用场景

  1. 01细化含糊的功能请求
  2. 02补全不完整的错误报告
  3. 03明确未充分定义的任务

安装

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

$npx skills add https://github.com/team-attention/plugins-for-claude-natives --skill vague

安装后在 Claude Code 中输入/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