What an extension actually is.

From directing agents to authoring the direction CORE

Everything you did in Modules 3 through 6 had the same shape: you held the steering wheel. You wrote the prompt. You chose the scope. You approved the draft. When the agent acted, it acted on your instructions, given that session, by you, with your attention on the result. Even when you put work on a schedule in Module 6, you still wrote the plan once and then let the scheduler replay it. You were directing.

Module 7 asks you to do something different. Instead of typing a new instruction every time a particular job shows up, you name the instruction. You give it a description, a scope, and a home on disk. You write it down in a way the agent can find later, on its own, when the right kind of request comes through. You are no longer telling the agent how to do this job each time; you are teaching it how to recognize the job and reach for the right instructions without you prompting it.

That named, reusable piece of instruction is an extension. A skill is one kind of extension. A plugin is a bundle of them. A memory is a lightweight one. An MCP connector is a different shape of one. There are others. The common thread is that every extension is a durable, reusable piece of capability that sits between you and the model — something you installed or authored once and that the agent consults many times.

A useful way to see the shift: in Module 3 you were the agent’s instructor — you told it what to do one interaction at a time. In Module 7 you become the agent’s librarian — you curate the reference shelf it will consult on its own. Two concrete examples of what that means in practice:

• Each time you do a research sweep, you type the same six-line prompt describing how you want sources triangulated, how fabricated citations should be surfaced, and what the output shape is. Eventually you write that prompt into a file called research-sweep/SKILL.md with a clear description, and now any time you say anything research-sweep-shaped — “check this topic” or “triangulate sources on X” — the agent reaches for the skill without you retyping the prompt. You stopped re-instructing; you started referencing.
• You find a community-authored plugin that adds a tidy daily-journal capability. It has a sensible description. It writes to a folder you control. It handles credentials cleanly. You install it. You did not write any of it, and you do not need to — but you did choose it, and you are responsible for it as long as it lives on your machine.

Both of those — authored and installed — are extensions. Both enter the register. Module 7 is the module where you learn to do both well. There is a temptation, right up front, to treat this as purely a productivity shortcut — “skills save me retyping my prompts.” That is not wrong, but it undersells the move. The deeper thing happening here is that you are making your working style legible to the agent. A skill is not just a saved prompt; it is a declaration of how you want a particular kind of work done, phrased in a way the agent can pick up on its own. Over a year, the stack of skills and plugins on your machine is a map of how you work. It is also a liability if you let it grow without care. Lessons 7.3 and 7.4 teach the authoring. Lesson 7.5 teaches the care.

The taxonomy: six places an instruction can live CORE

The word “extension” can mean a lot of things, so the module fixes a taxonomy early. Six common places an instruction can live, from most ephemeral to most shareable:

1. One-off prompt (in-session). You type the instruction in chat, the agent runs it, the session ends, the instruction is gone. Everything you did in Modules 3–6 at the per-session level lived here. Half of what you do after this module will still live here. This is where most of your instruction-giving happens and should stay.

2. Saved prompt / prompt snippet. You paste the same prompt from a note or a snippet manager at the start of each session. It persists across sessions, but only because you moved it by hand. The agent does not know it exists until you paste it in. This is the manual version of what a skill automates.

3. Memory. A short fact the agent carries across sessions — “I prefer concise responses,” “my research is for a college-prep class,” “skip the preamble on weekly reports.” Memories are conversational tuning, not capability. They shape how the agent talks to you. They do not add a new job the agent can do on its own.

4. Skill. A named, described, durable piece of capability stored as a file or folder the agent can consult. A skill has a trigger (a description the agent reads to decide whether this skill applies to the current request) and a body (the instructions, example inputs and outputs, and any supporting scripts). The agent reaches for a skill when its description matches the work the user is asking for, whether or not the user named the skill explicitly. A well-authored skill fires on phrases like “do a research sweep on X” or “run this through the weekly-report shape” — even when the user did not say the exact words “use the research-sweep skill.” This is the headline Module 7 object.

5. Plugin. A bundle of skills, plus optional tool wiring and optional commands, packaged as a single installable unit. A plugin is the shareable, removable wrapper around one or more skills. Installing a plugin is a single action that lands a coherent set of capabilities on a machine; uninstalling it removes them cleanly as a group. Plugins are the right shape when a set of capabilities goes together and you want them to live and die as a unit. Module 7 has you author one.

6. MCP connector. A tool that gives agents new verbs — a way to talk to Slack, Google Calendar, a database, a filesystem, an API — so a skill or a chat session can act outside the model’s own world. An MCP connector is not itself instruction; it is capability. Skills and plugins can use MCP connectors. In this module, you will install and wire at least one existing MCP connector into your plugin. You will not author one; that is a deeper topic.

Three observations about this taxonomy that matter for the rest of the module:

• Memories are not skills. Students often blur these because both “persist across sessions.” A memory tells the agent how you like to be talked to; a skill tells it how to do a specific kind of work. A memory is a sentence or two. A skill is a bounded piece of instruction with a trigger and a body. If you find yourself trying to do real capability work through memories, that is the signal to promote it to a skill. Lesson 7.3 names the boundary sharply.
• Plugins are bundles, not replacements. A plugin is not “a better skill.” It is a group of skills, sometimes with tools and commands around them. A single well-authored skill is often all a student needs; a plugin is for the case where multiple related skills and tools travel together and deserve a shared install/uninstall story.
• MCP connectors sit underneath both. Skills and plugins can call MCPs. The MCP is not “another level of skill” — it is the layer below, where the new verbs come from. The taxonomy is not strictly linear, but thinking of MCP connectors as underneath skills and plugins keeps the mental model clean.

When a skill earns its keep: the threshold test CORE

Not every prompt you type often should become a skill. This matters, because the most common Module 7 failure mode is premature extension-building — a student turns every half-memorable prompt into a skill in week one and then cannot tell which skill is still useful in week eight.

Use a three-part test. A prompt earns promotion to a skill when all three answers are yes:

1. Same shape. Are you doing the same kind of work — not just with the same tool, but with the same inputs, the same intermediate steps, and the same output shape? A skill fires on a shape, not a topic. “Research sweep on a topic I name” is a shape; “research sweep on nineteenth-century American history” is a topic (and probably belongs in memory or in a saved prompt, not a skill). If every instance you care about has the same inputs and produces the same kind of artifact, you have a shape.

2. Reliable enough. Can you describe the work clearly enough, in writing, that a stranger could run it without asking you questions? A skill has to work when you are not in the chat to clarify. If you find yourself saying “well, it depends on the situation” more than once or twice while writing the skill down, the shape is not yet stable enough to name. Let it mature as a saved prompt for a few more weeks.

3. Often and heavy enough. Is the work happening often enough — weekly, say, or several times a week — and is it heavy enough that the overhead of re-prompting feels like friction? A prompt you run once a month is not worth a skill. A prompt you run three times a week that takes one sentence to re-specify is also not worth a skill — the friction is zero. A prompt you run twice a week that takes six lines of set-up is a skill candidate. The threshold is the crossing of both frequency and per-run weight.

Concrete examples, applied:

• “Draft an inbox triage pass.” Same shape, reliable, heavy (the full triage prompt is long), happens daily. Skill.
• “Run a research sweep on a topic I name.” Same shape, reliable, heavy (triangulation + citation checks are five to six lines of specification), happens several times a week if the student does project work. Skill.
• “Summarize this one article.” Same shape, reliable, one-sentence prompt, happens often but is light. Not a skill. Keep as an in-session prompt.
• “Write me an essay about the French Revolution.” Different topic every time, the real work is the student’s thinking — not a shape the agent does on its own. Not a skill. This is writing, not a named job.
• “Format my capstone register entry.” Same shape, reliable, light (one or two lines). Not a skill — too light to be worth a name. Keep it as a saved prompt.

The test fails open. When in doubt, do not build a skill. Live with the prompt in chat or as a saved snippet for a few more weeks. If you reach for it the same way several times, the shape is stable enough. If you stopped reaching for it, the prompt was not load-bearing and the saved snippet quietly fades. A student who applies this test honestly ends Module 7 with fewer skills than they started the module expecting — a small number of named jobs, not a sprawl. That is the intended outcome. The register will end up larger than the authored column because the register also holds off-the-shelf entries; but the authored column stays small on purpose.

The pile-up failure mode CORE

Imagine a student who ignores the threshold test. Early on, they author several skills based on whatever prompts they happened to use that week. They install a handful of community plugins because the descriptions sounded interesting. A newer version of a plugin lands and silently adds skills under the hood. They author more skills because some do almost the same job as one of the plugins but not quite.

A few months in, there are many extensions on the machine. The student can name only some of them. Several have overlapping descriptions, so when they ask the agent for help, the agent sometimes picks the wrong one — and the student cannot tell whether it picked the wrong one or whether it picked the right one and ran it wrong. One plugin has updated itself and now reaches for an email connector the student does not remember granting it. A memory the student wrote months ago is quietly overriding a skill they wrote last week.

The student is now slower than they were before Module 7. Every request has more surface area than it needs to. The wrong skill fires and they lose time debugging. The right skill does not fire because a vaguer one matched first. They cannot tell what any of it is doing, because they never wrote down what any of it was for.

This is the pile-up failure mode. It is not unique to AI extensions — it is the same arc that eats Chrome extensions, VS Code plugins, browser bookmarks, and installed apps more broadly. In the AI setting it is quieter because the failure is invisible: the agent reaches for the wrong skill, produces a plausible-looking result, and nobody sees the problem unless someone reads carefully. By the time the student notices their workflow has degraded, they have lost the trail.

The rail that prevents the pile-up is an extension register, maintained over time. Every authored or installed extension lands in the register with:

• Name (what you call it in prose).
• Type (skill / plugin / memory / MCP).
• What it does (one sentence, in the same voice as a job description: “runs a research sweep on a named topic and produces a sources.md.”)
• Where it lives (folder path, URL, or install location).
• Invocation (how it fires — a phrase, a command, a chat cue).
• Audience (must be only me for anything the student authored; anything else is rejected).
• Budget / model (rough dollars per invocation and the model it calls).
• Next review date (≤ 90 days out).
• Keep or retire (the condition under which this extension earns its keep vs. the condition under which you will remove it).

A register row that is not renewed by its review date is paused, not left running. The register is the Module 7 parallel to Module 6’s automation register, and the failure mode it prevents is the same shape: silent, slow, invisible-until-expensive. You will set up an empty register this lesson. You will fill it across the rest of the module. You will freeze it at the end of Lesson 7.5.

Audience = only you, carried forward CORE

Module 6 installed the rule audience = only you for scheduled tasks: an agent runs on a schedule and delivers to the student, not to any other human. In Module 7, the same rule extends to any extension the student authors.

A custom skill may read anything on the student’s machine. It may draft anything. It may produce artifacts in any folder the student names. It may not auto-send, auto-post, auto-RSVP, or otherwise put text in front of any second person without a human-click approval. The same uniform rule, the same reasoning: carve-outs metastasize, and the student who writes the first auto-send skill in week four is the student who writes the second in week six and the third in week nine.

One place students ask for an exception is “but the plugin I am considering installing sends email on my behalf — am I not allowed to install it?” The answer is nuanced and matters for how you will fill the register starting in Lesson 7.2. Off-the-shelf extensions that offer send-capabilities are in scope for your register — you will see them, and you need a posture for them — but Module 7 asks you to evaluate them on minimum permissions. If the plugin has a drafts-only mode, you install it in that mode. If it does not, you either (a) install with the send permission disabled where possible, (b) decline the install and document why, or (c) document the install as a conscious, reviewed decision and add a near-term review date. There is no single right answer; there is a standard of care. Lesson 7.2’s minimum-viable-audit worksheet walks you through it.

Extensions you author are a different story. The authoring target this module sets is clean: a skill or a plugin you built delivers to you and to no one else. That is the only way you can be certain, in month nine, what your own extensions do. Any extension that fails this test is out of scope for Module 7’s custom work. If you want to build an autonomous outbound capability later, that is a post-course decision, made with your own eyes open, and not a Module 7 deliverable.