What does Tessl do? Key features and where it fits

TL;DR: Tessl is a registry and quality gate for AI agent skills. Every submitted skill runs through automated evals and Snyk-backed security scoring before it gets installed and published through its CLI. Tessl doesn't answer who's in charge of keeping a skill up to date, whether it meets the org's governance and access rules, or how it fits with the other plugins, MCPs, agents, and workflows already running in the org’s agentic ecosystem. That's where Port's context lake, orchestration, and governance layers come in.

If you're building a skills registry, the reusable instructions and scripts that power AI agents, from coding agents like Claude and Cursor to a marketing team's Claude Desktop or a managed agent running unattended. This piece covers what Tessl does, what it solves and what it doesn't solve, and how Port fits in. By the end of this read, you'll have a better understanding of whether you need Tessl, Port, or both.

This piece is written for platform engineers and engineering leaders working through these questions:

1. What does Tessl do?
2. What problem does Tessl solve?
3. What doesn't Tessl solve?
4. How does Port solve what Tessl leaves open?
5. What is each tool actually for, Tessl and Port?
6. How do you choose, and where do you start?

What is Tessl?

Tessl is a package manager for AI agent skills. It works the way engineers already expect a package manager to work: an install command pulls a skill down, a search command finds one, and a create command publishes a new one. The public registry holds more than 3,000 searchable skills. A private workspace holds anything an org wants to keep internal, hosted on Tessl's own cloud by default, the same way a private npm registry works, with self-hosting available on Enterprise plans.

The core of the product is a registry and a quality gate. Publish a skill, and it runs through Tessl's own evals (an LLM judges whether the skill improves an agent's performance on generated test scenarios) plus a Snyk security score. Its newest release, Tessl Code Review, extends the same idea to agent-written pull requests.

What problem does Tessl solve?

Writing a skill is easy. Testing it, making it reachable to other personas in the organization, and proving it won't do something dangerous once an agent is running it is much harder.

Tessl's answer is to make skills publishing feel familiar to engineers. A skill installs and updates through the CLI the same way engineers already pull packages, so there's no new tooling to adopt. Every submitted skill runs through Tessl's own evals and security check. Snyk's own research found that 36% of the public skills it scanned carried prompt injection techniques.

What Tessl doesn't solve?

Tessl's skills registry answers whether a skill is good and safe. It doesn't answer three other questions, and all three start to matter the moment you realize skills are a new form of code.

Who's in charge of keeping it up to date? Three versions of the same deploy skill exist across three repos, each written by a team that didn't know the others existed. Nobody owns any of them enough to say which one is the official one, or to update it when the underlying deploy process changes.

What's the process for applying org standards and best practices? Skills are a way to encode your organizational processes and policies. Someone from the CIO office should review a security-related skill. A UX-related skill should be tested by someone from the design team. You might decide that in your organization, a production-ready skill must be assigned to a role or a professional group. The lifecycle and the org standards you're interested in setting are not in Tessl's scope.

How does it fit in the org’s agentic ecosystem? Which complementary skills exist? Are they bundled into a plugin? The skill instructs an agent to call certain tools. Does the agent running it have the relevant MCP? Which agents use this skill? A skill by itself is just a text file. It becomes a powerful agentic asset only when combined with the other agentic artifacts running across the organization.

How Port solves that

Traceability. Port pulls skills straight out of the Git repos and tools teams already use for the content source of truth, before they are formally published. The scattered skills are centralized in a single catalog, where every skill entity holds the metadata and relations to where it came from - wiring it to Port’s organizational context lake. Since Port already knows which team owns which service, a skill built for Snowflake gets scoped to the team that owns the Snowflake entity automatically. A PM or an on-call engineer sees by default only the skills that apply to their actual context, not only what happens to live in their own repo.

Certification. A certification workflow defined by the platform team is triggered the moment a skill's pull request opens, runs review and promotion checks and routes the result to whoever your org has set as the approver. Every org standard is stored in a scorecard reflected on each skill and on the full skills registry level. The certification review does not only look at the skill as a standalone asset, but also analyzes how it fits with the other agentic artifacts - suggesting adding it to plugin or bundling with an MCP it mentions. 

Enforcement. Every skill entity in Port carries its own RBAC and dynamic policies. Every member gets a tailor-made skills catalog, based on his role and the groups he’s assigned to, whether in the UI or in his coding agent through Port’s MCP. While any user of the skills can suggest an update, only a member of the skill’s owning team can approve it. Every change to a skill entity is documented in an audit log.

Optimization. Port gathers data from different providers' APIs and brings it together, making it possible to analyze skill usage and ROI after a skill is published to the registry. An unused skill might be up for decommission, a skill with a negative ROI should be refactored, and a top-used skill might be assigned to more groups in the org. This data drives the skills lifecycle and registry health as much as the initial quality and certification checks.

Port and Tessl: what each is for

Tessl and Port solve different jobs. Tessl gives skill content a quality bar. Port gives that content an owner, a policy, and a place in the rest of your agent ecosystem.

Use Tessl for:

• CLI-based distribution. Skills install and update through CLI, the same way engineers already pull packages. No new tooling to adopt.
• Sandbox evals. Every submitted skill runs through Tessl's evals automatically, scored against generated usage scenarios, not just a lint pass. That tells you whether a skill helps before it spreads.
• Security scans. Snyk-powered scoring runs on every skill in the registry.

Use Port for:

• Organizational context. Team owners, related services, assigned groups, wired into your SDLC context lake. A skill is not a floating file. It is scoped to whatever it depends on, a service, an org policy, a process, whatever context already lives in your catalog.
• Lifecycle and certification workflows. Approvals and promotion paths built on your org's own standards and policies, informed by real usage pulled from Claude, Cursor, and whatever else your teams run.
• The AgentOps layer. Skills do not exist in isolation. Port maps the relations and dependencies between skills, MCPs, plugins, and agents, and the rest of the SDLC they plug into.

Bottom line: most teams don't pick one and walk away from the other. They decide that Tessl or a similar tool runs the registry and the quality gate. Port governs whatever comes out of it: who owns it, whether it's certified against your org's own standards, and how it relates to everything else your agents touch.

How to choose, and where to start

The case for running Port as your Agentic SDLC Platform is not that it replaces a tool like Tessl. Skills, like every other asset an agent touches, need an owner and a place in your org's structure, and that layer has to exist no matter what sits underneath it.

This logic shows up in a sales conversation. A prospect running its own shift toward a more agentic SDLC asked for evals and a security check on its skills, and named Tessl as a vendor doing registry and evals together. Port's answer was not to compete with that ask: run the skill through the same certification workflow every other skill goes through, trigger an evals sandbox as one of its checks, then feed the result into the same scorecard that already tracks the org's services. Tessl or a sandbox handles the eval. Port makes sure the result lands somewhere with an owner attached, inside an environment that already understands your org's context.

Start with whichever gap is costing you time today, a duplicate you keep rewriting, a skill you cannot vouch for, or a skill nobody outside one team ever sees. Sign up to pull your existing Git skills into a catalog you can see, or book a demo to walk through certification and scoping on your own org's data.

FAQ

What does Tessl do?

Tessl is a package manager and quality gate for AI agent skills. You publish and install skills through its CLI, and every public skill runs through automated evals and Snyk security scoring.

What is an Agentic SDLC Platform?

The governance and context layer underneath every AI agent, script, and skill touching your software delivery lifecycle. It tracks who owns what, certifies what is safe to run, and connects agents to the org data (services, teams, policies) they need to act correctly.

Is Tessl an Agentic SDLC Platform?

No. Tessl is a registry and quality gate scoped to skill content: evals, versioning, security scores. It does not track team ownership, certify skills against your org's standards, or map how a skill relates to the other agents and MCPs in your stack.

When should I choose Tessl?

When proving a skill works and is safe before it spreads is the open question, and you want that as a standalone tool with its own CLI and versioning.

Port vs Tessl: do I need both?

Not necessarily. If skill quality and safety are the open question, Tessl on its own is a strong answer. If ownership, approval, and org-wide visibility are the gap, Port covers that whether or not a Tessl registry sits underneath it. Teams run both, because both questions eventually show up.

‍