Communitygithub.com

AlemTuzlak/skills — 實證導向課程產生器

當使用者想要從頭深入學習一個新主題時使用。會進行預先訪談(當前知識、最終目標熟練度、深度、練習負荷、背景、範圍),線上研究(文章、利基影響者部落格、權威文件、子主題地圖),然後產生結構化的 Markdown 課程,其中包含強制性的視覺圖表、基於證據的學習科學功能(提取練習、間隔回顧、工作範例淡出、概念記錄、術語閘門、類比衛生),以及一個自包含的互動式 HTML 迷你課程。觸發詞為 /teach-me、「教我關於 X」、「我想學 X」、「深入探討 X」、「為我建立一個關於 X 的課程」、「和我一起學習 X」。

skills — 實證導向課程產生器 是什麼?

這個技能是一個全面的證據導向課程產生器,專為希望從頭開始深入學習任何主題的成人學習者設計。它基於紮實的認知心理學與教學設計研究,實施了 13 條嚴格的教學規則,包括具體先於抽象、提取練習、間隔暴露、工作範例淡出、認知負荷理論、分割/卡片、圖表優先的視覺連貫性、類比衛生、術語閘門、受限制的自我解釋提示、B1 閱讀者適用的平實語言、建立在學習者已知知識的基礎上,以及用狀態序列圖取代敘述。該技能支援 Claude Code,並透過多階段流程運作:首先進行結構化的預先訪談以了解使用者的知識水平、目標和偏好;然後執行四個並行研究代理(權威內容、利基影響者、權威參考資料、子主題地圖);接著產生一個大綱,讓使用者選擇章節;最後以平行批次產生章節,並進行一致性檢查。最終產出包含一個結構化的 Markdown 課程和一個自包含的互動式 HTML 迷你課程,所有內容都儲存在指定的輸出位置。

相容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/AlemTuzlak/skills/tree/HEAD/skills/teach-me

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

/teach-me — 實證導向課程產生器

為任何使用者想學習的主題,產生一個自定進度的 Markdown 課程 + 自包含的 HTML 迷你課程。專為成人學習者設計(CEFR B1 閱讀等級,無需先備知識),基於認知心理學和教學設計研究。

何時使用

  • 使用者呼叫 /teach-me <主題>(或不帶參數 — 詢問主題)
  • 使用者說「教我關於 X」、「我想學 X」、「深入探討 X」、「為我建立一個關於 X 的課程」、「和我一起學習 X」
  • 跳過以下情況:快速事實問題(「什麼是 X」— 直接回答)、程式碼幫助、除錯、文件查詢、程式庫 API 問題(改用 context7)

教學法基礎(開始工作前請閱讀)

這個技能建立在經過充分驗證的學習科學之上。以下的規則不是可協商的預設值 — 它們是使用者付出的代價:

  1. 具體先於抽象(Goldstone, Fyfe 等人)。每一章都以一個具體的可觀察實例開頭,然後才是抽象定義。
  2. 提取練習勝過重讀(Roediger & Karpicke; Rowland 2014 年後設分析)。每一章結尾都包含 3-5 個自由回憶提示 + 1 個跨章節回呼。
  3. 透過刻意回呼進行間隔暴露(Cepeda 等人 2006 年)。每個主要概念在≥2 個後續章節中被使用(而非重新定義)。
  4. 工作範例 + 向後淡出(Sweller, Renkl & Atkinson)。早期章節:完整的工作範例。中期:逐步留空的步驟。晚期:僅提供提示。
  5. 認知負荷理論(Sweller, Mayer)。每章最多約 4 個新的命名概念。一次只引入一個新的難度維度。
  6. 分割/卡片(Mayer & Pilegard)。章節由 250-500 字的卡片組成,每張卡片一個概念,每張卡片一個圖表。
  7. 圖表優先的視覺連貫性(Mayer 多媒體原則)。關係概念必須有圖表。無裝飾性圖像。標籤直接放在圖表上,而非圖例中。
  8. 類比衛生(Gentner 結構映射)。每個類比在 2 句內必須附帶一個明確的「此處類比失效」免責聲明。
  9. 術語閘門(Nathan/Koedinger 專家盲點研究)。每個技術術語在首次使用時定義,或連結到前面章節的詞彙表條目。即使是「常見」術語也不得有例外。
  10. 受限制的自我解釋提示(Chi 等人;Bisra 等人 2018 年,效果量 g≈0.55)。在卡片之間:「完成這個句子:X 之所以有效是因為 ___」,並在切換開關中提供模型答案。
  11. B1 讀者適用的平實語言。平均句子長度 ≤18 個字,最多 25 個字。每句最多一個從屬子句。被動語態 ≤10%。主動語態。第二人稱。無慣用語。
  12. 建立在學習者已知知識的基礎上(Ausubel)。預先訪談捕捉使用者的已知領域;寫作指南將其轉化為類比庫。
  13. 展示狀態變化;不要敘述它們(Larkin & Simon 1987 年;Tversky & Morrison 2002 年理解原則;Wong/Leahy/Marcus/Sweller 2012 年瞬態資訊效應;Tufte 小倍數;Mayer 的分割原則)。當散文需要逐步描述連續狀態時(「首先這樣,然後那樣,在崩潰之後…」),改用一個 2-5 個面板的 <div class="state-sequence"> 代替。每個面板形狀相同,標註差異,說明文字 = 觸發事件 + 不變量。讀者看見演化過程;他們不是在讀一個故事。

已被推翻 — 切勿使用: 學習風格(VAK)、一萬小時框架、遊戲化連續記錄/徽章、為「參與度」而使用的裝飾性圖像、「右腦/左腦」、「數位原住民」。

流程圖

digraph teach_me {
  rankdir=TB;
  "解析呼叫" [shape=box];
  "已有資料夾?" [shape=diamond];
  "輸出位置" [shape=box];
  "預先訪談" [shape=box];
  "研究(4 個並行代理)" [shape=box];
  "綜合並撰寫 OUTLINE.md" [shape=box];
  "使用者選擇章節" [shape=box];
  "撰寫 WRITING_GUIDE.md" [shape=box];
  "章節生成(並行批次)" [shape=box];
  "一致性檢查" [shape=box];
  "建立 index.html" [shape=box];
  "開啟資料夾和瀏覽器" [shape=doublecircle];

  "解析呼叫" -> "已有資料夾?";
  "已有資料夾?" -> "輸出位置" [label="否"];
  "已有資料夾?" -> "輸出位置" [label="擴充 / 全新 / 取消"];
  "輸出位置" -> "預先訪談";
  "預先訪談" -> "研究(4 個並行代理)";
  "研究(4 個並行代理)" -> "綜合並撰寫 OUTLINE.md";
  "綜合並撰寫 OUTLINE.md" -> "使用者選擇章節";
  "使用者選擇章節" -> "撰寫 WRITING_GUIDE.md";
  "撰寫 WRITING_GUIDE.md" -> "章節生成(並行批次)";
  "章節生成(並行批次)" -> "一致性檢查";
  "一致性檢查" -> "建立 index.html";
  "建立 index.html" -> "開啟資料夾和瀏覽器";
}

不要跳過任何階段。 使用 TaskCreate 追蹤進度,以便使用者看到您所在的位置。


階段 0 — 解析呼叫

  1. 從參數中取得主題。如果沒有參數,回覆:「您想學什麼主題?可以是技術性的(一個函式庫、語言、概念)或非技術性的(一個哲學、領域、技能)。」並等待。
  2. 主題驗證防護措施:
    • 如果主題是有害的(武器合成、惡意駭客目標、非法行為)— 簡短拒絕並停止。不要說教。
    • 如果主題過於寬泛(programming、science、everything)— 要求使用者用 2-3 個具體例子縮小範圍:「這非常廣泛。您想縮小到像是 'asynchronous programming patterns in TypeScript' 或 'how compilers work' 嗎?」等待更精確的答案。
    • 如果主題模糊但可處理(AI、databases)— 繼續進行;訪談中的自由形式範圍問題將進一步縮小範圍。
  3. 計算 slug:轉為小寫,將非字母數字字元替換為 -,合併重複的 -,去除前後空白。範例:Asynchronous Programming → asynchronous-programming。

階段 1 — 檢查既有資料夾

  1. 從記憶體讀取輸出位置(請參閱階段 2 了解儲存方式)。如果記憶體中尚無位置,則延後此檢查,直到階段 2 收集到位置。
  2. 檢查 <輸出位置>/learn-<slug>/ 是否已存在。
  3. 如果存在,透過 AskUserQuestion 提供三個選項:
    • 擴充 — 新增章節、使用新的風格註解重新生成特定章節,或重新整理研究並再次選擇。
    • 全新開始 — 將現有資料夾重新命名為 learn-<slug>-archived-YYYY-MM-DD/,然後繼續建立新課程。
    • 取消 — 停止。
  4. 如果選擇擴充:子選項 — (a) 新增關於新子主題的章節(跳至研究階段,以先前的 OUTLINE.md 作為上下文),(b) 使用新的註解重新生成特定章節編號(跳至撰寫階段處理這些章節),(c) 重新整理研究並重新選擇章節(完全重新執行,並合併先前的 OUTLINE.md)。
  5. 絕不破壞性地覆蓋先前的課程。

階段 2 — 輸出位置

  1. 在記憶體中搜尋帶有 teach-me-output-location 或類似標籤的條目。使用 Glob 搜尋 C:/Users/AlemTuzlak/.claude/projects/F--projects/memory/*.md 並使用 Grep 搜尋 teach-me。
  2. 如果找到且路徑仍然存在,則使用它。簡短說明:「正在寫入到 <路徑>。」
  3. 如果未找到,透過 AskUserQuestion 詢問:
    • 使用 F:/projects/learning/(如果資料夾不存在則建立)— 建議。
    • 使用當前工作目錄 (./)。
    • 指定不同路徑 — 使用者透過「其他」提供。
  4. 使用者回答後,詢問:「是否將此儲存為未來 /teach-me 執行的預設位置?」— 透過 AskUserQuestion 回答是/否。
  5. 如果是,寫入一個記憶體檔案 teach_me_output_location.md,其中包含 frontmatter type: user 和路徑內容。在 MEMORY.md 中新增一行。
  6. 現在,使用已解析的位置重新嘗試階段 1 的既有資料夾檢查。

階段 3 — 預先訪談

分兩輪詢問:

第一輪 — 一個 AskUserQuestion,包含 4 個結構化問題

Q1 [當前知識]:您對 <主題> 已經了解多少?
  - 從未聽過
  - 知道術語,但無實作經驗
  - 已經建立過基本的東西
  - 中級從業者

Q2 [最終目標熟練度]:您希望達到什麼程度?
  - 僅概念概述
  - 能夠建立基本的東西
  - 能夠建立生產品質的東西
  - 能夠教導他人

Q3 [深度預算]:您想要多少內容?
  - 快速入門(約 3-5 章)
  - 標準(約 6-10 章)
  - 深入探討(所有研究內容,10-15 章以上)

Q4 [練習負荷]:您想要多少動手練習?
  - 輕度(以閱讀為主)
  - 標準(閱讀 + 提取 + 偶爾練習)
  - 重度(每章都有工作範例和練習)

第二輪 — 一個純文字訊息回覆

傳送以下確切訊息(替換 <主題>):

在我開始研究之前,還有兩件事:

1. 您對什麼領域已經很熟悉? 列出語言、框架、領域、嗜好 — 任何您投入過大量時間的事物(例如「TypeScript, React, 音樂理論, 烹飪, 西洋棋」)。我將使用這些作為類比來源,將新概念與您已知的事物連結。

2. 對於 <主題>,有任何特定的角度要聚焦,還是要我廣泛涵蓋? 說「讓我很驚喜」以獲得完整涵蓋。

等待同時包含這兩項的單一回覆。寬鬆解析 — 接受逗號分隔的清單、項目符號清單或自由格式。

將答案持久化到一個工作結構體中(您之後會將它們寫入 OUTLINE.md 和 WRITING_GUIDE.md)。

階段 4 — 研究(4 個並行代理)

發送一個批次化的 Agent 呼叫,其中包含 4 個 general-purpose 子代理。它們會並行執行。每個代理都會收到一個自包含的簡報,並回報一個結構化的報告。

通道 A — 權威內容。 尋找關於 <主題> 的頂尖文章、教學、會議演講和論文。使用 WebSearch + WebFetch 取得訊號最強的結果。回傳 8-15 個結果,每個附帶一行「為何閱讀」的說明,標記為 [article|tutorial|talk|paper]。

通道 B — 利基影響者和實務從業者。 尋找已知在 <主題> 有深入研究的特定人士 — 不是科技名人,而是擁有自己的部落格/電子報/Twitter、並深入鑽研此利基領域的實務從業者。回傳 4-8 個結果,包含:姓名、個人媒體(部落格網址)、簽名文章網址、一行說明為何值得關注。跳過唯一產出是企業行銷內容的人。

通道 C — 權威參考資料。 官方文件、規格、參考實作、權威教科書。如果 <主題> 是一個函式庫/框架/CLI 工具,請使用 context7 MCP(resolve-library-id 然後 query-docs)取得目前的權威文件。回傳 3-8 個來源,包含版本資訊。

通道 D — 子主題地圖和規範語言。 調查主題以產生一個子主題樹,附帶一行描述(通常 8-15 個子主題)。建議一個教學順序(先備知識優先,進階內容在後)。如果主題是技術性的,確定官方文件使用/在生產環境中最常見的規範語言(例如 Temporal → TypeScript 或 Go;LangGraph → Python)。明確說明:「規範語言:X,因為 Y。」

每個代理報告在 800 字以內,結構化。在所有 4 個代理回傳後,進行綜合。

階段 5 — 大綱和章節選擇

  1. 將 <輸出位置>/learn-<slug>/OUTLINE.md 寫入以下結構:
# 學習 <主題>

## 您的目標(已記錄)
- **當前等級**:<Q1 的答案>
- **目標熟練度**:<Q2 的答案>
- **深度**:<Q3 的答案>
- **練習負荷**:<Q4 的答案>
- **已知領域(類比庫)**:<第二輪的答案,逗號分隔>
- **範圍/角度**:<第二輪的答案>

## 子主題地圖(來自研究)
1. <子主題 1> — <一行描述>
2. <子主題 2> — <一行描述>
...

## 建議順序
考慮先備知識的順序,並附上每一步的理由。

## 建議章節(約 N 章,取決於您的深度預算)
建議章節的編號清單。每個條目:短標題 + 一行說明涵蓋內容 + 估計卡片數(每章 5-9 張)。

## 規範語言(僅技術主題)
<語言和一行理由>

## 建議來源
- [來源 1](網址) — [類型] — 為何閱讀
...

## 值得關注的利基影響者
- **姓名** — [部落格網址] — 簽名文章:[文章網址] — 一行說明為何
...
  1. 自動開啟檔案:Bash code --new-window "<OUTLINE.md 的絕對路徑>"。
  2. 向使用者回覆以下確切訊息(適當替換):

我已經將大綱寫入 <絕對路徑> 並為您開啟。

請回覆要撰寫哪些章節:

  • all — 撰寫所有建議的章節
  • 1,3,5-7 — 特定章節或範圍
  • 自由格式 — 用您自己的話描述要聚焦的內容
  • reshape — 告訴我要新增、移除、合併或重新排序,然後再定案

如果您選擇 reshape,我將修改 OUTLINE.md、儲存、重新開啟,並再次詢問。重複直到確定。

  1. 如果使用者說 reshape,記錄他們的意見、修改 OUTLINE.md、儲存、重新開啟,並再次詢問。重複直到確定。
  2. 將選擇解析為最終的有序章節清單 picks = [...]。

階段 6 — 撰寫 WRITING_GUIDE.md

將 <輸出位置>/learn-<slug>/WRITING_GUIDE.md 寫入。此檔案是所有章節撰寫代理和一致性檢查代理的共享簡報。它必須全面且具體。

使用 <技能目錄>/assets/templates/WRITING_GUIDE.template.md 的範本作為起點 — 將使用者記錄的訪談答案填入佔位符({{TOPIC}}、{{CURRENT_LEVEL}}、{{TARGET_PROFICIENCY}}、{{PRACTICE_LOAD}}、{{KNOWN_DOMAINS}}、{{SCOPE}}、{{CANONICAL_LANGUAGE}})。

同時指引章節撰寫者參考 <技能目錄>/assets/COMPONENTS.md 的元件庫參考 — 他們應該在撰寫前先瀏覽。提示框、圖表卡片、比較區塊、分頁、統計卡片、平台標籤和步驟清單都可供使用;有些是從 Markdown 約定自動生成的,其餘的是 Markdown 內明確的 HTML。

驗證生成的檔案是否強制執行此 SKILL.md 頂部「教學法基礎」部分中列出的所有 12 條教學規則。如果任何規則未在指南中呈現,請在繼續之前新增。

階段 7 — 章節生成(並行批次)

以每個回合 3-5 個撰寫子代理的並行批次生成挑選的章節,跨回合順序執行。

對於每個回合:

  1. …

[為翻譯而截斷]

Individual skills in this repo

This repo contains 14 individual skills — each has its own dedicated page.

AlemTuzlak/skills

Use when the user wants to write a blog post about a feature, product change, PR, git diff, or any technical topic - accepts marketing briefs, PRs, git refs, codebase paths, or freeform descriptions as input

AlemTuzlak/skills

Use when the user wants to generate a changelog, release notes, or document what changed between versions, tags, or PRs

AlemTuzlak/skills

Use when writing, editing, or organizing documentation, when planning what docs a feature needs, and whenever planning or implementing a new feature or change in a repo (docs ship with the code). Also use when tempted to write docs without showing the discovered readers to the user, without asking for tone, or without loading simple-english and i-have-adhd. Triggers on "write docs for X", "document this feature", "add a guide", "update the docs", "reorganize the docs", "plan feature X", "implement X", or /docs.

AlemTuzlak/skills

Use when a bug is in play: a test fails, CI is red, an API returns the wrong result, a stack trace appears, or the user says it is broken or fix this. Don't use for a new feature with no failure, for types-only work, or for docs.

AlemTuzlak/skills

Use when the user invokes /i-have-adhd, says they have ADHD, or asks for ADHD-friendly output. Also used as a required writing filter by the docs skill. Don't use for marketing copy or after the user says "stop adhd mode" or "normal mode".

AlemTuzlak/skills

Use when a settled change must be turned into an ordered stack of small blocks before anyone implements. Don't use for unsettled intent, typos, comments, formatting, docs-only work, or writing the implementation itself.

AlemTuzlak/skills

Use when the user wants to write a product update email, feature announcement newsletter, or digest email for users or subscribers

AlemTuzlak/skills

Use when the user wants to turn a raw talking-head / screen-share recording into a finished, edited, annotated video plus a full content package. Removes silences, flags mistakes for the user to cut, transcribes, adds transcript-synced overlays (code, on-screen code highlights, word highlights, lists, comparisons, diagrams, section labels, punch-in zooms), renders with original audio, then generates blog/socials/YouTube content. Triggers on "produce a video", "edit my video", "annotate my recording", "/produce-video".

AlemTuzlak/skills

Use when the user runs /prove-it or says prove it, prove the changes, show me in the browser, or asks to prove a UI or API change. Don't use only because the agent is about to say done, for types-only work, or for docs with no behavior to prove.

AlemTuzlak/skills

Use when the user wants to write, draft, or author an RFC (Request for Comments) / technical design doc for a feature, change, or architectural decision. Interactively interviews the user, grounds the proposal in the actual codebase, presents 2-3 concrete API/code-snippet approaches to choose from, then writes a review-ready RFC. Triggers on "write an RFC", "draft an RFC", "RFC for X", "design doc for X", or /rfc.

AlemTuzlak/skills

Use when the change intent is already settled and the agent must map what a behavior change touches before an implementation plan or any code. Use for new features, bug fixes, and refactors that move a boundary. Don't use for typos, comments, formatting, lockfile-only diffs, docs with no code, or while the user is still deciding what they want.

AlemTuzlak/skills

Use when the user wants to transcribe a video or audio file to text with word-level timestamps — spins up a self-contained local Whisper (whisper.cpp) Docker service bundled in this skill and returns transcript.txt, transcript.srt, and word-level transcript.words.json. Also used as a building block by /produce-video. Triggers on "transcribe this video", "get a transcript", "transcribe-video".

AlemTuzlak/skills

Use when the user wants to write a video script for a product demo, feature walkthrough, launch video, or social media video about a feature or product change

AlemTuzlak/skills

Use when the user wants YouTube metadata for a video — a click-worthy title, an SEO/above-the-fold description, tags, and timestamped chapters. Accepts a transcript (ideally timestamped SRT), a topic, a PR, or a freeform description. Used standalone and by /produce-video. Triggers on "youtube title", "youtube description", "youtube chapters", "youtube tags", "youtube metadata", "youtube-copy".

相關技能