メニュー
Use when a plan or spec needs pressure-testing before you build it — finds the holes through an in-depth interview rather than a passive review
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when the Kickbacks/vibe-ads ad extension owns the Claude Code statusline and the user wants the Yuumi Tokyo Night statusline back WITHOUT removing the ad — installs a combined HUD+ad statusline and locks it against the extension's rewrites (Claude Code only; macOS/Linux)
Agree on domain, package location, responsibility, and function signatures before implementing — sketch the skeleton, record a design note, hand off code to yuumi:implement. Invoke by hand.
Use when a document carries inline {curly-brace} edit notes to apply in place, or when scattered edits across long drafts or multiple files must stay consistent — no copy-paste round-trips
Use when a file, endpoint, module, system, concept, or change (a PR, branch, or diff) needs to be genuinely understood, not skimmed — renders a single-file Anthropic-style HTML explainer that installs a mental model in one read; add a comprehension quiz when the user wants their understanding verified ("a quiz I must pass")
Use when implementing a spec whose reviewer will need the decision trail — resolved ambiguities, deviations, tradeoffs, open questions — not just the diff; keeps a running single-file HTML decision log alongside the code
Use when a deliverable should be a polished single-file HTML page — a report, explainer, design note, comparison, or anything too long or too visual for chat — rendered in the warm editorial Yuumi visual system
| name | yuumi:interview |
| description | Use when a plan or spec needs pressure-testing before you build it — finds the holes through an in-depth interview rather than a passive review |
| version | 1.6.4 |
| argument-hint | ["plan"] |
Read the plan file $1 and interview the user about it in depth: technical implementation, UI & UX, concerns, tradeoffs, edge cases — anything that materially shapes what gets built. If no file is given, interview about the plan under discussion in the conversation; if there is none, ask for the file path before starting.
The questions must not be obvious. A question earns its slot when the plan does not already answer it and the answer would change the work. Mine where plans usually stay silent:
Ask with a structured question tool (such as AskUserQuestion) when the agent provides one; where none exists, ask in plain text as a short numbered list. Either way: small rounds (2–4 questions), never re-ask what an earlier answer settled, and let each round build on the last.
Continue until the interview is genuinely complete: every major decision has an answer and a fresh round from a new angle (implementation, UX, failure, operations, scope) surfaces nothing new. Don't stop early because several rounds have passed; don't pad rounds to look thorough.
Then write the refined spec back into the plan file itself — that file remains the single source of truth the user builds from. Fold the answers into the document's own structure; do not append a Q&A transcript. Close by telling the user what materially changed.
