I was scrolling GitHub Trending the other day and something clicked. Five of the seven projects on the daily board were Claude Agent Skills, and almost all of them pointed the same direction: package a prompt, some sample code, and a director's guide into a skill, then let an agent auto-generate a product promo video. One repo was 189 stars. Two others, same shape, same day, sat right next to it. Neat little bundles, some barely 50KB.
The interesting part wasn't the skill format. It was what happened when I opened the LICENSE files.
The license read that stopped me
The top project, the 189-star one, had PolyForm Noncommercial written on the first line. Noncommercial. The other two were MIT. Same category, same day, wildly different rules for whether you can build anything commercial on top. If you clone based on star count alone and skip the license, you paint yourself into a corner later, and it's expensive to unwind.
So the discipline is boring but non-negotiable: read the LICENSE original text, not the one-line description in the README. MIT and Apache go into the candidate pile. AGPL and Noncommercial stay as reference only. There were a few high-star AGPL projects on that board too, and for a closed-source SaaS you basically can't touch them. None of this is glamorous, but it's the difference between shipping and rewriting.
The gap nobody has solved yet
Here's the thing that kept nagging me. Skills right now only have free distribution through GitHub. There's no mature paid marketplace. So an individual developer is stuck asking the same question I was: do you go "free package for reach, sell the hosted execution," or do you wait for a market to form?
I don't think you wait. Markets that don't exist yet are terrible things to bet a launch on.
And once you frame it as "free file, paid run," the license mess actually resolves itself. A skill file is inherently a giveaway. It's tiny, it's copyable, and the moment it's public anyone can fork it. Fighting that is a losing game. What you can actually charge for is the validated workflow behind it, running somewhere the buyer can't just clone. The file is the brochure. The endpoint is the product.
There's a comment buried in one of the other threads that says this better than I can. Someone described their current work as distilling an employee's judgment and experience into a reusable automated workflow, and their takeaway was that the human value sits in exploring the unknown and turning it into a stable, repeatable pipeline. That's exactly the asset worth hosting. Not the prompt. The pipeline.
What you'd actually build
Say you have one workflow you've genuinely validated. The example the original poster floated was an SEO article pipeline, topic selection through to finished draft, structured the way a skill is structured. Good candidate, because it's a repeatable sequence with clear inputs and a clear output.
Here's how I'd package it on VicroCode without pretending it's more than it is.
The workflow logic lives as Python. You can run Python online on the platform, which means the orchestration, the validation steps, the retries, the formatting, all of it stays server-side where the buyer never sees it. That's your moat, such as it is. The free skill file they downloaded describes the shape; the paid endpoint does the work.
Wrap that logic behind an API Endpoint that agents invoke as a tool call. This is the part that matters for distribution. Instead of shipping a file and hoping, you expose the run. An agent, or a buyer's own automation, calls your endpoint, passes the inputs, gets the finished output back. The platform's support for AI agent development and in-platform tool calls is what lets the skill file and the hosted execution be two separate things: one free, one metered.
For the parts that need memory, use what's there. A SQLite database for run records, job state, whatever the workflow needs to track between calls. A LanceDB knowledge base if the workflow leans on retrieval, say a house style guide or a corpus of past drafts the SEO pipeline pulls from. Model access comes through Model Center for models already on the platform, so you're not wiring up external accounts to make the run happen.
Then you publish it. Project publishing, hosting, and monetization are in the box, and published projects sit alongside other online tools buyers and agents can find. The free skill file is your top-of-funnel; the hosted endpoint is what you charge for.
Where the boundary sits
I want to be honest about the edges, because the evidence doesn't support half the things a pitch like this usually claims.
Whether this actually converts, whether "free package plus paid run" beats waiting for a marketplace, is unverified. Nobody in the source material has run that experiment and reported numbers. The 189-star project's traction is real; its revenue, if any, is not something I can see.
Distribution is still hard, and the evidence is blunt about it. One independent developer described being told to go find 50 to 100 precise users, trying Reddit, and getting posts deleted for account-level reasons. Building the endpoint is the easy 20%. Getting agents and buyers to call it is the other 80%, and VicroCode's hosting doesn't solve that for you.
The platform capabilities are also a hard boundary. If your workflow needs a framework, a language, a cloud service, or a deployment method outside HTML apps, online Python, Model Center models, hosted API endpoints, SQLite, LanceDB, and file management, that part doesn't happen here. Don't design a pipeline that assumes a Next.js frontend or an external queue and then act surprised. Scope the workflow to what the platform actually runs.
And there's the skeptic's point from the thread, which I think is fair: when a model vendor ships a new model, some of a skill's supposed magic just evaporates. So don't sell the prompt as if it's permanent. Sell the validated workflow, the thing you distilled from real deliveries, and keep it current. That's the part that survives a model upgrade.
The short version
Skills are having a moment, the licenses are a minefield, and there's no paid market yet. Read the LICENSE original text every time, keep only MIT and Apache in the commercial pile, and stop treating the distributable file as the thing you sell. Give the file away. Host the run. On VicroCode that maps cleanly onto Python execution behind a tool-call endpoint, with SQLite and LanceDB for state and retrieval, published and monetized in place. Just don't skip the license read, and don't assume the traffic shows up on its own.