القائمة
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.
