Back to guides

How Do I Package a Team SOP as a Claude Skill Anyone Can Run?

Jake McCluskey••Beginner•30 min read
How Do I Package a Team SOP as a Claude Skill Anyone Can Run?

Every team has SOPs nobody follows. They live in a Notion doc someone wrote six months ago, and three people on the team do the task three different ways. A Claude Skill fixes this structurally: the SOP becomes something your team invokes instead of reads, and it produces consistent output every time. Here's how to package one of your team's SOPs as a Skill anyone can run.

Why this matters

SOPs fail because they're passive. The doc exists, people skim it once in onboarding, and then everyone improvises. Meanwhile, the business depends on the SOP being followed — that's why you wrote it.

A Claude Skill is active. When a team member types /onboard-new-client, the Skill runs — not a reminder to follow the SOP, but the SOP actually executing: gathering inputs, applying the template, producing the deliverable. The team doesn't have to remember the steps because Claude does them.

Best first candidates: anything you've trained someone on more than twice. Client onboarding docs, QBR deck generation, bug triage templates, weekly status reports, invoice prep, meeting recaps formatted for your specific Slack conventions.

Before you start

You need:

  • Claude Code installed. Skills live inside Claude Code (the CLI), not Claude.ai. See How Do I Set Up Claude Code on macOS?.
  • One SOP to codify. Pick something small and well-defined. "Turn a client kickoff call transcript into a structured scope doc" is a great first one.
  • A shared Git repo or shared folder where the team's Skills will live (we'll make it discoverable to everyone).

Step 1: Pick the SOP and write out the "perfect run"

Before you write any Skill code, write the SOP the way you wish it were always done. One Google Doc, top to bottom:

  • Input: what does the person running it provide? (A transcript? A client name?)
  • Steps: what happens, in order?
  • Output: what does the final deliverable look like? Ideally attach an example.
  • Gotchas: what does every new hire get wrong?

Tight example — scope doc from kickoff transcript:

  • Input: call transcript (.txt or pasted).
  • Steps: extract goals, extract constraints, extract deliverables, map deliverables to phases, flag anything ambiguous as "needs confirmation."
  • Output: a markdown scope doc in our template.
  • Gotchas: don't invent deliverables the client didn't mention; always quote the client's own words for each goal.

Do not skip this step. Skills built without a crisp spec are Skills that produce inconsistent output, which is the problem you're trying to solve.

Step 2: Create the Skill file

Skills live in .claude/skills/ in your project (or globally in ~/.claude/skills/). Create a folder per Skill:

bash
mkdir -p .claude/skills/scope-from-transcript
cd .claude/skills/scope-from-transcript
touch SKILL.md

SKILL.md is the Skill's definition. The format:

markdown
---
name: scope-from-transcript
description: Turn a kickoff call transcript into a structured scope doc. Runs on pasted transcript or file path.
---

# Scope-from-transcript

You are generating a scope doc from a client kickoff call transcript.

## Inputs
The user provides a transcript (pasted inline or as a file path).

## Process
1. Read the transcript fully before writing anything.
2. Identify and extract:
   - **Goals:** what the client wants to achieve (business outcome, not feature list).
   - **Deliverables:** concrete things to produce.
   - **Constraints:** budget, timeline, technology requirements, people/stakeholder constraints.
   - **Ambiguities:** anything the client said that could mean two things. Flag these explicitly.
3. For each goal, quote the client's own words in italics beneath the goal.
4. Group deliverables into phases: Phase 1 (weeks 1–2), Phase 2 (weeks 3–6), Phase 3 (weeks 7+).
5. Output in the template below.

## Output template
See `./template.md` in this Skill's folder.

## Rules
- Never invent deliverables the client didn't mention.
- Never drop ambiguous items — flag them as "needs confirmation" in a final section.
- Quote the client's language verbatim when stating goals.

Step 3: Add supporting files

Claude Skills can include helper files. Drop the scope doc template into the Skill folder:

bash
# .claude/skills/scope-from-transcript/template.md
# Scope: [Client Name]

## Goals
- [Goal 1]
  > *"client's own words here"*

## Deliverables

### Phase 1 (weeks 1–2)
- [Deliverable]

### Phase 2 (weeks 3–6)
- [Deliverable]

### Phase 3 (weeks 7+)
- [Deliverable]

## Constraints
- [Constraint]

## Needs confirmation
- [Ambiguity]

Any file in the Skill folder is available to Claude when the Skill runs. Use this for templates, reference docs, example outputs, or lightweight scripts.

Step 4: Test the Skill end-to-end

In Claude Code, inside the project, type /scope-from-transcript and paste a real transcript (or provide a path).

Claude invokes the Skill. You should see:

  1. Claude reads SKILL.md and template.md.
  2. Claude processes the transcript against the steps.
  3. Claude outputs a scope doc in your template.

Compare the output to one a senior team member would have produced. Close? Ship it. Missing something? Edit SKILL.md (tighten a rule, add a step, clarify a gotcha) and re-run.

Iteration is fast because the Skill is just a markdown file — no code, no redeploy.

Step 5: Share it with the team

Commit the .claude/skills/scope-from-transcript/ folder to your repo. Any teammate who pulls the repo now has the Skill available in their Claude Code session.

For Skills that aren't tied to a single repo (general-purpose company SOPs), put them in a shared company-skills repo and have teammates symlink it into ~/.claude/skills/ globally:

bash
git clone [email protected]:your-org/company-skills.git ~/work/company-skills
ln -s ~/work/company-skills/* ~/.claude/skills/

Now every teammate, on every project, can run any company Skill.

Step 6: Add a short runbook for the team

One paragraph in your internal wiki:

Our company Skills — we package common SOPs as Claude Skills. Run one by typing /skill-name in Claude Code. Current Skills: scope-from-transcript, qbr-deck-from-report, bug-triage-template. To add a new one, see company-skills/README.md.

The friction you're removing: nobody has to remember the SOP exists. They invoke the Skill, get the output, ship it. That's it.

Verify it worked

1. Skill is discoverable. In Claude Code, type / and scroll — your Skill should appear in the list.

2. Output is consistent across runs. Run the Skill three times on three different transcripts. The structure should be identical; only the content varies.

3. Teammate can run it. Have a teammate pull the repo and run the Skill on their own input. If their output matches yours in structure, you've successfully codified the SOP.

Where this breaks

  • SOPs that are genuinely judgment-heavy. "Decide whether to fire a client" isn't Skill-shaped — the decision requires context no Skill can encode. Reserve Skills for repeatable transformations, not judgment calls.
  • The "kitchen sink" Skill. If your SKILL.md is 400 lines, you're trying to do three Skills in one. Split it: scope-from-transcript + scope-to-proposal + proposal-to-contract.
  • Client data in versioned Skills. If a Skill references a real client transcript as an example, redact it before committing. The repo is your team's forever.
  • Skills that depend on MCP tools the user might not have. If your Skill requires an Ahrefs MCP connection and a new hire doesn't have it, the Skill will fail cryptically. Document required MCPs at the top of SKILL.md.
  • Letting Skills rot. SOPs change. When the QBR deck template gets a new section, update the Skill the same day. Otherwise the Skill produces obsolete output and the team loses trust in Skills generally.

What to try next

Want this built for you instead?

Let's talk about your AI + SEO stack

If you'd rather skip the how-to and have it shipped for you, that's what I do. Start a conversation and we'll figure out the fastest path to results.

Let's Talk
Questions from readers

Frequently asked

What's the difference between a Claude Skill and a Claude Project?

Projects are for persistent context (voice guide, offer docs) used in ongoing conversations. Skills are for reusable workflows — specific transformations you run on demand. A Project holds who you are; a Skill performs a specific job.

Do Skills work in Claude.ai or only Claude Code?

Skills are a Claude Code feature today. Claude.ai has Projects with custom instructions, which can approximate smaller Skills for solo users, but the Skills mechanic — slash-invoked, composable, with helper files — is CLI only. For team SOPs, Claude Code is the right tool.

Can a Skill call other Skills?

Yes. Skills compose — a master Skill like /onboard-new-client can invoke sub-Skills like /scope-from-transcript and /proposal-from-scope. Claude Code orchestrates the calls. For complex SOPs, this chaining is how you stay DRY.

How do I roll out Skills to a team that doesn't all use Claude Code yet?

Pair the Skill release with a one-page runbook in your wiki and a 15-minute demo. Most teammates adopt Skills faster than they adopt the SOP docs they were supposed to follow — because Skills save time instead of asking for it.

What if a Skill produces wrong output on an edge case?

Edit SKILL.md. It's just markdown, no redeploy. Add the edge case to the rules section or the gotchas list, commit, push, done. The team gets the fix on their next git pull. This is the core reason Skills beat static SOPs: they're editable in seconds.