How to publish a private AI skill without sharing its rules

You have an AI skill that contains a valuable method: perhaps a review process, a private rubric, or a set of instructions built from years of experience. You want other people to use it, but you do not want to hand them the files that contain the complete method.

If you send somebody a normal Agent Skill folder, they can read the instructions in the required SKILL.md file. To let people use the skill without delivering those rules, you need to run it as a hosted service and give buyers access to the result instead of the source package.

That choice introduces responsibilities of its own. You must keep the rules on the server, explain how buyer data is handled, and test every buyer-visible surface where private material might appear.

What do you want to keep private?

Start by naming what you are trying to protect:

• Private source: the buyer should not receive the detailed instructions.
• Restricted access: only approved people should be able to use the skill.
• Private inputs: buyer data should not become public or visible to other buyers.
• Confidential method: the creator wants to reduce the chance that the process can be copied or reconstructed.

These needs overlap, but one setting does not solve all of them.

A private repository can restrict who sees source. It does not stop an approved collaborator from reading the files. A hosted runtime can keep rules off the buyer's machine. It does not automatically protect buyer inputs, remove provider access, or make the method impossible to infer.

For example, imagine a skill that reviews landing pages with a private scoring method. A useful promise would be:

Approved users can submit a landing page for review. They receive the critique, while the creator's review rules remain server-side.

You can test whether that statement is true. “The skill is private” is too vague to test or explain to a buyer.

Decide whether buyers receive the files or access

The delivery model decides what can remain private.

Open source is not shorthand for “people can see it.” The Open Source Definition also requires rights such as redistribution and derived works. A visible proprietary package, a private repository, and an open-source skill are different arrangements.

If the rules are the part you need to protect, hosted access is the suitable model. If local use and buyer control matter more, distribute the package and state clearly that the recipient can inspect the method.

Publish the promise, not the private method

A private skill still needs a public or buyer-facing surface. Privacy does not remove the need to explain what someone is being asked to trust.

Publish enough to answer:

• What result does the skill produce?
• Who is it for, and when should they use it?
• What does a representative input and output look like?
• Which agent, environment, or dependency does access require?
• What data leaves the buyer's environment?
• What limits, current version, and support route apply?
• Who operates the skill?

Keep these parts in the private runtime:

• detailed instructions and decision sequences;
• proprietary references, rubrics, or examples;
• hidden evaluation and abuse cases;
• service credentials and provider configuration;
• internal logs and support material that reveal the method.

Putting private rules in a download with a “do not read” notice does not keep them private. Neither does sending them to the browser and hiding them with interface code. The server should receive the request, apply the rules, and return only the intended result and necessary status information.

Saucekit's current hosted shape follows this split. The public skill page can show the creator, promise, audience, examples, privacy boundary, and access information. The supported private rules remain server-side, and an approved buyer receives access rather than the rules themselves.

Protect the whole runtime, not just one file

Keeping SKILL.md off the buyer's machine is only the beginning. The rules or buyer data can still appear in logs, error messages, support exports, or model requests.

Map each item before launch:

Give each person and service only the access it needs. Avoid copying complete rules or buyer inputs into general support tools. Error messages should help the buyer recover without returning internal prompts, stack traces, credentials, or protected references.

Private source and private buyer data are separate promises. A creator can keep the rules server-side and still mishandle the input. Document both boundaries.

Give buyers enough information to trust the skill

A buyer does not need the private method, but they do need enough information to decide whether the skill is useful and safe for their situation.

Show a representative input and output. State the current compatibility and limits. Name the creator or operator. Explain what the buyer sends, what they receive, which service processes it, and what happens when access fails.

For the landing-page review skill, show a real page excerpt and the critique it produced. That gives the buyer evidence of the result without publishing the complete scoring rubric, private references, or internal evaluation cases.

The live Check by Luke page illustrates the public side of this boundary: a named creator, a concrete result, an example, and an access path. Those facts let a person decide whether to continue even though the hosted rules are not on the page.

Test the boundary as a buyer

Test the boundary from a buyer account, not an administrator account.

Inspect:

1. every downloaded or installed file;
2. page source and browser network responses;
3. normal outputs and deliberately invalid inputs;
4. error messages, retry details, and support identifiers;
5. logs or exports visible to the buyer;
6. confirmation emails and access instructions;
7. account removal and expired-access behavior.

Search those surfaces for distinctive phrases from the private rules. Check that credentials and provider details are not returned. Confirm that an expired or unapproved user cannot invoke the hosted method.

Then check that an approved buyer can still understand how to use the skill. Privacy is not useful if requirements, limits, and support are hidden too.

Be precise about what hosted delivery protects

Hosted execution reduces direct exposure. It is not perfect secrecy.

A determined user may infer parts of the method from examples, repeated inputs, outputs, latency, or error behavior. Employees and infrastructure providers may have authorized operational access. A security failure could expose stored material. The creator also becomes responsible for uptime, access control, updates, support, and provider costs.

Use precise language:

• “The operating rules are not included in the buyer's package.”
• “Supported private rules run server-side.”
• “Access can be revoked without recovering a distributed source file.”

Avoid promises such as “uncopyable,” “impossible to reverse engineer,” or “fully private” unless a qualified review can define and support them.

Hosted delivery is appropriate when keeping the source method out of the normal buyer handoff is worth the cost and responsibility of operating the service. If you choose it, describe exactly what remains server-side, what data the service processes, and what the setup cannot guarantee.