Evaluating and using existing extensions.

Off-the-shelf first, and the four reasons to build CORE

The default posture a Module 7 student should hold — and, more importantly, should keep holding through Lesson 7.5 — is: if a working off-the-shelf extension does the job I need, I install it rather than write my own.

There are four reasons this is the right default, even in a course whose job is teaching you to author extensions:

• Authoring has compounding maintenance cost. Every custom skill you write is a line item on a list you will later have to keep current. Descriptions drift. Underlying models change. Tooling changes. If the off-the-shelf option exists and is maintained, someone else absorbs that cost on your behalf.
• Off-the-shelf options often beat your first draft on description-tuning. A well-written third-party skill has had many triggers tested and refined by the author. Your first skill is, almost by definition, undertuned. In Lesson 7.3 you will learn why this matters; for now, trust that a good community skill is usually a more reliable tool than a good first-effort custom one.
• Evaluation skill is itself the Module 7 capability you need longest. You will evaluate dozens of off-the-shelf extensions across your life. You will author, at most, a handful. The higher-leverage skill is knowing how to tell a good extension from a bad one at install time — the audit you learn this lesson.
• The register does not care where a row came from. A row in the register owes its keep-or-retire decision to the same questions whether you authored the extension or installed it. Investing in audit discipline pays off on both sides of the register.

Against all of that, there are exactly four conditions under which you should author your own. The off-the-shelf-first heuristic flips — and only then — when any of the following is true:

1. No off-the-shelf option exists for the shape you care about. You searched, you asked, and nothing does what you need. (This is rarer than students expect.)
2. Every available off-the-shelf option fails the audit. The five audit questions (below) cannot all be answered satisfactorily, or they are answered in ways that violate the Module 6 rule.
3. Your need is materially more specific than the generic versions. The available extensions are aimed at a broader audience, and your workflow depends on a specificity the generic versions cannot match without authoring the thin layer yourself.
4. You are building it for pedagogical reasons. Lesson 7.3 is this reason — you will author a skill even if an off-the-shelf option would do, because the authoring itself is the learning objective. Outside the course, this is not usually a reason to build.

If none of the four conditions applies, install, do not author. A student who reflexively authors when an off-the-shelf option would serve is a student who will have twenty-five skills in nine months, twelve of them half-finished.

The minimum viable audit: five questions CORE

Before any extension enters the register — installed or declined — you run the audit. The five questions are deliberately plain. They exist to force you to consult the documentation, the manifest, and the source rather than inferring from the name or the reviews.

Q1 — What does it do? A one- or two-sentence description of the job the extension is meant to perform. Write it in your own words, not copy-pasted from the marketing blurb. If you cannot write it in your own words after reading the documentation, the documentation is too vague or the extension tries to do too many things. Either is a reason to be suspicious.

Q2 — What tools does it grant the agent? An extension is installed to make the agent more capable. Every new capability is a new thing the agent can do without asking you. Read the manifest and the permission list. Write down the tool set in plain language: “this skill grants the agent the ability to read the user’s calendar and create draft events; it does not grant send, post, or auto-accept capabilities.” If the manifest does not enumerate tools, treat that as the same red flag you would treat from a browser extension that cannot tell you what sites it runs on.

Q3 — What data can it read? Read is not the same as write. An extension that reads your entire Gmail archive but never sends is a privacy question, not a safety question. An extension that reads your entire local filesystem is a privacy and credential question because API keys often live in files. Name the data sources plainly: “local folder ~/projects/,” “Gmail labels agent-access and inbox,” “any page the user visits in Chrome.” If the data scope is “unbounded” or “whatever the user grants in session,” treat that as a flag to install more narrowly if the tool supports scoping, or to decline if it does not.

Q4 — What can it send, post, or write? This is the Module 6 audience question applied to install-time. An extension that drafts is in scope. An extension that sends email, posts to channels, RSVPs to events, or otherwise puts text in front of a second human is where the module expects friction. Three acceptable answers:

• “It only drafts and writes to files I control.” Install.
• “It can send, but has a drafts-only mode I can enable.” Install with drafts-only. Record the setting in the register.
• “It can send and cannot be limited to drafts.” Decline or document a conscious override (below) with a short review date.

There is no acceptable fourth answer. An extension that auto-sends without a mode you can configure and that you install anyway — without documenting why — is the carve-out the module refuses to allow. You are not banned from ever installing such an extension in real life; you are banned from installing one without writing down, in the register, that you are consciously doing it.

Q5 — How does it handle credentials? Credentials are the quiet failure surface of the extension layer. The question has three parts:

• Where are the credentials stored? An OS-level keychain / keyring is good. A .env file in the home directory is tolerable if you know it is there. A field in a config file readable by any process is bad.
• What is their scope? A token granted for “read Calendar” is different from a token granted for “read, write, delete, share Calendar.” Prefer least-privilege tokens. Most OAuth providers let you see the requested scopes at grant time; read them.
• Are they shared across extensions? A plugin that reuses the same OAuth grant another plugin is already using saves the student a click but creates a wider-blast-radius credential. Prefer per-extension credentials where the tool allows it.

If the documentation does not answer the credential question, ask it directly of the author (many extensions have a support channel) or open the source and find the auth section. If neither is possible, decline.

Reading a manifest, a description, and a changelog CORE

All three artifacts live in the extension. All three are short. All three are read by students who know what they are looking for and skipped by students who do not. Three signals each.

The manifest. (In Cowork plugins, the file at the root that names the plugin; in a Claude Code skill, the SKILL.md frontmatter; in an MCP connector, the server’s config.)

• Is the version number current? A plugin whose manifest says v0.1 and whose last commit is eight months old is not abandoned per se, but it is not maintained either. Add a “likely stale” note to the register and reduce the next-review date.
• Are tools and permissions enumerated? If the manifest lists what the extension can do, it has thought about it. If the manifest says nothing about tools and the extension still runs, the author is offloading that thought to you.
• Is the author identifiable? A named author with a contact surface (GitHub, website, support email) is a better counterparty than anonymous. Anonymous can still be fine — many open-source projects are anonymous — but it changes the risk budget for what you install.

The description. The field the agent reads to decide whether to trigger the skill. Read it as the agent would:

• Is it specific about inputs and outputs? “Summarizes long documents” is vague. “Summarizes documents longer than 2,000 words into a 5-bullet executive summary with a key-quote callout” is specific. The second one is more likely to fire reliably and less likely to misfire.
• Does it list triggering phrases? A good description often names the phrases the agent should listen for: “Use when the user asks for a research sweep, source triangulation, or competitive landscape.” This is the author telling you — and the model — exactly when this skill is the right tool.
• Is it honest about what it does not do? The best skill descriptions include a short exclusion: “Do not use for informal summaries, single-article reads, or conversational chitchat.” If the description overclaims — “handles all research needs” — expect misfires.

The changelog. The history of what the extension has done over time:

• Is it current? A changelog that stops in 2024 is a tell.
• Do changes enlarge or narrow the permission surface? A changelog entry that adds a new outbound capability between versions is an important thing to notice. If you approved v1.2 on the basis of an audit, v1.5 may not merit the same approval; the changelog is how you find out.
• Does the author respond to issues? A changelog that shows quick turnaround on bugs — even bugs the author did not introduce — is a signal of care. A changelog with nothing but feature bumps and no bug fixes is unusual (every non-trivial extension has bugs) and worth noticing.

The outbound decision matrix CORE

Many off-the-shelf extensions offer outbound capabilities. This is not a flaw of the ecosystem; outbound is genuinely useful, and many responsible authors build it. The Module 7 posture on outbound, carried forward from Module 6, is a five-way decision:

Option A — Install with a clean audit. The extension only drafts, writes to files you control, or delivers to you. No outbound. No decision to make. Install.

Option B — Install with drafts-only mode enabled. The extension could send, but has a mode you can set at install time that limits it to drafting. Record the setting in the register (“installed with send_enabled: false”). Revisit the setting in the hygiene ritual — a later version might silently change the default.

Option C — Install with send disabled via platform. The extension does not support a drafts-only mode, but the platform does — the underlying email provider, calendar system, or similar has a permission scope that lets you grant read-and-draft without send. Prefer this to Option D. Record the scope you granted.

Option D — Decline. The extension cannot be narrowed to drafts-only at any layer — extension or platform — and you are unwilling to grant send. Write a two-sentence rationale in the register: “Declined because the extension requires send permission and has no drafts-only mode; same capability is available from [alternative] with a narrower permission.”

Option E — Conscious override. The extension can only run with send enabled, no narrower path exists, and you have a specific reason to proceed. This is an intentional exception to the audience-only-you rule and therefore requires extra care. Write in the register: (a) why you are making the exception, (b) what specifically the extension may send and to whom, (c) a next-review date no more than 30 days out (not 90 — send-capable extensions get a tighter review cadence), and (d) the condition under which you will reverse the decision. A conscious override without all four fields is not a conscious override; it is a carve-out dressed up as one.

Across a Module 7 student’s register, a healthy mix has most rows at Option A or B, a small number at C, a steady stream at D (declines are a common and healthy outcome), and at most one at E. A register with three or more conscious overrides is drifting; the hygiene ritual in Lesson 7.5 surfaces that drift.

Installing a plugin, installing a skill RECIPE