How to Write AI Skills Other People Can Reuse

A skill that works well for you is usually full of you. Your name is in the rules, your facts are in the examples, and your machine is in the setup steps.

I have now turned two of my own working systems into versions other people can run: a resume kit and a public data research agent. The same changes made both of them reusable.

What makes an AI skill hard to share?

Three things get tangled together while you build it: the method, the facts, and the settings. The method is how the work is done, the facts are what is true for one person or one case, and the settings are which account, sheet, or folder to use.

A new person can reuse the method. They cannot reuse your facts or your settings, and if the three are mixed in one file, they cannot tell which is which.

Step one: split the method from the facts

In the AI resume kit, the rules, templates, and tools are the shared part. A person’s confirmed history, numbers, and skills live in a profile folder that starts empty and is filled by a first-run questionnaire.

In the public data research agent, the workflows and shared safeguards are fixed. Everything specific to one data source lives in that source’s own file, and a new source starts from an intake template.

Step two: write down who wins a conflict

Every reusable skill needs a short rule for what happens when two files disagree. Without it, the agent picks, and picking is a guess.

The research agent uses three sentences. The source file wins on how a step is done, the shared safeguards win on safety and can never be weakened, and the config file wins on settings. The resume kit ranks its sources from the person’s latest statement down to the original resume.

Step three: replace yourself with a role

My early files said “Josh” everywhere: Josh’s preferences, ask Josh, Josh’s bans. That works until someone else runs it.

The reusable versions say “the operator” or “the candidate” instead, with one line explaining that older files that name me should be read that way. Anything tied to a person or a machine moved into one config file.

Step four: move fragile steps into scripts

Prose instructions get followed most of the time. A step that must be right every time belongs in a script, because a script does not drift.

In my experience a validator is often a better prompt than another paragraph of rules. Some of the scripts that do this work:

• A ledger tool that refuses duplicate keys, backs up first, and verifies the file grew.
• A sheet-row builder that width-checks every row, so a note can never land in the wrong column.
• An ATS checker that fails a resume with tables, text boxes, headers, or a third page.
• A content validator for this site that checks lengths, headings, banned words, privacy, and links, and builds the JSON-LD.

Step five: add a first-session checklist and stop rules

A new operator’s first session should check the setup before any work starts: folders connected, tools loaded, accounts shared, and what is missing reported plainly.

Stop rules travel with the skill. A captcha, a sign-in wall, a payment screen, or an uncertain match means stop and ask, for every operator, every time.

Step six: package it without personal data

Sharing a copy by hand invites leaks. The resume kit has a packaging script that builds a clean copy with no personal data, and the research agent ships as a packaged folder with the per-person settings isolated in config.

Before sharing, read the packaged copy as if you were a stranger. Anything that only makes sense to you is still a fact, not method.

How do you know a skill is ready to share?

Run it from a fresh session using only the files. If a new session cannot reproduce yesterday’s result, something the skill depends on is still in your head instead of in the files.

The research agent makes this a formal gate. A new data source is not ready until a fresh session repeats a pull and gets the identical set of records.

Frequently asked questions

Does a reusable skill need code?

Not always, but the steps that must never vary are safer in a small script. Prose is fine for judgment, and scripts are better for counting, formatting, and checking.

How long should a skill’s main file be?

Short enough to read every session. I keep the main file as the reading order and the core rules, and put detail in the files it points to.

What should never go in a shared skill?

Personal facts, credentials, account ids, and private data. Those belong in a profile or config file that each person fills in for themselves.

Takeaway

A reusable skill is a method with clear seams: facts in one place, settings in another, safety rules above both, and scripts for anything that must be exact.

The reasoning behind all of this is in Why Constraints in AI Development Matter. For the coding side, read Why I Write Tests Before AI Writes Code.