Claude Code skills for operators: 5 capabilities, 1 stack

Most posts about Claude Code skills for operators read like tutorials. Here's a SKILL.md, here's the frontmatter, go build one.

That's not the part that's hard.

The hard part is deciding which capabilities your stack actually needs, and how the output of one capability becomes the input of the next without you re-explaining context every run. This post is the capability map I wish I'd had a year ago, written by someone running a real one. The post you're reading was generated by a stack like the one described here. That's the proof.

Key takeaways:

• A Claude Code skill is a folder, not a prompt. It bundles instructions, scripts, references, and approval gates into a unit Claude executes on demand. The format is portable across Claude Code, Cursor, Codex CLI, and Gemini CLI.
• Five capabilities cover almost any operator content stack: research, planning, short-form output, long-form output, downloadables. Each is a single-purpose unit. The handoffs are what make them a system.
• The architectural pattern that turns capabilities into a stack is shared state, not message passing. A simple, durable surface every skill reads and writes. That's the difference between a folder of scripts and something that compounds.
• Time saved is the wrong metric. The right one is whether the output is repeatable without you. Skills that produce inconsistent output under the same input aren't skills, they're prompts in disguise.

What "skill" actually means in Claude Code

Anthropic shipped Skills in October 2025. The format is boring on purpose: a folder with a SKILL.md file, YAML frontmatter at the top, instructions below, and any scripts or reference files alongside. Claude loads the skill when the description matches the task. The official docs at code.claude.com cover the syntax. The anthropics/skills repo ships the reference examples.

That's the surface. The mechanic underneath is what changed how I build.

A skill is a contract. The frontmatter declares what the skill does. The body declares how. Scripts in the folder declare what's deterministic versus what's model-generated. A reader, including a future me, can tell at a glance whether a given task is in scope. That's what separates a skill from a clever prompt I pasted into a doc somewhere.

The same SKILL.md files work across Claude Code, Cursor, Gemini CLI, and Codex CLI. The format is portable on purpose. If you build a skill once, it's not locked into one tool's UI.

Five capabilities every operator content stack needs

After a year of running a content engine on Claude Code, the same five capabilities keep showing up. Different operators implement them differently. The categories don't change.

• Research. Pulls signal from where your audience actually talks (Reddit, X, YouTube, niche forums, the open web). Returns a synthesized brief with citations on a 30-day window. Without this, you're writing from training data, which is stale by definition.
• Planning. Holds the editorial calendar. Decides what gets written when, by which format, against which pillar. Audits last period's output against targets. Refreshes weekly with research signal so the plan stays alive instead of brittle.
• Short-form. Voice-locked output for the platforms where you publish daily. Three variations per topic so you pick the one that lands, not the one the model liked best.
• Long-form. SEO-aware writer with image generation built in. Multi-phase: research, brief approval, draft, audit, distribution. Approval gates between phases.
• Downloadables. Lead magnets, frameworks, swipe files. Distinct format, same voice, paired with promo content for the platforms that drive traffic to it.

That's it. Five units. Each does one job. None of them invents a new abstraction for an existing tool. The art isn't in the units, it's in the handoffs.

What turns capabilities into a stack: the handoff principle

This is the part most "operator AI stack" posts skip, and it's the only part that matters.

The pattern is shared state, not message passing. Every skill in your stack should read from and write to the same durable surface. The surface holds the editorial decisions: what's being written, when, against which keyword, in which voice. The skills are stateless. The state lives in one place. When a skill starts, it reads. When it finishes, it writes.

That's the whole architecture.

Why it works: as soon as your skills share a surface, the stack becomes resumable. Killed Claude mid-run? The state still says "in progress," the next invocation picks up from where it stopped. Want to swap a topic on Monday morning before drafting starts? Edit the surface, the skill reads the new context. That kind of resumability is what separates a system from a sequence of prompts.

The Anthropic docs cover related patterns when they describe subagents and Agent Teams. Shared-state handoffs are the cheap version of the same idea. You don't need a job queue or an event bus. You need a place where the editorial decisions live, and a discipline that every skill reads it before acting and writes to it before exiting.

The other thing the handoff buys you is auditability. Every piece of output in your stack should leave a trail you can reconstruct from. When something looks off in a published post, you should be able to open the source of truth and see what the skill saw when it wrote. That trail is what makes failure recoverable instead of mysterious. A chat-history-only workflow can't give you that.

Time saved is the wrong metric

People ask how many hours this saves. It's the wrong question.

A long-form post used to take me roughly six to eight hours of focused time across research, brief, drafting, image work, SEO, and distribution. With a stack like the one described here, the same post takes about ninety minutes of human time. That's a real number from my own logs, not a marketing claim.

But the time figure misses the point.

The actual win is that the output is repeatable. Voice doesn't drift across posts because the tone-of-voice rules get re-read on every run. SEO doesn't slip because keyword strategy lives in a reference file the stack consults, not in your head on a Tuesday. Internal linking stays clean because the links map updates itself when a post ships. The compounding effect is on quality, not on speed. Quality compounds. Speed is the side effect.

This is the same point I made in tools commoditize, systems compound. A skill stack is the system. The model underneath gets better every quarter. The capabilities your stack covers don't have to.

What to build, what to skip

If you're starting your own set of Claude Code skills for operators tomorrow, here's what I'd do and not do based on what's worked.

• Build skills around outcomes, not tools. A "blog writer" skill is good. A "Claude wrapper" skill is not. The unit of value is what the user gets, not which API got called.
• Encode references once. Tone-of-voice rules, SEO targets, brand assets, link maps. Put them in reference files inside the skill folder. Read them on every run. Do not paste them into every prompt.
• Use approval gates as your safety rail. A long-form skill should not write a post without you confirming the operator-facts block. Gates catch fabrications before they ship. Do not skip them to look fast.
• Skip the meta-skills. A skill that picks which skill to run is almost always a Claude Code subagent in disguise, and the /agents command already covers that case. Don't reinvent the dispatcher.
• Skip the wrapper skills. A skill that just rewords a prompt and adds two formatting rules is a prompt, not a skill. The bar for adding to your stack should be "this has its own scripts and references," not "this is a paragraph of instructions."

The anthropics/skills public repo is a reasonable starting point if you want to see what production-grade skills look like. Read three or four. Then write your own from scratch once you understand the shape. Cloning is the wrong starting move because the skills you'll find online are calibrated to other people's outputs, not yours.

What it actually feels like to operate this way

I'm a Director at a Nordic IT academy and I run a personal brand on the side. The constraint is honest: time. A capability stack is what makes the second viable without the first suffering.

The mindset shift is what took the longest to land. The first month I treated each skill like a clever assistant and tried to coach it through every decision in chat. The output was uneven and the time saved was minimal. The shift happened when I stopped treating skills as collaborators and started treating them as functions with contracts. Inputs are explicit. Outputs are typed. Approval gates exist for the decisions that need a human, not for hand-holding.

Once I stopped negotiating with the skills mid-run, the system started compounding.

I track my own version of this the same way I track my quarterly biomarker panel. Specific numbers, repeated cadence, no ceremony. Learning AI by building was the first post I wrote after committing to this approach. The capability map above is what came out the other side.

If you're an operator running personal output alongside a real job, the question isn't whether to use Claude Code skills for operators. It's whether you've thought about the handoffs between them, or whether you're still running each capability as a one-off. Tools commoditize. Skills compound, but only if you treat them as systems with handoffs, not as bookmarks.