> For the complete documentation index, see [llms.txt](https://docs.tessl.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tessl.io/creating-skills-and-plugins/publish-and-update.md).

# Publish and update

Publish a skill or plugin to the registry, control who can install it, and ship new versions.

{% hint style="info" %}
**Takeaway** Publish a skill or plugin with `tessl skill publish` or `tessl plugin publish`. It goes to your workspace as private by default. Bump the version to ship an update, and request public visibility only when you want anyone to install it.
{% endhint %}

Publishing puts a skill or plugin on the [Tessl Registry](https://tessl.io/registry) so it can be installed by name. This page covers the publish command, visibility, and versioning. Rolling context out across many repositories, and the GitHub-based publishing flow, are covered in [Distribute](/distribute/distributing-via-registry.md).

{% hint style="info" %}
Your agent can run this step too: `tessl install tessl/plugin-creator`
{% endhint %}

## Publish

From the skill or plugin directory, or with a path:

```bash
tessl plugin publish ./api-conventions --workspace engteam
```

`engteam` is a stand-in workspace. Run `tessl workspace list` and use one of yours.

A single skill uses the same flow through `tessl skill publish`. Both publish to your workspace as **private**: only workspace members can install it.

| Flag                         | Purpose                                                                           |
| ---------------------------- | --------------------------------------------------------------------------------- |
| `--workspace`                | Workspace to publish under. Required when non-interactive.                        |
| `--dry-run`                  | Run every pre-publish check without publishing. Use it first.                     |
| `--bump patch\|minor\|major` | Bump the version automatically if the current one already exists on the registry. |
| `--skip-evals`               | Skip publishing the eval scenarios in `evals/`.                                   |
| `--version`                  | Publish a specific version (plugin publish).                                      |

On publish, Tessl lints and reviews the content automatically, and the review score appears on the registry. See [Check a skill's quality using review](/improving-your-skills/reviewing-skills.md).

## Publication checks and blocked versions

An accepted upload is not necessarily available to install yet. Tessl runs publication checks asynchronously after the upload. The publish command tells you whether the version is available, blocked, still being checked, or could not be checked.

Check the exact version that you uploaded:

```bash
tessl plugin info engteam/api-conventions@1.2.0
```

If your organization or workspace enables a minimum skill review score policy, every skill in the plugin version must meet that score. Tessl does not average scores across the skills. For example, with a minimum score of 80, scores of 91 and 78 block the version, while scores of 91 and 85 pass this check. A score equal to the minimum passes.

The version must also pass every other publication check that applies to it. A version is unavailable while blocked and cannot be overwritten. Use `tessl plugin info` to check its publication status and the reported reason. For a score below the threshold, open the exact version in the Tessl Registry, select **Quality**, and use the per-skill findings to improve the failing skill. Then bump the version and publish the higher version.

If the publication or moderation status is pending and the version is unavailable, wait and check the same version again. An available version can still have quality or security reviews running in the background; those reviews do not delay its use.

Skill reviews are free, so a lack of credits does not stop a quality review from running. If a review completed without a score, contact Tessl support before publishing a higher version. This outcome does not mean that the skill itself needs improvement. For other system errors, contact Tessl support.

Versions blocked by policy are not available for distribution, including Claude marketplace sync. The policy provides a publish-time quality gate without requiring a CI step.

## Install it

Once published, you or your workspace can install it in any project:

```bash
tessl install engteam/api-conventions
tessl install engteam/api-conventions@1.2.0
```

To let teammates install a private plugin, add them to the workspace with `tessl workspace add-member`. See [Workspaces](/reference/workspaces.md).

## Ship an update

1. Make your changes.
2. Bump `version` in `.tessl-plugin/plugin.json` following [semantic versioning](https://semver.org/): patch for fixes, minor for backward-compatible additions, major for breaking changes.
3. Validate with `tessl plugin lint`.
4. Publish again.

```bash
tessl plugin publish ./api-conventions --workspace engteam
```

Anyone who installed it updates by running `tessl install engteam/api-conventions` again, which fetches the latest version.

## Make it public

Public means anyone can discover and install it. It is irreversible, so it needs approval first:

1. Open your plugin or skill in the [Tessl Registry](https://tessl.io/registry) and sign in.
2. Select **Actions** then **Make Public**, and confirm the request.

Once approved, set the visibility and publish again:

* **A plugin** takes its visibility from the `private` field in `.tessl-plugin/plugin.json`. Set `"private": false` and publish.
* **A skill** can be published public directly with `--public`:

```bash
tessl skill publish ./my-skill --workspace engteam --public
```

See [Sharing with your team and publicly](/distribute/sharing-plugins-publicly.md) for more.

## Remove or deprecate

Published something you should not have, or no longer want it installed? There is no hard delete, but two options cover it. Both use `tessl plugin` whether you published a skill or a plugin.

To drop one skill from a plugin that contains others, delete the skill file and publish a new version with `tessl plugin publish`. The old version remains on the registry; the new version simply omits the skill.

* **Unpublish** removes a version as if it was never published. It has a short time limit, a couple of days after publishing:

```bash
tessl plugin unpublish --plugin engteam/api-conventions@0.1.0
```

* **Archive** hides it from search but keeps it working for anyone who already references it, so existing installs do not break:

```bash
tessl plugin archive --plugin engteam/api-conventions --reason "superseded"
```

To simply stop new people finding it, you can also make it private again: set `"private": true` in the manifest and republish, or change visibility from the registry UI.

## Next

* [Distributing via registry](/distribute/distributing-via-registry.md) - archive, unpublish, and monitor usage.
* [Distribute plugins across multiple repositories](/distribute/distribute-plugins-across-multiple-repositories.md) - push plugins across many repos.
* [Improving your skills](/improving-your-skills/overview-improving-skills-and-plugins.md) - raise quality before you publish widely.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.tessl.io/creating-skills-and-plugins/publish-and-update.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
