Lesson 5 — Publishing & installing across a team

You've built a git-hygiene plugin and it works on your machine. This last lesson takes it the rest of the way: onto the registry, into a teammate's repo, and into a maintenance loop you can run for as long as the library lives. That's the whole arc of this workshop closing: from never having run a skill, to publishing one your whole team installs with a single command.

What you'll do

• Dogfood the plugin against real work, the way you'd want it to behave for everyone else.
• Publish it to your workspace and install it exactly as a teammate would.
• Ship an update with a version bump and watch a consumer pick it up.
• Run a four-point check that the published library is healthy.

First, dogfood it

A clean lint and review eval scores in the 90s are necessary but not sufficient. Before you publish anything to a registry other people install from, install the plugin from your own filesystem and put every skill through its paces against your real workflow:

tessl install file:./plugins/git-hygiene

For the git-hygiene library: make a commit (does commit-conventions fire?), open a PR (does pr-description fire?), cut a release (does release-notes fire?). Two things to watch for:

• Triggering. Does each prompt load the right skill? If a prompt loads the wrong skill, or nothing, the descriptions need tightening.
• Tripping. Do the skills tread on each other? A skill loading when a sibling should have is the classic symptom of overlapping descriptions, the same failure you guarded against when you bundled the library.

Fix what you find, then publish. A bad first release on the registry costs far more to recall than ten minutes of dogfooding.

Step-by-step

1. Publish to your workspace

When the plugin feels stable:

tessl plugin publish ./plugins/git-hygiene

Publishing isn't just an upload. A fair amount happens server-side, and it's worth knowing because it's the same quality gate every published plugin passes:

• The plugin is linted again.
• Every skill in it is validated against the Agent Skills specification.
• A review eval runs automatically against each skill, the same one you can run by hand with tessl review run. Scores appear on the plugin's registry page within minutes. (Those scores are exactly why sharp, non-overlapping descriptions matter: the registry grades each skill on its own.)
• The version (0.1.0 for the first publish) is locked. Future publishes need a --bump flag or an explicit version edit.

Once it lands, anyone in the workspace installs the whole library with one command, the same command you used to install someone else's skill back in Lesson 1, now pointed at yours:

tessl install my-workspace/git-hygiene
# or pin a version:
tessl install my-workspace/[email protected]

Check what landed, including the auto-generated review eval scores:

tessl plugin info my-workspace/git-hygiene

2. Ship an update

A library is never finished. Editing a skill, re-publishing, and bumping the version is a one-line loop:

# edit SKILL.md for whichever skill you changed
tessl plugin publish ./plugins/git-hygiene --bump patch
# new version: 0.1.1

--bump follows semver, and choosing the right level is a promise you're making to everyone who installed your plugin:

• patch: bug fixes, wording tweaks, anything backward-compatible.
• minor: new skills or capabilities; existing usage still works. (Adding pr-description to the library is a minor.)
• major: breaking changes; consumers should read release notes before updating.

Consumers who installed the library pick up the new version with:

tessl update my-workspace/git-hygiene

tessl outdated shows them which plugins have updates available, the same shape as npm outdated or pip list --outdated, just for context instead of code.

Verify the published library

Four checks confirm the library is genuinely live and healthy:

• tessl list shows my-workspace/git-hygiene installed locally, with each skill inside it.
• tessl plugin info my-workspace/git-hygiene shows a review eval score for each skill, set automatically on publish.
• Each skill loads on the right prompt and only the right prompt. Prompt for a commit message, then a PR description, then release notes; each should load a different skill.
• You can tessl install my-workspace/git-hygiene cleanly into a different repo. That's the discoverability and distribution test passing in one shot.

If the third check fails (two skills load on the same prompt) the fix is always the same: return to the descriptions, tighten the narrower one until the overlap disappears, and re-publish with --bump patch.

What you keep

You've gone the whole distance: a skill you installed, a skill you wrote, a library you bundled, and now a plugin published to a registry that your whole team can install and update with one command each. More than the git-hygiene plugin, you keep the loop that keeps it alive (dogfood, publish, version, update) and the instincts underneath it that carry to every plugin you ship after this one. That's the foundation. From here, the other workshops build on it: putting your skills under test so you can improve them with numbers, and rolling agent practice out across a whole organization.