Publish Sign in

Teach Agent Skill

Explain a body of work plainly so a person actually understands it.

Install this skill Read the source first Free Written by geiserx
Context cost
1.6k tokensestimated from the bundle, loaded when it triggers
Bundle
1 file · 6.5 kBtext throughout, nothing executable
Licence
GPL-3.0the author’s own terms
Last change
—no release on file
Servers it uses
Noneruns standalone

What it does

Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.

What this skill changes about the agent has not been set out here as a list. Its SKILL.md, shown below, says it in the author’s own words.

documentation
Filed under

Learning & Documentation

The skill itself

A skill is instructions the model reads, and here they are in full: the front matter loads with every session, and the body below it loads when the skill triggers.

SKILL.md6.5 kB
--- name: teach ---
6# Teach
7
8**You explain what a thing is, how it works, and why it's built that way, in one plain account at the person's pace. The goal is that they understand it, not that you change anything.** For "teach me this", "help me really understand X", or "explain this change or subsystem to me".
9
10Teach sits on top of how and why. Get your bearings on what the work is and what it touches, then run how for how it works and why for why it's that way. Those are real skill invocations that do their own digging. Blend what they find into one plain explanation, lead with what matters to the person, and go deeper when they ask. Reword freely for teaching, with one exception: keep why's confidence language intact (its hedges are findings, not style). Let those skills do the investigation. Don't redo it by hand.
11
12**Platform note.** On Codex or another non-Claude runtime, running how and why in parallel maps to parallel subagent dispatch (spawn_agent fan-out), and the image-generation tool resolves to your platform's equivalent. Resolve tool names via [codex-tools.md](../poteto-mode/references/codex-tools.md).
13
141. Decide the few things they should walk away understanding. Choose them from why they're asking (about to change it, reviewing it, debugging it, new to it) and what they already know, both read from the conversation, not quizzed out of them. Skip what they plainly already know. Put the depth where their question is.
152. Let how and why do the work, don't redo it. Read the code yourself to get oriented, then run how for how it works and why for why. Run them in parallel and combine the results. Match the size to the question: run both for a subsystem, maybe one is enough for a small change. Keep why narrow by default since its full sweep is slow: put the narrowing in the ask itself (a scoped question, git plus a source or two) so why records the skipped categories per its own contract, and widen it only when the reasons are the point.
163. Start with a plain definition. Name the thing and say what it is in general terms, the way a senior engineer would say it out loud, with its common name if it has one. Then tie it to the case in front of you ("in X, we use this to ...") and build from there: how it works, the deeper reasons, the edge cases. Explain how it works, don't just name it. For each part, explain the idea so it clicks: the problem it solves and how it actually works. Walk through what happens as the person does the thing (opens a long chat, scrolls up) when that is what makes it land. Listing functions and constants is reference, not teaching. Don't print framing labels ("the one idea to hold onto", "the thing to walk away with", "the key insight", "at its core", "TL;DR"). Give the smallest complete answer first, a sentence or two, not a dense paragraph, then stop. Add layers when they ask. Never a wall of text.
174. Keep it a conversation, not a lecture or a performance. Offer to go deeper or move on, and follow their lead. No quizzes. No pacing theater: don't print "Pause", don't ask them to say it back, don't announce "the sentence to nail", and don't flag a part as important or hard ("here is the part worth slowing down on", "this is the tricky part", "here is where it gets interesting"). Just say it. When you would pause, stop and let them respond. Running one-shot with no live human, deliver it cleanly and put any offer to go deeper at the end.
185. Show, don't only tell, and build the picture up diagram by diagram. Open the diff, the code, or the debugger when that is the fastest way to land it. Draw when a picture lands faster than words. For anything with three or more moving parts, do not draw one diagram with all of them at once. Draw a short series instead, where each diagram redraws the last and adds a single part, so the reader watches the system assemble. That series is not a wall. It is the opposite of one, since each step is small and adds exactly one idea. A single all-at-once diagram, especially one saved for the end, is a reference, not teaching. Concretely, to teach a flow from A to B to C, draw it three times. First A to B. Then redraw and add C. Then redraw and add the return edge or the next piece. Three small growing diagrams beat one crowded diagram. Match the medium to the idea, and use both kinds when both help. A mermaid diagram fits a flow or structure where the labels carry the meaning. When the idea is spatial, like layout, overlap, scroll position, or a before and after, reach for the image-generation tool and draw it marker-on-whiteboard style with a few short labels, since image models garble long text. Generate that picture, don't settle for describing it in words. The build-up rule holds for generated images too. A single simple point needs no figure. A visual earns its place by teaching, not decorating.
19
20Write every response through the **unslop** skill, in plain spoken English, the way you'd explain it to a colleague. Be tight, not terse: cut filler and hedging, keep the part that makes it click. Padding is the enemy, not ideas. Don't list functions and constants like a changelog. State the concrete mechanism, not a metaphor, a framing, or a preview of what is coming. This is the target density: "Virtualization runs in two parts, one for rendering and one for loading from disk. When an item scrolls out past the buffer, both its DOM node and its in-memory data are evicted." Normal sentence case, not all-lowercase. No em dashes. Prefer periods over commas. Keep each sentence to one or two commas. If clauses pile up, split them into separate sentences. Give each concept one name and keep it, since switching between synonyms for the same thing (bubble, message, row) makes the reader re-derive that they are the same. Avoid mirror sentences ("A without B, or B without A") and tidy closers ("the rest follows", "it all falls out"). The words in these steps are directions to you, not labels to print. Don't echo the scaffolding as headers or stock phrases.
21
22**Reply:** the explanation itself, never a report about what you did or delivered. Lead with the main point, then the plain account of what it is, how it works, and why, and the threads worth chasing with how or why.
23
This is the whole of SKILL.md. Install the skill to get it and everything beside it.
In the file
SKILL.md1,160 words
Files1
LicenceGPL-3.0
Why you can read it

Nothing in a skill executes. The client loads the text and the model follows it, so a skill can be audited the way a runbook is — by reading it.

What it costs in context

Skills are not billed by the call. They are paid for in context: every token the instructions occupy is a token your code, your diff and your conversation cannot use. Here is what this one takes and when it takes it.

≈70
always loaded
The name and description, so the model knows the skill exists and when to reach for it.
1,555
on trigger
The instruction body, read only when the skill fires.
0.81%
of a 200k window
Ten skills this size would take about 8% of the window before you open a file.
050k100k150k200k context window

1.6k tokens, estimated from the bundle at four bytes to the token, held for the rest of the session once it triggers. Middling. Fine to keep on in a project where you use it weekly, worth unloading in one where you never do.

Servers bill, skills cost

A server charges by the month. A skill charges once per session, in context, and then keeps charging it for as long as the session lives.

Before and after

The same question, put to the same model twice: once as it comes, and once with these instructions loaded.

No worked example has been published for this skill yet.

The procedure it runs

The procedure has not been set out here step by step. It is in the body of its SKILL.md, shown in full above.

Prose, not code

These steps are written for a model to follow, not executed by a runtime. It can still be told to skip one, and it will say so when it does.

Servers it uses

None. This skill calls no MCP servers at all.

Everything it needs is in the instructions, so it works in a project with nothing connected — the model reads the file and changes how it works with what it can already reach.

Its SKILL.md does not declare which tools it asks the agent for, so what it touches is whatever the instructions themselves ask for — read them before you install it.

What it asks for
Writes filesnot declared
Network accessnot declared

This SKILL.md carries no allowed-tools line, so neither is declared. A skill grants no permissions of its own — it can only ask for tools your client already has.

What it will not do

Every skill is narrow, and the useful ones say where they stop. These are the jobs this one is the wrong tool for.

What this skill is not for has not been published here. Nothing is implied by that: it is a section the author has not filled in.

What is in the bundle

1 file, 6.5 kB on disk. A bundle is text throughout: the instructions the model reads, plus the templates it fills in.

  • SKILL.md6.5 kB
What is not in it

No dependencies and nothing executable: a skill is text the agent reads, so the bundle is 1 file you can review in full before installing. The GPL-3.0 licence covers the templates and examples as well as the instructions.

Install

Installing copies the bundle into your project. Nothing runs at install time — the files sit on disk until the model reads them.

# Teach · 1.6k tokens when loaded · macOS, Linux mkdir -p .claude/skills && t=$(mktemp -d) && curl -fsSL -o "$t/bundle.tar.gz" https://mcprush.com/api/skills/teach/bundle.tar.gz && tar -xzf "$t/bundle.tar.gz" -C "$t" && [ -d "$t/teach" ] && { [ ! -e .claude/skills/teach ] || { mv .claude/skills/teach "$t/.previous" && echo "Previous copy moved to $t/.previous"; }; } && mv "$t/teach" .claude/skills/ && echo "Installed .claude/skills/teach"
On Windows, or any OS with Node 20+
npx mcprush@latest skill add geiserx/teach

Windows PowerShell says 'running scripts is disabled on this system'? Run Set-ExecutionPolicy -Scope CurrentUser RemoteSigned once, or type npx.cmd instead of npx (codex.cmd, gemini.cmd, grok.cmd likewise). PowerShell 7 needs neither. Writes to .claude/skills/teach/ in the current project. For every project instead, run mkdir -p ~/.claude/skills && t=$(mktemp -d) && curl -fsSL -o "$t/bundle.tar.gz" https://mcprush.com/api/skills/teach/bundle.tar.gz && tar -xzf "$t/bundle.tar.gz" -C "$t" && [ -d "$t/teach" ] && { [ ! -e ~/.claude/skills/teach ] || { mv ~/.claude/skills/teach "$t/.previous" && echo "Previous copy moved to $t/.previous"; }; } && mv "$t/teach" ~/.claude/skills/ && echo "Installed ~/.claude/skills/teach" (macOS, Linux) — or add --global to the npx line. The curl line replaces .claude/skills/teach/ only after the download succeeds, so files left there by another skill of the same name, or by an older release, do not mix in. A copy already there is moved aside, not deleted, and the line prints where.

Which clients pick it up on their own

A skill is a folder of text. Most of these read a skills folder and pick it up without being told; the rest take the same folder another way — an upload in the app, a parameter on an API call — and then choose it by its description just the same.

Claude Code.claude/skills/
Claude DesktopCustomize › Skills
ChatGPTSkills › Create › Upload
Cursor.cursor/skills/
VS Code.github/skills/
Codex CLI.agents/skills/
Gemini CLI.gemini/skills/
Grok Build.grok/skills/
Microsoft CopilotSkills › Upload a skill
PerplexityComputer › Skills › Upload a skill
DeepSeek Harness.dsh/skills/
Zed.agents/skills/
Devin Desktop.devin/skills/
Windsurf (legacy).windsurf/skills/
OpenAI Agents SDKInstructions or sandbox Skills
HTTP / APIa request parameter
This release
Versionnot versioned
Publishedno release date on file
PriceFree
Referencegeiserx/teach

Versions

Its author publishes no version number, so there is nothing here to pin to: what you install is the folder as it stands today. Instructions change more often than APIs do — a skill can be rewritten entirely without anything it depends on moving.

Pinning

Nothing to pin to: this skill carries no version number of its own. What you install is what the folder holds on the day you install it.

Reviews

—no reviews yet

Nobody has reviewed this skill yet. The rating is the mean of the reviews written here, so there is none until somebody writes the first.

Sign in to review it

A review is tied to an account so it can be answered, edited and taken down by the person who wrote it.

Sign in
Who can post

Anybody with an account, one review each. It carries the version that was current when you wrote it, and the publisher may reply once.

Who wrote it

GE
geiserx

Publishes on mcprush.

9 servers listed51 skills listednot claimed
Profile
Publisher
Servers9
Claim this skill