f2s-req-clarify

name	f2s-req-clarify
description	Clarify a PRD or requirement through follow-up questions until it is actionable, then use f2s-req-tech to produce a technical design; triggers: 需求澄清、PRD 澄清、requirement clarification、PRD clarification

Orchestration (main / sub agent)

• The semantics of subAgent / switchAgentVerification use the unified entry as the only source of truth: Cursor/Claude read the config-root rules/f2s-flow2spec-unified-entry.*; Codex reads .codex/topics/f2s-flow2spec-unified-entry.md (same source, mirrored by flow2spec init). This skill does not restate those semantics.
• This skill does not split work by default: regardless of the subAgent value, the clarification process stays entirely in the main conversation. Follow-up questions and alignment with the user strongly depend on continuous context; sub-agent splitting would break that context.
• Verification is performed by the agent that writes the artifact. This skill does not bind to cross-agent verification.

Requirement Clarification

Execution scope: clarification documents are written to .Knowledge/req-docs/.

Input: Optional. The full PRD, a requirement description, or a document path (for example .Knowledge/req-docs/xxx.md). If omitted, clarify based on the current conversation. Later replies may add requirement conditions.

Behavior: Identify vague wording, undefined concepts, missing information, contradictions, and implementation-relevant details that are not specified. Group them, ask concrete answerable follow-up questions, then iterate based on the answers until the flow, boundaries, exceptions, and key concepts are unambiguous. Do not make business assumptions for the user; ask when something is unclear.

Completion (write clarification doc → auto-chain to technical design): When the information is clear enough, output a Markdown "requirement clarification document" that can be written directly to disk. The document must include at least: background and goals, scope (included / excluded), key flows, boundaries and exceptions, key concept definitions, acceptance criteria, and open questions if any. Save it under .Knowledge/req-docs/ (recommended name: <capability>_需求澄清.md).

After the clarification document is written to disk, this skill auto-chains to f2s-req-tech within the same turn: feed the just-written clarification path directly into technical-design generation without waiting for another user trigger. Before chaining, emit a one-line notice "Clarification document ready: <path>; proceeding to generate the technical design via f2s-req-tech", then continue.

Exceptions — stay at clarification, do NOT auto-chain to technical design (any one triggers a stop):

• The clarification document's "open questions" section still has items that materially shape the design structure (e.g., core contracts for tables / APIs / state machines are undefined) — in that case, list the remaining questions, wait for answers, then write and chain;
• The user explicitly says "only produce the clarification / don't rush the design / discuss first" or a similar stop phrase during clarification;
• The user explicitly specifies a different next action (e.g., "stop after clarification", "break down tasks first").

Prohibited:

• Appending an f2s-kb-distill closing hint at the end of the clarification document or immediately after it (see the prohibited section of rules/f2s-kb-feedback-closing.* — process-orchestration skills do not trigger distill on write);
• Auto-chaining to f2s-req-tech before the clarification document is written to disk (the auto-chain requires an on-disk clarification path);
• Skip-chaining to f2s-req-plan / implement-tech-design / any other f2s-* skill in the same turn (only one hop — to f2s-req-tech — is allowed; subsequent skills still require a new user turn).