The problem
A lot of software products are bundles of instructions wrapped in an interface.
You enter some text, choose an option, and get transformed text back. The product may correct grammar, summarize a document, generate a plan, review code, or rewrite something in a different tone.
That used to require a dedicated app. Now Claude Code and Codex can do many of those jobs directly.
The problem is figuring out which parts of an app can be reproduced reliably. A customer does not want to keep paying for functionality their existing agent can already provide. A founder needs to know whether their product has value beyond instructions that a capable model can follow.
So I built Skillify.
What Skillify does
An agent skill is a small Markdown file that teaches Claude Code or Codex how to perform a repeatable task.
Skillify takes a public website URL, reads the site and its documentation, infers what the product does, and turns those capabilities into a portable skill.
The goal is not to clone the website exactly. The goal is to answer a more useful question:
How much of this product can an agent reproduce from the public explanation of what it does?
If the answer is “most of it,” that matters.
The customer test
Imagine paying for an app because it corrects grammar, improves clarity, adjusts tone, and rewrites sentences.
Those are useful capabilities. But they are also capabilities that Claude Code or Codex may already have.
A customer could give the Grammarly website to Skillify and receive a skill that teaches their agent to review writing, return a corrected version, and explain its grammar, clarity, and tone changes.
The result will not reproduce every part of Grammarly. It may still cover enough of the job that the subscription is no longer worth paying for.
That is the customer test:
Give Skillify an app you pay for. See how much of the value survives without the app.
The founder test
The same test is useful from the other side.
If Skillify can read a product’s public website and reproduce most of its useful behavior as a Markdown file, the product probably does not have much of a moat.
That does not mean the product is useless. It means the defensible value is not the interface or the instructions behind it.
The harder things to reproduce are proprietary data, accumulated context, and trust.
Proprietary data matters when the product knows something the agent cannot learn from public pages.
Context matters when the product becomes more useful because it remembers the user, their work, their preferences, or their organization.
Trust matters when customers rely on the product’s judgment, consistency, security, or reputation enough that a plausible approximation is not sufficient.
Skillify does not measure all of those things perfectly. It gives founders a simple pressure test. If the public description of the product is enough to recreate its core value, the next question should be uncomfortable:
What does this product know, remember, or earn that the model does not?
The boundary
Skillify uses public pages and documentation to infer capabilities.
It does not copy source code, bypass authentication, or extract proprietary data. It approximates what the product does from what the product publicly claims it can do.
That boundary is also what makes the test useful. Anything Skillify cannot recover from public evidence may be where the real value lives.
Takeaway
Skillify is useful whether you are buying software or building it.
If you are paying for an app, test whether an agent skill can cover enough of the job.
If you are building an app, test whether your value survives after the interface is removed.
URL → skill → cost test or moat test
The interesting result is not that every app can become a skill.
It is finding out which ones can.