For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Write a plugin definition and publish it to the registry catalog so it can be referenced in harness agent definitions.

Before you begin

1. Set up an OIDC provider so that users can authenticate with the registry.

2. Install Solo Enterprise for agentregistry in an AWS EKS cluster and the arctl CLI.

3. Port-forward the Solo Enterprise for agentregistry server on port 12121 if you have not done so already. The registry is not exposed externally by default, so you need port-forwarding to reach it from your local machine.

   kubectl -n agentregistry-system port-forward svc/agentregistry-enterprise-server 12121:12121

Publish a plugin

There is no scaffold command for plugins. Write the plugin definition by hand, then apply it.

1. Create a plugin definition file and push it to the registry catalog. The following example publishes the hello-plugin from the Solo.io doc-examples repository.

   arctl apply -f- <<EOF
   apiVersion: ar.dev/v1alpha1
   kind: Plugin
   metadata:
     name: hello-plugin
   spec:
     title: Hello Plugin
     description: A simple test plugin with a /hello slash command.
     harnesses:
       - claude-code
     source:
       type: git
       git:
         repository:
           url: https://github.com/solo-io/doc-examples
           branch: main
           subfolder: agentregistry/plugin
   EOF

   Field	Description
   spec.title	Human-readable display name for the catalog UI.
   spec.description	Short description that is shown in catalog listings.
   spec.harnesses	Informational list of harnesses the bundle supports. Supported values: claude-code and openclaw. This field does not affect how the registry resolves or indexes the plugin.
   spec.source.type	Source type. Must be git.
   spec.source.git.repository.url	The URL of the repository that contains the plugin bundle. GitHub (github.com) and GitLab repositories, including self-hosted GitLab instances, are supported. If the repository is private, make sure that you have configured your credentials first and that you referenced your credential secret in the spec.source.git.repository.credentialsRef field.
   spec.source.git.repository.branch	The branch that contains the plugin bundle. When you publish the plugin to the registry catalog, the registry resolves the branch to a specific commit SHA and stores that commit SHA in the plugin. All future deployments use that pinned commit, not the current branch tip. To pick up new commits, you must re-publish the plugin.
   spec.source.git.repository.commit	Optional. Pin directly to a specific commit SHA instead of a branch. Use this option when you want the plugin to stay locked to an exact revision regardless of where the branch moves.
   spec.source.git.repository.subfolder	Optional. The path to the plugin root within the repository. Use this field when the plugin is not at the repository root.

   Example output:

   ✓ Plugin/hello-plugin (latest) created
   

2. Verify that the plugin is created in the catalog.

   arctl get plugin

   Example output:

   NAME           TAG      DESCRIPTION
   hello-plugin   latest   A simple test plugin with a /hello slash command.
   

3. Get the details of the plugin to verify that the registry successfully resolved the provided GitHub URL and retrieved information about the plugin bundle. This information is stored in the status section of your plugin.

   arctl get plugin hello-plugin -o yaml

   Example output:

   status:
     conditions:
     - lastTransitionTime: "2026-08-13T16:11:53.147855761Z"
       reason: Resolved
       status: "True"
       type: Ready
     inventory:
       commands:
       - hello
     manifest:
       description: A simple test plugin
       name: hello-plugin
       version: 1.0.0
     resolvedSource:
       commit: a1681ab532ee6bce445db351aa8048bf06df9159
       type: git
   

   Status field	Description
   status.conditions[Ready=True]	The registry successfully resolved and scanned the plugin.
   status.resolvedSource.commit	The concrete git commit SHA the registry pinned. Future deployments use this commit, not the branch tip, so your catalog entry stays reproducible, even if the branch moves forward.
   status.manifest	The parsed contents of the plugin’s plugin.json manifest.
   status.inventory	The resources that are bundled in the plugin and that the registry found during scanning, including skills, hooks, MCP servers, and executables.

   If the Ready condition in the plugin shows False, review the reason field for details.

   Reason	Meaning
   Progressing	The registry is still scanning the plugin source.
   Resolved	The registry successfully resolved the source URL and created a commit SHA.
   RefNotFound	The branch or commit does not exist in the repository. Check spec.source.git.repository.branch or commit.
   SourceInvalid	The repository does not contain a valid plugin bundle. Verify that a plugin.json manifest is present at the expected path.
   SourceUnresolvable	A transient error, such as a network timeout, prevented the resolution of the source repo. The registry automatically retries to scan the source repo.
   SourceUnsupported	The plugin source is not supported. Plugins must be hosted in a Git repository. You cannot provide an OCI image or another source type for your plugin bundle.

Next steps