/task-clarifier

name: task-clarifier
description: >-
  Deep need-clarification skill. Use only when the user explicitly invokes
  $task-clarifier. Once activated, keep clarifying until three goals are met:
  the user understands their own needs, the AI understands the user's needs,
  and the user confirms the AI's understanding is correct. Do not intervene in
  task execution unless explicitly invoked.

Task Clarifier

This skill clarifies a request. It does not execute the task. Execution may begin only after the user confirms the understanding and, for high-risk actions, approves them separately.

Language Rule

Write user-facing output (questions, options, recommendations, alignment material, confirmation summaries) in the user's language. Detect it from the user's latest message; default to Chinese when unknown. The Chinese templates in this file are output forms, not a requirement to write in Chinese. When the user writes in another language, keep the same structure in that language. Keep code, paths, commands, identifiers, and quoted user text exactly as they are.

Three Goals

All three must be met before this skill ends:

1. **The user understands their own needs**, including considerations they have not raised, latent contradictions, and implicit premises that would change the outcome. 2. **The AI understands the user's needs** completely and specifically. No user-owned decision is filled with a default. 3. **The user can verify the AI's understanding.** It is stated in checkable form, and each inference is listed for confirmation or correction.

Judge completion by these goals and the user's explicit confirmation. Do not use a numeric clarity score or a required number of questions.

Startup Reads

On activation, make these best-effort reads silently. If a source is unavailable or fails, continue without it.

• **Profile.** If `$user-profile-keeper` is available, read only its low-sensitivity `clarification_summary` view. It may shape phrasing, option wording, and examples. It must never decide the audience, scope, acceptance criteria, risk, permissions, or whether a question is needed. Do not infer an audience from demographic, career, education, or other personal fields. Describe roles by function and situation, not as labels for a real person.
• **Task forest.** If `$task-forest` is available, read the current workspace task list and open todos for global context. This context informs recommendations; it does not override the current message.

Use the host's native skill or tool mechanism first. Do not assume a particular agent, skill root, home-directory layout, shell, or operating system. If direct script execution is the only route, discover the companion skill through the host's registry or a repo-local `skills/<skill-name>/` path, build paths with the runtime's path utilities, and never hard-code home, absolute, or drive-letter paths.

Do not read the full profile, pending profile entries, private background, raw evidence, credentials, tokens, or unrelated private information. Do not write to the profile or the task forest. This skill keeps no state between sessions. It writes a file only for a medium whose path the user has accepted.

Clarification Loop

Each round:

1. **Look up before asking.** Facts that the current conversation, provided materials, workspace files, or the task forest can answer are not questions. 2. **Find the open decisions that most affect the outcome.** These are choices, priorities, risk tolerances, acceptance criteria, and facts that cannot be looked up. Raise contradictions and infeasible parts in the current round as soon as you identify them. 3. **Ask the fewest questions that resolve those decisions, at most three per round.** Ask questions that depend on earlier answers in later rounds. Combine only independent questions. 4. **For each question, state the result it changes, offer distinguishable options, and give a recommended answer.** Always keep a free-form option.

Questions may cover anything that still affects the outcome: the goal and why it matters now; what counts as done and done well; scope and non-goals; time, budget, technology, format, region, permissions, risk, and external effects; which goal wins when goals conflict; and premises the user has not recognized. Ask about audience only under the Audience Impact Test below.

Lay out each question with the reason first, options second, and the recommendation last:

**Q1. [One sentence: why this answer changes the outcome]**

A) [option]  B) [option]  C) [option]  D) Tell me your own view

→ My recommendation: [short, direct recommended answer]

Separate multiple questions in one round with a blank line and `---`. Keep questions simple, accurate, and understandable to someone new to the topic.

If the user says "up to you", "whatever", "your call", "你看着办", "随便", or "你来定", give a recommended option and ask them to confirm it. Do not proceed on your own.

**Zero-question branch.** If local lookup leaves no open user-owned decision, ask no questions and go straight to the Confirmation Stage. Zero questions never means zero confirmation: the user still confirms before execution.

Audience Impact Test

Ask about who uses, reviews, approves, or is affected by the result only if the answer would change at least one of:

• scope or non-goals
• observable acceptance criteria
• security, privacy, compliance, or external effects
• interaction design, accessibility, language, or who reads or approves the output
• implementation, output format, tools, deployment boundary, or level of detail

If no answer would change any of these, do not spend a question on audience. State the audience assumption as an inference in the confirmation summary instead. For internal technical work, identify the operator, reviewer, or maintainer only when that role changes acceptance, permissions, or operations. An internal tool still has an audience.

Alignment Evidence

Use Markdown by defaul