القائمة
Learn a topic in-session — taught from trusted resources, verified with a tight feedback loop, recorded as evidence of understanding.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | teach |
| description | Learn a topic in-session — taught from trusted resources, verified with a tight feedback loop, recorded as evidence of understanding. |
| disable-model-invocation | true |
| argument-hint | What would you like to learn about? |
The user asked you to teach them something. This is a light, on-demand capability — one topic, in-session, conversational. You are the architect and the teacher: teaching is interaction, not code work, so you do it yourself (no worker dispatch). Do NOT build a persistent lesson workspace (no HTML lessons, no asset library, no print machinery) — that weight is out of scope. Produce understanding, verify it, record the evidence — the four steps below, every time.
Before explaining anything, know why the user wants this — the real-world outcome, not "to understand X". If it's obvious from $ARGUMENTS, state it back in one line and move on. If it's vague, ask once (interview them), then proceed.
If the topic is large, pick the smallest slice that serves the mission and sits in the user's zone of proximal development (challenging, not overwhelming). One tangible win per pass.
When the user wants the mission durable across sessions, read references/mission-format.md.
Never trust your parametric knowledge. Ground the explanation in high-quality, high-trust resources: fetch current docs (use the ctx7 CLI / find-docs for any library, framework, API, or tool), cite primary sources, and surface links so the user can verify.
Teach only the knowledge the win requires — no encyclopedia. Keep it tight, concrete, and scannable. Recommend ONE primary source (the best resource you found) for the user to read or watch after.
The Knowledge / Skills / Wisdom split — and the difficulty inversion that separates them:
Fluency ≠ storage strength. Fluency (smooth in-the-moment recall right after seeing something) gives an illusion of mastery; storage strength (long-term retention) is the goal. The lever that builds it is desirable difficulty: retrieval practice (recall from memory, not recognition), spacing (revisit over time), interleaving (mix related topics — skills practice only). Match your teaching mode to the topic: theory leans knowledge, a craft leans skills.
Understanding is proven by retrieval, not by nodding along. After teaching, run an immediate feedback loop — a quiz question or a small task — where the user recalls or applies, and you give feedback immediately.
Quiz anti-cueing rule (mandatory): every answer option must be the same word count and, where possible, the same character count — no length tells, no formatting tells (no bolding one option, no punctuation that flags the answer). The distractors must be as plausibly-shaped as the correct answer, or the quiz tests test-taking, not understanding.
Prefer questions that force recall from memory over ones the user can recognize. If they miss, re-teach the specific gap and loop again — don't move on over a shaky foundation.
When the user demonstrates real understanding (answers correctly under retrieval, completes the task, corrects a prior misconception, or discloses solid prior knowledge), record it as evidence — a learning record. This is the evidence ledger that sets the floor for what to teach next and prevents re-teaching what's known. Format and the "what does NOT qualify" bar (coverage is not learning) are in references/learning-record-format.md.
If the topic has its own nomenclature, maintain a tight glossary as the user's understanding compresses — one canonical term per concept, aliases listed under _Avoid_. Format in references/glossary-format.md. Add a term only once the user can use it correctly — the glossary is a record of compressed understanding, not a dictionary to read.
Teaching is a side-path, not a work-session stage — it has no lifecycle successor. End by presenting an AskUserQuestion (one question) that restates the teaching pass is done and offers to continue:
/dobby:<stage>.On the user's selection, act on it directly; when the choice is a /dobby:<skill>, invoke it via the Skill tool (chaining runs on the session's current model/effort). "Stop here" ends the turn.
Interact with the user in their language. Write any durable artifacts (mission, glossary, learning records) in English, keeping domain terms in their real-world form.
/dobby:<skill> invoked through the Skill toolAdapted from mattpocock/skills productivity/teach.
Cut an npm release of @kvnwolf/dobby from the main checkout — inferred bump, raw-TS tarball gate, publish, tag, GitHub release with changelog.
Syncs documentation, authors the commit message + PR body, runs the gate and performs the git/gh ceremony directly (stage → `dobby check --fix` → commit → push → PR), then monitors the PR to a verdict. Use when committing code, finishing a task, pushing changes, or creating a PR.
One-pass migration of a consumer repo off vite-plus onto @kvnwolf/dobby — swap deps, thin `tsconfig.json` and delete the now-default tool configs (biome/vite/vitest/drizzle, kept only for real deltas), move files to canonical paths, regenerate dobby.config.json, drop .conductor, rewire CI + Vercel build, verify with `dobby check`. Run in a consumer repo, once, after updating the dobby plugin.
Set up a repo (greenfield or existing) for the work skills — interview, install @kvnwolf/dobby, scaffold the base files + thin tsconfig, write the dobby.config.json contract. Run once.
Disciplined diagnosis loop for hard bugs — build a fast deterministic feedback loop, rank falsifiable hypotheses, instrument one variable at a time. Use when something is failing, a bug is intermittent or non-obvious, or there's a performance regression.
Dispatch a scoped, ad-hoc task to a worker agent (or a few in parallel) and review what comes back — without the full /dobby:execute plan-and-waves ceremony. Use for a small fix or change, or a bounded investigation, when you don't need a STATE.md spec.