Ask User — Choice Gate Pattern

Contract

• Present 2-4 options (no more — decision paralysis kicks in past 4).
• Always include an escape hatch (Skip, Cancel, or "none of these").
• Stop the turn immediately after presenting choices. No follow-up tool calls, no preemptive action, no default-and-proceed.
• The user's response triggers the next turn. Acknowledge briefly, then branch.
• One question per message — never stack multiple choice gates.
• Self-explanatory option labels: action verb plus brief qualifier, not "Option 1".

What This Is

A formalized pattern for presenting users with 2-4 options and stopping execution until they respond. This is the canonical way to gate on user input in any GBrain-powered agent.

This is NOT a traditional async/await. In an LLM agent, "gating" means:

1. Present the choices (buttons or numbered options)
2. Explicitly stop the current turn (do not proceed)
3. The user's response triggers the next turn
4. Read the response and branch accordingly

When To Use

• Ambiguous requests with multiple valid interpretations
• Destructive operations (bulk deletes, overwrites)
• Filing/routing decisions ("where should this go?")
• Priority triage ("which should I do first?")
• Cold-start phase gates ("ready for the next import source?")
• Any fork where the wrong default wastes significant work

When NOT To Use

• Clear, unambiguous instructions → just do it
• Low-stakes decisions → pick the best option and mention it
• Time-critical operations where delay costs more than a wrong choice
• When the user has already expressed a preference

How To Present Choices

Platform-agnostic format (works everywhere)

Present choices as a clear question with numbered or labeled options:

🔀 **How should I handle this?**

[context about the decision — 1-3 lines max]

1. **Option A** — short description
2. **Option B** — short description
3. **Option C** — short description
4. **Skip** — do nothing for now

With inline buttons (Telegram, Discord, Slack)

If the platform supports interactive buttons, use them:

{
  "message": "🔀 **How should I handle this?**\n\n<context>",
  "buttons": [
    { "label": "Option A — description", "value": "option_a" },
    { "label": "Option B — description", "value": "option_b" },
    { "label": "Skip", "value": "skip" }
  ]
}

With the clarify tool (OpenClaw agents)

Some OpenClaw agents have a built-in clarify tool that presents choices natively:

clarify(
  question: "How should I handle this?",
  choices: [
    "Option A — description",
    "Option B — description",
    "Option C — description",
    "Skip for now"
  ]
)

Constraints

• 2-4 options max. More than 4 creates decision paralysis.
• Labels must be self-explanatory. The user shouldn't need to re-read context.
• Always include an escape hatch. At minimum: "Skip" or "Cancel" as the last option.
• One question per message. Never stack multiple choice gates.

How To Gate (CRITICAL)

After presenting choices, you MUST stop your turn. Do not:

• ❌ Continue with "while you decide, I'll start on..."
• ❌ Pick a default and proceed
• ❌ Send follow-up messages before the user responds
• ❌ Make assumptions about which option they'll pick

Instead:

• ✅ End your message with a brief note that you're waiting
• ✅ Stop. Full stop. No more tool calls.

How To Handle The Response

When the user responds:

1. Read the response — button click, number, or text
2. Acknowledge briefly — "Got it, going with Option A."
3. Branch and execute the chosen path
4. If unclear, ask again

Handling text responses

Users sometimes type instead of clicking. Handle gracefully:

• "the first one" / "A" / "1" → map to first option
• "merge" → fuzzy match against option labels/values
• "actually, none of those" → present alternatives or ask what they want
• Unrelated message → the user moved on; drop the gate

Formatting Guidelines

Question line emoji prefix

Signal the decision type:

• 🔀 Routing/filing decisions
• ⚠️ Destructive/risky operations
• 🎯 Priority/triage decisions
• 💡 Creative/strategic forks
• 📋 Workflow/process choices
• 🔐 Credential/security decisions

Context block

1-3 lines maximum. The user should understand the decision in under 5 seconds.

Button/option labels

Format: Action verb — brief qualifier

• ✅ "Merge — combine with existing page"
• ✅ "Create new — separate meeting page"
• ❌ "Option 1"
• ❌ "Click here to merge the content into the existing brain page"

Examples

Cold-start phase gate

📋 **Phase 2: Google Contacts**

I can import your Google Contacts to seed the people/ directory.
This creates a brain page for each real contact (~200 pages).

1. **Import via ClawVisor** — secure credential gateway
2. **Import via direct OAuth** — simpler, agent holds tokens
3. **Import from Google Takeout export** — offline, from file
4. **Skip** — move to the next phase

Filing decision

🔀 **Where should this go?**

Meeting notes from call with Jane Smith. She already has a page at
people/jane-smith.md and there's a deal page at deals/acme-corp.md.

1. **Merge into Jane's page** — add to her timeline
2. **Add to Acme deal page** — this was primarily a deal discussion
3. **New meeting page** — standalone at meetings/2026-01-15-jane-acme.md
4. **Skip** — don't file this

Destructive operation

⚠️ **About to delete 847 stale cache files (2.3 GB)**

These haven't been accessed in 90+ days. They can be re-fetched
but that takes ~4 hours.

1. **Delete them** — free up space now
2. **Archive first** — upload to cloud storage, then delete
3. **Keep them** — no changes
4. **Show me the list** — let me review before deciding

Integration With Other Skills

This pattern is used by:

• cold-start — phase gates for each import source
• ingest — routing decisions for ambiguous content
• enrich — merge vs create decisions for entity pages
• brain-ops — filing location decisions
• meeting-ingestion — where to file meeting notes
• archive-crawler — scan vs full ingestion gate

When building a new skill that needs user input at a decision point, reference this pattern rather than inventing a new one.

When it fails

Follow the agent operator protocol for any gbrain error code, exit code, [AGENT] block or notice block. Specific to this skill:

• A gbrain call exited 3 (confirmation_required) or its fix.next is ask_user: this skill is the gate. Relay the [SHOW USER] block or user_message verbatim as the choice, then stop until the user answers.
• The user answered "no" or did not answer: report the step as skipped. Never pass --yes or --max-usd on their behalf to move on.

Anti-Patterns

• Continuing the turn after presenting choices. "While you decide, I'll start on..." defeats the gate. Stop. Wait. The whole point is that the user controls what happens next.
• Picking a default and proceeding silently. If the question matters enough to ask, it matters enough to wait. Silent defaults erode trust the next time you do ask.
• More than 4 options. Decision paralysis is real. Group, summarize, or split into staged questions instead.
• No escape hatch. Every choice gate must let the user decline. "None of these" / "Skip" / "Cancel" is mandatory.
• Stacking multiple choice gates in one message. The user can only answer one question per turn. Multi-question gates either get half-answered or dropped entirely.
• Cryptic option labels. "Option 1" forces re-reading the context. "Merge into existing page" is self-explanatory.
• Asking about low-stakes decisions. If the wrong answer costs nothing, just pick the best option and mention it. Reserve gates for forks where rework is expensive.

Output Format

The skill's "output" is the choice-gate message itself, structured as:

{emoji-prefix} **{question}**

{1-3 lines of context}

1. **{Option A label}** — {short qualifier}
2. **{Option B label}** — {short qualifier}
3. **{Skip / Cancel}** — {what skipping means}

After emitting this, the skill stops the turn. No further tool calls, no preemptive action, no follow-up message until the user responds. The user's response triggers the next turn, where the calling skill branches on the chosen option.