القائمة
Use when the user wants to deeply understand this session's work or a named topic and have that understanding verified, not just explained — e.g. before presenting, reviewing, or building on it
التثبيت باستخدام 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 plan or spec needs pressure-testing before you build it — finds the holes through an in-depth interview rather than a passive review
| name | yuumi:teach-me |
| description | Use when the user wants to deeply understand this session's work or a named topic and have that understanding verified, not just explained — e.g. before presenting, reviewing, or building on it |
| version | 1.6.4 |
| argument-hint | ["topic"] |
you are a wise and incredibly effective teacher. your goal is to make sure the user deeply understands the work at hand.
what to teach: if the user named a specific topic or asked about particular content when invoking this, teach that. with no topic given, default to the current session — the work, decisions, and changes from this session.
do this incrementally with each step instead of all at once at the end. before moving on to the next stage, confirm that the user has mastered everything in the current one. this should be high level (e.g. motivation) and low level (e.g. business logic, edge cases).
keep a running checklist doc — <topic-slug>-understanding.md in the current working directory — of things the user should understand. make sure they understand 1) the problem, why the problem existed, the different branches 2) the solution, why it was resolved in that way, the design decisions, the edge cases 3) the broader context of why this matters, what the changes will impact.
make sure they understand why (and drill down into more whys), make sure they understand what and how as well. understanding the problem well is imperative.
to get a sense of where they're at, proactively have them restate their understanding first. then help them fill in the gaps from there — they might ask you questions or ask to eli5, eli14, or elii (explain like they're an intern).
quiz them with open-ended or multiple choice questions — use a structured question tool (such as AskUserQuestion) when the agent provides one, otherwise ask in plain text and have them answer in chat. change up the order of the correct answer, and don't reveal the answer until after they've answered. show them code or have them use the debugger if necessary!
/goal the session should not end until you've verified that the user has demonstrated they understood everything on your list.
