Plugin Development
Practical guidance for packaging and documenting Curator-compatible plugins.
Plugin development should start from the real extension surface you actually have today.
What exists today
Curator Marketplace supports plugin listings, releases, compatibility metadata, and download delivery. That makes it a distribution workflow for plugins, even though the engine does not yet expose a large formal plugin API in these docs.
What this means for developers
Today, plugin work is best treated as a packaging and compatibility discipline:
- define what your plugin changes
- declare the compatible Curator versions
- attach release artifacts clearly
- document installation and support expectations
Release expectations
When you publish a plugin for the marketplace, make sure each release answers these questions clearly:
- which Curator version range it supports
- what files are included in the release archive
- whether the plugin changes UI, behavior, or data handling
- how users should install or replace it
Keep the contract narrow
If you do not have a stable public API yet, document the integration points you control and avoid promising broad compatibility you cannot enforce. That protects both maintainers and buyers.
Suggested documentation checklist
- installation steps
- compatibility range
- release notes
- support contact
- rollback guidance
As the engine's extension hooks get formalized, this page can grow into a deeper technical reference. For now, it should stay practical and honest.