teach
在当前工作区中教授用户一项新技能或概念。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Menü
在当前工作区中教授用户一项新技能或概念。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
使用并行 sub-agents 为一个 module 生成多套差异显著的 interface 设计。适用于用户希望设计 API、探索 interface 选项、比较 module 形态,或提到“design it twice”的场景。
运行交互式 QA session:用户通过对话报告 bugs 或 issues,agent 随后创建 GitHub issues;同时在后台探索 codebase,获取上下文和 domain language。适用于用户希望报告 bugs、开展 QA、通过对话创建 issues,或提到“QA session”的场景。
通过用户访谈创建一份由微小 commits 组成的详细 refactor plan,并将其提交为 GitHub issue。适用于用户希望规划 refactor、创建 refactoring RFC,或将 refactor 拆分为安全的增量步骤。
从当前对话中提取一份 DDD 风格的 ubiquitous language glossary,标出歧义并提出规范术语,保存到 UBIQUITOUS_LANGUAGE.md。适用于用户希望定义 domain terms、建立 glossary、收紧术语、创建 ubiquitous language,或提到“domain model”或“DDD”的场景。
询问当前情境适合使用哪个 Skill 或工作流。本 Skill 是仓库内其他 Skills 的路由入口。
从用户指定的固定点(commit、branch、tag 或 merge-base)开始,从两个维度审查代码变更:Standards 检查代码是否遵守仓库记录的编码规范,Spec 检查实现是否符合原始 Issue、PRD 或规格。两个审查由并行子 Agent 分别完成,再并列汇报。适用于用户希望审查分支、PR、开发中的改动,或要求“审查自 X 以来的变更”时。
| name | teach |
| description | 在当前工作区中教授用户一项新技能或概念。 |
| disable-model-invocation | true |
| argument-hint | 你想学习什么? |
用户希望你教授某项内容。这是一项有状态的请求:他们准备跨多个会话学习这个主题。
将当前目录视为教学工作区。学习状态保存在以下文件中:
MISSION.md:记录用户为什么对该主题感兴趣。所有教学都应以此为依据。格式参见 MISSION-FORMAT.md。./reference/*.html:参考资料目录。这些文件是课程内容的浓缩成果,例如速查表、算法参考、语法、瑜伽体式和术语表。它们是学习内容的基础单元,应拥有漂亮的排版,适合打印,并为快速查阅而设计。RESOURCES.md:可供探索的资料列表,用于让教学建立在上下文知识之上,或帮助用户获得知识和智慧。格式参见 RESOURCES-FORMAT.md。./learning-records/*.md:学习记录目录,用于记录用户已经掌握的内容。它们大致相当于软件开发中的架构决策记录:保存不明显的经验和关键认识;这些内容以后可能需要修订,也可能推动未来会话。应依据这些记录判断用户的最近发展区。文件名为 0001-<dash-case-name>.md,编号每次递增。格式参见 LEARNING-RECORD-FORMAT.md。./lessons/*.html:课程目录。一个**课节(lesson)**是一份独立、自包含的 HTML 产物,只教授一个范围紧凑、与学习使命直接相关的内容。这是工作区中的主要教学单元。./assets/*:供多份课程复用的组件。参见组件。NOTES.md:临时记录区,用于记下用户偏好和工作笔记。深入学习需要三项要素:
在 RESOURCES.md 尚未积累足够资料前,应优先寻找能够帮助用户获得知识的高质量资源。绝不能盲目信任模型参数中已有的知识。
不同主题对知识和技能的依赖程度不同。理论物理更偏向知识学习,瑜伽则更偏向技能练习。
谨慎区分两类学习效果:
流畅感可能让用户误以为自己已经掌握内容,真正目标是存储强度。通过“有益的困难”设计能够形成长期记忆的课节:
课节是主要产物,也是知识和技能抵达用户的单元。每节课都是一个自包含 HTML 文件,保存到 ./lessons/;文件名为 0001-<dash-case-name>.html,编号每次递增。
课节应该美观,拥有干净、易读的字体排版和布局,因为用户以后会回来复习。以 Tufte 的作品作为审美参照。
课节应当简短,并且能够很快完成。学习者的工作记忆容量很小,内容必须控制在这个限制内。每节课仍需带来一项明确、可感知的成果,使用户能够在此基础上继续前进。内容要直接服务于学习使命,并处于用户的最近发展区。
条件允许时,运行 CLI 命令为用户打开课节文件。
每节课都应通过 HTML 锚点链接到其他课节和参考文档。
每节课都应推荐一份供用户阅读或观看的一手资料。它应当是你在该主题上找到的质量最高、可信度最高的资源。
每节课都应提醒用户向 Agent 继续提问。Agent 是他们的教师,可以帮助澄清任何不理解的内容。
课节由保存在 ./assets/ 中的可复用组件构成,包括样式表、测验组件、模拟器、图表辅助工具,以及任何可能被第二节课复用的内容。
复用是默认做法。编写课节前先读取 ./assets/,优先使用已经存在的组件。课节需要新的可复用能力时,把它写成 ./assets/ 中的组件并通过链接引入;绝不能内联一段未来课节还会重复使用的代码。
共享样式表是每个工作区最先建立的组件。所有课节都应链接它,使整套内容看起来像一门一致的课程,而不是一堆互不相关的单页。工作区逐渐增长时,组件库也应同步成长。
每节课都必须与学习使命相连,也就是用户为什么想学习这个主题。
用户对使命表达不清,或 MISSION.md 尚未填写时,第一项工作是询问他们为什么希望学习该主题。
不理解使命,会让知识获取脱离现实目标,课程显得过于抽象,也无法判断用户下一步应该做什么。
随着用户掌握更多知识和技能,学习使命可能发生变化。这很正常。使命变化时更新 MISSION.md,并添加一条学习记录保存本次转变。修改使命前必须先与用户确认。
用户在每节课中都应感觉自己受到“恰到好处”的挑战。
用户可能明确指定想学习的内容。没有指定时,通过以下方式判断最近发展区:
learning-records课节应围绕用户准备掌握的一项技能设计。课节中的知识只保留获得该技能所必需的部分。先教授知识,再通过互动反馈闭环让用户练习技能。
知识应先从可信资料中收集。使用 RESOURCES.md 跟踪资料。课节中应广泛使用引用,以外部链接支持每一项事实主张,提高内容可信度。
获取知识时,困难会占用理解所需的工作记忆,因此应尽量降低无关难度。
知识关注获取,技能关注持久性和迁移能力。让知识真正留下来。
技能学习需要适当困难。需要付出努力的提取过程,才能提高存储强度。技能应通过互动课节教授,可以使用:
每种形式都必须建立在反馈闭环之上,让用户收到关于表现的反馈。闭环应尽量紧密,立即提供反馈,最好能够自动反馈。
测验的每个选项必须拥有完全相同的词数;条件允许时,字符数也应相同。不能通过排版向用户泄露答案线索。
智慧来自真实世界中的互动,也就是离开学习环境后实际检验技能。
用户提出的问题看起来需要实践智慧时,默认先尽力回答,最终仍应把验证交给一个社群。
社群是线上或线下场所,用户可以在真实世界中检验技能,例如论坛、subreddit、线下课程(预算允许时)或本地兴趣小组。
主动寻找信誉良好、适合用户加入的社群。用户明确表示不希望加入社群时,尊重该偏好。
创建课节的同时,也应创建参考文档。课节可以引用这些文档;它们用于保存跨多节课都可能需要的基础知识单元。
课节以后很少会被完整重读,参考文档则会被频繁查阅。参考文档应当提炼课节的核心内容,并采用适合快速查阅的格式。
以下学习主题适合制作参考文档:
术语表尤其重要。一旦建立,后续每节课都必须遵守其中定义。
NOTES.md用户有时会说明自己偏好的教学方式,或提出需要持续留意的事项。将这些内容记录在这里,以便以后设计课节或与用户协作时查阅。