← All posts
Product·August 19, 2026·The Supper Team

Supper's Skill Parser


Teams are investing serious time building skills for Claude, ChatGPT, and other AI platforms.

Those skills often encode genuinely valuable institutional knowledge: how revenue is calculated, which tables matter, which joins are trustworthy, what a customer means by “active,” how a particular workflow should run, or which edge cases an analyst needs to remember.

But as companies build more of them, something starts to break.

A skill that was useful when it was one carefully scoped workflow becomes harder to manage when there are five, ten, or twenty of them. The underlying data model changes. SQL gets stale. Definitions get repeated across files. Reference folders grow. Different skills contain slightly different versions of the same business logic.

And because skills are usually designed to handle a particular task, they can be surprisingly brittle. Ask the question they were designed for and they work. Move a little outside those boundaries and suddenly all of that carefully encoded knowledge becomes much less useful.

We built the Supper Skill Parser to solve that problem.

The Skill Parser lets teams bring skills they’ve already built elsewhere into Supper—without starting over. Connect a repository or upload a skill as a ZIP file, and Supper parses the skill and incorporates its useful knowledge into the Supper semantic model.

The result isn’t simply “your Claude skill, now running in Supper.”

It’s something much more useful: the knowledge trapped inside a narrow skill becomes reusable infrastructure for analytics across the company.

Skills contain more knowledge than their interface exposes

A typical AI skill might have a main skill file plus a reference directory containing several supporting documents. Those documents may include SQL, metric definitions, schema notes, business rules, examples, caveats, or instructions.

Over time, that can become enormous.

We’ve seen skills with seven or eight reference files and enough material to consume a very large context window. Much of that content is useful—but some is redundant, some is outdated, and some exists only because an LLM kept layering new instructions on top of old ones.

That creates two problems.

First, the knowledge is trapped inside the skill. The skill may work very well for the exact workflow it was designed to execute, but it doesn’t automatically make the underlying business knowledge available to other questions.

Second, maintenance scales badly. If a database table changes, a metric definition evolves, or a business rule gets updated, teams may have to find and fix that logic across several separate skills.

The Skill Parser takes a different approach.

Instead of treating a skill as one giant prompt that must be invoked as a unit, Supper breaks it apart and asks: What does this actually tell us about the business and its data?

From a pile of files to a semantic model

Supper already builds a semantic model around a company’s connected data. That model contains the business and technical context Supper’s agents use to understand questions and retrieve the right data—for example, schema information and business Terms that explain important concepts and calculations.

The Skill Parser extends that model using the work teams have already done.

When Supper imports a skill, it examines the skill and its supporting files and extracts the pieces that belong in the Supper model. Depending on what’s inside, that can include:

  • table and column definitions that improve schema understanding;
  • Terms that describe metrics, processes, and business concepts;
  • quirks that explain unusual relationships or behavior inside the customer’s data;
  • reusable workflow knowledge; and
  • other structured context that can make future questions more accurate.

At the same time, Supper can strip away redundant material instead of carrying the entire skill around as context for every relevant interaction.

So the goal isn’t merely compression.

It’s normalization: turning a collection of instructions, examples, SQL, notes, and reference files into a cleaner representation of how the business actually works.

That fits naturally with Supper’s existing architecture. Supper’s data agents don’t receive an entire company’s schema and business knowledge on every question. Relevant context is selected as it is needed, including business Terms and schema information used during data retrieval.

The Skill Parser gives that system another source of high-value business knowledge.

A real example: from a brittle RevOps skill to flexible analytics

One of our customers, a brand management platform, had already built a revenue operations skill for its Snowflake data.

The skill was valuable. It encoded how people should retrieve specific revenue analytics from the warehouse.

It was also huge.

The skill contained seven or eight reference files and a significant amount of hardcoded SQL. If someone asked one of the questions the skill had been explicitly designed to answer, it worked well.

But the moment a user went slightly off-road, things became much more fragile.

Supper imported the skill and decomposed what it knew.

The Skill Parser found useful table and column definitions, which enriched Supper’s understanding of the customer’s schema. It extracted business concepts into Terms. It identified quirks in how the customer’s database related to itself.

Instead of keeping all that knowledge bound to one RevOps skill, those components became part of the customer’s broader semantic model.

The immediate result was that the questions the customer already cared about continued to work.

The more important result was what happened next.

Users could now ask variations of those questions that weren’t anticipated when the original skill was written. They could extend the semantic model with additional business logic without rebuilding every skill that depended on it. And more people across the RevOps organization could self-serve analytics without requiring someone to constantly maintain a growing collection of tightly scoped instructions.

That’s the difference between a skill and a model.

A skill teaches an AI how to perform a task. A semantic model teaches an AI how your business works.

Your existing AI work shouldn’t become migration debt

There’s another reason we built the Skill Parser: companies shouldn’t have to throw away the work they’ve already done in order to adopt better analytics infrastructure.

Teams evaluating Supper increasingly arrive with existing AI investments. They’ve built Claude skills. They’ve built internal prompts and workflows. They may have spent months teaching an AI how to navigate some complicated corner of their business.

A reasonable first question is:

“Do we have to rebuild all of this?”

With the Skill Parser, the answer is no.

Bring the skills with you.

Supper can use that work to jump-start the semantic model, which means teams can begin much closer to where they are today instead of recreating their institutional knowledge from scratch.

That matters especially because Supper is designed to build and refine its understanding of a company over time. Its semantic model includes concepts like Terms, and its agent system can identify missing business knowledge as people use the product.

Imported skills become another starting point for that learning process.

And you don’t have to stop building skills

The Skill Parser isn’t an argument that companies should abandon Claude skills or other internal AI workflows.

Quite the opposite.

If your team likes building skills, keep building them.

The point is that those skills no longer have to become isolated islands of business logic.

A team can continue creating internal skills for specific use cases and bring that knowledge into Supper as well. Instead of maintaining two completely separate worlds—one inside bespoke AI skills and another inside your analytics stack—the same underlying knowledge can help inform both.

That makes it much easier to keep models aligned as the business changes.

The broader idea: business knowledge should compound

The exciting part of the Skill Parser isn’t importing ZIP files.

It’s what happens to the knowledge after the import.

Today, companies are encoding valuable business context everywhere: analytics code, dbt models, dashboards, documentation, AI skills, SQL snippets, prompt libraries, and the heads of the handful of people who understand why a particular revenue query has three strange joins in it.

Most AI systems consume that context in isolated chunks.

We think the better model is cumulative.

When Supper learns something important about your business—whether from your connected data, a Term someone creates, an interaction with an analyst, or now an existing AI skill—that knowledge should make the rest of the system better.

The Skill Parser is another step toward that.

Bring us the skills you already built. We’ll turn the useful parts into a model the rest of your company can actually use.