| 1 | --- |
| 2 | name: plugin-creator |
| 3 | description: Scaffold a local Codewhale plugin bundle with a versioned manifest, namespaced Skills, and an explicit trust review. |
| 4 | --- |
| 5 | |
| 6 | # Plugin Creator |
| 7 | |
| 8 | Use this skill when a user wants a local Codewhale plugin bundle. Trusted and |
| 9 | enabled bundles may add declarative Skills, commands, agents, hooks, and MCP |
| 10 | servers (stdio and remote) through the existing engines. LSP, native |
| 11 | extensions, filesystem roots, and lifecycle mutation are inventory-only. |
| 12 | |
| 13 | ## Workflow |
| 14 | |
| 15 | 1. Pick a Codewhale-owned location: |
| 16 | - User bundle: `~/.codewhale/plugins/<plugin-name>/` |
| 17 | - Workspace bundle: `<workspace>/.codewhale/plugins/<plugin-name>/` |
| 18 | 2. Normalize the bundle name to lowercase hyphen-case. |
| 19 | 3. Create `plugin.toml`: |
| 20 | |
| 21 | ```toml |
| 22 | schema_version = 1 |
| 23 | |
| 24 | [plugin] |
| 25 | name = "my-plugin" |
| 26 | version = "0.1.0" |
| 27 | description = "What this bundle provides" |
| 28 | |
| 29 | [skills] |
| 30 | path = "skills" |
| 31 | ``` |
| 32 | |
| 33 | 4. Put each Skill under `skills/<skill-name>/SKILL.md`. Codewhale exposes it |
| 34 | as `my-plugin:<skill-name>`, never as an unqualified command. |
| 35 | 5. Add `[mcp_servers.<name>]` only when the bundle needs an existing MCP |
| 36 | engine. Keep stdio commands and paths inside the bundle. Map local |
| 37 | environment values only as exact `${SOURCE_ENV}` references. For remote MCP, |
| 38 | use HTTPS (or loopback HTTP), forbid URL user information/query/fragment, |
| 39 | use only environment-backed headers or bearer tokens, and declare the exact |
| 40 | normalized endpoint host set in `[capabilities].network_hosts`. Never place |
| 41 | credentials in the manifest. |
| 42 | 6. Commands (`commands/*.md`), agents (`agents/*.toml`), and hooks |
| 43 | (`hooks/*.toml`) activate under the current policy — workspace bundles win |
| 44 | same-name collisions over user and built-in bundles. LSP, native |
| 45 | extensions, filesystem roots, and lifecycle mutation are inventory-only: |
| 46 | declare them only when inventorying future work. A bundle that declares |
| 47 | only unsupported surfaces cannot be enabled. |
| 48 | 7. Validate and review without executing bundle content: |
| 49 | - `/plugin validate <plugin-name>` |
| 50 | - `/plugin show <plugin-name>` |
| 51 | - `/plugin enable <plugin-name>` to open the content/capability review |
| 52 | - run the exact `/plugin trust ...` confirmation shown, then enable again |
| 53 | 8. Verify `/skills inspect` reports plugin provenance and `/plugin list` |
| 54 | reports the expected trust and activation state. Trust stages the reviewed |
| 55 | content but does not activate it; enablement rebuilds the current |
| 56 | workspace's Skill/MCP catalogue immediately. |
| 57 | |
| 58 | Every user and workspace bundle starts untrusted and disabled. Do not add a |
| 59 | marketplace, downloader, updater, compatibility scan, executable extension |
| 60 | runtime, or automatic trust flow; those surfaces are outside v0.9.1. |
| 61 |