القائمة
Use when a composition is built and the user wants to share it, to publish or re-publish it to the Tessl registry. Lints it, confirms private/public visibility, and publishes.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when reviewing a pull request, to check for logic bugs, style consistency, and security concerns and summarise the findings for the author.
Use once there is a confirmed composition plan, to create it. Scaffolds the plugin, authors or restructures the skill(s), decomposes anything too big, and adds any rules or MCP servers the plan called for. Uses the CLI to scaffold the plugin, then adds further skills by hand.
Database administration tasks including schema changes, backups, monitoring, and user access management.
Use when someone wants to turn a problem, a messy or sprawling skill, or some existing work into well-shaped reusable context for their agent. Triggers include "help me make a skill for X", "my skill is a mess, sort it out", "I want to get more out of Tessl with this skill", or "package this so my team can use it". Runs the arc - understand the problem, gather the artifacts, plan the right composition, build it - then points to eval as a separate next step.
Use during build when a skill or a problem is too big for one skill - a sprawling SKILL.md doing several jobs, or a large problem the user wants a single skill for. Splits it into focused, independently-verifiable skills, with a plugin as the superstructure that holds them together.
Use at the start of creating context, to understand the problem the user is solving and take stock of what they already have. The user may arrive with an existing skill or plugin, code, a written prompt or transcript, or nothing but a pointer ("go look at my PRs"). Gathers what exists and fills the gaps - by asking or by hunting - until there is enough to plan a composition.
| name | publish-plugin |
| description | Use when a composition is built and the user wants to share it, to publish or re-publish it to the Tessl registry. Lints it, confirms private/public visibility, and publishes. |
Publishing makes a plugin installable from the registry. It lives in this plugin for now; the broader distribute workflow (rollout across repos, org distribution) is a larger surface that may absorb parts of this later. Only invoke this when the user explicitly wants to publish.
Never publish without an explicit yes, and confirm public vs private first. The private field in .tessl-plugin/plugin.json controls it:
"private": true (default): only the workspace can see and install it."private": false: anyone can discover and install it. This is irreversible, a public plugin cannot be made private again.If the user is new to Tessl, be extra clear about what public means.
If the plugin wraps skills the user did not author, do not publish on their behalf without making ownership clear. Wrapping and publishing someone else's work is a real sensitivity, surface it.
Inspect the live CLI first (tessl plugin publish --help). Then:
tessl plugin lint <plugin-dir>
tessl plugin publish <plugin-dir> --dry-run
Fix all issues. Publishing requires Tessl auth (tessl login, or TESSL_TOKEN in CI). Published plugins should have evals (the internal bar is review and task-eval scores of 80%+); if they are missing, point the user at tessl/skill-optimizer first, evals are a separate, downstream flow.
tessl plugin publish <plugin-dir>
Bump the version each release (--bump patch|minor|major, or edit version).
tessl plugin unpublish works only within 2 days.tessl plugin archive is the normal way to retire a plugin: blocks new installs, keeps existing ones working.Stop when the plugin is published at the intended visibility, or the user chooses to keep it local.