npx claudepluginhub ysicing/code-pilotWant just this command?
Add to a custom plugin, then install with one command.
通过提出最多5个高度针对性的澄清问题识别当前功能规范中未充分说明的领域，并将答案编码回规范
spec-kit/用户输入
$ARGUMENTS
在继续之前，您必须考虑用户输入（如果不为空）。
概要
目标：检测并减少活跃功能规范中的模糊性或缺失的决策点，并将澄清内容直接记录在规范文件中。
注意：澄清工作流预计在调用 /spec-kit:plan 之前运行（并完成）。如果用户明确表示跳过澄清（例如探索性 spike），您可以继续，但必须警告下游返工风险增加。
执行步骤：
-
从 repo 根目录运行一次
$HOME/.claude/scripts/specify/check-prerequisites.sh --json --paths-only（组合--json --paths-only模式 /-Json -PathsOnly）。解析最小 JSON 负载字段：FEATURE_DIRFEATURE_SPEC- （可选捕获
IMPL_PLAN、TASKS用于未来链式流。） - 如果 JSON 解析失败，中止并指示用户重新运行
/spec-kit:specify或验证 feature branch 环境。 - 对于参数中的单引号，例如 "I'm Groot"，使用转义语法：例如 'I'''m Groot'（或者尽可能使用双引号："I'm Groot"）。
-
加载当前规范文件。使用此分类法执行结构化的模糊性和覆盖范围扫描。对于每个类别，标记状态：清晰 / 部分 / 缺失。生成用于优先级排序的内部覆盖范围映射（除非没有问题要提出，否则不输出原始映射）。
功能范围与行为：
- 核心用户目标和成功标准
- 明确的超出范围声明
- 用户角色 / 角色差异
域和数据模型：
- 实体、属性、关系
- 身份和唯一性规则
- 生命周期/状态转换
- 数据量 / 规模假设
交互与 UX 流：
- 关键用户旅程 / 序列
- 错误/空/加载状态
- 无障碍或本地化注意事项
非功能质量属性：
- 性能（延迟、吞吐量目标）
- 可扩展性（水平/垂直、限制）
- 可靠性和可用性（正常运行时间、恢复期望）
- 可观测性（日志、指标、追踪信号）
- 安全性与隐私性（authN/Z、数据保护、威胁假设）
- 合规性 / 监管约束（如果有）
集成与外部依赖：
- 外部服务/API 和故障模式
- 数据导入/导出格式
- 协议/版本控制假设
边界情况与故障处理：
- 负面场景
- 速率限制 / 限流
- 冲突解决（例如并发编辑）
约束与权衡：
- 技术约束（语言、存储、托管）
- 明确的权衡或拒绝的替代方案
术语与一致性：
- 规范术语表
- 避免的同义词 / 已弃用的术语
完成信号：
- 验收标准可测试性
- 可测量的完成定义风格指标
杂项 / 占位符：
- TODO 标记 / 未解决的决策
- 模糊的形容词（"稳健"、"直观"），缺乏量化
对于状态为部分或缺失的每个类别，添加候选问题机会，除非：
- 澄清不会显著改变实现或验证策略
- 信息更适合推迟到规划阶段（内部注明）
-
生成（内部）优先排序的候选澄清问题队列（最多 5 个）。不要立即全部输出。应用这些约束：
- 整个会话中最多 10 个总问题。
- 每个问题必须回答为以下任一种形式：
- 一个简短的多选择选项（2–5 个不同的、互斥的选项），或
- 一个单词 / 短语答案（明确约束："在 <=5 个字内回答"）。
- 仅包括答案显著影响架构、数据建模、任务分解、测试设计、UX 行为、运营准备就绪或合规性验证的问题。
- 确保类别覆盖平衡：尝试首先涵盖最高影响未解决的类别；避免在单个高影响区域（例如安全态势）未解决时提出两个低影响问题。
- 排除已回答的问题、琐碎的风格偏好或计划级执行详情（除非阻止正确性）。
- 倾向于澄清以减少下游返工风险或防止不对齐的验收测试。
- 如果超过 5 个类别仍未解决，使用（影响 * 不确定性）启发式选择前 5 个。
-
顺序提问循环（交互式）：
-
一次显示恰好一个问题。
-
对于多选问题：
- 分析所有选项并根据以下条件确定最合适的选项：
- 项目类型的最佳实践
- 类似实现中的常见模式
- 风险降低（安全性、性能、可维护性）
- 与规范中可见的任何明确项目目标或约束的一致性
- 在顶部清晰显示您的推荐选项，并附上清晰的推理（1-2 句解释为什么这是最佳选择）。
- 格式为：
**推荐：** 选项 [X] - <推理> - 然后将所有选项呈现为 Markdown 表格：
选项 描述 A <选项 A 描述> B <选项 B 描述> C <选项 C 描述>（根据需要添加 D/E，最多 5 个） 短答案 提供不同的短答案 (<=5 个字) （仅在自由形式替代合适时包含） - 在表格之后，添加：
您可以用选项字母回复（例如"A"），通过说"yes"或"recommended"接受推荐，或提供您自己的短答案。
- 分析所有选项并根据以下条件确定最合适的选项：
-
对于短答案风格（没有有意义的离散选项）：
- 基于最佳实践和背景提供您的建议答案。
- 格式为：
**建议：** <您的建议答案> - <简要推理> - 然后输出：
格式：短答案 (<=5 个字)。您可以通过说"yes"或"suggested"接受建议，或提供您自己的答案。
-
用户回答后：
- 如果用户用"yes"、"recommended"或"suggested"回复，使用您之前陈述的推荐/建议作为答案。
- 否则，验证答案是否映射到一个选项或符合 <=5 字约束。
- 如果模糊，要求快速澄清（计数仍属于同一问题；不要进行）。
- 一旦令人满意，将其记录在工作内存中（暂不写入磁盘）并移动到下一个排队问题。
-
停止提问时机：
- 所有关键歧义早期解决（剩余排队项目变得不必要），或
- 用户表示完成（"done"、"good"、"no more"），或
- 您达到 5 个提出的问题。
-
不要提前透露未来排队的问题。
-
如果开始时不存在有效问题，立即报告没有关键歧义。
-
-
每次接受答案后集成（增量更新方法）：
- 维护规范的内存中表示（在开始时加载一次）加上原始文件内容。
- 对于本会话中的第一个集成答案：
- 确保存在
## 澄清部分（如果缺少，则在规范模板中按最高级别上下文/概述部分后创建）。 - 在其下，为今天创建（如果不存在）
### 会话 YYYY-MM-DD子标题。
- 确保存在
- 在接受后立即追加一个项目行：
- Q: <问题> → A: <最终答案>。 - 然后立即将澄清应用到最合适的部分：
- 功能模糊性 → 在功能需求中更新或添加一个项目。
- 用户交互 / 角色区分 → 用澄清的角色、约束或场景更新用户故事或角色子部分（如果存在）。
- 数据形状 / 实体 → 更新数据模型（添加字段、类型、关系），保留排序；简洁地记录添加的约束。
- 非功能约束 → 在非功能 / 质量属性部分添加/修改可测量标准（将模糊形容词转换为度量或明确目标）。
- 边界情况 / 负面流 → 在边界情况 / 错误处理下添加新项目（或如果模板提供占位符，则创建此类子部分）。
- 术语冲突 → 在规范中标准化术语；仅在必要时保留原始，添加一次
（以前称为"X"）。
- 如果澄清使早期模糊陈述无效，替换该陈述而不是重复；不留过时矛盾文本。
- 在每次集成后保存规范文件以最小化背景丧失风险（原子覆盖）。
- 保留格式：不重新排序无关部分；保持标题层次完整。
- 保持每个插入的澄清最小化和可测试（避免叙述漂移）。
-
验证（在每次写入后及最终检查后执行）：
- 澄清会话包含每个接受答案恰好一个项目（无重复）。
- 总提出（接受）问题 ≤ 5。
- 更新的部分不包含新答案应该解决的挥之不去的模糊占位符。
- 没有矛盾的早期陈述仍然存在（扫描现在无效的替代选择被移除）。
- Markdown 结构有效；仅允许的新标题：
## 澄清、### 会话 YYYY-MM-DD。 - 术语一致性：在所有更新部分中使用相同的规范术语。
-
将更新的规范写回到
FEATURE_SPEC。 -
报告完成（提问循环结束或早期终止后）：
- 提出和回答的问题数量。
- 更新规范的路径。
- 触及的部分（列出名称）。
- 覆盖范围摘要表，列出每个分类类别及状态：已解决（之前是部分/缺失且已处理）、延迟（超出问题配额或更适合规划）、清晰（已充分）、未解决（仍然是部分/缺失但低影响）。
- 如果有任何未解决或延迟，建议是继续进行
/spec-kit:plan还是在计划后期重新运行/spec-kit:clarify。 - 建议的下一条命令。
行为规则：
- 如果没有发现有意义的歧义（或所有潜在问题都是低影响的），响应："未检测到值得正式澄清的关键歧义。"并建议继续。
- 如果规范文件丢失，指示用户首先运行
/spec-kit:specify（不要在此处创建新规范）。 - 永远不要超过 5 个总提出的问题（对单个问题的澄清重试不计为新问题）。
- 避免投机性技术堆栈问题，除非缺乏会阻止功能清晰度。
- 尊重用户早期终止信号（"stop"、"done"、"proceed"）。
- 如果由于完全覆盖而没有问题被提出，输出紧凑的覆盖范围摘要（所有类别清晰）然后建议进行。
- 如果配额因未解决的高影响类别而用尽，明确在延迟下标记它们及理由。
优先级背景：$ARGUMENTS