A traditional marketing team stores its process in people, so the process leaves when a person leaves. An AI-native marketing team stores the same process in files that Claude reads every session. With no Claude skills set up, Claude has the same flaw as the person: it forgets you every session, so you re-explain the job and repeat each correction.

A traditional team scales by hiring, and its quality resets each time someone quits.
An AI-native team scales by adding files, and every saved correction improves the next run.
A Claude skill plus a state file is an SOP that a stranger can run on day one.
Six agents can split the marketing work, and each one has an action it may never take alone.
Nine steps turn one weekly SOP into a skill, and you can start with the one you run most.

A Traditional Team Stores Its Process in People, and an AI-Native Team Stores It in Files

A traditional marketing team is a group of people with jobs. The writer knows the voice, the ops lead knows the calendar, and the founder knows the offer. That knowledge moves through meetings and chat, so it lives in heads.

An SOP, a standard operating procedure, is the written steps for one repeated job. Most teams never write it down. When the owner takes leave, the work stops, and you pay for the same work again next week. I call that rented work, because you keep nothing.

An AI-native team is a system. Every repeated job is a file, and every file sits in Git, a free tool that saves every version of a folder. A person still decides what ships, but the process no longer needs that person in the room.

The same week of posts stalls when the process lives in a head, and ships when it lives in files.

Picture one week with the marketing lead on leave. The job is one newsletter and five LinkedIn posts.

In the traditional team, a teammate asks around in chat and writes from memory. The posts slip, or ship in the wrong voice.
In the AI-native team, the teammate types a one-line prompt. The skill asks for each input and writes six drafts to a folder.
The lead comes back to six drafts waiting for review, and approves or cuts each one.

The files that make this work form a harness. A harness is Claude plus the files it reads on startup: your rules, your identity, your skills, your tools and your state. A harness turns a 20-prompt job into a 2-prompt job, because the files correct a lazy prompt before Claude acts.

An AI-native team runs as a loop of six parts, and feedback rewrites the strategy and skills.

The system is a loop of six parts:

Strategy: your voice, audience and offer, written in one file Claude reads first
Skills: one folder per repeated job
Agents: one per workstream, each with a hard stop
Review: a scorer checks each draft, then you approve or cut it
Publishing: only after your explicit yes
Feedback: each correction goes back into a file, so the loop starts smarter

The last part is the reason the system wins over time. In a traditional team, a correction lives in one person's memory. In an AI-native team, a correction lives in a file, so every later run inherits it.

An illustrative curve shows traditional quality resetting at each departure while AI-native quality keeps climbing.

The curve above is an illustration with no data behind it. The shape is the claim. The AI-native line starts lower, because writing the skills takes weeks. The traditional line drops each time a person leaves and takes the process with them.

Rule of thumb: If a correction you made last month still lives only in your head, your team runs on rented work.

A Skill Plus a State File Is an SOP a Stranger Can Run

A Claude skill is a folder that teaches Claude one job. Anthropic shipped the format on October 16, 2025. The folder holds three parts:

SKILL.md, the prompt, the trigger words and the output format
scripts/, optional Python checks, scorers and loops
references/, optional examples whose style the skill copies

Anthropic announced Skills as packaged instructions that teach Claude your way of working.

A skill alone still leaves a gap. A reader can follow the steps, but cannot see what happened on the last run. So every skill that acts on the world also writes a state file. A state file is a log the agent edits after each run, with rows marked sent, pending or failed.

A skill file, a state file and a reference file each have one owner, and only the agent writes state.

My newsletter outreach shows why the state file matters. The DM tool writes a sent log and a reply log after every send. Those two logs are the only thing that stops the next run messaging the same person twice.

Claude reads the context, skills and tools layers as local folders, so the setup outlives one chat session.

A skill library is a folder of these skills. It replaces the habit of typing a fresh prompt for the same job every morning.

Six Agents Run My Marketing Work, and Each One Has a Hard Stop

An agent is a markdown file that names one workstream, the skills it may call and the point where it stops. In Claude Code, these files sit in .claude/agents/. I sort agents by workstream rather than by job title. If two agents could take the same job, the split is wrong.

Six agents split the marketing work, and each card names the one action that agent never takes alone.

The hard stop carries the most weight. Each agent knows the one action it may never take alone, and that limit is written in its file. The publisher drafts and polishes, then waits for my yes. The librarian archives old files and never deletes one.

Grace Leung builds a marketing team from Claude skills and agents in this 16-minute walkthrough.

A New Skill Joins the Team in Four Moves

Adding a skill to the team works like hiring a specialist. You hand over the job description, point the specialist at the brand guide, and name a manager. Then you test the work before you trust it.

Drop the skill folder into .claude/skills/. Claude finds it on the next session.
Point the skill at your voice and brand file, so it writes as you.
List the skill in the one agent file that owns its workstream.
Run one lazy prompt in a fresh session and check the output.

My skill pack installs the same way. Each skill is a folder you copy in, and one setup file holds your voice.

The skill pack page shows the install path: drop the folder in, ask for the outcome, keep the file.

Two groups in the pack map to marketing roles. The growth group covers research and outreach. Marketing X-Ray interrogates your offer and ends in seven ranked moves. Dream 100 Outreach scores your ideal prospects and writes the message and the gift.

Marketing X-Ray interrogates your offer and ends in seven ranked moves.

The everyday social group fills the content seats. LinkedIn Posts picks a proven format before it writes. LinkedIn Carousels exports every slide as a PNG. Content Calendar puts a specific title on every slot.

LinkedIn Posts writes in your voice and picks a proven format first.

Skills call tools, such as a scheduler or an SEO data source. My tool directory lists the 18 content and marketing tools I use, from Zernio for scheduling to OpenSEO for rank tracking.

The Content and Marketing shelf of my tool directory, with Zernio for scheduling.

Step 1. Write the SOP as Numbered Steps in a Skill Folder

You need Claude Code or Claude Desktop, a folder, and an SOP you already run every week. CLAUDE.md is a markdown file that Claude reads at the start of every session in that folder. Put your brand voice and audience notes there first.

Shann Holmberg tells marketers to write a brand foundation file first, with voice, tone, audience and banned phrases.

Then build the skill itself:

Pick the SOP you repeat most, such as the weekly newsletter or the Friday report.
Write its steps as a numbered list, the way you would brief a new hire.
Save the list as SKILL.md in its own folder under .claude/skills/.
Add a name and a description at the top, with the exact words that should trigger the skill.

Keep the first SKILL.md short: a name, a description with trigger words, and five or six numbered steps. The Appendix holds a skeleton.

Step 2. Make the Skill Interview You and Wait for a Yes

A weak skill takes your one-line prompt and guesses the rest. A good skill asks for each input it needs, one at a time, and cannot reach step 2 until step 1 has an answer.

Take a skill that sends a Slack DM blast. It asks for the message first. Then it asks for the channel. Then it shows the final DM and asks for a yes. A "maybe" or silence stops the run.

My own skills follow the same shape:

My article skill runs an intake before it drafts a word. It asks for my hot take, the one number only I have, and who the piece is for.
My DM tool runs a dry run by default. A dry run shows what would go out and sends nothing. Only a live flag sends, and that needs my explicit word.
My comment tool makes the dry run mandatory, because LinkedIn's API offers no way to delete a posted comment.

Watch out: A sent Substack DM cannot be deleted by the API or in the web UI. The dry run is the last place a mistake still costs nothing.

Step 3. Log Every Run in a State File and Keep Examples Beside It

Tell the skill to add one row to a state file after every run. The row records what went out, to whom, and whether it worked. The next run reads the file before it acts.

Then put two or three examples of good past output in references/. The skill copies their shape, so you stop describing your format in words.

Step 4. Send Every Draft to a File and a Review Queue

Tell every skill to write its output to a drafts folder. Chat is the wrong place for a draft, because chat disappears when the session ends.

This matters most when you review in bulk. Over three sessions, an agent can produce 30 drafts. If they sit in chat, they scroll away, and nothing records which ones you approved. A draft you never saw either ships unchecked or dies quietly.

The fix has two parts:

Each skill saves its output as a file in one known folder.
One script builds a single review page that lists every waiting draft with an approve or cut choice.

Step 5. Block Bad Output With a Scorer Inside a Hook

A rule the agent can ignore is a suggestion. Claude follows a prompt rule most of the time, then drops it deep in a long session. You learn about the miss when a reader sees it.

More rules, written louder, fail because each new rule competes with every other line in the prompt. So put the rule in a hook. A hook is a script Claude Code runs on its own before or after an action, such as a file save. A hook that finds a failure blocks the action.

A scorer is the script inside that hook. It reads the output and returns a number. Below the bar, it refuses to continue.

In one session, 21 LinkedIn comments failed the scorer and never posted. The comment script refuses three things on its own:

A comment longer than 240 characters
About twenty generic compliment openers
The sentence template "the X is the Y"

The third rule came from a real failure. In one batch, half of my comments used that template, and readers flagged the batch as AI. Now the script refuses the template before a reader can see it.

You can build the same loop for any output:

Write down what good output and bad output look like.
Generate a draft.
Score it with a script or a grader.
Regenerate until it passes, or stop after 3 to 5 tries.

Tip: Use a fresh subagent as the grader. A subagent is a second Claude session that the first one starts for a single task. An agent will not reject an answer it wrote earlier in the same session.

Step 6. Let a Check That Crashes Pass the Work Through

A check has two ways to stop work. It can find a real failure in the draft, or it can break itself. Block on the first. On the second, let the work through and print a warning.

Checks break for dull reasons:

Python is missing on a new laptop.
A file has an odd format.
The script has a bug.

If the check blocks on its own error, every save fails and the afternoon is gone. The owner then switches the hook off to get work done, and from that moment nothing is checked at all. So wrap the check in an error handler that exits cleanly and reports the crash.

Step 7. Run the Stranger Test in a Fresh Session

Test every skill by handing it to a fresh AI session that has no memory of your past chats. If that session cannot run the job from the files alone, the SOP is unfinished.

This test is harder than onboarding a person. A new hire who gets stuck walks over and asks you. A fresh session cannot ask, so it guesses, and the guess looks confident.

The usual test fails because you run it in the session where you built the skill. That chat already holds your corrections, so the skill passes. Next week a new session opens with none of that, and the same skill drifts.

So open a new session and type a lazy one-line prompt, the kind a busy teammate will type. Note each place the output goes wrong. Each one is a fact you never wrote down, so add it to a file the skill reads.

Step 8. Keep Team Skills in the Company Repo, Apart From Your Second Brain

A second brain is a personal notes vault that Claude reads as context about you. A company brain is the company's own repo, with team skills and a README written for agents. A repo is a project folder that Git tracks. Keep the two in separate repos.

The split follows ownership:

The second brain holds your personal voice, your personal keys and your own notes.
The company brain holds the company voice, the shared skills and the instructions any teammate's Claude can follow.

A company documentation repo makes a good company brain. Its team skills, such as a blog writer and a LinkedIn post writer, live in .claude/skills/. A new joiner points Claude at the repo and starts with zero context.

Dan Rosenthal moved his company brain to GitHub, so each of 20+ teammates starts a ready assistant.

An agency uses the same split. One skill library serves every client, and each client gets its own context folder for brand, audience and product facts.

One skill library serves every client workspace, and only the context folder changes per client.

Step 9. Commit the Skills Folder to Git Before You Change Laptops

A skill that lives on one laptop is the same SOP in one head, one level up. Commit these folders to a private Git repo on GitHub:

Commit your skills, agents and routines folders, your CLAUDE.md files and a template that lists your API key names with no values.
Never commit the file that holds your API keys or the file that holds your live login tokens.

On a new machine, clone that repo and run one restore script. My full PC setup came back in 45 minutes that way. The full backup and restore guide lives in the 5 files that give Claude Code permanent memory.

Advanced Users Split Agents by Workstream and Store Routines as Files

Once three or four skills work, the next problems are scale, schedules and drift. Four habits handle them:

One agent per workstream. Each agent owns one stream of work and calls the skills inside it. Publishing, outreach and auditing never share an agent.
Routines live in Git. A routine is a scheduled workflow that runs on a timer. A routine saved only inside a Claude account vanishes when you switch accounts, so keep each one as a file.
Load order decides which rule wins. The load order is the sequence in which Claude reads its instructions. The global CLAUDE.md loads first, then the project CLAUDE.md, then the skills, then the tools.
Connectors follow their owner. MCP, the Model Context Protocol, is the standard plug that connects Claude to outside tools. Cloud connectors belong to the account, and local MCP servers belong to the machine.

Example: If the wrong files loaded, throw the output away and rerun. A fresh run costs one prompt, and a patched draft keeps the wrong rules inside it.

FAQ

Do I need to code to build a Claude skill? No. A skill is a markdown file with numbered steps. Scripts are optional, and you can add a scorer later when a rule keeps slipping.

How many skills does a small marketing team need? Start with the one SOP you repeat most each week. Add a second skill only after the first one passes the stranger test in a fresh session.

What is the difference between a skill and an agent? A skill teaches Claude one job, such as a LinkedIn post. An agent owns a workstream, calls several skills, and has one action it may never take alone.

Will an AI-native team replace my marketers? The people still own strategy, taste and the final yes. The files take over the repeated steps, so a person's leave no longer stops the work.

Can I use ready-made skills instead of writing my own? Yes. A ready-made skill installs as a folder. Point it at your voice file, assign it to an agent, and run the stranger test before you trust it.

Appendix

A skill folder with its state and examples:

.claude/
  agents/
    publisher.md
    outreach-rep.md
  skills/
    weekly-newsletter/
      SKILL.md
      references/
        issue-41.md
        issue-42.md
      state/
        sent.tsv
CLAUDE.md

A first SKILL.md, short enough to finish in an afternoon:

---
name: weekly-newsletter
description: Draft the weekly newsletter. Use when asked for "the newsletter", "this week's issue" or "the Friday email".
---

1. Ask for this week's one main story. Wait for the answer.
2. Ask for the number or result only we have. Wait for the answer.
3. Read the two issues in references/ and copy their shape.
4. Write the draft to drafts/ as a file. Never paste it in chat.
5. Show the subject line and ask for a yes before any send.
6. After the send, add one row to state/sent.tsv.

A hook that blocks on a real failure and lets the work through when the check itself crashes:

import sys, json

try:
    draft = json.load(sys.stdin)["tool_input"]["content"]
    if len(draft) > 240:
        print("Blocked: comment over 240 characters", file=sys.stderr)
        sys.exit(2)  # exit 2 blocks the action
except Exception as e:
    print(f"Check crashed, letting work through: {e}", file=sys.stderr)
    sys.exit(0)

Build an AI Marketing Team From Claude Skills…