agentleFS
Sign inStart free
Hans010101Hans010101/bitworld/skills/paperclip-create-plugin/SKILL.md

paperclip-create-plugin

Skill1 starsChanged 8 months agoMITView on GitHub

Create new Paperclip plugins with the current alpha SDK/runtime. Use when scaffolding a plugin package, adding a new example plugin, or updating plugin authoring docs. Covers the supported worker/UI surface, route conventions, scaffold flow, and verification steps.

4 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

12 rules. About 0 are common, 10 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the task is to create, scaffold, or document a Paperclip plugin.

    line 12
  2. Distinctive:

    Read these first when needed:

    line 16
  3. Distinctive:

    no host-provided shared plugin UI component kit yet

    line 28
  4. Distinctive:

    Use the scaffold package instead of hand-writing the boilerplate:

    line 33
  5. Distinctive:

    Make sure the plugin:

    line 64
  6. Very specific:

    does not use ctx.assets

    line 67
  7. Distinctive:

    does not import host UI component stubs

    line 68
  8. Distinctive:

    Only do this if the user wants the plugin surfaced as a bundled example.

    line 80
  9. Very specific:

    If you changed SDK/host/plugin runtime code too, also run broader repo checks as appropriate.

    line 92
  10. Distinctive:

    When authoring or updating plugin docs:

    line 96
  11. Distinctive:

    do not promise host UI components or asset APIs

    line 100
  12. Distinctive:

    prefer npm-package deployment guidance over repo-local workflows for production

    line 101

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Create a Paperclip Plugin

Use this skill when the task is to create, scaffold, or document a Paperclip plugin.

1. Ground rules

Read these first when needed:

  1. doc/plugins/PLUGIN_AUTHORING_GUIDE.md
  2. packages/plugins/sdk/README.md
  3. doc/plugins/PLUGIN_SPEC.md only for future-looking context

Current runtime assumptions:

  • plugin workers are trusted code
  • plugin UI is trusted same-origin host code
  • worker APIs are capability-gated
  • plugin UI is not sandboxed by manifest capabilities
  • no host-provided shared plugin UI component kit yet
  • ctx.assets is not supported in the current runtime

2. Preferred workflow

Use the scaffold package instead of hand-writing the boilerplate:

pnpm --filter @paperclipai/create-paperclip-plugin build
node packages/plugins/create-paperclip-plugin/dist/index.js <npm-package-name> --output <target-dir>

For a plugin that lives outside the Paperclip repo, pass --sdk-path and let the scaffold snapshot the local SDK/shared packages into .paperclip-sdk/:

pnpm --filter @paperclipai/create-paperclip-plugin build
node packages/plugins/create-paperclip-plugin/dist/index.js @acme/plugin-name \
  --output /absolute/path/to/plugin-repos \
  --sdk-path /absolute/path/to/paperclip/packages/plugins/sdk

Recommended target inside this repo:

  • packages/plugins/examples/ for example plugins
  • another packages/plugins/<name>/ folder if it is becoming a real package

3. After scaffolding

Check and adjust:

  • src/manifest.ts
  • src/worker.ts
  • src/ui/index.tsx
  • tests/plugin.spec.ts
  • package.json

Make sure the plugin:

  • declares only supported capabilities
  • does not use ctx.assets
  • does not import host UI component stubs
  • keeps UI self-contained
  • uses routePath only on page slots
  • is installed into Paperclip from an absolute local path during development

4. If the plugin should appear in the app

For bundled example/discoverable behavior, update the relevant host wiring:

  • bundled example list in server/src/routes/plugins.ts
  • any docs that list in-repo examples

Only do this if the user wants the plugin surfaced as a bundled example.

5. Verification

Always run:

pnpm --filter <plugin-package> typecheck
pnpm --filter <plugin-package> test
pnpm --filter <plugin-package> build

If you changed SDK/host/plugin runtime code too, also run broader repo checks as appropriate.

6. Documentation expectations

When authoring or updating plugin docs:

  • distinguish current implementation from future spec ideas
  • be explicit about the trusted-code model
  • do not promise host UI components or asset APIs
  • prefer npm-package deployment guidance over repo-local workflows for production

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free