name: requirements-clarification
user-invocable: false
description: >-
Clarify a material user-owned product decision before substantive
implementation commitments. Use only when request and named/governing evidence
still leave a choice that would materially change scope, platform support, user-facing
surface, data/API contract, domain values, project placement, or cross-system
architecture; also use when a truncated request omits such a choice.
On the initial turn, inspect only named or governing requirements evidence,
then ask directly without loading: prefer structured input; ask one blocking
outcome question or at most three coupled questions; wait. After the answer,
load the body before write or delegation. Do not use for
implement/build/fix/debug/refactor work when expected behavior is settled,
plan/design deliverables owned by Plan, complexity/greenfield/integration
alone, agent-owned technical choices, locally discoverable facts, reversible
defaults, permission to begin, or stop/no-tool turns. Never re-ask supplied
facts or turn clarification into refusal.
Requirements Clarification / 需求澄清
Resolve only a remaining user-owned product decision. Do not turn normal
implementation uncertainty into a question.
只解决尚存的、归用户所有的产品决策。不要把正常的实现层面不确定性变成提问。
- Read the request and any explicitly named or governing requirements source.
Do not scan broadly for hypothetical ambiguity. If this evidence settles the
outcome, proceed without asking.
阅读请求以及任何被明确点名或具有约束力的需求来源。不要宽泛地搜寻假设性的歧义。如果这些证据足以确定结果，直接继续，无需提问。 - Separate user-owned outcomes and authoritative inputs from agent-owned
implementation choices. Research discoverable facts yourself. Never ask the
user to choose a library, framework, or method the agent can determine.
把归用户所有的结果与权威输入，同归助手所有的实现选择区分开。可自行查明的事实要自己调研。绝不要求用户去挑选库、框架或助手自己能确定的方法。 - If a narrow reversible default safely satisfies the request, state it and
proceed. Complexity, greenfield status, file count, or integration work alone
never requires clarification.
如果一个范围窄、可回退的默认选择能安全满足请求，说明该选择并继续。复杂度、全新项目状态、文件数量或集成工作本身绝不构成需要澄清的理由。 - Otherwise ask before substantive commitment. Reads, notes, or one small
branch-neutral probe are allowed; a scaffold, public contract, embedded domain
values, or cross-system architecture is a commitment.
否则，在做出实质承诺之前先提问。读取、记笔记或一次与分支无关的小型探查是允许的；搭建脚手架、确定公开契约、内嵌领域取值或跨系统架构则属于承诺。 - Prefer
request_user_inputwhen available. Ask one blocking outcome question;
group at most three tightly coupled questions. Offer concrete outcome options
and a recommendation. Never ask merely for permission to begin.
在可用时优先使用request_user_input。问一个阻塞性的结果问题；至多把三个紧密耦合的问题归为一组。给出具体的结果选项和一项推荐。绝不仅为"获准开始"而提问。 - After the answer, do not ask again unless later evidence reveals a distinct
material fork. Apply the answer and continue.
得到回答后，除非后续证据揭示出另一个不同的重大分叉，否则不再追问。应用该回答并继续。
plan owns standalone plan and design deliverables. This skill does not create
an approval gate or stop a specified implementation merely because planning
would be useful. Never re-ask facts already supplied by the request or governing
evidence, and never turn clarification into a refusal.
独立的计划与设计交付物归 plan 所有。本技能不设立审批关卡，也不应仅因为"做规划可能有好处"就叫停一项已明确的实现。绝不重复询问请求或权威证据已给出的事实，也绝不要把澄清变成拒答。
【评论】该技能把"何时该问、何时不该问"写成硬边界，用于抑制以澄清为名的过度打断与变相拖延。