speckit-clarify

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

User Input

用户输入

text

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

text

$ARGUMENTS

你必须在继续之前考虑用户输入（如果不为空）。

Pre-Execution Checks

执行前检查

Check for extension hooks (before clarification):

Check if
```
.specify/extensions.yml
```
exists in the project root.
If it exists, read it and look for entries under the
```
hooks.before_clarify
```
key
If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
Filter out hooks where
```
enabled
```
is explicitly
```
false
```
. Treat hooks without an
```
enabled
```
field as enabled by default.
For each remaining hook, do not attempt to interpret or evaluate hook
```
condition
```
expressions:
- If the hook has no
```
condition
```
  field, or it is null/empty, treat the hook as executable
- If the hook defines a non-empty
```
condition
```
  , skip the hook and leave condition evaluation to the HookExecutor implementation
When constructing command invocations from hook command names, replace dots (
```
.
```
) with hyphens (
```
-
```
). For example,
```
speckit.git.commit
```
→
```
/speckit-git-commit
```
.
For each executable hook, output the following based on its
```
optional
```
flag:
- Optional hook (
```
optional: true
```
  ):
  text
```
## Extension Hooks

**Optional Pre-Hook**: {extension}
Command: `/{command}`
Description: {description}

Prompt: {prompt}
To execute: `/{command}`
```
- Mandatory hook (
```
optional: false
```
  ):
  text
```
## Extension Hooks

**Automatic Pre-Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}

Wait for the result of the hook command before proceeding to the Outline.
```
  After emitting the block above you MUST actually invoke the hook and wait for it to finish before continuing. Run it the same way you would run the command yourself in this agent/session (the invocation may differ from the literal
```
{command}
```
  id shown above, e.g. a skills-mode agent runs it as
```
/skill:speckit-...
```
  or
```
$speckit-...
```
  ). Emitting the block alone does not run the hook.
If no hooks are registered or
```
.specify/extensions.yml
```
does not exist, skip silently

检查扩展钩子（澄清前）:

检查项目根目录下是否存在
```
.specify/extensions.yml
```
文件。
如果存在，读取该文件并查找
```
hooks.before_clarify
```
键下的条目
如果YAML无法解析或无效，静默跳过钩子检查并正常继续
过滤掉
```
enabled
```
显式设为
```
false
```
的钩子。未设置
```
enabled
```
字段的钩子默认视为启用。
对于剩余的每个钩子，不要尝试解释或评估钩子的
```
condition
```
表达式：
- 如果钩子没有
```
condition
```
  字段，或该字段为null/空，视为可执行钩子
- 如果钩子定义了非空的
```
condition
```
  ，跳过该钩子，将条件评估留给HookExecutor实现处理
从钩子命令名称构造命令调用时，将点（
```
.
```
）替换为连字符（
```
-
```
）。例如，
```
speckit.git.commit
```
→
```
/speckit-git-commit
```
。

对于每个可执行钩子，根据其

optional

标志输出以下内容：

可选钩子（

optional: true

）：

text

## Extension Hooks

**Optional Pre-Hook**: {extension}
Command: `/{command}`
Description: {description}

Prompt: {prompt}
To execute: `/{command}`

强制钩子（
```
optional: false
```
）：
text
```
## Extension Hooks

**Automatic Pre-Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}

Wait for the result of the hook command before proceeding to the Outline.
```
输出上述块后，必须实际调用该钩子并等待其完成后再继续。以你在该Agent/会话中运行命令的相同方式执行它（调用方式可能与上面显示的字面
```
{command}
```
ID不同，例如技能模式Agent会以
```
/skill:speckit-...
```
或
```
$speckit-...
```
的方式运行）。仅输出块并不会运行钩子。

如果没有注册钩子或
```
.specify/extensions.yml
```
不存在，静默跳过

Outline

大纲

Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.

Note: This clarification workflow is expected to run (and be completed) BEFORE invoking

/speckit-plan

. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.

Execution steps:

Run
```
.specify/scripts/bash/check-prerequisites.sh --json --paths-only
```
from repo root once (combined
```
--json --paths-only
```
mode /
```
-Json -PathsOnly
```
). Parse minimal JSON payload fields:
- ```
FEATURE_DIR
```
- ```
FEATURE_SPEC
```
- (Optionally capture
```
IMPL_PLAN
```
  ,
```
TASKS
```
  for future chained flows.)
- If JSON parsing fails, abort and instruct user to re-run
```
/speckit-specify
```
  or verify feature branch environment.
- For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'''m Groot' (or double-quote if possible: "I'm Groot").
IF EXISTS: Load
```
.specify/memory/constitution.md
```
for project principles and governance constraints.
Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).

Functional Scope & Behavior:
- Core user goals & success criteria
- Explicit out-of-scope declarations
- User roles / personas differentiation
Domain & Data Model:
- Entities, attributes, relationships
- Identity & uniqueness rules
- Lifecycle/state transitions
- Data volume / scale assumptions
Interaction & UX Flow:
- Critical user journeys / sequences
- Error/empty/loading states
- Accessibility or localization notes
Non-Functional Quality Attributes:
- Performance (latency, throughput targets)
- Scalability (horizontal/vertical, limits)
- Reliability & availability (uptime, recovery expectations)
- Observability (logging, metrics, tracing signals)
- Security & privacy (authN/Z, data protection, threat assumptions)
- Compliance / regulatory constraints (if any)
Integration & External Dependencies:
- External services/APIs and failure modes
- Data import/export formats
- Protocol/versioning assumptions
Edge Cases & Failure Handling:
- Negative scenarios
- Rate limiting / throttling
- Conflict resolution (e.g., concurrent edits)
Constraints & Tradeoffs:
- Technical constraints (language, storage, hosting)
- Explicit tradeoffs or rejected alternatives
Terminology & Consistency:
- Canonical glossary terms
- Avoided synonyms / deprecated terms
Completion Signals:
- Acceptance criteria testability
- Measurable Definition of Done style indicators
Misc / Placeholders:
- TODO markers / unresolved decisions
- Ambiguous adjectives ("robust", "intuitive") lacking quantification
For each category with Partial or Missing status, add a candidate question opportunity unless:
- Clarification would not materially change implementation or validation strategy
- Information is better deferred to planning phase (note internally)
Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints:
- Maximum of 5 total questions across the whole session.
- Each question must be answerable with EITHER:
  - A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR
  - A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words").
- Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation.
- Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved.
- Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness).
- Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests.
- If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic.

Sequential questioning loop (interactive):

Present EXACTLY ONE question at a time.
Question writing quality (applies to every question, MC or short-answer):
- Lead with
```
**Question:**
```
  followed by a full interrogative that ends with
```
?
```
  . The question text before the
```
?
```
  must make sense on its own.
- NEVER use a topic label, section heading, or requirement id as the question itself. For example,
```
Acceptance device/runtime matrix (FR-023)
```
  is INVALID — it is a label, not a question.
- After the
```
?
```
  , the only permitted suffix is an optional parenthesized requirement/question id. Exact format:
```
**Question:** <interrogative>?
```
  or
```
**Question:** <interrogative>? (FR-023)
```
  . Never put the id before the
```
?
```
  , and never use the id (alone or with a topic label) as the whole prompt.
- Immediately after the question line, add one plain-language "Why it matters" sentence (the stake for acceptance or shipping) before the recommendation/options.
- Use everyday wording; introduce jargon only if defined in the same sentence. Self-check: a reader who does not know Spec Kit must be able to answer from the Question line alone. Terse is fine; cryptic labels are not.

For multiple‑choice questions:

Analyze all options and determine the most suitable option based on:
- Best practices for the project type
- Common patterns in similar implementations
- Risk reduction (security, performance, maintainability)
- Alignment with any explicit project goals or constraints visible in the spec
Present your recommended option prominently at the top with clear reasoning (1-2 sentences explaining why this is the best choice).

Format as:

**Recommended:** Option [X] - <reasoning>

Then render all options as a Markdown table:

Option	Description
A	<Option A description>
B	<Option B description>
C	<Option C description> (add D/E as needed up to 5)
Short	Provide a different short answer (<=5 words) (Include only if free-form alternative is appropriate)

After the table, add:

You can reply with the option letter (e.g., "A"), accept the recommendation by saying "yes" or "recommended", or provide your own short answer.

For short‑answer style (no meaningful discrete options):

Provide your suggested answer based on best practices and context.

Format as:

**Suggested:** <your proposed answer> - <brief reasoning>

Then output:

Format: Short answer (<=5 words). You can accept the suggestion by saying "yes" or "suggested", or provide your own answer.

After the user answers:
- If the user replies with "yes", "recommended", or "suggested", use your previously stated recommendation/suggestion as the answer.
- Otherwise, validate the answer maps to one option or fits the <=5 word constraint.
- If ambiguous, ask for a quick disambiguation (count still belongs to same question; do not advance).
- Once satisfactory, record it in working memory (do not yet write to disk) and move to the next queued question.
Stop asking further questions when:
- All critical ambiguities resolved early (remaining queued items become unnecessary), OR
- User signals completion ("done", "good", "no more"), OR
- You reach 5 asked questions.
Never reveal future queued questions in advance.
If no valid questions exist at start, immediately report no critical ambiguities.

Integration after EACH accepted answer (incremental update approach):
- Maintain in-memory representation of the spec (loaded once at start) plus the raw file contents.
- For the first integrated answer in this session:
  - Ensure a
```
## Clarifications
```
    section exists (create it just after the highest-level contextual/overview section per the spec template if missing).
  - Under it, create (if not present) a
```
### Session YYYY-MM-DD
```
    subheading for today.
- Append a bullet line immediately after acceptance:
```
- Q: <question> → A: <final answer>
```
  .
- Then immediately apply the clarification to the most appropriate section(s):
  - Functional ambiguity → Update or add a bullet in Functional Requirements.
  - User interaction / actor distinction → Update User Stories or Actors subsection (if present) with clarified role, constraint, or scenario.
  - Data shape / entities → Update Data Model (add fields, types, relationships) preserving ordering; note added constraints succinctly.
  - Non-functional constraint → Add/modify measurable criteria in Success Criteria > Measurable Outcomes (convert vague adjective to metric or explicit target).
  - Edge case / negative flow → Add a new bullet under Edge Cases / Error Handling (or create such subsection if template provides placeholder for it).
  - Terminology conflict → Normalize term across spec; retain original only if necessary by adding
```
(formerly referred to as "X")
```
    once.
- If the clarification invalidates an earlier ambiguous statement, replace that statement instead of duplicating; leave no obsolete contradictory text.
- Save the spec file AFTER each integration to minimize risk of context loss (atomic overwrite).
- Preserve formatting: do not reorder unrelated sections; keep heading hierarchy intact.
- Keep each inserted clarification minimal and testable (avoid narrative drift).
Validation (performed after EACH write plus final pass):
- Clarifications session contains exactly one bullet per accepted answer (no duplicates).
- Total asked (accepted) questions ≤ 5.
- Updated sections contain no lingering vague placeholders the new answer was meant to resolve.
- No contradictory earlier statement remains (scan for now-invalid alternative choices removed).
- Markdown structure valid; only allowed new headings:
```
## Clarifications
```
  ,
```
### Session YYYY-MM-DD
```
  .
- Terminology consistency: same canonical term used across all updated sections.
Write the updated spec back to
```
FEATURE_SPEC
```
.
Re-validate Spec Quality Checklist (if it exists):
- Check if
```
FEATURE_DIR/checklists/requirements.md
```
  exists.
- If it does NOT exist, skip this step silently.
- If it exists:
  1. Read the checklist file.
  2. Identify all GitHub task-list checkbox lines — lines matching
```
- [ ]
```
    ,
```
- [x]
```
    , or
```
- [X]
```
    (case-insensitive, tolerant of leading whitespace for nested items) outside of code fences. Ignore all other content (headings, notes, non-checkbox bullets, metadata).
  3. For each checkbox line, record its current marker state (checked or unchecked) and item text into a before-snapshot list.
  4. Re-evaluate each checkbox item against the updated spec (the version just saved in step 7).
  5. For each checkbox item, update only if the checked/unchecked state actually changes:
    - If the item now passes and was unchecked: change
      [ ]
      to
      [x]
      .
    - If the item now fails and was checked: change
      [x]
      /
      [X]
      to
      [ ]
      .
    - If the state is unchanged: leave the marker as-is (preserve existing case to avoid cosmetic diffs).
  6. Save the updated checklist file. Only toggle the
    [ ]
    /
    [x]
    marker portion of checkbox lines whose state changed. All other file content — headings, metadata, notes, line ordering, whitespace — must remain unchanged to avoid noisy diffs.
  7. Compare the before-snapshot with the current state to compute three lists for the Completion Report:
    - Newly passing: items that changed from unchecked to checked.
    - Regressions: items that changed from checked to unchecked.
    - Still unchecked: items that remain unchecked.
  8. Record the before/after pass counts as checked/total checkbox items (e.g., "12/16 → 15/16 items passing").

Behavior rules:

If no meaningful ambiguities found (or all potential questions would be low-impact), respond: "No critical ambiguities detected worth formal clarification." and suggest proceeding.
If spec file missing, instruct user to run
```
/speckit-specify
```
first (do not create a new spec here).
Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions).
Avoid speculative tech stack questions unless the absence blocks functional clarity.
Respect user early termination signals ("stop", "done", "proceed").
If no questions asked due to full coverage, output a compact coverage summary (all categories Clear) then suggest advancing.
If quota reached with unresolved high-impact categories remaining, explicitly flag them under Deferred with rationale.

Context for prioritization: $ARGUMENTS

目标：检测并减少当前功能规格说明书中的歧义或缺失的决策点，并将澄清内容直接记录到规格文件中。

注意：此澄清工作流应在调用

/speckit-plan

之前运行（并完成）。如果用户明确表示要跳过澄清（例如探索性研究），你可以继续，但必须警告后续返工风险会增加。

执行步骤：

从仓库根目录运行一次
```
.specify/scripts/bash/check-prerequisites.sh --json --paths-only
```
（组合
```
--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"）。
如果存在：加载
```
.specify/memory/constitution.md
```
以了解项目原则和治理约束。
加载当前规格文件。使用以下分类法进行结构化的歧义与覆盖范围扫描。对于每个类别，标记状态：清晰/部分缺失/完全缺失。生成用于优先级排序的内部覆盖图（除非不会提出任何问题，否则不要输出原始覆盖图）。

功能范围与行为：
- 核心用户目标与成功标准
- 明确的范围外声明
- 用户角色/人物角色区分
领域与数据模型：
- 实体、属性、关系
- 标识与唯一性规则
- 生命周期/状态转换
- 数据量/规模假设
交互与UX流程：
- 关键用户旅程/序列
- 错误/空/加载状态
- 可访问性或本地化说明
非功能质量属性：
- 性能（延迟、吞吐量目标）
- 可扩展性（水平/垂直扩展、限制）
- 可靠性与可用性（正常运行时间、恢复预期）
- 可观测性（日志、指标、追踪信号）
- 安全与隐私（身份认证/授权、数据保护、威胁假设）
- 合规/监管约束（如有）
集成与外部依赖：
- 外部服务/API及故障模式
- 数据导入/导出格式
- 协议/版本假设
边缘情况与故障处理：
- 负面场景
- 速率限制/节流
- 冲突解决（例如并发编辑）
约束与权衡：
- 技术约束（语言、存储、托管）
- 明确的权衡或被否决的替代方案
术语与一致性：
- 标准术语表术语
- 避免使用的同义词/已弃用术语
完成信号：
- 验收标准的可测试性
- 可衡量的完成定义指标
杂项/占位符：
- TODO标记/未解决的决策
- 缺乏量化的模糊形容词（如"健壮"、"直观"）
对于每个状态为部分缺失或完全缺失的类别，添加候选问题机会，除非：
- 澄清不会实质性改变实现或验证策略
- 信息最好推迟到规划阶段（内部记录）
（内部）生成优先级排序的候选澄清问题队列（最多5个）。不要一次性输出所有问题。应用以下约束：
- 整个会话最多5个问题。
- 每个问题必须可以通过以下方式之一回答：
  - 简短的多项选择（2-5个不同、互斥的选项），或者
  - 一个单词/短语答案（明确限制："答案不超过5个单词"）。
- 仅包含那些答案会对架构、数据建模、任务分解、测试设计、UX行为、运维就绪性或合规验证产生实质性影响的问题。
- 确保类别覆盖平衡：优先覆盖影响最高的未解决类别；避免当单一高影响领域（例如安全态势）未解决时，提出两个低影响问题。
- 排除已回答的问题、琐碎的风格偏好或计划层面的执行细节（除非会阻碍正确性）。
- 优先选择那些能减少后续返工风险或防止验收测试不一致的澄清。
- 如果超过5个类别仍未解决，根据（影响×不确定性）启发式算法选择前5个。

顺序提问循环（交互式）：

每次仅呈现一个问题。
问题编写质量（适用于每个问题，选择题或简答题）：
- 以
```
**Question:**
```
  开头，后跟完整的疑问句，以
```
?
```
  结尾。
```
?
```
  之前的问题文本必须能独立表意。
- 永远不要使用主题标签、章节标题或需求ID作为问题本身。例如，
```
Acceptance device/runtime matrix (FR-023)
```
  是无效的——它是一个标签，不是问题。
- 在
```
?
```
  之后，唯一允许的后缀是可选的括号括起来的需求/问题ID。格式为：
```
**Question:** <疑问句>?
```
  或
```
**Question:** <疑问句>? (FR-023)
```
  。永远不要将ID放在
```
?
```
  之前，也永远不要将ID（单独或与主题标签一起）作为整个提示。
- 在问题行之后，立即添加一个通俗易懂的"为什么重要"句子（即验收或发布的利害关系），然后再给出建议/选项。
- 使用日常用语；仅在同一句话中定义过的情况下才引入行话。自我检查：不了解Spec Kit的读者必须仅通过问题行就能回答问题。简洁是可以的；晦涩的标签不行。

对于多项选择题：

分析所有选项，并根据以下因素确定最合适的选项：
- 项目类型的最佳实践
- 类似实现中的常见模式
- 风险降低（安全、性能、可维护性）
- 与规格中可见的任何明确项目目标或约束的一致性
将你的推荐选项突出显示在顶部，并附上清晰的理由（1-2句话解释为什么这是最佳选择）。
格式为：
```
**Recommended:** Option [X] - <理由>
```
然后将所有选项渲染为Markdown表格：

Option	Description
A	<选项A描述>
B	<选项B描述>
C	<选项C描述>（根据需要添加D/E，最多5个）
Short	提供不同的简短答案（≤5个单词）（仅当适合自由格式替代时包含）

在表格之后添加：

你可以回复选项字母（例如"A"），通过说"yes"或"recommended"接受推荐，或者提供你自己的简短答案。

对于简答题格式（无有意义的离散选项）：

根据最佳实践和上下文提供你的建议答案。

格式为：

**Suggested:** <你的建议答案> - <简要理由>

然后输出：

格式：简短答案（≤5个单词）。你可以通过说"yes"或"suggested"接受建议，或者提供你自己的答案。

用户回答后：
- 如果用户回复"yes"、"recommended"或"suggested"，使用你之前陈述的推荐/建议作为答案。
- 否则，验证答案是否对应某个选项或符合≤5个单词的约束。
- 如果答案模糊，请求快速澄清（仍算作同一个问题，不推进到下一个）。
- 一旦答案令人满意，将其记录到工作内存中（暂不写入磁盘），然后转到下一个排队的问题。
在以下情况下停止提问：
- 所有关键歧义提前解决（剩余排队问题变得不必要），或者
- 用户表示完成（"done"、"good"、"no more"），或者
- 你已提出5个问题。
永远不要提前透露未来排队的问题。
如果一开始就没有有效问题，立即报告没有关键歧义。

每次接受答案后的整合（增量更新方法）：
- 维护规格的内存表示（在开始时加载一次）以及原始文件内容。
- 对于本次会话中的第一个整合答案：
  - 确保存在
```
## Clarifications
```
    章节（如果缺失，根据规格模板在最高级别的上下文/概述章节之后创建）。
  - 在其下创建（如果不存在）
```
### Session YYYY-MM-DD
```
    子标题（YYYY-MM-DD为当天日期）。
- 接受答案后立即添加一个项目符号行：
```
- Q: <问题> → A: <最终答案>
```
  。
- 然后立即将澄清内容应用到最合适的章节：
  - 功能歧义 → 更新或添加功能需求中的项目符号。
  - 用户交互/角色区分 → 更新用户故事或角色子章节（如果存在），添加澄清后的角色、约束或场景。
  - 数据形状/实体 → 更新数据模型（添加字段、类型、关系），保留顺序；简洁地记录添加的约束。
  - 非功能约束 → 在成功标准>可衡量结果中添加/修改可衡量标准（将模糊形容词转换为指标或明确目标）。
  - 边缘情况/负面流程 → 在边缘情况/错误处理下添加新的项目符号（如果模板提供了占位符，则创建该子章节）。
  - 术语冲突 → 在整个规格中统一术语；仅在必要时保留原始术语，添加
```
(formerly referred to as "X")
```
    一次。
- 如果澄清内容使之前的模糊陈述无效，替换该陈述而非重复；不要留下过时的矛盾文本。
- 每次整合后保存规格文件，以最大限度减少上下文丢失的风险（原子覆盖）。
- 保留格式：不要重新排序无关章节；保持标题层级不变。
- 保持每个插入的澄清内容简洁且可测试（避免叙述偏离）。
验证（每次写入后以及最终步骤执行）：
- 澄清会话中每个接受的答案对应恰好一个项目符号（无重复）。
- 提出（接受）的问题总数≤5。
- 更新后的章节中没有新答案本应解决的模糊占位符残留。
- 没有残留矛盾的早期陈述（扫描已删除的现在无效的替代选项）。
- Markdown结构有效；仅允许新增标题：
```
## Clarifications
```
  、
```
### Session YYYY-MM-DD
```
  。
- 术语一致性：所有更新章节中使用相同的标准术语。
将更新后的规格写回
```
FEATURE_SPEC
```
。
重新验证规格质量检查表（如果存在）：
- 检查
```
FEATURE_DIR/checklists/requirements.md
```
  是否存在。
- 如果不存在，静默跳过此步骤。
- 如果存在：
  1. 读取检查表文件。
  2. 识别所有GitHub任务列表复选框行——匹配
```
- [ ]
```
    、
```
- [x]
```
    或
```
- [X]
```
    的行（不区分大小写，允许嵌套项的前导空格），且不在代码块内。忽略所有其他内容（标题、注释、非复选框项目符号、元数据）。
  3. 对于每个复选框行，将其当前标记状态（已勾选或未勾选）和项目文本记录到快照前列表中。
  4. 根据更新后的规格（步骤7中刚保存的版本）重新评估每个复选框项目。
  5. 对于每个复选框项目，仅在勾选/未勾选状态实际改变时更新：
    - 如果项目现在通过且之前未勾选：将
      [ ]
      改为
      [x]
      。
    - 如果项目现在未通过且之前已勾选：将
      [x]
      /
      [X]
      改为
      [ ]
      。
    - 如果状态未改变：保持标记不变（保留现有大小写以避免无意义的差异）。
  6. 保存更新后的检查表文件。仅切换状态改变的复选框行的
    [ ]
    /
    [x]
    标记部分。所有其他文件内容——标题、元数据、注释、行顺序、空格——必须保持不变，以避免产生嘈杂的差异。
  7. 比较快照前和当前状态，为完成报告计算三个列表：
    - 新通过项：从未勾选变为已勾选的项目。
    - 回归项：从已勾选变为未勾选的项目。
    - 仍未勾选项：保持未勾选的项目。
  8. 记录勾选/总复选框项目的前后通过计数（例如，"12/16 → 15/16项通过"）。

行为规则：

如果未发现有意义的歧义（或所有潜在问题的影响都很低），回复："未检测到值得正式澄清的关键歧义。"并建议继续。
如果规格文件缺失，指示用户先运行
```
/speckit-specify
```
（不要在此处创建新规格）。
永远不要超过5个总提问数（单个问题的澄清重试不算新问题）。
避免推测性技术栈问题，除非其缺失会阻碍功能清晰度。
尊重用户的提前终止信号（"stop"、"done"、"proceed"）。
如果因覆盖范围完整而未提出任何问题，输出简洁的覆盖范围摘要（所有类别均为清晰），然后建议推进。
如果已达到问题配额但仍有高影响类别未解决，明确在"推迟"部分标记它们并说明理由。

优先级上下文：$ARGUMENTS

Mandatory Post-Execution Hooks

强制执行后钩子

You MUST complete this section before reporting completion to the user.

Check if

.specify/extensions.yml

exists in the project root.

If it does not exist, or no hooks are registered under
```
hooks.after_clarify
```
, skip to the Completion Report.
If it exists, read it and look for entries under the
```
hooks.after_clarify
```
key.
If the YAML cannot be parsed or is invalid, skip hook checking silently and continue to the Completion Report.
Filter out hooks where
```
enabled
```
is explicitly
```
false
```
. Treat hooks without an
```
enabled
```
field as enabled by default.
For each remaining hook, do not attempt to interpret or evaluate hook
```
condition
```
expressions:
- If the hook has no
```
condition
```
  field, or it is null/empty, treat the hook as executable
- If the hook defines a non-empty
```
condition
```
  , skip the hook and leave condition evaluation to the HookExecutor implementation
When constructing command invocations from hook command names, replace dots (
```
.
```
) with hyphens (
```
-
```
). For example,
```
speckit.git.commit
```
→
```
/speckit-git-commit
```
.
For each executable hook, output the following based on its
```
optional
```
flag:
- Mandatory hook (
```
optional: false
```
  ) — You MUST emit
  EXECUTE_COMMAND:
  for each mandatory hook:
  text
```
## Extension Hooks

**Automatic Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}
```
  After emitting the block above you MUST actually invoke the hook and wait for it to finish before continuing. Run it the same way you would run the command yourself in this agent/session (the invocation may differ from the literal
```
{command}
```
  id shown above, e.g. a skills-mode agent runs it as
```
/skill:speckit-...
```
  or
```
$speckit-...
```
  ). Emitting the block alone does not run the hook.
- Optional hook (
```
optional: true
```
  ):
  text
```
## Extension Hooks

**Optional Hook**: {extension}
Command: `/{command}`
Description: {description}

Prompt: {prompt}
To execute: `/{command}`
```

在向用户报告完成之前，你必须完成此部分。

检查项目根目录下是否存在

.specify/extensions.yml

文件。

如果不存在，或
```
hooks.after_clarify
```
下没有注册钩子，跳转到完成报告。
如果存在，读取该文件并查找
```
hooks.after_clarify
```
键下的条目。
如果YAML无法解析或无效，静默跳过钩子检查并继续到完成报告。
过滤掉
```
enabled
```
显式设为
```
false
```
的钩子。未设置
```
enabled
```
字段的钩子默认视为启用。
对于剩余的每个钩子，不要尝试解释或评估钩子的
```
condition
```
表达式：
- 如果钩子没有
```
condition
```
  字段，或该字段为null/空，视为可执行钩子
- 如果钩子定义了非空的
```
condition
```
  ，跳过该钩子，将条件评估留给HookExecutor实现处理
从钩子命令名称构造命令调用时，将点（
```
.
```
）替换为连字符（
```
-
```
）。例如，
```
speckit.git.commit
```
→
```
/speckit-git-commit
```
。
对于每个可执行钩子，根据其
```
optional
```
标志输出以下内容：
- 强制钩子（
```
optional: false
```
  ）——你必须为每个强制钩子输出
  EXECUTE_COMMAND:
  ：
  text
```
## Extension Hooks

**Automatic Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}
```
  输出上述块后，必须实际调用该钩子并等待其完成后再继续。以你在该Agent/会话中运行命令的相同方式执行它（调用方式可能与上面显示的字面
```
{command}
```
  ID不同，例如技能模式Agent会以
```
/skill:speckit-...
```
  或
```
$speckit-...
```
  的方式运行）。仅输出块并不会运行钩子。
- 可选钩子（
```
optional: true
```
  ）：
  text
```
## Extension Hooks

**Optional Hook**: {extension}
Command: `/{command}`
Description: {description}

Prompt: {prompt}
To execute: `/{command}`
```

Completion Report

完成报告

Report completion (after questioning loop ends or early termination):

Number of questions asked & answered.
Path to updated spec.
Sections touched (list names).
Spec quality checklist status (if
```
FEATURE_DIR/checklists/requirements.md
```
was re-validated): show before/after pass counts (e.g., "Spec Quality Checklist: 12/16 → 15/16 items passing") and list any items that changed state — both newly checked (unchecked → checked) and any regressions (checked → unchecked). If any items remain unchecked, list them as areas needing attention.
Coverage summary table listing each taxonomy category with Status: Resolved (was Partial/Missing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial/Missing but low impact).
If any Outstanding or Deferred remain, recommend whether to proceed to
```
/speckit-plan
```
or run
```
/speckit-clarify
```
again later post-plan.
Suggested next command.

报告完成（提问循环结束或提前终止后）：

提出并回答的问题数量。
更新后的规格文件路径。
涉及的章节（列出名称）。
规格质量检查表状态（如果重新验证了
```
FEATURE_DIR/checklists/requirements.md
```
）：显示前后通过计数（例如，"规格质量检查表：12/16 → 15/16项通过"），并列出任何状态改变的项目——包括新勾选的（未勾选→已勾选）和任何回归项（已勾选→未勾选）。如果仍有未勾选的项目，将其列为需要关注的区域。
覆盖范围摘要表，列出每个分类法类别及其状态：已解决（之前为部分缺失/完全缺失并已处理）、推迟（超出问题配额或更适合规划阶段）、清晰（已足够）、未解决（仍为部分缺失/完全缺失但影响低）。
如果仍有未解决或推迟的项目，建议是继续执行
```
/speckit-plan
```
还是稍后在规划后重新运行
```
/speckit-clarify
```
。
建议的下一步命令。

Done When

完成条件

Spec ambiguities identified and clarifications integrated into spec file
Spec quality checklist re-validated against updated spec (if
```
FEATURE_DIR/checklists/requirements.md
```
exists)
Extension hooks dispatched or skipped according to the rules in Mandatory Post-Execution Hooks above
Completion reported to user with questions answered, sections touched, checklist status, and coverage summary

已识别规格歧义并将澄清内容整合到规格文件中
已根据更新后的规格重新验证规格质量检查表（如果
```
FEATURE_DIR/checklists/requirements.md
```
存在）
已根据上述强制执行后钩子中的规则调度或跳过扩展钩子
已向用户报告完成情况，包括已回答的问题、涉及的章节、检查表状态和覆盖范围摘要