Turn one person's best prompt into a skill the whole team can use

To turn one person's best prompt into a team skill, write down the job it does, the context it depends on, the steps it follows and what good output looks like, then store it where every teammate and AI tool can load it. A prompt lives in one person's chat history. A skill is a documented, tested, shared procedure that anyone on the team can run and improve.

Most teams already have a few people whose AI output is noticeably better. The difference is rarely talent. It is a prompt they refined over weeks, plus context they paste in from memory. This post shows how to capture that and make it a team asset.

Why good prompts stay private

Good prompts tend to stay with the person who wrote them, for simple reasons:

• They live in chat history. The best version is buried in a thread from three weeks ago.

• They depend on hidden context. The prompt works because its author pastes in last quarter's pricing notes or the brand voice doc. Nobody else knows to do that.

• They are never tested. No one checks whether the prompt still works after the product, the model or the policy changes.

• There is no obvious place to put them. A shared doc of "useful prompts" goes stale within a month.

The result is uneven quality. Two people write release notes with AI and get two very different results. Gallup reports that 52% of U.S. employees use AI at work, so this gap shows up in a lot of everyday work.

Prompt vs skill: what changes

A skill is a prompt plus everything that makes it work for someone other than its author.

Step 1: Pick a prompt worth sharing

Not every prompt deserves to become a skill. Look for tasks that are:

1. Repeated. Weekly or more often, by more than one person.

2. Judgment-heavy. The output depends on team-specific knowledge, such as tone, pricing rules or customer segments.

3. Visible when wrong. Mistakes reach customers, leadership or production.

Good first candidates: release notes, customer escalation replies, sales call summaries, weekly reporting, first-pass code review against team conventions.

Step 2: Interview the author

Sit with the person who wrote the prompt and run it together. Ask:

• What do you paste in before you run this?

• What do you fix in the output every time?

• What would make you throw the output away and start again?

• Which decisions or rules is this prompt quietly enforcing?

The answers to the last question are often the most valuable part. A release-notes prompt might enforce "never mention internal ticket numbers" and "lead with the customer benefit." Those are team decisions. They belong in the skill, written down, with a link to where the decision was made. If you keep a decision log, point to it.

Step 3: Write the skill

A simple structure works across tools:

Purpose

One or two sentences. "Turn merged pull requests into customer-facing release notes for the monthly changelog."

Inputs

What the user must provide. "List of merged PR titles and descriptions. Target release month."

Context

The background the AI needs and where it comes from. "Brand voice guide (link). Product glossary (link). Rule: we don't announce features that are still behind a flag."

Steps

The procedure, in order. "Group changes by product area. Drop internal-only changes. Write one line per change, benefit first. Flag anything that mentions pricing for review."

Output and examples

The format, plus one or two real examples of good output. Examples do more than any amount of description.

Owner and last reviewed

A name and a date. Without these, the skill will rot.

This is the same thinking behind context engineering for teams: the instructions matter, but the context you hand over matters more.

Step 4: Put it where people and tools can use it

Several AI products now have a native home for this kind of shared procedure. Check what your plan supports before you build around it.

• Claude Skills. Anthropic describes Skills as "folders of instructions, scripts, and resources that Claude loads dynamically." On Team and Enterprise plans, organization owners can provision skills so they appear for every team member. (Anthropic help center)

• ChatGPT custom GPTs and Projects. A custom GPT combines instructions with uploaded knowledge files, and workspace users can share it. Projects group chats, files and custom instructions, and Business, Enterprise and Edu users can share projects with teammates. (OpenAI: creating a GPT, OpenAI: Projects)

• Gemini Gems. Gems can be shared with specific people or by link, with viewer or editor access. (Google support)

Each of these works inside its own product. If your team uses more than one AI tool, you end up keeping a separate copy of the same skill in each one. Keep one source of truth, such as a shared folder or wiki page, and treat the tool-specific versions as copies you update from it.

Step 5: Test and maintain it

Before you announce the skill, have two people who did not write it run it on real inputs. Compare their output to the examples. If it misses, the skill is missing context, not the person.

Then set a maintenance rhythm:

• Review on change. When a pricing decision, brand rule or process changes, update every skill that depends on it.

• Review on schedule. Quarterly is enough for most skills.

• Collect fixes. Give people one place to report "the skill got this wrong." Each report is a missing rule or example.

• Retire skills. If nobody has run a skill in three months, archive it.

Common mistakes

• Copying the prompt verbatim. The author's prompt assumes the author's context. Write that context down.

• One giant skill. "Do all customer support" is not a skill. "Draft a refund reply under our refund policy" is.

• No examples. Without examples of good output, everyone's idea of "good" drifts apart.

• No owner. An unowned skill keeps confidently applying last year's rules.

FAQ

What's the difference between a prompt library and a skills library?

A prompt library stores text. A skills library stores procedures: inputs, context, steps, examples and an owner. The extra structure is what lets someone other than the author get the same result.

Do skills need to be tied to one AI tool?

No. Write the skill in plain Markdown first. Tool-specific features like Claude Skills or custom GPTs are a good way to deliver it, but your source of truth should not depend on any one vendor.

How many skills should a team start with?

Start with three. Pick the repeated, judgment-heavy tasks where uneven quality hurts most. Prove those work before you build more.

Who should own a skill?

The person closest to the process, usually the one whose prompt it started as. Ownership means reviewing it when something changes, not writing every edit.

Start with one prompt

The best prompt on your team is probably sitting in one person's chat history right now. Interview them, write down the context and rules it depends on, test it with someone else, and give it an owner. That turns a personal trick into something the whole team can rely on, and it makes onboarding new hires faster too.

We're building Shane to keep a team's skills and the decisions behind them in one place, and hand them to every AI tool and teammate. If that's a problem your team has, you can join the waitlist at tryshane.ai.