A reusable agent skill should explain what to do when a required input is missing. Start by checking the current request, prior answers and authorized sources. Then distinguish information that changes the work from a minor preference the assistant can reasonably default. Ask a focused question when the unresolved choice matters, and continue useful work that does not depend on the answer.
For a team maintaining SKILL.md workflows, “ask if anything is unclear” is too broad to be the entire policy. It can produce a questionnaire before every task, while still leaving the assistant to guess a consequential requirement. The skill needs a small set of decisions about missing information, including what to do when the workflow runs without an available person.
This guide proposes those decisions through a fictional workshop-planning skill. We have not installed or tested that skill, compared assistant products or measured the effect of its questions on users.
Make input handling part of the workflow
The Agent Skills specification defines a package with SKILL.md instructions and optional scripts, references and assets. Its Markdown body can include workflow steps and edge cases. That gives an author room to describe missing-input behavior; it does not impose a universal clarification policy or guarantee an interactive question interface across products.
For each important input, identify its role. Does it determine the audience, the permitted action, the calculation, the source to use or merely a presentation preference? Then identify where an authoritative answer should come from.
An approved project brief may already supply the audience. The current user request may supply the duration. A maintained reference may define the reporting period. Asking the user to repeat those facts adds work without resolving uncertainty. Retrieving them must still stay within the task’s authorized sources and access boundaries.
Keep the input policy close to the steps it governs. Our guide to scripts inside skills covers helper inputs and failures. Here the focus is the surrounding conversational decision: retrieve, default, clarify or report a limitation.
Research distinguishes missing intent from model uncertainty
In Structured Uncertainty guided Clarification for LLM Agents, published in Findings of ACL in July 2026, Manan Suri and colleagues distinguish uncertainty about what the user wants from uncertainty in a model’s predictions. Their ClarifyBench evaluation includes explicit, ambiguous and infeasible requests, with a simulated user and evaluation of the resulting tool calls. Their approach considers tool parameters and the value and cost of a question.
This is research on a specific agent method and benchmark, not proof that a paragraph added to SKILL.md produces the same benefits. The paper notes its simulated environment and scoped models, including GPT-4o and Qwen2.5 configurations. We do not translate its results into expected gains for today’s business workflows.
Anthropic’s February 2026 study of agent autonomy also describes clarification as one reason Claude Code stops. This is a vendor’s observational analysis, using model-based classifications and data from its own products during a particular period. It does not establish that every observed question was necessary or that asking more questions improves task quality.
The editorial implication is to judge a question by the uncertainty it resolves and the action it changes. A question count alone is an incomplete quality measure.
Work through a fictional workshop request
Imagine a skill that drafts a workshop brief and agenda. A user requests a 45-minute session about support handovers. An approved planning document contains the team’s terminology, but the intended participant group is unresolved.
The assistant can read the approved material, identify relevant handover topics and prepare an agenda structure. However, exercises for new starters may differ substantially from exercises for experienced team leads. Choosing one silently could produce an internally coherent plan for the wrong audience.
By contrast, whether an agenda uses numbered headings may be a reversible formatting choice. That preference rarely deserves to block preparation unless the user or an established template has made it a requirement.
The following matrix is a proposed policy for this fictional skill, not a set of universal defaults:
| Situation | Proposed response | Evidence to retain |
|---|---|---|
| Duration is stated in the request | Use it without asking again | The supplied duration |
| Terminology is in the approved planning document | Read that source | The document used |
| Participant group changes the exercises | Ask for the group before tailoring exercises | The answer and affected work |
| Heading style is unspecified | Use the established template or state a simple default | The chosen default |
| Required source cannot be accessed | Explain the access limitation | What could not be retrieved |
| Nobody can answer a required question | Follow the unattended-run policy | The unresolved decision and partial work |
Do not promote a likely answer into an established fact. “The team probably means new starters” is an assumption. “The approved brief names new starters” is a sourced input. The difference should remain visible in the working record.
Ask the question that changes the next step
For the fictional request, a focused question could identify the participant group and explain that it determines the exercises. Present meaningful alternatives when they help the person answer, while allowing an answer outside those alternatives.
Avoid asking the user to design the implementation. A workshop owner may know the audience and objective without wanting to choose an agenda-generation algorithm or file library. The assistant should investigate technical details it can establish itself and reserve the question for information the user can actually supply.
Also avoid coupling independent work to the unresolved answer. The assistant can organize known materials while waiting to tailor the exercise. It should make that distinction clear in its progress record so unfinished work is not mistaken for a completed audience-specific plan.
Once an answer is available, use it and continue. Do not re-ask the same decision merely because a later phase begins. Revisit it when new evidence conflicts with it, the task changes or its scope no longer applies. Existing authorization should likewise be respected within its stated scope rather than repeatedly treated as absent.
A question interface does not validate its inputs
The target assistant’s runtime determines how a skill receives arguments and communicates with a user. Claude Code’s skills documentation describes passing arguments through placeholders such as $ARGUMENTS, including behavior for missing indexed or named arguments. Those are product-specific input mechanics; they do not establish that the supplied value is sufficient or correct for the business task.
Define the semantic check separately. A participant field containing “everyone” may be present but still insufficient to tailor the fictional workshop. Conversely, a missing invocation argument may already be answered in the surrounding conversation. Check the available evidence before deciding that the user must fill a particular slot.
Use the supported interaction mechanism in the intended product. Do not assume that a tool name or question widget from one assistant exists in another. If the workflow requires an interactive surface, describe that environment requirement and verify it during the team’s own evaluation.
Decide what an unattended run can finish
An unattended workflow needs an explicit response to missing required information. It cannot rely on waiting indefinitely for a conversational answer, and elapsed time does not supply the answer.
For the fictional skill, the owner might permit a generic agenda outline while withholding tailored exercises until the audience is known. The result should be marked as partial and name the missing decision. Another task may require stopping before producing any dependent artifact. Choose that policy according to the task, not a blanket instruction to always finish something.
Optional preferences can have documented defaults. Required decisions need evidence or an explicitly authorized assumption. Keep the distinction stable across interactive and unattended runs; otherwise a scheduling change can silently change the meaning of the output.
A compact status record should say what is complete, what remains dependent on an answer, which default was used and how work can resume. Our handoff guide for unfinished agent work covers preserving that state separately from reusable instructions.
Test both guessing and unnecessary interruption
Evaluate the proposed policy with clear requests as well as incomplete ones. Include an audience supplied directly, an audience available in an approved source, a genuinely missing audience, a cosmetic preference, conflicting inputs and an unavailable required source. Specify the expected behavior before running the skill.
Inspect whether the assistant uses the answer after asking, continues independent work where appropriate and reports partial completion accurately. A useful question followed by an unchanged generic result has not resolved the workflow problem. A flawless result obtained only after unnecessary repeated questions may still impose avoidable effort.
Begin with one recurring missing-input problem. Define its authoritative sources, the decision it affects and the response when an answer is unavailable. That gives the skill a reviewable interaction policy instead of an open-ended instruction to ask whenever it feels uncertain.