Making Smootify readable to AI

Most agencies are talking about how they use AI. We spent the last few months on the opposite problem: making sure AI could actually use what we build.

The shift nobody is naming yet

Over the past year, the conversation around AI in our industry has been almost entirely about consumption. Which model is best, which IDE plugin saves more time, which prompt produces better copy. All useful questions, all framed from the same direction: how does our team get more out of these tools.

There is a second question that almost no one is asking out loud. When a developer working on a Webflow and Shopify project opens Claude or Cursor and types "help me debug this Smootify integration", what does the AI actually see? What does it know about our product? Where does that knowledge come from?

For most third-party tools the answer is: outdated forum posts, partial documentation scraped years ago, and whatever the model managed to infer from a handful of GitHub issues. That is the silent default, and it is a problem we decided to fix on our side instead of waiting for the platforms to fix it for us.

What we actually shipped

Two things, both deliberate.

The first is a fully restructured documentation layer for Smootify, written from the start to be machine-readable. Clean hierarchy, consistent terminology, every concept defined once and referenced everywhere else. No marketing copy mixed with technical reference. No screenshots that replace text instructions. Each page does one job and signals clearly what that job is. We call this internally our AI-ready documentation, but the truth is that it is also dramatically better for human readers, because the constraints AI imposes on writing are mostly the constraints of good technical writing.

The second is a Claude Skill for Smootify. A Skill, in the way Anthropic defines it, is a packaged set of instructions and context that Claude loads on demand when a task matches. Ours does one thing very well: it inspects a Smootify integration and surfaces what is wrong. Mismatched product handles, CMS fields not bound to Shopify variants, missing required attributes on cart elements, conflicts between Smootify settings and Webflow custom code. The kind of issues that used to require an hour of back-and-forth with our support team, and that experienced developers usually find by ruling out fifteen wrong hypotheses first.

The Skill does not replace that experience. It compresses it. It is the closest thing we could build to having one of our senior developers sitting next to a customer's screen, pointing at the line that is breaking the build.

Why a Skill and not a chatbot

This part is worth saying explicitly, because the distinction is the whole point.

A chatbot is a generalist that has memorized our docs. It can answer questions, but it cannot look at your specific project. It does not know that your CMS collection is named "products-v2" instead of "products", that you renamed the cart wrapper, or that you are running an older version of the Smootify embed.

A Skill is different. It activates when you are already working on a real Smootify project, with Claude already connected to your Webflow site through the official Webflow connector we wrote about a few weeks ago. At that point Claude has direct read access to your structure. The Skill provides the diagnostic logic on top of that access: what to inspect, in what order, what symptoms map to what root causes, when to recommend a quick fix and when to flag something that needs a human decision.

The result is not "AI knows about Smootify". The result is "AI can debug your Smootify integration". Two completely different products, even if they sound similar in a tweet.

What this changes for the people using Smootify

The most common moment of friction with Smootify has always been the same. A developer or a Webflow designer is two thirds of the way through an integration. Most of it works. One specific thing is broken, and the symptom does not point cleanly to the cause. They open our docs, they search the forum, they consider opening a support ticket, they decide to try one more thing first. That last hour is the one that erodes confidence in the product.

With the Skill loaded, the same moment looks different. Claude reads the project, identifies the misconfiguration, explains why it is breaking the integration, and suggests the fix. If the fix is trivial, the developer applies it and moves on. If the fix is structural, they understand why before they decide what to do.

This is not automation in the marketing sense. It is the removal of a specific category of stuck moments that used to cost our users time and cost us support volume.

Why we did this work ourselves

It would have been reasonable to wait. Webflow, Shopify, and Anthropic are all moving in this direction. Within twelve to eighteen months, AI-readable documentation will likely be a default expectation for any serious developer tool, and platforms will provide more standardized ways to expose product context to assistants.

We chose not to wait, for a reason that is consistent with how we run Eclipse. The teams that learn early how AI consumes their content, their products, and their interfaces will spend the next phase ahead of the ones who treated this as a documentation refresh. The infrastructure for AI agents to read and act on third-party tools is being built right now. Showing up later, with a generic chatbot bolted onto a marketing site, will not catch up.

There is also a more direct reason. Our users are spending more and more of their working day inside an AI assistant. If Smootify is not legible to that assistant, Smootify is invisible at the exact moment a decision is being made.

The honest part

We do not think this is finished. The Skill catches a defined set of issues well, and silently misses others. The documentation is structured but still has corners written for humans first and machines second. We will keep iterating on both.

What we are confident about is the direction. The agencies and product teams that will matter in the next few years are not the ones with the most impressive AI demos. They are the ones whose work, code, products, and content can be picked up by an AI agent and used correctly without a human having to translate.

That is the job we are doing on Smootify, in public, with the rough edges still visible. We think it is the most useful thing we can build right now.

See how we are putting AI to work for our clients with Automate.