teach
在当前工作区中教授用户一项新技能或概念。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
在当前工作区中教授用户一项新技能或概念。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
使用并行 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用户有时会说明自己偏好的教学方式,或提出需要持续留意的事项。将这些内容记录在这里,以便以后设计课节或与用户协作时查阅。