paperclip-create-plugin

A CLI-first workflow for building and iterating on external Paperclip plugins against a running local Paperclip instance. The guiding principle is that plugins are their own packages: unless a bundled in-repo example is explicitly requested, plugin source is scaffolded outside the Paperclip checkout and installed into the running instance by absolute local path, keeping Paperclip core untouched.

Scaffolding uses paperclipai plugin init, which accepts optional flags for output directory, starter template (default, connector, workspace, or environment), manifest category, display name, description, author, and an SDK snapshot path for developing against an unreleased SDK. On success it prints the exact next commands to run. The local development loop is pnpm install, pnpm dev (an esbuild watch that rebuilds dist/manifest.js, dist/worker.js, and dist/ui/), and paperclipai plugin install with the plugin's absolute path. Because the server watches built outputs for local-path plugins and restarts the worker on rebuild, reinstalling after every edit is unnecessary; plugin list and plugin inspect confirm the installed key, version, and status.

The doc is explicit about current runtime assumptions: plugin workers and UI are trusted code, worker APIs are capability-gated, the plugin UI is not sandboxed by manifest capabilities, there is no shared host UI component kit yet, and ctx.assets is unsupported. A sanity checklist verifies the manifest, worker entry, UI entry, placeholder test, and the package.json paperclipPlugin block. Verification before declaring success is pnpm typecheck, pnpm test, and pnpm build, and a reporting checklist covers scaffold path, commands run, install status, test/build results, and any reload limitations. Local-path installs are the supported development model, while npm packages are the production deployment path.