user-feedback

name	user-feedback
description	Strategic guidance for the ask_user tool (UserFeedbackTools) — when to pause and ask the user structured questions, how to design options, anti-patterns to avoid, and how to behave after the run resumes. Load this skill before calling ask_user whenever you need to clarify intent, resolve a trade-off, or collect a preference that genuinely shapes your next action.

User Feedback (ask_user)

When to load this skill

Load this skill (via get_skill_instructions("user-feedback")) BEFORE you call ask_user for the first time in a run. If you have already loaded it this run, you do not need to load it again.

The core decision: ask or not?

Call ask_user ONLY when ALL of these are true:

1. The answer genuinely shapes your next action. If you can proceed either way without material difference, don't ask.
2. You cannot read the answer from your context. Check the DB, user profile, entity memory, decision log, learned knowledge, and conversation history first. If the answer is already there, use it.
3. The question has meaningful trade-offs or genuine ambiguity. A binary "yes/no" where you should just proceed is not a trade-off.

If any of these are false, do NOT call ask_user. Proceed with your best judgment and explain your assumption.

Think before you ask

Before calling ask_user, use think() (if available) to plan your questions:

• What specifically is ambiguous?
• What are the realistic options for each ambiguity?
• How few questions can I ask while still resolving the ambiguity?
• Can I collapse two questions into one?

Designing the questions

Count

• Ask 1-2 questions by default. Ask a 3rd only if all three are genuinely independent and each shapes a different decision.
• Never ask more than 3 questions in one ask_user call. If you need more, you haven't thought enough — re-plan.

Options

• 2-4 options per question. Two is ideal when the choice is binary; four is the max.
• Each option label is 1-5 words. Each option description (optional) is one short sentence explaining what the option means.
• Options must be mutually distinct — if two options could lead to the same outcome, merge them.
• Order options from most likely / most conservative to most aggressive / most exploratory. Don't randomise.

multi_select

• Use multi_select: true ONLY when the choices are not mutually exclusive (e.g. "which activities?" — hiking AND museums both ok).
• Use multi_select: false (default) when picking one option precludes the others (e.g. "which timeline?" — 1 month OR 3 months, not both).

header

• Max 12 characters. A short label, not a sentence.
• Examples: "Timeline", "Scope", "Priority", "Approach".

question text

• Must end with a question mark.
• One question per AskUserQuestion — never compound questions ("Which timeline and who owns it?" → two questions).

The "Other" fallback

The frontend presents a synthetic "Other (type your own)" option for every question. The user can type a free-text answer that doesn't match any predefined label. Design your options knowing this:

• Don't add an option like "None of the above" — the "Other" fallback covers it.
• Don't try to enumerate every possibility — 2-4 well-chosen options + "Other" is better than 6 options.
• If the user's "Other" answer is vague, you may ask one follow-up ask_user to narrow it — but only once.

After the user answers

1. Use the answers. Incorporate them directly into your next action. Do not re-ask the same question.
2. Don't narrate the asking. Don't say "Thanks for answering!" or "Based on your selection..." — just proceed. The user knows what they picked.
3. If the answer changes your plan, say so briefly — one sentence ("Going with the 3-month timeline — adjusting milestones accordingly.") then proceed.
4. You may ask again if a genuinely new ambiguity surfaces after the first answer. But if you're asking a 3rd time, consider whether you should just proceed with your best judgment instead.

Anti-patterns (do NOT do these)

• Asking for info you already have. Check memory, DB, profile, history first.
• Asking "Are you sure?" or "Do you want to proceed?" — just proceed. If the action is destructive, that's a confirmation flow, not ask_user.
• Asking 4+ questions in one call. Re-plan or proceed with assumptions.
• Asking the same question twice (in one run or across pause cycles).
• Options that are not distinct ("Fast" / "Quick" / "Rapid" — merge).
• Using ask_user as a progress indicator ("I'm about to decompose your goal — ready?"). It's for resolving ambiguity, not narrating progress.
• Asking when the user's message was already specific. If they said "3-month timeline, focus on milestones 1-3", don't ask about timeline or scope.

Domain-specific filters

Each agent that loads this skill has its own domain. Apply your domain knowledge to the "when to ask" decision:

• Goal Coach: ask about timeline horizon, decomposition granularity, which milestone to tackle first — only when the user hasn't specified and the choice changes the decomposition structure.
• Agno Support: ask to disambiguate which meaning of a term the user intends (e.g. "sessions" = storage vs memory vs history) — only when the term is genuinely polysemous in the Agno docs.