Extension Register — Row Template

Module 7 capstone scaffold · introduced in Lesson 7.1 · concept shape + recipe path fields

What this is. The header block and row template for extension-register-v1-draft.md, the seventh capstone artifact of the course. Copy the header once into the file at the start of Lesson 7.1. Add one row per extension — off-the-shelf, custom, declined, or retired — at each lesson’s project checkpoint.

How to use. Unlike Module 6’s automation register (one row per live task), the extension register is honest about the whole set: the four you audited and declined in 7.2 are rows; the skill you authored in 7.3 is a row; the plugin you packaged in 7.4 is a row. Declines and retires stay in the register with their reason.

Two load-bearing rules of Module 7 — keep these visible while you fill in rows.

Audience = only you. · Drafts, not sends. — every extension you author or install inherits both norms.

Header block — copy once into extension-register-v1-draft.md

# Extension Register — v1 (draft) Owner: <your name> Started: <YYYY-MM-DD> Platform(s) this register covers: <Claude Code CLI | Cowork tab | both | other> Skill folder(s): <~/.claude/skills/ and/or <project>/.claude/skills/> Plugin install surface: <Cowork-tab plugin manager, plugin marketplace name> ## Posture reference Soft ceiling on active rows: <the number you can defend> Maximum next-review interval: 90 days Safety norms that apply to every row: audience = only you; drafts, not sends. ## Taxonomy Every row is one of: one-off-prompt (recorded here only if it’s a candidate for promotion), saved-prompt, memory, skill, plugin, mcp-connector. See Lesson 7.1 for the six-place taxonomy.

Row template — use once per extension

## Entry <N>: <Extension name> - Type: <saved-prompt | memory | skill | plugin | mcp-connector> - What it does: <one sentence; match the description field if it has one> - Where it lives: <~/.claude/skills/<name>/, Cowork-tab plugin ID, MCP server URL, etc.> - Invocation: <how the agent reaches for it — description-matched, slash command /name, explicit user request, keyword, schedule> - Audience: me only ← required in Module 7; if not, row is not allowed - Permission surface: <every tool call granted, every read/write scope, every MCP connector; union of bundled skills if a plugin> - Data it reads: <the inputs the extension is allowed to see> - Data it sends out: <what leaves the local machine, to whom, under whose credential; “none” is a valid answer and is the default> - Credential handling: <where keys live, rotation cadence> - Budget / model: <per-invocation cost estimate, default model, caps> - Last invoked: <YYYY-MM-DD> - Last success: <YYYY-MM-DD> (invocation produced a usable output AND I acted on it or filed it) - Next review: <YYYY-MM-DD> (within 90 days) - Keep-or-retire condition: <the specific observable that would tell future-you this row is ready to retire — e.g., “I have not invoked this skill in 30 days,” or “the MCP connector’s upstream tool has reached end-of-life”> - Status: Active | Drafts-only | Paused (past review) | Declined | Retired YYYY-MM-DD - Install source: <off-the-shelf marketplace URL | authored by me | bundled in <plugin-name> | MCP server URL> - Audit reference: <path to the filled Minimum Viable Audit or Plugin Planner · Security Questionnaire that cleared this row> ### Notes <free-form — what this extension is learning to do well, what it still gets wrong, anything future-you will want when the review date arrives>

Columns the register enforces

  1. Every row has every column filled. A blank on Data it sends out is not “unknown” — it is a row you are not allowed to keep active until you know the answer.
  2. Audience = me only. Any extension whose audience is someone else stays on the “do not install” list through Module 7.
  3. Permission surface is the union. For a plugin, list every tool every bundled skill is allowed to call. A plugin is one install decision; its surface is everything that comes with it.
  4. Next review is within 90 days. Past-due reviews pause the row until the quarterly hygiene ritual (Lesson 7.5) runs.
  5. Declines are rows, not absences. When Lesson 7.2’s audit produces an “Option D decline,” file it as a row with Status: Declined and a one-line reason. The register’s institutional memory includes what you chose not to install.
  6. Retires are rows too. A retired extension’s row stays, with the retirement date and the signal that triggered it. Deletion loses the lesson.
  7. Audit reference is a real path. Every active row points at the filled-in worksheet that cleared it. If the audit is not on disk, the row is not allowed to be active.

Example filled rows (reference only; use your own values)

Example A — an off-the-shelf skill kept after audit

## Entry 2: diff-reviewer (off-the-shelf) - Type: skill - What it does: Walks a git diff through the Module 3 four-question review and highlights any changes outside the stated scope. - Where it lives: ~/.claude/skills/diff-reviewer/ - Invocation: description-matched; fires when the user asks to “review this diff” or “check scope on this change.” - Audience: me only - Permission surface: read-only access to the current repo tree; no network calls; no write access. - Data it reads: files changed in the working tree + HEAD diff. - Data it sends out: none. - Credential handling: none (no external API). - Budget / model: ~$0.04/invocation, default model. - Last invoked: 2026-04-18 - Last success: 2026-04-18 - Next review: 2026-07-17 - Keep-or-retire condition: I have not invoked this skill in 30 days, OR Module 3’s four-question review gets updated upstream. - Status: Active - Install source: https://plugins.example/skills/diff-reviewer@1.2.0 - Audit reference: /capstone/extension-artifacts/audit-diff-reviewer.md ### Notes Fires cleanly on bounded diffs. Over-flags rename-only commits; check traces/ for a false-positive example.

Example B — an extension declined at audit

## Entry 4: repo-summarizer (declined) - Type: plugin - What it does: Summarizes an entire repository into a one-page brief using LLM calls over every file. - Where it lives: not installed. - Invocation: — - Audience: — - Permission surface: read-access to all files in any opened folder, network calls to the plugin author’s hosted endpoint. - Data it reads: every file in the granted folder, sent to a hosted third-party endpoint. - Data it sends out: file contents (including code), to the plugin author’s endpoint, under the plugin author’s credential. - Credential handling: plugin author’s key; not rotated by me. - Budget / model: — - Last invoked: — - Last success: — - Next review: 2026-10-18 (re-evaluate if plugin ships a local option) - Keep-or-retire condition: — - Status: Declined (Option D, Lesson 7.2 outbound matrix) - Install source: https://plugins.example/plugins/repo-summarizer - Audit reference: /capstone/extension-artifacts/audit-repo-summarizer.md ### Notes Fails Question 4 of the minimum viable audit: sends full file contents to a third party under a credential I don’t control. Revisit if a local-only mode ships.

Print this page. Paste the header block into your draft register. Add one row per extension, in the order the lessons build them.