/ulw-interview

name: "ulw-interview"
description: "[omh] Vague, underspecified request: one-question-at-a-time clarification. Use when the user says: deep-interview, interview me, clarify, feature shaping, ambiguous product request, one question, 要件を詰めて, 曖昧な要求."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, clarification]
    category: clarification
    phase: discovery
    role: planner
    quality_tier: clarity-gated

Deep Interview

This is a Hermes-native `deep-interview` workflow skill.

Why This Exists

`deep-interview` exists to stop Hermes from guessing through ambiguous product, workflow, or implementation intent; it converts uncertainty into a clarified brief before planning or handoff.

Do Not Use When

• The request already has concrete scope, acceptance criteria, and verification commands.
• The missing information is discoverable from the repository or local artifacts without asking the user.
• The user asked for immediate read-only analysis and the ambiguity does not change the answer.
• The ambiguity is specifically repository terminology or project-language alignment; use `context` and its direct-lookup/frontier boundary.
• The open question is answerable by a small reversible experiment rather than another interview round; use `decision-prototype`.

Examples

Good example:

• Prompt: $deep-interview before planning Discord and Slack routing, ask what each channel owns and what evidence counts.
• Expected behavior: Ask one decision-changing question at a time, then produce goals, non-goals, and acceptance criteria.
• Why: The request explicitly rejects assumptions and needs product boundaries before implementation.

Bad example:

• Prompt: $deep-interview fix this failing test; the traceback and expected behavior are attached.
• Expected behavior: Proceed to diagnosis or implementation instead of interviewing.
• Why: The required facts are already available, so more questions would slow the workflow.

Completion Checklist

• The clarified brief names goals, non-goals, constraints, and one next planning or handoff path.
• Remaining ambiguity is listed only when it changes the plan, risk, or stop condition.
• No implementation handoff is prepared until the blocking decision is resolved.

Recovery Notes

• If an answer surfaces new ambiguity, file it under one of the three clarity dimensions and keep asking only while the round budget allows; once round 6 is reached, record the rest as assumptions and plan.
• If repo evidence can answer the question, inspect it before asking the user.

Workflow Lane

• Current lane: **Intent -> plan** (`oh-my-hermes`, `meta-router`, `deep-interview`, `context`, `plan`, `ralplan`, `adversarial-consensus`, `codebase-onboarding`, `+8 more`) - clarify, plan, ship, or loop goals.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Interview Round Protocol

This interview is bounded: at most 6 rounds, one question per round.

Before each question, find the most recent round header you emitted in this thread and add 1. If there is no header, you are at Round 1. If you have already asked questions here but cannot recover the number (for example after context compaction), do not restart at Round 1 — run the mid-interview check now and continue from Round 4.

**Every question is preceded by this header on its own line, then a blank line, then the question:**

Round {n}/6 · Clarity: {percent}% ({resolved}/3) · Targeting: {dimension}

• Clarity is scored against exactly three fixed dimensions: **outcome** (what is true when this

is done), **constraints and non-goals** (what bounds the work), and **success criteria** (how anyone would verify it). `{resolved}` counts how many you could restate in one sentence without a qualifier. The denominator is always 3; `{percent}` is 0, 33, 67, or 100.

• `{dimension}` names the unresolved dimension this question targets — the one that most

changes the plan, not the easiest one.

• A new concern raised in an answer files under one of the three dimensions. It never extends

the denominator and never extends the round budget. Once the budget is spent, record it as an assumption instead of asking about it.

**Voice — the header is instrumentation; the question is a conversation.**

• Never fold counters, ratios, or dimension names into the question sentence.
• Ask the way a senior colleague would ask out loud: one sentence, no preamble, no restating

what the user just said, no numbered sub-questions. If it reads like a form field, rewrite it.

• Outside the header line, the user never hears the words round, budget, dimension, or resolved.
• Mirror the user's language in the header labels and the question. Korean header:

`라운드 {n}/6 · 명확도: {percent}% ({resolved}/3) · 확인 중: {목표/제약과 비목표/성공 기준}`. Never mix languages in one message.

• The clarified brief follows the same rule: write its headings and labels in the user's

language. Translate those terms, never transliterate them.

**Answer options — every question ships with candidates.**

After the question sentence, offer the likely answers as a short numbered list: two to four real candidates, then one final free-input entry. Each candidate is an answer the user could actually pick — drawn from the request, repo evidence, or the tradeoff the question is really about, never filler to reach a count, and never a candidate whose text is itself a bare number (it would collide with reply-by-number). The last entry is always the open door, in the user's language — for example English `N) Something else — type your answer`, Korean `N) 기타 — 직접 입력`.

• A number, an option's own words, or a completely different free-text answer are all valid;

free text is always accepted, even when it matches no option. Never re-ask because the reply was not a listed option.

• Options mirror the user'