Most content teams I work with install too many Claude Code skills. They grab anything tagged "writing," wire up seven different SEO helpers, and then wonder why their drafts come back sounding like a committee wrote them. The right stack is small, opinionated, and shaped around the actual editorial pipeline — brief, draft, voice, structure, ship.
This is the stack I'd hand a content team on day one: ten to twelve skills that earn their place, organised by the moments in the workflow where Claude actually saves time. I'll show install commands, typical invocations, two or three combined workflows, and — just as important — the skills I'd uninstall because they quietly degrade Claude's writing.
Claude Code skills are bundles of instructions, examples, and tool allowances stored as SKILL.md files under ~/.claude/skills/. Each one teaches Claude how to behave inside a specific domain — write a brief, run an outline review, fact-check a draft. The problem isn't that skills are bad; it's that they compound.
Every active skill costs context. Every one you install adds invocation triggers Claude has to weigh on every prompt. Install fifteen overlapping writing skills and Claude starts arbitrating between them instead of just writing. I've watched teams paste the same brief into Claude and get six different tones back across six sessions, simply because three skills with conflicting voice guidance were all firing.
The pattern that works: pick one skill per editorial function, not three. One drafting skill, one voice enforcer, one editorial reviewer, one SEO pass, one fact-checker. Layer your house style on top via a CLAUDE.md at the project root — that's the file Claude reads automatically for every prompt in that directory, and it's where your non-negotiables live (brand vocabulary, banned phrases, target reading level).
The rule of thumb I give new teams: if two skills overlap by more than 30%, uninstall the weaker one. Don't try to combine them with prompt-level instructions. Claude follows the skill that fires first more reliably than it follows your runtime overrides.
A second rule: skills should map to moments in your workflow, not to topics. A skill called blog-writer is too vague — Claude doesn't know whether you want a draft, an outline, a headline test, or a repurposing pass. A skill called longform-draft-from-brief is much more useful because the trigger condition is unambiguous. When you browse /category/content/, prioritise picks with narrow, verb-shaped names over broad role names.
The stack below is sized for a content team of two to ten people producing a mix of long-form, social, and email. Solo creators can cut it in half; in-house enterprise teams might add a compliance review skill on top. But ten to twelve is the sweet spot — enough coverage that Claude has the right tool for each step, few enough that you can hold the whole stack in your head and know which one is firing when.
Drafting is where most content teams start, and it's the easiest place to over-install. You only need one skill in this slot — the one that takes a brief and produces a first draft your editor doesn't want to throw away. Browse /category/content/ and look for skills tagged longform, brief-to-draft, or article-writer.
The pick should accept a structured brief (audience, angle, key points, target length, voice notes) and produce a draft that respects those constraints. Skills that ignore brief structure and just riff from the headline are a trap — they read fluently but the editor ends up rewriting the structural bones.
Install:
cd ~/.claude/skills/
git clone https://github.com/<author>/<longform-draft-skill>.git longform-draftOr, if the skill is in the ClaudSkills catalog and you've installed the desktop app, hit the install button on the skill page — same destination, no shell needed.
Typical use:
claude "Use the longform-draft skill. Brief is in briefs/2026-06-pricing-page.md.
Target 1,800 words, audience is mid-market SaaS founders, voice is the
standard ClaudSkills voice. Draft to drafts/pricing-page-v1.md."The single most important quality bar: does the skill ask clarifying questions when the brief is thin? A drafter that confidently fabricates an angle when given a vague brief will burn editor time for years. A drafter that responds with "the brief doesn't specify a primary call-to-action — should the draft assume a free trial signup or a sales conversation?" is worth ten times more.
A second drafting skill that earns its place on some teams: an outline-first variant for pieces over 2,500 words. Long pieces benefit from a two-step flow — outline review with the editor, then draft against the approved outline. If your team produces a lot of long-form, install both and triage by length. If you're mostly producing 800-1,500 word pieces, one drafter is enough.
What I avoid in this slot: any drafting skill that bundles its own "voice" assumptions ("writes in a punchy, conversational tone"). Voice belongs in a separate skill, layered on top. Bundled voice means every draft sounds the same no matter what brand you're writing for, and overrides are unreliable.
This is the slot that most teams underweight. A voice & style enforcement skill takes a draft Claude (or anyone) produced and rewrites it to match a documented house style — reading level, sentence rhythm, banned phrases, signature vocabulary, opening/closing patterns.
The good ones are picky in a useful way. They flag "in today's fast-paced world" and similar zombie phrases. They notice when the draft drifts above the team's target Flesch reading level. They catch the AI tells — em-dash overuse, "it's worth noting," "delve," "navigate the landscape of" — and either rewrite or flag.
Browse /category/content/copywriting/ for picks. The strongest skills in this category ship with editable house-style configuration files, not hardcoded rules. You should be able to drop your brand's banned-words list into a file the skill reads, without forking the skill itself.
Install and typical use:
claude "Use the voice-enforcer skill on drafts/pricing-page-v1.md. Output
to drafts/pricing-page-v1-voiced.md. Show me a diff of every change with
a one-line reason."The "show me a diff with reasons" pattern is critical. A voice enforcer that silently rewrites two hundred lines is a black box — you lose track of what changed and why. The good ones produce structured output: original line, rewritten line, the rule that fired. Editors review the diff, accept or reject per change, and ship.
One configuration tip: keep your house style in a style-guide.md file at the project root and reference it from CLAUDE.md. That way the voice skill reads it, the drafter reads it, and any other skill that needs it reads it — all from one source. When the head of brand updates the banned-words list, every skill picks it up on the next invocation.
Don't install more than one voice skill at a time. Two voice enforcers running on the same draft will fight each other, and the result is mush. If your team writes for multiple brands, configure the single voice skill to load brand-specific style files per project, rather than installing separate skills per brand.
Editorial review is structurally different from voice enforcement. Voice enforcement asks "does this sound like us?" Editorial review asks "does this actually work as a piece of writing?" — is the argument structured, do the transitions land, are claims supported, is the opening earning its space.
The skill in this slot should produce structured feedback, not rewrites. You want a numbered list of issues with line references, severity, and suggested fixes — not a wholesale redraft. Rewrites short-circuit the editor's judgment; feedback respects it.
Look for picks in /category/content/ tagged editorial-review, line-edit, or copy-edit. The category page on ClaudSkills surfaces the strongest options at the top.
Typical use:
claude "Use the editorial-review skill on drafts/pricing-page-v1-voiced.md.
Review for structure, argument flow, and claim support. Output a numbered
punch-list. Don't rewrite the draft itself."What separates good editorial review skills from bad ones: the good ones distinguish between local issues (this sentence is unclear) and structural issues (paragraphs 4 and 7 make the same argument). The bad ones bury structural feedback inside line-by-line nitpicks, which is exhausting to act on. If you find yourself ignoring the skill's output because the signal-to-noise is low, that's a sign to swap it for a sharper pick.
A second skill worth considering in this slot if you produce technical content: a fact-claim extractor that pulls every assertable claim out of a draft into a checklist for fact-checking. It pairs naturally with whatever review skill you've picked — review handles "does this argument work," claim extractor handles "which sentences need a source." I'll come back to fact-checking proper in its own section.
SEO skills are where I see the most damage to good writing. The naive ones stuff target keywords into every other sentence, add an "FAQ" section to articles that don't need one, and bloat word count to hit some arbitrary threshold. By the time you've reversed all the damage, you might as well have written the piece without the skill.
The pick I recommend is a skill that does three specific things and nothing else: (1) suggests where the target query and natural variants could appear without forcing them, (2) flags genuinely missing on-page SEO signals like a too-thin title or a missing meta description, and (3) checks heading structure for hierarchy and scannability. That's it. No keyword density warnings, no "increase word count by 30%" suggestions.
Install and typical use:
claude "Use the seo-pass skill on drafts/pricing-page-v1-voiced.md.
Target query is 'saas pricing page examples'. Suggest natural integrations
only — don't rewrite the piece. Flag any missing meta or heading issues."The phrase "suggest natural integrations only" matters. Without it, even good SEO skills sometimes get aggressive and rewrite the opening to lead with the target keyword. That's bad SEO and bad writing — search engines have been demoting awkward keyword leads for years.
What I avoid: any SEO skill that promises "keyword density optimization," "LSI keyword injection," or an "SEO score" out of 100. The score is meaningless and teams optimise for the score instead of the reader. If your SEO skill produces a number, ignore the number and read the actual suggestions.
A bonus skill in this slot: a title and meta generator that produces five to seven options per page, each with character counts and a one-line rationale. Titles and meta descriptions deserve real iteration, and a skill that generates options without you having to remember the character limits earns its install every time.
The repurposing slot is high-leverage. One well-written long-form piece can become five LinkedIn posts, a thread, a newsletter, three pull-quote graphics, and a podcast outline. Doing that by hand takes hours. A repurposing skill does the first pass in seconds and your editor finishes in fifteen minutes per asset.
The strongest picks in this category accept a source piece and a target channel, and produce platform-appropriate output — not just shorter versions. A LinkedIn post is not a truncated blog post; a newsletter is not a copy-paste of the article body. The skill should know the conventions of each channel and write to them.
Browse /category/content/ for picks tagged repurpose, cross-channel, or specific channels like linkedin, thread, newsletter.
Typical use:
claude "Use the repurpose skill. Source: drafts/pricing-page-v1-final.md.
Targets: 1 LinkedIn post (founder voice, ~200 words), 1 X thread (8 posts),
1 newsletter intro (~150 words pointing to the article). Output to repurpose/."One pattern that works well: configure the repurpose skill to read the same style-guide.md your voice enforcer uses. That way LinkedIn posts sound like your brand, not like generic LinkedIn-bait. Without the style file, repurposing skills default to platform conventions, which means every brand on LinkedIn sounds the same.
What I avoid: skills that promise "omnichannel repurposing across 15 platforms." In practice, you ship to two or three channels. A skill focused on those three will produce better output than one trying to be everything.
A useful pairing: a headline iteration skill that takes one strong headline and produces ten variants — different angles, different lengths, different emotional registers. Pair it with whatever channel-specific repurposer you've picked. The headline iterator runs first, you pick the strongest options, then the repurposer writes to those headlines.
Fact-checking is the slot most teams skip and regret. The skill here doesn't replace human fact-checking — it makes the human's job tractable. The job: pull every factual claim out of a draft, flag which ones have a cited source, flag which ones need one, and (where possible) check the obvious ones.
The pick should never verify claims by itself — Claude is wrong often enough about specific dates, numbers, and attributions that any skill claiming to "fact-check" autonomously is a liability. The good skills are honest about this: they extract, structure, and prompt, but they leave verification to a human checking against the cited source.
Typical use:
claude "Use the factcheck-prep skill on drafts/pricing-page-v1-final.md.
Extract every numerical claim, attributed quote, and statement about a
company or product. Output a checklist with line numbers. Don't verify
anything — just structure the list for the editor."The checklist format matters more than the cleverness of the extraction. An editor with a numbered list of 14 claims and line references can work through it in twenty minutes. An editor handed a wall of prose annotated inline with question marks will give up after three claims.
One pattern I recommend: keep a sources.md file at the project root listing every external source the team has cited in the last quarter, with URLs and access dates. The fact-check skill can read it, recognise repeat-cited sources, and flag which claims in the new draft trace back to which existing source. Saves your editors the lookup tax on every piece.
What I avoid: any skill that pulls live web data to "verify" claims. Two reasons. First, Claude's web-fetch results are inconsistent enough that a confident verification is sometimes wrong, and false confidence is worse than no verification. Second, your editor needs to look at the source themselves anyway for context, so the skill's check is wasted work.
The point of a curated stack is that the skills compose into pipelines you can run end-to-end on one prompt or in chained sessions. Three worked examples below.
Pipeline 1: Brief to publish-ready draft (long-form article).
claude "For brief briefs/2026-06-pricing-page.md, run this pipeline:
1. longform-draft → drafts/v1.md
2. voice-enforcer on drafts/v1.md → drafts/v1-voiced.md (show diff)
3. editorial-review on drafts/v1-voiced.md → review/v1-notes.md
4. factcheck-prep on drafts/v1-voiced.md → factcheck/v1-checklist.md
Stop after step 4. I'll act on the review notes and check facts manually,
then come back for the SEO pass."The stop point is intentional. Editorial review and fact-checking are human-in-the-loop steps; automating past them defeats the purpose. The pipeline gets you to the moment where a human adds judgment, then waits.
Pipeline 2: Headline iteration before drafting (the brief is strong but the angle is uncertain).
claude "For brief briefs/2026-06-pricing-page.md, generate 10 headline
variants with the headline-iterator skill. For each, write a one-paragraph
angle summary. Output to angles/v1.md. Don't draft anything yet."You pick the strongest two or three angles, refine the brief, then run the drafting pipeline. This costs an extra fifteen minutes upfront and saves an hour of editor rewrites downstream.
Pipeline 3: Post-publish repurposing.
claude "Final piece is at published/2026-06-pricing-page.md. Run repurpose
for: LinkedIn (founder voice), X thread, newsletter intro. Use style-guide.md
for voice. Output to repurpose/2026-06-pricing-page/. Editor will review."Repurposing as a separate pipeline (not chained into the drafting one) has a real benefit: you can run it weeks after publish, when you've seen which angles landed and want to lean into them on social. Repurposing immediately after publish often pushes the weakest angles to channels because you haven't seen reader response yet.
The general rule for pipelines: each skill should have a clean handoff file as its output, so a human can intervene at any point. Pipelines that pass intermediate state in-memory between skills are fragile — one skill misbehaves and you can't tell which one or fix it cleanly. File-based handoffs let you re-run any single step without re-running the whole thing.
Some skills are tempting on the install page and damaging once they're active. I uninstall these on every team I work with.
The general pattern: skills that promise breadth over depth, skills that produce scores, and skills that bypass human judgment are the three failure modes. When in doubt, prefer a narrower skill that does one thing well.
A diagnostic for whether a skill belongs on your stack: turn it off for two weeks and see if your editors ask for it back. If nobody notices, it wasn't earning its slot.
Even with a strong curated stack, every content team eventually hits a moment where no off-the-shelf skill fits. The signs:
Writing a skill is much less work than writing one tends to look. A skill is a markdown file with YAML frontmatter and a body explaining when to use it and how to behave. Most useful skills are under 200 lines. See /learn/writing-a-skill-md-file/ for the format and a worked example, and /learn/installing-claude-code-skills/ if you haven't installed any yet.
The pattern I recommend for first-time skill authors: take your strongest editor's longest piece of feedback on a recent draft. The recurring patterns in that feedback — the things they say every week — are your skill. Document those patterns as anti-trigger rules ("NEVER do X"), positive instructions ("DO Y"), and worked examples ("if the draft says Z, rewrite to W"). Test on three real drafts. Iterate. Within an afternoon you'll have a skill that captures your editor's judgment well enough to apply to every future draft.
The team-internal skills don't need to be in the public catalog. Keep them in a private git repo, install via git clone into ~/.claude/skills/, and version them like any other piece of editorial infrastructure. When a new writer joins, your custom stack is part of onboarding — they get your voice and process loaded onto Claude on day one, which is faster than two months of feedback cycles.
Found a bug or want a topic covered? Email [email protected] or open an issue via GitHub.
SKILL.md files, not affiliated with, endorsed by, or sponsored by Anthropic.