菜单
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.
用 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 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.
Use once the problem and artifacts are understood, to decide the right shape for the context. Produces a short composition plan - a single skill for simple cases, or a plugin (with rules, commands, MCP servers, or multiple skills) for richer ones - and confirms it with the user before anything is built.
| name | decompose-into-skills |
| description | 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. |
Big skills are hard to get right and hard to verify. Splitting them into focused pieces is often the most valuable thing this plugin does, so lead with the value, do not treat it as tidying. This is invoked from build-composition (or plan-composition when the plan already calls for a split).
A skill is too big when it does several distinct jobs, has unrelated triggers, or is so long the core procedure is hard to follow. Identify the independent responsibilities inside it.
Draft a decomposition: one skill per responsibility, each with its own clear trigger and a verb-form skill name. Show the user the proposed structure and the reasoning. Make the call for them, but bring them in, explain why each split makes the result more reliable and easier to prove later. This is the moment to make the benefit visible.
Create each focused skill as skills/<name>/SKILL.md directly (do not run tessl skill new per sub-skill inside a plugin, it nests a broken standalone plugin that pack silently drops, see build-composition). Move shared depth into references/. If skills depend on one another, make that explicit so they are not used in isolation. The plugin becomes the superstructure that bundles them, a legitimate reason to go from a single skill to a plugin.
Not every piece is a skill. If decomposition surfaces an always-on convention (something the agent should always follow, not a workflow it triggers), that piece belongs in a rule, not a skill. Route it accordingly.
Honour the original content: preserve the user's wording and intent, restructure rather than rewrite, unless a review flags a real problem and the user agrees.
Hand the decomposed set back to build-composition to finish assembling. Note to the user that each skill can now be evaluated independently, later, via skill-optimizer, that independence is a big part of why decomposition was worth it. Do not run evals here.
Stop when the big skill has become a set of focused, independently-triggerable skills the user is happy with.
