Tutorials 4 min read

How to let people use a skill in a browser

Turning a skill into a browser app isn't a format conversion — it's building a product. An app is made for a goal and usually composes several skills; the frontend is designed for the goal, not generated from a SKILL.md.

The other three ways to “run a skill anywhere” all keep it a skill — installed, shared, or scheduled, but still instructions for an agent. This one is different. When the person who needs to use your skill has no agent at all — a colleague in ops, a customer, your non-technical co-founder — they need something they can open in a browser and type into. They need an app. And an app is not a skill in a different wrapper.

The distinction that changes everything

A skill records how to perform a step correctly. An app is built for a goal.

Those aren’t two names for the same thing. “Extract the tables from a PDF” is a skill — a reusable procedure. “Turn a quarterly PDF into a one-page board summary” is a goal, and reaching it might draw on three skills: extract the tables, summarize the narrative, format the output. The app is the product built for that goal; the skills are the know-how it leans on for particular steps.

This is why turning a skill into an app is not a format conversion. There’s nothing in a SKILL.md that tells you what the app’s form should ask for — the frontmatter carries a name and a description, and that’s it. Deciding what a user needs to supply to reach the goal is design work, done over the goal and its skills together. It’s the interesting part, and it’s not something a template can do for you.

Composing skills into one app

Create an app from several owned skills at once:

POST /v1/apps
{
  "slug": "board-summary",
  "title": "Board Summary Builder",
  "description": "Turn a quarterly PDF into a one-page board summary.",
  "skill_ids": ["skl_extract", "skl_summarize", "skl_format"]
}

The skills are composed, in order, into one prompt under a preamble that states the app’s goal and frames them as procedures serving it — not as three alternative tasks to choose between, which is what an agent does when you paste three SKILL.md files end to end without that framing. A single skill is snapshotted verbatim; several become a goal-directed whole.

Then design the frontend

Creating the app gives it a prompt, not a face. The frontend is the part you design for the goal: what does this app need from the user that it can’t work out itself? For the board summary, maybe a file upload and a “tone” selector — decisions that come from the goal, not from any one skill.

The fastest way to build that face well is to let an agent do it. The deploy guide is written for exactly this: an agent — yours, or the platform’s chat builder at creator.skillsafe.ai — reads it, designs a spec or a full frontend bundle for the goal, and uploads it with POST /v1/apps/{slug}/releases. Accounts, credit billing, and storage are already there; you’re designing an interface, not building a backend.

The one-command version, and its honest limit

skillsafe deploy does the whole thing in one call — publish the skill, create the app, ship a runnable frontend — and it’s the fastest way to see your skill in a browser. But be clear about what it ships: a scaffold. One free-text box, enough to prove the deploy works. It is not a designed frontend, and the command says so rather than letting the scaffold pass for a finished product. Use it to verify, then design the real thing.

Deployed apps are private by default — only you can open one until you decide otherwise. An agent deploying on your behalf should never make your work world-runnable as a side effect; going public is an explicit step that requires a clean security scan, since a public app is running code in front of strangers.

When to reach for this

Not every skill should become an app, and most shouldn’t. If the people who need your skill have agents, share it or install it — that’s less work for everyone. Reach for an app when the audience is people without an agent, when the task is self-contained enough to express as “inputs in, result out,” or when you want a link you can hand to anyone. That’s the moment a skill has outgrown being a skill, and a browser is the right place for it to live.

More ways to run a skill: on any machine · shared with no install · on a schedule