Create a Tessl plugin: turn agent workflows and guardrails into a versioned bundle of skills, rules, hooks, and MCP servers, then validate and publish it.
93
88%
Does it follow best practices?
Impact
95%
1.31xAverage score across 9 eval scenarios
Low
Low-risk findings worth noting
You know the problem and have the material. Now decide how best to arrange it. This is a plan, not a build, keep it short and confirm it before creating anything.
Before deciding single-skill-vs-plugin, decide what kind of context each part is, because it is easy to default everything to skills. See references/choosing-the-shape.md.
hooks; use nativeHooks only when the event or data is agent-specific.Watch for always-on-convention language: "the agent keeps getting X wrong", "every time", "it never follows our...". That is usually a rule (or a rule plus a skill), not a skill alone. Do not push a conventions request toward skills by default.
Default to the smallest thing that solves the problem.
plugin.json), so this is not a lesser option; it is the right one when the problem is simple.In a few lines, state: the problem, the artifacts, and the proposed shape, which primitive each part becomes (skill, rule, hook, MCP server, or command), and whether anything needs decomposing. For a hook, state the lifecycle event and whether the generic or native tier is justified. Explain the why, especially if you are proposing to split a big skill, encode a convention as a rule, or use an agent-specific hook. Confirm with the user, or make the call and tell them your reasoning.
Pass the confirmed plan to build-composition.
Stop when there is a confirmed composition plan.