Agent Skills: Ask Me Command

Verbalized Sampling (VS) protocol for deep intent exploration before planning. Use when starting ambiguous or complex tasks, when multiple interpretations exist, or when you need to explore diverse intent hypotheses and ask maximum clarifying questions before committing to an approach.

UncategorizedID: OutlineDriven/odin-claude-plugin/askme

Install this agent skill to your local

pnpm dlx add-skill https://github.com/OutlineDriven/odin-claude-plugin/tree/HEAD/skills/askme

Skill Files

Browse the full folder contents for askme.

Download Skill

Loading file tree…

skills/askme/SKILL.md

Skill Metadata

Name
askme
Description
Verbalized Sampling (VS) protocol for intent exploration before planning, mode-aware. Default `exhaustive` runs full VS; `collaborative` runs tip-sharing dialogue; `adversarial` walks the design tree one fork at a time. Auto-detects from phrasing ("help me refine" → collaborative, "poke holes" → adversarial); override via `/askme adversarial|collaborative|exhaustive`. Use for ambiguous tasks or maximum clarifying questions before committing.

Ask Me Command

Before proceeding to ask planning questions, you must proactively and critically execute both Verbalized Sampling (VS) and exploration:

  • For Verbalized Sampling, sample multiple intent hypotheses, assign each an explicit probability weight (0–1 scale), and identify the specific observation or scenario that would falsify each before selecting a direction. Each hypothesis names which operation (compress / extend / correct) and the rejection category it must avoid (overkill, monkey-patching, overcomplication). Expand hypothesis depth as ambiguity, risk, or architectural surface grows; keep it concise when scope is truly narrow. Explore meaningful edge cases until additional cases stop changing the decision; broaden sampling if no clear leader emerges. Surface decision points early with concrete options and trade-offs. Synthesize surviving hypotheses into one consolidated direction before responding. Output should stay compact and decision-oriented: intent summary, assumptions, and focused questions. Do not proceed on non-trivial changes without visible VS.

Required VS Output Format:

1. [Weight: 0.42] hypothesis here
   - Falsifier: [observation or scenario that would invalidate this]

2. [Weight: 0.28] hypothesis here
   - Falsifier: [observation or scenario that would invalidate this]
  • For exploration, deliberately seek out unconventional, underexplored, and edge-case possibilities relating to the user's objective, drawing on both the provided context and plausible but non-obvious requirements. Include at least 3 edge cases (at least 5 if architectural), and stop expanding once additional cases no longer change decisions.

Only after completing both critical VS and exploration steps, proceed to use the question tool to ask the maximum possible number of precise, clarifying, and challenging planning questions that holistically address the problem space, taking into account uncertainty, gaps, and ambiguous requirements.

Modes [LOAD-BEARING]

askme is intentionally one skill with three modes (not split into per-mode skills); callers without a mode arg get exhaustive (the original VS protocol) unchanged. The body above describes exhaustive; the two new modes share the AskUserQuestion contract and antipattern guidance below but differ in posture.

Mode-selection (hybrid)

Auto-detect from invoking-context phrasing, with slash-arg override:

  • User wording matches help me refine, walk through with me, let's brainstorm, share tipscollaborative.
  • User wording matches poke holes, stress-test, grill, find weaknessesadversarial.
  • Anything else, including no qualifier → exhaustive (current VS behavior; backward-compatible default).
  • Explicit override: /askme exhaustive, /askme collaborative, /askme adversarial. The override always wins over auto-detect. Callers that invoke without any mode arg get exhaustive — zero behavior change for existing invocations.

exhaustive mode

The VS-shaped protocol described above. Sample multiple intent hypotheses, assign weights, identify the falsifier per hypothesis, then fire the maximum-cardinality clarifying question batch. This is the default when no other signal fires.

collaborative mode

Two-way tip-sharing dialogue. Surface one of your own observations / tips back to the user as a counter-tip per round; let depth emerge through exchange. No scoring, no ranked sample. Use when the user is exploring a problem space rather than approaching commitment, or when their wording explicitly invites collaboration. Stop when the user signals convergence.

adversarial mode

Walk the design tree one fork at a time. Per fork: state the question, recommend an answer with one-sentence rationale, wait for the user, do not proceed on assumed answers. Resolve dependencies parents-first; do not descend into children while a parent is unresolved. Stop conditions: every fork has a committed answer, a blocking unknown surfaces, or the design dissolves under questioning.

Escalation triggers (collaborative → adversarial)

Promote from collaborative to adversarial mid-session when any of these fire:

  • Ambiguity cardinality ≥ 2 valid architectural decisions surface from a single user message; force a fork.
  • Unspecified file paths — the user references "the function" / "that file" without a concrete path; demand resolution before continuing.
  • Missing success criteria — the user describes a goal without a verifiable signal of done; surface the gap.

Sources: signal patterns documented in Cursor Plan Mode best practices and the NeurIPS 2025 Multi-Agent Clarification (MAC) paper. Treat as guidance, not a hard rule — the user can always override mode via slash-arg.

Mode interactions with the VS preamble

The VS preamble (sample, weight, falsifier-per-hypothesis) is required only in exhaustive mode. collaborative does not run VS — it foregrounds dialogue. adversarial runs VS once at the start to map the design tree, then proceeds per-fork.

AskUserQuestion tool contract (Claude Code reference)

This protocol assumes a single "ask user" tool with the contract below. Other agent harnesses (Codex, Gemini CLI, Aider, OpenAI Assistants, …) should map their equivalent question/prompt tool to this surface — field names and numeric limits below are Claude Code's AskUserQuestion; the shape is what the protocol depends on, and the (Recommended) convention is what the per-axis pick semantics rest on.

Antipattern: override-checklist UI [LOAD-BEARING]

Bad shape — never generate this:

Which of these defaults should I override before I lock in the plan?
❯ 1. [ ] Diff-only mode
  2. [ ] Include root prompts
  3. [ ] system-prompt-baseline.md wins on conflict
  4. [ ] Bump plugin manifests

This is a single multiSelect: true question where unticked = "default stands". It collapses four independent axes into one checkbox list. Never generate this shape.

Correct shape — one single-select question per axis:

Q1 — Scope (single-select)
❯ Diff-only mode (Recommended) — propagate only recently-new baseline
  Full block alignment — full sweep across all blocks

Q2 — Roots (single-select)
❯ Skip root prompts (Recommended) — derivative artifacts
  Include root prompts — also touch ODD/{GENERIC,COMPACTED,MINIMAL}

Q3 — Conflict policy (single-select)
❯ Preserve target policy (Recommended) — non-conflicting only
  system-prompt-baseline.md wins — override divergent target policy

Q4 — Manifests (single-select)
❯ Skip bump (Recommended) — sibling-harness scope
  Bump minor — semver per system-prompt-baseline.md memory note

Positive routing rule: When the brief calls for the user to rarely have to type, route the intent into N per-axis single-select questions (≤4 per fire) — each axis's (Recommended) option carries the default. Ticking (Recommended) is accepting the default.

Never use multiSelect for axis-with-default override semantics. Reserve multiSelect strictly for additive picks (feature toggles, optional sub-tasks).

Per fire (one tool call):

  • questions array — minItems: 1, maxItems: 4. All questions in the array render as one batched UI; one user round-trip per fire.

Per question:

  • question — full sentence ending in ?
  • header — short chip label, ≤ 12 characters
  • multiSelect — boolean (default false). false = single-pick (mutually exclusive options); true = subset of additive items (feature toggles, optional sub-tasks)
  • options — array, minItems: 2, maxItems: 4

Per option:

  • label — 1-5 words; the chip text the user sees and ticks. Mark the recommended choice by appending (Recommended) to its label and placing it first in the array.
  • description — explanation of the trade-off / consequence; the one-sentence rationale lives here.
  • preview — optional rendered content (markdown, monospace box). Single-select only (tool constraint). Use for visual comparisons (layout mockups, code diffs, file trees); skip when the difference is purely conceptual.

Built-in escapes (do not duplicate):

  • The free-text "Other" input is auto-provided on every question; never add an explicit "Other" option.
  • Users may attach free-text notes via the annotations response field.

Plan-mode caveat:

  • Use this tool only to clarify requirements or choose between approaches during planning. Do not ask "Is the plan ready?" / "Should I proceed?" — that's what ExitPlanMode is for.

askme-specific notes:

  • The "maximum possible number" of questions above is bounded by the tool's per-fire cap (4); for larger question sets, fire multiple sequential batches, ordered by dependency.
  • Render the VS block immediately before the first AskUserQuestion fire of a planning session; subsequent intra-session fires need not repeat the VS preamble unless the survivor set materially changed.

Mapping for other harnesses:

  • If the harness exposes only single-question prompts, fire them sequentially in the dependency order — the shape (clarifying questions with one Recommended each) is what matters; batching is an optimization.
  • Map (Recommended) to whatever default-marker convention the harness uses; the rationale belongs in the description body either way.
  • Map multiSelect: true to whatever multi-pick mechanism the harness exposes; if none, decompose additive picks into N independent single-selects.