What you can — and can't — protect when you sell an AI skill

Start with the legal reality

Sellers often assume copyright or a license will protect their work. In practice, neither holds much weight for prompts:

• Copyright on prompts is thin. Short instructional text sits in a gray zone, and someone who rephrases your method has likely stepped around whatever protection existed. (This isn't legal advice; it's the practical consensus among people selling in this market.)
• Licenses don't enforce themselves. A "no-resale" clause means a lawsuit you'd have to fund, against a buyer you may not be able to identify, in a jurisdiction you may not reach — over a purchase worth less than the filing fee.
• Watermarking and fingerprinting identify leakers after the fact. Detection isn't prevention; by the time you've detected, the copy exists.

So legal and forensic tools won't save a leaked file. The only protection that works is structural: the buyer never holds the file at all — which is what server-side execution provides. But even that has a boundary, and this is where honesty matters.

The boundary: doing vs dispensing

Every sellable skill falls on one side of a line:

Skills that DO things — protectable. The value is the method: how the skill transforms, analyzes, restructures, or generates against the buyer's specific inputs. A code-review method with a refined checklist. A cold-email rewriter with a tested persuasion sequence. A contract analyzer with a specific risk taxonomy. The buyer sends inputs, gets back a result shaped by the method — and the result doesn't contain the method. Run server-side, this kind of skill can be sold ten thousand times and never leak. A live example of the doing side: Repo README Writer, a Connected skill ($0.49 per call) that works on the files in the buyer's repository under a scope the buyer approves and writes the README into their working tree. The work happens in the buyer's project — and the method never reaches their machine.

Skills that DISPENSE a document — not protectable. If the entire value is a fixed block of text the skill hands over — a template, a swipe file, a guide — then the output is the IP. The first buyer to receive the output has received everything. No architecture, no marketplace, no legal instrument can protect a product whose delivery and disclosure are the same act.

A quick self-test for your skill

Ask one question: if a buyer showed someone else their result, could that person replicate the skill?

• If the answer is no — the result is specific to the buyer's inputs and doesn't expose your method — your skill is a doing skill, and sealed execution protects it fully.
• If the answer is yes — the result is essentially your product, reusable by anyone who sees it — you have a dispensing skill, and you should price it as a one-time sale with no illusions, or rework it.

How to move a skill to the protectable side

Many dispensing skills have a doing skill hiding inside them:

• iSell the application, not the artifact. Don't sell your prompt-writing guide — sell a skill that applies your methodology to the buyer's draft and returns an improved version.
• iiMake inputs do work. The more a result depends on the buyer's specific context, the less of your method each result reveals.
• iiiKeep the judgment server-side. Checklists, scoring rubrics, decision trees — encode them in the skill body so buyers get conclusions, not the rubric.

Reworked this way, a skill also fits per-call pricing naturally: buyers come back because the skill does new work on each new input.

Have a skill that does real work?

Join the early-access list — sellers on the list get the launch deal first.

Building in the open · @sealedrun