| name | plugin-creator |
| description | Creates opt-in plugin packs with manifests + module scaffolding for Claude/Codex. Triggers: new plugin, plugin pack, plugin scaffold. |
| effort | high |
| disable-model-invocation | true |
| argument-hint | [plugin pack name or domain] |
| allowed-tools | Read, Write, Edit, Bash, Grep, Glob |
Plugin Creator
$ARGUMENTS
Create a new experimental opt-in plugin pack following ai-toolkit conventions.
Workflow
- Capture scope -- what domain should the plugin pack own?
- Pick packaging model -- domain pack, policy pack, or hook/observability pack?
- Define manifest -- name, description, version, domain, compatibility, included assets
- Select assets -- agents, skills, rules, hooks, docs, templates
- Add scaffolding -- create
plugin.json, README.md, and optional subdirectories
- Validate -- manifest JSON, included asset references, executable hooks, documentation links
Directory Layout
app/plugins/<plugin-name>/
├── plugin.json
├── README.md
├── agents/ # optional
├── skills/ # optional
├── hooks/ # optional
├── rules/ # optional
└── templates/ # optional
Manifest Template
{
"name": "memory-pack",
"description": "Domain plugin pack for persistent cross-session memory.",
"version": "1.0.0",
"domain": "memory",
"type": "plugin-pack",
"status": "experimental",
"requires": {
"ai-toolkit": ">=1.0.0",
"claude-code": ">=1.0.33"
},
"includes": {
"agents": [],
"skills": ["mem-search"],
"rules": [],
"hooks":
The two hooks are files the pack owns, under app/plugins/memory-pack/hooks/.
That is what makes this a pack rather than a bookmark: installing it puts scripts
on disk and entries in the host's hook config that were not there before.
Authoring Rules
- MUST keep packs domain-scoped — "memory-pack", "mobile-pack", not "misc-pack"
- MUST install something the core install does not already provide.
ai-toolkit install links every core skill and agent, so a pack whose includes names only core assets installs zero files and is a no-op. Verify before shipping: install core into a throwaway HOME, then install the pack, and confirm the file count changed. Nine packs were removed in v4.20.0 for failing exactly this check.
- MUST reference existing toolkit assets rather than forking them — but referencing alone is not a pack. A pack earns its existence through hooks, scripts, or assets of its own; the reference list is context, not content.
- MUST ship a valid
plugin.json with name, description, version, domain, type, status, and includes
- NEVER have a pack silently alter default global install behavior — experimental packs are opt-in only
- NEVER copy an agent or skill file into a pack when referencing the toolkit-level version suffices; duplication creates drift
- CRITICAL: optional hooks bundled in a pack must be executable (
chmod +x) and documented in the pack README with their install semantics
- MANDATORY: the pack README names supported runtimes (
claude, codex, or all) and explains that the pack is not part of the default install
Gotchas
- Plugin packs are discovered by scanning
app/plugins/*/plugin.json. A pack with a missing or malformed plugin.json is silently ignored — no error surfaces. Check with ls app/plugins/*/plugin.json and jq . app/plugins/*/plugin.json.
- The
status: experimental flag gates visibility in some install paths — marking a pack "stable" before it is audited can make it install by default for every user. Keep experimental until the pack has eaten its own dogfood.
- Packs that include hooks inherit the toolkit's hook merge rules (
_source: "ai-toolkit"). Hooks without the _source tag survive ai-toolkit update and can leak into other packs' merge pools.
- Versions in
plugin.json are separate from the toolkit version. A pack at v1.2 running inside toolkit v2.11 may still satisfy requires.ai-toolkit: >=1.0.0 but mean nothing about actual compatibility — test against the current toolkit before tagging.
- Codex-runtime packs need matching
.agents/rules/ and .codex/hooks.json variants; a plugin that only ships Claude assets looks broken under Codex CLI. Declare runtime support explicitly.
Validation Checklist
When NOT to Use
- For an individual skill (slash command or knowledge doc) — use
/skill-creator
- For an individual agent — use
/agent-creator
- For a single hook (not a pack) — use
/hook-creator
- For an MCP server — use
/mcp-builder
- For modifying an existing plugin pack — edit its files directly; this skill is create-only