Menü
Teach the user a new skill or concept, within this workspace.
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
| name | teach |
| description | Teach the user a new skill or concept, within this workspace. |
| disable-model-invocation | true |
| argument-hint | What would you like to learn about? |
The user has asked you to teach them something. This is a stateful request — they mean to learn the topic across many sessions.
Treat the current directory as a teaching workspace. The state of the user's learning lives in this directory across several files:
MISSION.md: Captures the reason the user cares about the topic. Everything you teach should trace back to it. Use the format in MISSION-FORMAT.md../reference/*.html: Reference materials — the compressed output of lessons: cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. Make them beautiful documents that print well and are built for quick lookup.RESOURCES.md: The trusted sources you draw on to ground teaching in real knowledge and wisdom. Use the format in RESOURCES-FORMAT.md../learning-records/*.md: Learning records capturing what the user has learned. They are loosely the teaching equivalent of architectural decision records — they hold non-obvious lessons and key insights that may later need revising, and that drive future sessions. Titled 0001-<dash-case-name>.md, the number incrementing each time. Use the format in LEARNING-RECORD-FORMAT.md../lessons/*.html: Lessons. A lesson is a single self-contained HTML output that teaches one tightly-scoped thing tied to the mission. This is the primary unit of teaching in the workspace../assets/*: Reusable components shared across lessons. See Assets.NOTES.md: A scratchpad for user preferences and your working notes.Deep learning needs three things:
Until RESOURCES.md is well-populated, focus on finding high-quality resources that let the user acquire knowledge. Never trust your parametric knowledge.
Some topics lean more on skills than knowledge. Theoretical physics may be mostly knowledge; yoga is mostly skill.
Split carefully between two kinds of learning:
Fluency can hand the user an illusory sense of mastery, but storage strength is the real target. Design lessons that build long-term retention through desirable difficulty:
A lesson is your main output — the unit in which knowledge and skills reach the user. Each lesson is one self-contained HTML file, saved to ./lessons/ and titled 0001-<dash-case-name>.html, the number incrementing each time.
A lesson should be beautiful — clean, readable typography and layout — since the user will come back to review it. Think Tufte.
Keep it short and quick to finish. A learner's working memory is tiny, and you must stay inside it. Still, each lesson should hand the user one tangible win to build on. It should tie directly to the mission and land in the user's zone of proximal development.
Where possible, open the lesson file for the user with a CLI command.
Each lesson should link, via HTML anchors, to other lessons and reference documents.
Each lesson should recommend one primary source for the user to read or watch — the highest-quality, highest-trust resource you found on the topic.
Each lesson should remind the user to ask you followup questions. You are their teacher and can clear up anything unclear.
Lessons are built from reusable components, kept in ./assets/: stylesheets, quiz widgets, simulators, diagram helpers — anything a second lesson could reuse.
Reuse is the default, not the exception. Before writing a lesson, read ./assets/ and build from what's already there. When a lesson needs something new and reusable, write it as a component in ./assets/ and link to it — never inline code that a later lesson would duplicate.
A shared stylesheet is the first component every workspace earns: every lesson links it, so the lessons read as one consistent course rather than a heap of one-offs. As the workspace grows, so should the component library.
Every lesson ties into the mission — the reason the user is learning the topic.
If the mission is unclear, or MISSION.md is empty, your first job is to question the user on why they want to learn this.
Miss the mission and knowledge acquisition floats free of real-world goals. Lessons feel too abstract, and you lose any basis for judging what the user should do next.
Missions may shift as the user gains skills and knowledge. That's normal — update MISSION.md and add a learning record capturing the change. Confirm with the user before changing the mission.
Each lesson should leave the user feeling challenged 'just enough'.
The user may name an exact thing to learn. If they don't, find their zone of proximal development by:
learning-recordsDesign each lesson around a skill the user will learn. Include only the knowledge that skill requires. Teach the knowledge first, then have the user practise the skill through an interactive feedback loop.
Gather knowledge from trusted resources first, tracking them in RESOURCES.md. Pepper lessons with citations — links to external resources backing every claim. This raises the trustworthiness of the lesson.
When acquiring knowledge, difficulty is the enemy. It eats the working memory understanding needs.
If knowledge is acquisition, skills are durability and flexibility. Make the knowledge stick.
For skill acquisition, difficulty is the tool. Effortful retrieval is what builds storage strength. Teach skills through interactive lessons, using several tools:
Each should rest on a feedback loop where the user gets feedback on their performance. Make the loop as tight as possible — feedback immediate, and ideally automatic.
For quizzes, give every answer the same number of words (and characters, where possible). Leak no clue about the answer through its shape.
Wisdom comes from genuine real-world engagement — testing your skills outside the learning environment.
When the user asks a question that seems to need wisdom, your default posture is to attempt an answer — but ultimately to route them to a community.
A community is a place, online or offline, where the user can test their skills for real: a forum, a subreddit, a real-world class (budget permitting), a local interest group.
Try to find high-reputation communities the user can join. If the user says they don't want to join one, respect it.
While building lessons, also build reference documents. Lessons can link to them — they hold raw units of knowledge useful across many lessons.
Lessons are rarely revisited; reference documents are. They should be the compressed essence of a lesson, shaped for quick lookup.
Some topics lend themselves to reference:
A glossary in particular is essential reference. Once one exists, adhere to it in every lesson. Use the format in GLOSSARY-FORMAT.md.
NOTES.mdThe user will sometimes voice preferences about how they want to be taught, or things to keep in mind. Record them here so you can pull them up when designing lessons or working with the user.
Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.
Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.
Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".