clarify

A command that asks up to five targeted questions about an incomplete feature specification and records the answers in the specification.

In plain words
What is it for?
Clarifying feature requirements, checking areas such as user flows and error handling, and updating the relevant specification.
Why use it?
It exposes missing decisions and ambiguities before planning or building a feature.

Command

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add commands/linfee/spec-kit-cn/clarify
Clone the repo
git clone --depth 1 https://github.com/Linfee/spec-kit-cn
Per session 36 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,950 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00036 $0.02950
Opus 5 $0.00018 $0.01475
Sonnet 5 $0.00007 $0.00590
Haiku 4.5 $0.00004 $0.00295

Measured 2d ago against content hash 06d5f434db67, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

clarify scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

templates/commands/clarify.md · 183 lines

How it starts

The opening of the file, as written. The whole thing — 183 lines — stays where its author put it; the contents beside it link to each section on GitHub.

用户输入

$ARGUMENTS

在继续之前, 你必须考虑用户输入(如果不为空).

概述

目标: 检测并减少活跃功能规范中的模糊性或缺失的决策点, 并将澄清内容直接记录在规范文件中.

注意: 此澄清工作流应在调用 /speckit.plan 之前运行(并完成). 如果用户明确表示他们跳过澄清(例如, 探索性原型), 你可以继续, 但必须警告下游返工风险增加.

执行步骤:

  1. 从仓库根目录运行 {SCRIPT} 一次(组合 --json --paths-only 模式 / -Json -PathsOnly). 解析最小 JSON 负载字段:

    • FEATURE_DIR
    • FEATURE_SPEC
    • (可选捕获 IMPL_PLAN, TASKS 用于未来的链式流程.)
    • 如果 JSON 解析失败, 中止并指示用户重新运行 /speckit.specify 或验证功能分支环境.
    • 对于参数中包含单引号的情况(如 "I'm Groot"), 使用转义语法: 例如 'I'''m Groot'(或优先使用双引号: "I'm Groot").
  2. 加载当前规范文件. 使用此分类法执行结构化模糊性和覆盖范围扫描. 对于每个类别, 标记状态: 清晰 / 部分 / 缺失. 生成用于优先级排序的内部覆盖范围图(除非不会提问, 否则不输出原始图).

    功能范围与行为:

    • 核心用户目标和成功标准
    • 明确的超出范围声明
    • 用户角色 / 角色区分

    领域与数据模型:

    • 实体, 属性, 关系
    • 身份和唯一性规则
    • 生命周期 / 状态转换
    • 数据量 / 规模假设

    交互与 UX 流程:

    • 关键用户旅程 / 序列
    • 错误 / 空白 / 加载状态
    • 可访问性或本地化说明

    非功能性质量属性:

    • 性能(延迟, 吞吐量目标)
    • 可扩展性(水平 / 垂直, 限制)
    • 可靠性和可用性(正常运行时间, 恢复期望)
    • 可观察性(日志, 指标, 追踪信号)
    • 安全性和隐私(身份验证 / 授权, 数据保护, 威胁假设)
    • 合规性 / 监管约束(如有)

    集成与外部依赖:

    • 外部服务 / API 和故障模式
    • 数据导入 / 导出格式
    • 协议 / 版本控制假设

    边缘情况与故障处理:

    • 负面场景
    • 速率限制 / 节流
    • 冲突解决(例如, 并发编辑)

    约束与权衡:

    • 技术约束(语言, 存储, 托管)
    • 明确的权衡或被拒绝的替代方案

    术语与一致性:

    • 规范术语表术语
    • 避免的同义词 / 已弃用术语

    完成信号:

    • 验收标准可测试性
    • 可衡量的完成定义风格指标

    其他 / 占位符:

    • TODO 标记 / 未解决的决策
    • 缺少量化的模糊形容词("robust", "intuitive")

    对于每个处于部分或缺失状态的类别, 添加候选问题机会, 除非:

    • 澄清不会实质性地改变实施或验证策略
    • 信息更适合推迟到规划阶段(内部记录)
  3. (内部)生成候选澄清问题的优先级队列(最多5个). 不要一次性输出所有问题. 应用这些约束:

    • 整个会话最多5个问题.
    • 每个问题必须可以用以下任一方式回答:
      • 简短的多项选择(2-5个不同的, 互斥的选项), 或
      • 单词 / 短语答案(明确约束: "用 <=5 个词回答").
    • 仅包含答案实质上影响架构, 数据建模, 任务分解, 测试设计, UX 行为, 运营准备或合规性验证的问题.
    • 确保类别覆盖平衡: 尝试首先覆盖最高影响的未解决类别; 避免在单个高影响领域(例如, 安全态势)未解决时询问两个低影响问题.
    • 排除已回答的问题, 琐碎的风格偏好或规划级别的执行细节(除非阻碍正确性).
    • 偏好减少下游返工风险或防止不一致验收测试的澄清.
    • 如果超过5个类别仍未解决, 通过(影响 * 不确定性)启发式选择前5个.
  4. 顺序提问流程(交互式):

    • 一次只提出确切一个问题.
    • 对于多项选择题:
      • 分析所有选项并基于以下确定最合适的选项:
        • 项目类型的最佳实践
        • 类似实现中的常见模式
        • 风险降低(安全性, 性能, 可维护性)
        • 与规范中可见的任何明确项目目标或约束的一致性
      • 在顶部突出显示你的推荐选项并附上清晰推理(1-2句话解释为什么这是最佳选择).
      • 格式为: **推荐:** 选项 [X] - <理由>
      • 然后将所有选项渲染为 Markdown 表格:

Read the full file on GitHub · 183 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 183 lines · 36 tokens per session scan A 06d5f434db67

Subscribe to this mod's changes

clarify is a command published in the GitHub repository Linfee/spec-kit-cn (695 stars, last pushed 1mo ago), licensed MIT. It adds 36 tokens to every session and 2,950 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.