Using Tessl as a package manager

Use Tessl as a package manager for agent context: find and install skills, keep them up to date, and publish your own to a workspace.

Takeaways

• How to find, install, and update skills from the registry or a git repo.
• How to publish your own skill to a workspace, public or private.
• How to develop a plugin locally and reinstall it on every change.

Tessl manages agent context the way npm or pip manages code dependencies. Skills, rules, and docs are versioned packages you install into a project, update when new versions ship, and publish for others to consume. This tutorial covers the basics of using Tessl: the day-to-day package-manager flows you reach for most.

Find and install a skill

Search the registry by keyword:

tessl search "react testing"

You can also browse the registry UI, open a skill, and copy its install command straight from the page.

Install a skill or plugin by its registry name, a GitHub repo, or a local path:

tessl install engteam/react-testing      # from the registry
tessl install github:acme/skills          # from a GitHub repo
tessl install file:./local-plugin         # from a local directory

By default Tessl installs into the current project and records the dependency in your tessl.json manifest. Pass --global to install into ~/.tessl for every project, and --skill to pick specific skills from a multi-skill source. Without --agent, Tessl installs for every coding agent it detects in the project; pass --agent to target a specific one instead.

Keep installed skills up to date

See which installed dependencies have newer versions:

tessl outdated

This lists each dependency with its current, compatible-update, and latest version. Apply the updates:

tessl update

tessl update selects the compatible updates and lets you choose which to apply. A new major version that could break compatibility is held back until you pass --force. Pass --yes to apply all compatible updates without prompting. Remove a dependency you no longer want with tessl uninstall engteam/react-testing.

Publish your own skill

If you have a SKILL.md that is not yet a package, turn it into one:

tessl skill import ./path-to-skill

This writes a manifest next to the skill. Publish it to a workspace:

tessl skill publish ./path-to-skill --workspace engteam

The first publish starts at version 0.1.0. On later publishes, pass --bump patch, --bump minor, or --bump major to increment the version. Use --dry-run to validate what would be published without publishing.

Choose public or private

A skill is published privately by default: it goes to its workspace, where only members can find and install it. If you expect to see it in the public registry and do not, this is usually why. Add --public to publish it for anyone to install:

tessl skill publish ./path-to-skill --workspace engteam --public

Workspaces are how Tessl scopes who can see and install a package. List the workspaces you belong to with tessl workspace list. A skill's full name includes its workspace, for example engteam/react-testing, so workspace names are visible to anyone who can see the package.

Develop a plugin locally

A plugin is a bundle of skills, rules, commands, and hooks described by a .tessl-plugin/plugin.json manifest. You can install one straight from a local directory and iterate on it before publishing.

First add the local plugin to your project:

tessl install file:./my-plugin

Then run install in watch mode, which re-syncs every local source in your manifest whenever its files change:

tessl install --watch-local

Leave it running while you edit ./my-plugin. Each save reinstalls the updated plugin into your project, so you can test changes against a real codebase before you publish. When it is ready, publish the whole bundle with tessl plugin publish:

tessl plugin publish ./my-plugin --workspace engteam

Like tessl skill publish, it accepts --bump patch|minor|major to increment the version and --dry-run to validate without publishing.

Where to go next

• Creating skills and Creating plugins to go deeper on authoring.
• Distributing via registry to share with your team or publicly.
• Protecting yourself from insecure skills to review what you install for security.