Skip to main content

Publishing Plugins

Publish your plugins to the systemprompt.io marketplace. Share your integrations with your team or the community.

Once you have built and tested your plugin, you can publish it to make it available to others. systemprompt.io supports publishing to your team privately or to the public marketplace.

Prerequisites

Before publishing, confirm that:

  • Your plugin has been tested and all skills and tools work correctly. See Creating Plugins for testing instructions.
  • All metadata is complete -- name, description, version, and tags.
  • Any configuration fields have clear labels and descriptions.
  • Your plugin version follows semantic versioning (major.minor.patch).

Step 1: Choose Visibility

systemprompt.io offers three visibility levels for published plugins.

Private -- only you can use the plugin. This is the default for all new plugins. Use this for personal tools or plugins still in development.

Team -- everyone in your workspace can discover and install the plugin. Use this for internal tools that your organization needs but are not relevant to the broader community.

Public -- the plugin is listed in the systemprompt.io marketplace for anyone to find and install. Use this when you want to share your work with the community.

To set visibility:

  1. Open your plugin in the dashboard.
  2. Go to the Publishing tab.
  3. Select your desired visibility level.
  4. Click Save.

You can change visibility at any time. Downgrading from public to team or private removes the marketplace listing but does not uninstall the plugin from workspaces that already have it.

Step 2: Complete Your Marketplace Listing

A well-crafted listing helps users understand what your plugin does and whether it fits their needs. Complete these fields before publishing.

  1. Display name -- the name shown in the marketplace. Keep it concise and descriptive.
  2. Short description -- one or two sentences shown in search results. Focus on what the plugin does, not how it works.
  3. Full description -- a detailed explanation shown on the plugin detail page. Include:
    • The problem the plugin solves.
    • What skills and tools are included.
    • Any external services the plugin connects to.
    • Example use cases.
  4. Category -- select the most relevant category (e.g., Productivity, Development, Communication, Data).
  5. Tags -- add specific tags to improve discoverability (e.g., "slack", "notifications", "team-chat").
  6. Icon -- upload a square icon (minimum 256x256 pixels) that represents your plugin. If you do not upload one, a default icon is used.

Step 3: Declare Requirements

Tell potential users what they need before installing.

  1. On the Publishing tab, go to the Requirements section.
  2. List any external accounts or API keys users will need (e.g., "Requires a Slack API token with channels:read scope").
  3. Declare plugin dependencies -- other plugins that must be installed first.
  4. Specify any platform requirements if your plugin relies on specific features.

Clear requirements prevent installation failures and reduce support requests.

Step 4: Publish

  1. Review your listing by clicking Preview on the Publishing tab. This shows exactly what users will see.
  2. Verify that all information is accurate and complete.
  3. Click Publish.
  4. For public plugins, the listing goes through a brief review to check for completeness and policy compliance. Most reviews complete within a few hours.
  5. Once approved, your plugin appears in the marketplace.

Team-visibility plugins are available immediately without review.

Managing Versions

As you improve your plugin, you will need to release updates. systemprompt.io uses semantic versioning to communicate the nature of changes.

Version number format: major.minor.patch

  • Patch (1.0.0 to 1.0.1) -- bug fixes, minor copy changes. No breaking changes.
  • Minor (1.0.0 to 1.1.0) -- new skills or tools added. Existing functionality unchanged.
  • Major (1.0.0 to 2.0.0) -- breaking changes. Existing skills or tools modified or removed.

Releasing an Update

  1. Make changes to your plugin (add skills, fix tools, update configuration).
  2. Go to the Publishing tab.
  3. Update the version number according to the changes you made.
  4. Add release notes describing what changed. Be specific -- users rely on these to decide whether to update.
  5. Click Publish Update.

How Updates Reach Users

  • Patch updates are applied automatically to all installed instances.
  • Minor updates notify users that an update is available. Users choose when to install.
  • Major updates require users to explicitly upgrade and may prompt them to review new configuration requirements.

Users can pin a specific version if they need stability and do not want automatic patch updates.

Updating a Published Listing

You can update your marketplace listing without releasing a new version.

  1. Open your plugin in the dashboard.
  2. Go to the Publishing tab.
  3. Edit any listing fields -- description, tags, category, icon.
  4. Click Save.

Listing changes take effect immediately. They do not affect the plugin version or trigger update notifications.

Handling Dependencies

If your plugin depends on another plugin, manage those dependencies carefully.

  • Declare all dependencies explicitly. Do not assume users have specific plugins installed.
  • Specify minimum versions. If your plugin requires features from a specific version of a dependency, set that as the minimum.
  • Test with the minimum version. Verify your plugin works with the oldest supported version of each dependency, not just the latest.
  • Notify when dependencies change. If an update adds a new dependency, mention it prominently in your release notes.

The platform resolves dependencies during installation. If a required plugin is missing, the user is prompted to install it first.

Deprecating a Plugin

If you no longer plan to maintain a plugin, deprecate it instead of removing it outright.

  1. Go to the Publishing tab.
  2. Click Deprecate.
  3. Optionally, suggest a replacement plugin.
  4. Click Confirm.

Deprecated plugins remain installed for existing users but no longer appear in marketplace search results. Users see a deprecation notice on the plugin detail page.

Marketplace Listing Best Practices

Follow these guidelines to make your plugin successful in the marketplace.

  1. Write a clear, specific description. Explain the concrete problem your plugin solves. Avoid vague language like "enhances productivity."
  2. Include example use cases. Show potential users exactly how they would use the plugin in their daily work.
  3. Keep your plugin focused. A plugin that does one thing well is more useful than one that tries to do everything. If you have unrelated capabilities, split them into separate plugins.
  4. Maintain descriptive release notes. Each update should explain what changed and why. Users are more likely to trust and update plugins with transparent changelogs.
  5. Respond to user feedback. If users report issues through the marketplace, address them promptly. Active maintenance signals reliability.
  6. Use meaningful tags. Think about the terms your target users would search for. Include both general and specific tags.
  7. Test before every release. Run through all skills and tool integrations before publishing an update. A broken update erodes user trust quickly.

Troubleshooting

Plugin stuck in review. Public plugin reviews typically complete within a few hours. If your plugin has been in review for more than 24 hours, contact support through the dashboard.

Users report tools not working after update. Verify that any external service endpoints or authentication methods have not changed. Roll back to the previous version if needed while you investigate.

Cannot change visibility from public to private. This is expected -- you can change to team or private, but existing installations are not affected. Users who already installed the plugin retain access to their installed version.

Version number rejected. Ensure your new version number is higher than the current published version. You cannot publish a version number that has already been used, even if that version was later removed.

Dependency conflicts during user installation. If users report conflicts, check whether your declared dependency versions are compatible with commonly installed plugins. Widen your minimum version range if possible.