Extension hygiene, sharing, and the register freeze.

Why hygiene is continuous, not one-time CORE

An extension installed today is not the same thing as an extension running in your life in nine months. Three things drift, each on its own timescale:

The underlying tool drifts. The model the skill was written against gets retired; a newer version handles phrasing differently. The MCP connector’s API changes between minor versions. The folder layout the extension reads is reorganized by a different tool. None of these fire a loud alarm. The extension continues to run — it just slowly does worse, or produces outputs that look right but drift from the contract.

Your work drifts. The research pattern your research-sweep skill was tuned for was specific to one kind of academic project. A year later, most of your research is on a different topic with different source types. The skill still fires, but it is tuned for a world you no longer live in. A skill that was high-leverage at authoring time can become low-leverage or worse without the student noticing.

The ecosystem drifts. A community plugin was the best option at install time. Six months later, a more mature option with a tighter permission surface has landed in the Cowork marketplace. Your registered plugin still works, but a student who is paying attention would retire it in favor of the newer option. The old plugin did nothing wrong; it simply got out-matured.

Against all three kinds of drift, the register row is not an automatic fix. The register is a surfacing tool — it puts drift in front of you at a predictable cadence so you can decide what to do. The hygiene ritual is the practice that turns the register from a document into a habit.

The ritual is quarterly. Ninety days is not a magic number; it is a practical one. Faster than 90 days and the ritual becomes a recurring interruption to real work. Slower than 90 days and drift accumulates past the point where individual decisions are easy to make. Every capstone register row carries a next review date ≤ 90 days out. In a well-run register, the hygiene ritual touches every row at least once per quarter.

The hygiene ritual: five steps CORE

One sitting, quarterly. Every step is done for every row before moving to the next step; the steps surface different kinds of drift, and you want to see the full pattern before deciding any individual row’s fate.

Step 1 — Read descriptions aloud. For each row, read the what it does column and the extension’s live description aloud. Two questions: “Does this describe the work I actually do?” and “If a smart classmate read only this description, would they pick this extension for that work?” A description that reads clearly at install time frequently reads vaguely nine months later — your work has moved. Flag any row where either question gets a weak yes.

Step 2 — Check permissions against the row’s audit. Open each authored row’s SECURITY.md. Open each installed row’s manifest and changelog. Compare the current permission surface to what the row recorded at audit time. Any widening — a new read scope, a new write capability, a new outbound verb — is a surfacing event. Even if the widening is benign, it is a conscious decision point.

Step 3 — Check review dates. Any row whose next review date has passed gets flagged. A row more than 30 days past review is automatically moved to refactor-or-retire in Step 5. A row within 30 days of passing gets re-reviewed now; no point in deferring another 90 days on a row that is already sliding.

Step 4 — Look for collisions. Read every row’s invocation phrases side by side. Do any two rows share trigger phrases? Do any two rows describe overlapping work? Collisions are the most common cause of silent misfires — the agent picks the wrong tool because two descriptions looked equally applicable. Mark each collision for a Step 5 decision.

Step 5 — Decide per row: keep, refactor, replace, retire.

• Keep. The row still earns its place. Description still matches your work. Permission surface unchanged or consciously approved. No collisions. Set a new next review date and move on.
• Refactor. The row still earns its place, but the description has drifted, or the body needs tightening, or a collision with another row needs disambiguation. Schedule the refactor work — short for a description tightening, longer for a body rewrite. Set a next review sooner than the standard cadence so the refactor actually happens.
• Replace. A better option has matured in the ecosystem, or a more specific version of the same capability is now available. Install the replacement, smoke-test it, and retire the old row. Write a superseded by note in the retired row’s final entry.
• Retire. The row no longer earns its place. Uninstall, remove the credentials, update the register to show the row as retired with a date and a reason. A retired row is not deleted from the register — it is marked retired. The history is useful; you will see this extension again and will want the record of why you passed.

The ritual is a small practice that prevents a large failure mode. A student who runs it honestly, twice, finishes their first year with a register that still serves them. A student who skips it finishes their first year with the pile-up that Lesson 7.1 warned about.

The five retirement signals CORE

Retirement is the harder half of hygiene. Students hoard extensions the way they hoard browser tabs — the cost of keeping is invisible, the cost of retiring is a small but real decision. The five retirement signals make the decision explicit. Any one of the five is a reason to retire; two or more and the decision is nearly automatic.

Signal 1 — Use has stopped. The extension has not been invoked in the last 30–60 days. This is the quietest signal and the strongest. An extension you have not reached for in two months is not earning its keep. Exception: seasonal extensions (a tax-prep plugin invoked once a year, a college-app-deadline watcher used only in autumn) have legitimate long gaps; tag those in the register so the ritual does not flag them incorrectly.

Signal 2 — The underlying tool has changed. The model family was deprecated. The MCP connector’s API moved. The source data format shifted. Something the extension depends on is no longer the same shape. An extension running on a drifted foundation produces drifted output without saying so. Retire, or refactor to the current tool.

Signal 3 — The description no longer matches your work. Step 1 of the ritual surfaces this. A research-sweep skill tuned for academic triangulation, used by a student who has moved to industry-focused competitive research, is not doing what its description claims. Either refactor the description (and probably the body) to match the current work, or retire.

Signal 4 — The permission surface has widened. A community plugin added a new outbound capability in the last version; your authored plugin needed a broader read scope in the last revision; an MCP connector now grants verbs you did not approve. Widenings are the signal you most need to act on quickly because the trust you gave the extension was trust in the narrower version.

Signal 5 — A better option has matured. A new off-the-shelf option has landed that covers the same job with a tighter permission surface, better documentation, or active maintenance. Retiring in favor of a better option is a feature of ecosystem health, not a failure of your work.

Sharing posture: when and how CORE

You will end Module 7 with at least one custom skill and one custom plugin. At some point you will ask: should I share these? The module’s answer is narrow. Most students should not share in Module 7. The reasons are stable across first-year extension authors:

• Your first custom skill is tuned for your work. Its description fires reliably on your requests because it is written in your voice and trained against your phrasing. Another person reading it will get misfires you did not see.
• Your SECURITY.md is honest about the v1.0 permission surface. If someone else installs it and you later ship v1.1 that widens the surface, you have created an obligation you may not be ready to keep. Module 9 will go deeper into the supply-chain discipline this requires; Module 7 is honest about the cost.
• Sharing is not a rite of passage. You can complete Module 7 — including the capstone — by building extensions that only you use. Sharing is a separate decision with its own discipline.

That said, there are cases where sharing is reasonable, and the module does not forbid it. Three postures, from most to least common for a Module 7 graduate:

Posture A — Do not share. The common and recommended default. Your extensions are yours. Revisit the question when you have authored three or four that have survived multiple hygiene cycles without refactoring. First-year extensions are usually not ready.

Posture B — Private share with a named, small audience. A family member, a co-op classmate, a peer group. The audience is small enough that you know their setup, their skill level, and their risk posture. Ship with the full SECURITY.md, a README.md that names them as the intended audience, and a commitment to notify them manually when you ship an update. No marketplace listing. Audience-only-you extends: the bundle delivers only to the named recipient, in the same narrow way your original bundle delivers only to you.

Posture C — Public share. A marketplace listing, an open repo, an unknown audience. The bar is much higher: your plugin must survive a full quarter of your own use without refactoring, ship with a maintained changelog and a commitment to respond to permission-expansion questions, and answer Module 9’s supply-chain discipline. Few Module 7 students should publish in their first year; those who do should do so with eyes open, and should treat the plugin’s maintenance as a recurring commitment, not a one-time ship.

The sharing decision does not have to be made during Module 7. The frozen v1 of your skill and plugin are artifacts of your own learning and work. If, six months from now, your hygiene ritual surfaces that your skill has survived three quarterly reviews without needing refactoring, reconsider the question. In the meantime, the posture is: you are the audience.

Freezing the register and the retrospective RECIPE

Lesson 7.5’s deliverable is the seventh capstone freeze. This section is the how-to, short and concrete.

Step 1 — Run the hygiene ritual across every row. Use /resources/module-07/hygiene-ritual.md as the worksheet. Every row gets the five-step treatment. For each row, the ritual ends with one of keep, refactor, replace, retire, written into the row’s status column with today’s date.

Step 2 — Apply refactors and retires immediately. Refactors happen now — tighten the description, fix the collision, adjust the body. If a refactor is more than a small in-place fix, set a next review date soon and block time for it; do not defer it by a quarter. Retires happen now — uninstall, revoke credentials, mark the row retired.

Step 3 — Verify the final register has between 5 and 7 active rows. A register with fewer than 5 rows is under-populated for a Module 7 graduate (you need at least two installed, two declined, the custom skill, and the custom plugin; that is 6 rows). More than 7 rows at the end of Module 7 is probably too many — some of them likely should be retired. The 5–7 target is approximate; the honest answer is more important than the count.

Step 4 — Copy extension-register-v1-draft.md to extension-register-v1.md. This is the freeze. From this point, the register-v1 file is immutable; future changes go into register-v2 when you are ready.

Step 5 — Verify /capstone/custom-skill-v1/ and /capstone/custom-plugin-v1/ contents. Everything listed in the Lesson 7.3 and 7.4 freezes is present. CHANGELOG.md has dated entries. traces/ has two real-use runs each.

Step 6 — Write the Module 7 retrospective. Add a new section to my-first-loop.md: Module 7 retrospective. 300–500 words, four questions in order:

• What did I ship? Name the register, the skill, the plugin. One or two sentences each.
• What surprised me? The most surprising thing you learned. Often this is a description-tuning discovery or an install-time audit discovery.
• What would I build next? If Module 7 had six more lessons, what would you want the next extension to be? This is the honest forecast of where your authoring is headed.
• One concrete thing I learned about description-as-classifier. The module’s headline insight; the retrospective asks you to name a specific refinement it caused in your practice.

Step 7 — Update the Extension Posture. Return to the Extension Posture block in my-first-loop.md (written in Lesson 7.1) and revise it to reflect the rules you now actually follow. Your pre-module rule was a guess; your post-module rule is informed. Keep both visible so future-you can see the delta.