teach
在本工作区内向用户传授一项新技能或概念。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
在本工作区内向用户传授一项新技能或概念。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
使用并行子代理为一个模块生成多个截然不同的接口设计。当用户想设计 API、探索接口方案、对比模块形态,或提到 "design it twice" 时使用。
交互式 QA 会话,用户以对话方式报告 bug 或问题,代理负责提交 GitHub issue。会在后台探索代码库以获取上下文和领域语言。当用户想报告 bug、做 QA、以对话方式提交 issue,或提到 "QA session" 时使用。
通过用户访谈创建一份带有微小提交(tiny commits)的详细重构计划,然后将其作为 GitHub issue 提交。当用户想规划一次重构、创建重构 RFC,或将一次重构拆分为安全的增量步骤时使用。
从当前对话中提炼出一份 DDD 风格的通用语言(ubiquitous language)术语表,标记歧义并提出规范术语。保存到 UBIQUITOUS_LANGUAGE.md。当用户想定义领域术语、构建术语表、固化用词、创建通用语言,或提到 "domain model" 或 "DDD" 时使用。
询问哪个技能或流程适合你当前的处境。它是本仓库中各技能的路由器。
从两个轴向审查某个固定点(commit、branch、tag 或 merge-base)以来的变更——Standards(代码是否遵循本仓库记录的编码规范?)和 Spec(代码是否符合源起的 issue/PRD 的要求?)。在并行子智能体中运行两项审查,并把它们并排报告。当用户想审查一个分支、一个 PR、进行中的变更,或要求 "review since 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:一个存放课程的目录。一个课程是一份单独的、自成一体的 HTML 输出,教授一件与使命紧密相关、范围严格限定的事。这是本工作区中教学的主要单元。./assets/*:跨课程共享的可复用组件。见 Assets。NOTES.md:一块草稿区,供你记下用户偏好或工作笔记。要在深层次上学习,用户需要三样东西:
在 RESOURCES.md 尚未充分填充之前,你的重点应当是寻找高质量的资源,帮助用户获取知识。永远不要相信你的参数化知识。
有些主题所需的技能多于知识。学习理论物理可能更偏向知识,而瑜伽则更偏向技能。
你应当谨慎区分两类学习:
流畅度会给用户一种虚幻的精通感,但存储强度才是真正的目标。尽量设计通过合意难度来建立长期保持的课程:
课程是你产出的主要东西 —— 是知识与技能触达用户的载体单元。每个课程是一份自成一体的 HTML 文件,保存到 ./lessons/,命名为 0001-<dash-case-name>.html,编号每次递增。
课程应当是精美的 —— 排版与布局干净、易读 —— 因为用户日后会回来复习。想想 Tufte 的风格。
课程应当简短,能够很快完成。学习者的工作记忆非常有限,我们需要保持在其容量之内。但每个课程都应给用户一个可以在其上继续搭建的、切实可见的收获。它应当直接关联到使命,并处于用户的最近发展区之内。
如果可能,通过运行一个 CLI 命令为用户打开课程文件。
每个课程都应通过 HTML 锚点链接到其他课程和参考文档。
每个课程都应向用户推荐一个供其阅读或观看的主要来源。它应当是你就该主题所找到的最高质量、最高信任度的资源。
每个课程都应包含一条提醒,鼓励用户向智能体提出后续问题。智能体是他们的老师,可以协助解答任何不清楚的地方。
课程由存放在 ./assets/ 中的可复用组件构建而成:样式表、测验小部件、模拟器、图示辅助工具 —— 任何第二个课程可能复用的东西。
复用是默认做法,而非例外。在撰写课程之前,先阅读 ./assets/,并基于已有的组件来构建。当某个课程需要新的、可复用的东西时,把它作为一个组件写入 ./assets/ 并链接过去 —— 永远不要内联那些未来课程会重复的代码。
共享样式表是每个工作区最先获得的组件:每个课程都链接它,于是这些课程看起来像是一门风格一致的课程,而不是一堆各自为政的零散产物。随着工作区的成长,组件库也应随之壮大。
每个课程都应关联到使命 —— 即用户对学习该主题感兴趣的原因。
如果用户对使命不清楚,或 MISSION.md 尚未填充,你的首要任务应当是追问用户为什么想学这个。
未能理解使命将意味着知识获取无法扎根于现实目标。课程会显得过于抽象。你将无从判断用户接下来该做什么。
使命可能随着用户发展出更多技能与知识而改变。这是正常的 —— 务必更新 MISSION.md 并添加一条学习记录来记录这一变化。在改变使命之前先与用户确认。
在每个课程中,用户都应始终感觉自己受到"恰到好处"的挑战。
用户可能会指定一件他们确切想学的东西。如果他们没有,就通过以下方式弄清他们的最近发展区:
learning-records课程应围绕用户即将学习的一项技能来设计。课程中的知识应只包含习得该技能所必需的部分。你先教授知识,然后通过一个互动的反馈回路让用户练习技能。
知识应首先从可信资源中收集。使用 RESOURCES.md 来跟踪它们。课程中应遍布引用 —— 指向外部资源的链接,为提出的任何主张背书。这会提升课程的可信度。
对于获取知识而言,难度是敌人。它会吞噬你理解所需的工作记忆。
如果说知识关乎获取,那么技能关乎持久与灵活。让知识扎根。
对于习得技能而言,难度是工具。费力的提取才能建立存储强度。技能应通过互动课程来教授。你有若干工具可用:
以上每一种都应基于一个反馈回路,让用户就其表现获得反馈。这个反馈回路应尽可能紧凑,即时给出反馈 —— 最好是自动给出。
对于测验,每个答案的字数(若可能,字符数也)应完全相同。不要通过格式给用户任何关于答案的暗示。
智慧来自真正的现实世界互动 —— 在学习环境之外检验你的技能。
当用户提出一个似乎需要智慧才能回答的问题时,你的默认姿态应当是尝试作答 —— 但最终把它委托给一个社区。
社区是一个(线上或线下的)用户可以在现实世界中检验其技能的地方。它可能是一个论坛、一个 subreddit、一堂线下课程(预算允许的话)或一个本地兴趣小组。
你应当尝试寻找用户可以加入的高声誉社区。如果用户表示不想加入社区,尊重这一意愿。
在创建课程的同时,你也应创建参考文档。课程可以引用这些文档 —— 它们对于跟踪跨课程通用的原始知识单元很有用。
课程日后很少会被重访 —— 参考文档则会。它们应当是课程压缩后的精华,采用为快速查阅而设计的格式。
有些学习主题很适合做成参考:
尤其是术语表,是一种必不可少的参考。一旦创建,就应在每个课程中遵循它。
NOTES.md用户有时会表达他们希望被如何教导的偏好,或你应记住的事情。这里就是记录这些偏好的地方,以便你在设计课程或与用户协作时回过头来参考。