Core concepts

Takeaway: Understand the building blocks of Tessl, namely the kinds of context, how they are packaged, where they live, and how Tessl measures quality, so the rest of the docs make sense.

If you have worked through the getting started flow, you have already used most of these ideas. This page names them and explains how they fit together.

Context as software

Giving an agent good context is useful, but on its own it does not last. Libraries change, APIs evolve, and conventions drift, and static instructions quietly go stale. Tessl treats agent context the way you treat code: something you build, evaluate, distribute, and keep up to date. That single idea, context managed with a real lifecycle, is what everything below supports.

The two kinds of context

Tessl works with two types of context, each suited to a different job.

Type	When it is used	Purpose
Rules	Always	Your team's standards, applied to every task
Skills	When relevant	Procedural workflows, loaded when the task matches

Rules and skills are where Tessl starts, not where it stops. Plugins can also carry other agent capabilities alongside context; see the Plugins section below.

Skills

A skill is a folder of instructions, and sometimes scripts, that teaches an agent how to do something: a specific workflow, a procedure, or a way of using a tool correctly. An agent loads a skill when its description matches the task at hand. Skills are the primary unit of context in Tessl, and they are agent-agnostic, so the same skill works across Claude Code, Cursor, Gemini, Codex, and others.

Plugins

A plugin is a versioned bundle. It packages skills and rules, and can also carry MCP servers, which connect agents to external tools and services, and hooks, which run deterministic commands in response to specific agent events: PreToolUse, PostToolUse, UserPromptSubmit, SessionStart, and Stop. Everything in a plugin is installed, versioned, and updated as one unit, much like a package in npm or pip. When you want to share a coherent set of context and capabilities rather than a single skill, you publish a plugin.

The Registry

The Tessl Registry is where context is discovered and distributed. Your team's private context lives in your workspace; the public registry, with thousands of evaluated skills and plugins you can browse and install, is there when you want to reach beyond it. It is also where your published quality scores appear, so others can judge whether a skill is worth installing.

Workspaces

A workspace is the shared, private home for your team's context. It holds the skills and plugins you publish privately, controls who can access them, and is where your Skill Inventory results and the private index Tessl generates from them live. Workspace context stays with your team unless you choose to share it.

Projects

A project is the stable anchor for Tessl inside a repository. It identifies the repository and gives Tessl a fixed place to attach repository-connected data, such as evaluation runs, so your results stay tied to the right codebase over time even as branches and checkouts come and go.

How projects, workspaces, and plugins fit together

These three are easy to mix up, because each one groups things, but they work on different axes. A plugin is content and capability: the skills, rules, MCP servers, and hooks you package up. A workspace is ownership: the team boundary that decides who can see and publish private plugins, and where your inventory lives. A project is location: the tie between Tessl and one repository, so your results stay attached to the right codebase.

In practice, your team shares a workspace and publishes plugins to it, and in each repository where you want Tessl to track work, you create a project. A workspace can hold many plugins and back many projects, while each project belongs to one workspace and maps to a single repository.

Reviews and evals

Tessl offers two ways to judge context quality, and they answer different questions. It is worth being clear on the distinction, because the names sound similar.

A review checks a single skill against best practices. It is fast and cheap, it runs automatically when you publish, and it produces a score across three areas: validation (structure and format), implementation (the quality of the instructions), and activation (how well the description triggers the skill). It is also where a team enforces its own skill-authoring standards, much like static analysis for code. Use a review for quick, structural feedback on the skill itself.

A scenario eval measures impact rather than structure. It runs an agent on real tasks, once with your context and once without, and compares the results, so you can see how much the context actually improves performance. Each scenario pairs a task with a rubric of weighted criteria used to grade the result. Evals are slower and more involved, and they attach to a project. Use an eval when you want evidence that context helps, not just that it is well formed.

In short: a review tells you whether a skill is well written; an eval tells you whether it works.

Security checks

Alongside quality, Tessl checks the safety of skills and plugins. A security scan looks for risky or malicious patterns in a component's content and behavior, such as prompt injection buried in instructions, hardcoded secrets, suspicious download URLs, unverifiable external dependencies, or hidden and obfuscated text. Findings are graded by severity. Tessl surfaces critical and high severity findings when you install, warning rather than blocking and leaving the decision to you. A serious finding on a third-party skill can signal a supply-chain attack, so treat it with care.

Next

With the vocabulary in place, the Tutorials section goes deeper on creating, improving, and distributing context.