Teach Your Skill to Ask Before Giving Advice

Teach your skill to ask a clarifying question when missing information could change its recommendation or make the requested output misleading. Name the missing fact, explain the decision it affects, and wait for the answer before completing that dependent step.

Do not instruct it to ask questions merely to appear thoughtful. If the reader has already supplied the necessary information, proceed. If an optional preference is missing, a clearly labeled draft may be useful without another round of intake.

This is author judgment made explicit: which facts would you need before advising someone through the method in your book? The same request can be answerable, partially answerable, or impossible to complete depending on those facts.

“Ask questions when needed” leaves the meaning of needed unresolved. One person describing their experience with custom instructions, u/SteCaddy, wrote:

“The problem is that it still tends to answer immediately and never asks questions.”

The post concerns several consequential personal topics. It is a report of that person's interactions, not a controlled evaluation or evidence of current behavior across a product. The authoring lesson is to test actual clarification behavior instead of assuming the instruction is sufficient. Original discussion.

Start by replacing the vague instruction with a conditional one. For example: “If the reader asks you to prepare a meeting agenda but has not supplied the decision the meeting must support, ask for that decision before proposing agenda items.”

That instruction identifies an absent input, a dependent action, and the required response. It can be checked using a concrete case.

In a consulting discussion, u/StraiteNoChaser described starting with the assigned deliverable and asking:

“what information do I need to contribute to the completion of this deliverable?”

The commenter then describes separating questions they can answer from those requiring a colleague or client. It is a personal workflow, not a universal consulting standard, but the question is useful for an author drafting a companion. Original comment.

Inspect the output your skill promises. For each part, list the facts that justify it. A recommended next step needs different evidence from a blank worksheet. A summary of supplied material may be possible even when a final recommendation is not.

Keep four statuses distinct: supplied, missing, uncertain, and contradictory. A confident sentence from the reader can still describe an estimate. Two inconsistent dates should not be silently reconciled. “I think they approved it” should not become confirmed approval.

Consider a fictional book about preparing useful decision meetings. Its companion helps a reader draft an agenda for one meeting. The method and all examples below are invented; they are not records of customer use or AI tests.

The author chooses these context rules:

The table belongs to this fictional method. Your book may require different information. What matters is the connection between each input and the decision it supports.

Do not classify everything as required. A preferred heading style does not have the same importance as the actual decision. Making that distinction prevents an intake from becoming a long form before any useful work can happen.

An illustrative reader, Daniel, says: “Write an agenda for our team meeting about the new handover process.”

The topic is clear; the intended result is not. The skill should ask a question such as: “Do you need the team to choose a handover process, identify problems with the current one, or review a proposal already drafted?” These are examples, not an exhaustive list. Leave room for Daniel to describe another outcome.

Daniel replies: “Review the proposal and approve it.” He supplies the proposal and says the meeting is thirty minutes. The skill now has the intended result, material, and duration. It still does not know whether the participants can approve the change.

A useful next question would be: “Who needs to approve the new process, and will that person be in the meeting?” This question has a visible consequence. Without the answer, the agenda should not promise approval.

Daniel says the manager who approves changes will be absent. The skill can propose an agenda to review the draft and prepare recommendations for that manager. It should explain the changed outcome and ask Daniel to confirm it before treating that as the meeting's purpose.

The point is not to force a particular number of questions. Each question resolves a decision the proposed output depends on.

For the same fictional request, compare three authored responses. These are editorial examples, not outputs captured from competing models.

Unsupported completion: “End with a vote to approve the new process.” This assumes the team has authority and that a vote is the agreed approval mechanism.

Unfocused clarification: “Tell me more about your company, culture, goals, values, leadership style, and challenges.” Some details could matter later, but the response does not identify the missing fact blocking this agenda.

Targeted clarification: “Who has authority to approve the process, and will they attend? That determines whether the meeting can end in approval or should produce a recommendation.” The question explains the dependency and gives the reader a concrete answer to provide.

Use comparisons like these when reviewing your instructions. “The skill asked a question” is an insufficient quality check. Ask whether it asked a necessary question, used the answer, and avoided making the dependent assumption before receiving it.

A reader may be unable to supply the fact. Write the next behavior explicitly.

For Daniel, an acceptable partial result could be a draft agenda marked “approval route unconfirmed,” with a preparation item to identify the decision-maker. It should not end with a fabricated agreement. If Daniel wants only a list of questions for the meeting organizer, that narrower task may be fully answerable.

Sometimes the uncertainty is central enough that a provisional answer would mislead. In that case, stop the dependent recommendation and explain what information is needed. Offer a useful adjacent artifact only if it preserves the limit: a fact checklist, a summary of supplied options, or a question to take to the responsible person.

Do not repeat the same question endlessly after the reader says they do not know. Distinguish “not yet answered” from “not available.” The latter requires a boundary or a change of task.

Before asking, check the conversation and the relevant supplied document. If Daniel's invitation states the duration, do not ask again unless another statement conflicts with it. If the proposal names the approver, ask about attendance rather than making Daniel restate the whole approval process.

Keep the source of a fact visible during authoring. A reader's statement, a supplied draft, and your inference are different kinds of information. If the meeting invitation is old, the skill may need to confirm whether it still applies.

When a reader corrects an answer, update every affected part of the output. A changed duration should affect timing; a changed decision-maker may affect the meeting's purpose. A clarification that does not change anything can reveal a needless question or a failure to use the reply.

For each supported task, give the skill this author-specific sequence:

1. Identify the requested output and facts already supplied.
2. Compare those facts with the required-context table.
3. Ask the smallest useful question that resolves a blocking gap.
4. Use the answer before completing the dependent part.
5. If the fact is unavailable, produce only the permitted partial result or explain why the task must pause.
6. Keep unresolved facts visible in the final output.

The sequence is a design proposal. Whether a particular skill follows it requires actual testing in the environment where readers will use it.

Prepare a complete-input case where the skill should proceed without interrogation. Then remove the decision-maker, change a confirmed fact into an estimate, and supply conflicting durations. Write the expected differences before running the cases.

Add a conversation where the reader corrects an earlier answer. Inspect the final agenda for stale assumptions. Retain the complete exchange, because a final document alone may hide whether the skill asked an appropriate question or ignored an answer.

The agent skill testing guide covers real execution checks. Your context table tells the reviewer what good behavior means for your method.

To develop this part of your author skill, bring one output, its required-context table, and two incomplete reader requests to Skillfully. Choose Book onboarding to discuss the judgments your intake needs to preserve.