Plugin Planner
Save this as: /capstone/custom-plugin-v1/plan.md (or print and keep alongside your plan).
Fill order: three-condition check first (do you even need a plugin?) → manifest draft → permission-surface union → security questionnaire → uninstall-test plan. Do not skip ahead to writing code; the planner is the thinking.
A plugin exists to bundle. If none of the three conditions apply, stay with a loose skill.
Honesty beats brevity. The manifest is the contract, and the S1–S7 answers are what a future installer or a six-months-later you relies on to re-audit.
Header
Part 1 — The three-condition bundling check
A plugin is only the right shape if at least one of the three conditions applies. If none applies, a loose skill in .claude/skills/ is the right call. Check the boxes that apply and write the one-line evidence for each.
Shared scope. The capabilities read the same folder, use the same MCP connector, or share a config file that would otherwise be duplicated.
Evidence (one line):
Shared install/uninstall story. Installation wires credentials, connectors, or defaults you want to roll in and out as a set.
Evidence (one line):
Shared with someone else. You intend to hand the bundle to a named, small audience (family member, co-op, classmate) and want a single install step.
Evidence (one line):
Gate decision
If zero conditions apply, stop here. Your 7.3 skill is the right capstone artifact on its own; do not wrap it in a plugin to satisfy the module. (The module expects a plugin because most candidate bundles do meet at least one condition, but a loose skill plus a documented "why no plugin" note is also a valid Module 7 path.)
Conditions applying: ☐ 1 ☐ 2 ☐ 3
If only Condition 3 applies and the audience is "maybe someday," treat it as no condition and stay with loose skills.
Decision: ☐ Bundle as a plugin ☐ Keep as loose skill (document why)
Part 2 — Seven-field manifest draft
Fill every field. If a field genuinely does not apply (for instance, no MCP connectors), write none explicitly — do not leave blank.
| Field | Your draft |
|---|---|
| name kebab-case identifier |
|
| version semver; first ship is 1.0.0 |
|
| description 2–3 sentences. Descriptive + inclusive + exclusive (same discipline as skill descriptions, from 7.3). |
|
| author name + contact (email or handle) |
|
| bundled skills list, each with a one-line description |
|
| MCP connectors list, with granted verbs; none is valid |
|
| permission surface union across all bundled skills: reads / writes / sends / credentials |
Reference manifest shape (from Lesson 7.4)
Part 3 — Permission-surface union (honesty check)
Walk every bundled skill and list what it reads, writes, and sends. The union of these is your plugin's permission surface. A surface written as "reads files as needed" is a failed manifest — be specific.
Reads
Folders, mailboxes, calendars, conversation history, web domains, cached memories. If any source is "anything the user types," name it explicitly.
Writes
Files the plugin creates or modifies. Drafts count as writes. Where do they land?
Sends / posts
Module 7 rule: drafts and writes to your own files only. Anything outbound to a second human without a click is disqualifying. Write none here if that rule holds (it should).
Credentials / scopes
OAuth scopes requested. Whether credentials are shared across bundled skills or isolated. If no credentials, write none.
Part 4 — S1–S7 security questionnaire
S1–S5 are the audit baseline (same five as the Minimum Viable Audit from Lesson 7.2, now written for an installer of your plugin). S6 and S7 are the plugin-specific addenda. Answers below become SECURITY.md at the plugin root, 2–3 sentences each.
Written for the installer, not for you. Same shape as the manifest description.
Every verb, across every skill and every MCP. Do not assume the installer will read bundled skills individually; write the union here.
Plain-language sources. Folders, mailboxes, calendars, conversation history, cached memories. If any source is "anything the user types in chat," say so.
For a Module 7 capstone plugin, the honest answer must be: drafts and writes to the user's own files, nothing else. If anything else, stop — narrow or remove the capability before continuing.
Where credentials live. OAuth scopes. Shared vs isolated across bundled skills. If no credentials, say so.
Plugin-specific. Installing any bundle takes some decision out of the user's hands. Name it and name how the user can restore control (toggle off, uninstall, etc.).
Auto-update yes or no? Notification on permission delta? If manual updates, how is the installer expected to pull them?
Part 5 — Three permission-narrowing moves
Before you freeze the manifest, walk the three narrowing moves from Lesson 7.4 and note what you removed or tightened.
Move 1 — Split writes from sends.
Every outbound verb gets an explicit entry; "writes and sends" is never one bucket.
Move 2 — Scope reads narrowly.
If the plugin only needs ./research/, do not ask for the home directory. The narrowest scope that works is the right scope.
Move 3 — Drop the capability you were unsure about.
Any capability that made you pause in S2, S3, or S4 is a capability to remove from v1.0. Add it back in v1.1 only after a real need surfaces.
Part 6 — Uninstall-and-reinstall test plan
The plugin does not freeze until this test passes. A plugin with a broken uninstall is a plugin you cannot retire — and Module 7 requires retirable extensions.
- Install the plugin from its local folder. Confirm install completes without prompting for permissions not listed in the manifest.
- Trigger the bundled skill using a phrase from its description. Confirm the skill fires and produces the expected output.
- Save the install-plus-trigger session trace under traces/.
- Uninstall the plugin. Confirm zero orphan files, zero dangling credentials, zero lingering skills in the Cowork-tab registry.
- Reinstall the plugin. Confirm the install succeeds identically to the first install — same permission prompts, same trigger behavior.
- If any step fails, fix the plugin and re-run the full test from step 1. Do not freeze a plugin mid-fix.
- When all steps pass: copy custom-plugin-v1-draft/ to /capstone/custom-plugin-v1/ and freeze.
The uninstall test is the freeze gate.
A plugin that installs cleanly but leaves debris on uninstall is not a Module 7 capstone artifact. Ship a clean round-trip or do not ship.
Part 7 — Ready-to-author checklist
- At least one bundling condition applies, with one-line evidence written.
- Seven manifest fields drafted, none left blank (none written where applicable).
- Permission-surface union lists reads, writes, sends, credentials — each specific, not "as needed."
- S4 answers "drafts and writes to my own files, nothing else." If not, capability removed or plugin does not freeze as a Module 7 capstone.
- S1–S7 each answered in 2–3 sentences, ready to paste into SECURITY.md.
- Three permission-narrowing moves walked; one capability removed or tightened since draft.
- Uninstall-and-reinstall test plan understood; time blocked to run it before freeze.
This worksheet accompanies Lesson 7.4 of AI Architect Academy. Exact Cowork-tab plugin scaffolding commands and manifest schema live in the Recipe Book (/recipe-book/author-a-cowork-plugin.md). The bundling check, seven-field manifest, S1–S7 questionnaire, and uninstall-test gate are concept.