Growth work lives or dies on the loop: spot an opportunity, write the thing, ship the thing, look at what happened, repeat. Claude Code is unusually well-suited to that loop because most of the artefacts — briefs, outlines, ad variants, email subject lines, landing-page critiques, attribution sanity checks — are text you'd otherwise grind through in Google Docs and Notion. A skill (a SKILL.md file Claude loads on demand) lets you bottle one of those moves so it fires the same way every time.
This is an opinionated starter stack. Ten or twelve picks, three concrete workflows that chain them, an anti-stack of skills I'd actively skip, and a note on when to give up and write your own. Read it once, install the four or five that match your week, leave the rest.
Three properties of growth work make it a strong fit for skills. First, most of the deliverables are text with a known shape — a keyword brief has a query, intent, SERP snapshot, content angle, and outline. A skill can encode that shape once and stop you redesigning the wheel every Tuesday morning. Second, the work is iterative: ad copy, subject lines, CTAs, and meta descriptions are written in batches of five or ten variants. Claude is fast at the “give me ten more, weight them differently” loop in a way that no doc tool is. Third, growth output is almost always evidence-bound — you have a SERP, an analytics export, a transcript of customer calls, a competitor page. Pasting that into a chat works, but a skill that ingests the same shape every time produces comparable artefacts you can A/B against each other.
A quick orientation if you're new to SKILL.md: a skill is a markdown file with YAML frontmatter (name, description, optional allowed-tools, user-invokable, model) and a body that explains when to use the skill, how the model should think, and what to emit. Claude Code auto-discovers skills under ~/.claude/skills/ and surfaces them by their description field. Good skills lead with a sharp anti-trigger section — the situations where they should not fire — because the most common failure mode is a useful skill hijacking an unrelated request.
What you will not get from any stack of skills: a replacement for taste. Growth work that wins is built on a real understanding of who the customer is, why they came, and what nearly stopped them from buying. Skills accelerate the work that follows that understanding; they don't generate it. The picks below assume you already know your wedge and your audience and you're trying to get more output per hour without losing the line.
One practical note before the list. I'm going to use generic skill names below (keyword-brief, serp-snapshot, etc.) because the actual slugs in the catalog drift as authors revise their work. When you go to install, browse /category/growth/ and pick the highest-quality match for each role. The catalog's quality signals are content-derived, so an older skill with sharper structure usually beats a newer one with marketing fluff.
Each pick gets a one-line role, why I think it earns a slot, and the install + invocation pattern. Install is always claude skills install <slug> from the desktop app or cp the SKILL.md into ~/.claude/skills/<slug>/ by hand.
Takes a query and (optionally) a SERP paste, returns intent classification, content angle, must-cover subtopics, and outline skeleton. Saves the “what should this page even be” argument.
claude skills install keyword-brief
# in Claude Code:
/keyword-brief query="claude code skill marketplace" intent=researchPaste the top 10 results, get back a table of page types, word counts, schema usage, and the gap your page should exploit. Pairs with keyword-brief.
Reads a URL or pasted HTML and grades hero, social proof, objection handling, primary CTA, and friction. Emits a numbered fix list ordered by expected lift.
/landing-page-critique url="https://acme.com/pricing"Give it a product blurb and a target persona, get ten variants across three angles (problem-led, outcome-led, mechanism-led). Useful for Google RSAs and Meta primary text.
Generates 8–12 subjects across curiosity, urgency, personalisation, and value-prop. Notes which test against which segment.
Single-purpose. Takes the prospect's recent activity, writes a 1–2 line opener that doesn't sound like a tool wrote it.
Paste your page and a competitor's, get a side-by-side of claims, proof, social proof density, and messaging hierarchy.
Takes a keyword brief and emits a publishable outline with intro/body/CTA structure. Stops you starting drafts from blank.
Reads a GA4 or Plausible export and writes the “what changed this week” paragraph for your standup. No more eyeballing 47 rows.
Compares Stripe revenue, ad platform conversions, and your analytics tool's goal completions and flags the gaps that mean something vs. the ones that don't.
Walks the five-question positioning interview and emits a one-paragraph statement plus three messaging variants.
Generates a 5–7 email sequence given a product, segment, and goal. Each email has a single job. Avoids the “welcome / here are five features” trap.
This is the move I run most weeks. Start with a query you want to rank for, end with a first draft a human can edit in 30 minutes instead of 3 hours. Four steps, four skills.
Open the SERP for your query, copy the top 10 titles + meta descriptions + URL paths into a text file. Run serp-snapshot on it.
/serp-snapshot query="saas onboarding email examples"
# paste SERP text when promptedYou'll get back a table classifying each result (listicle, case study, product page, documentation), median word count, common subtopics, and the angle nobody's covered. If five of the top ten are 4000-word listicles, your odds of out-listing them are bad — pick a different angle. The output of this step is the single most important input to the next one.
Feed the SERP snapshot plus the query into keyword-brief. Ask it to lean on a specific angle from the snapshot output.
/keyword-brief query="saas onboarding email examples" \
angle="founder-led, real examples with screenshots" \
[email protected]The brief should include: target reader, search intent, primary keyword + 3–5 secondary keywords, must-cover subtopics, recommended length, and a draft H1 + meta description. If anything in the brief makes you go “no, that's not what we want”, fix it before you outline. A bad brief produces a bad outline produces a bad draft — you cannot recover later.
Run content-outline on the brief. The output is H2/H3 structure, one-line summary per section, intro hook, CTA placement, and internal linking suggestions.
/content-outline [email protected] style=conversational depth=2500This is the step where you do the most human work. Read every H2. Is it the right argument in the right order? Do the H3s flow? Is the intro hook actually a hook or does it sound like a definition? Edit the outline by hand. Iteration is cheap here, expensive once you have prose.
Pass the edited outline back to Claude and ask for a draft section by section, not the whole article in one shot. One section at a time lets you correct voice and fact-check claims before they propagate. When a section feels off, regenerate that section only, not the whole piece.
The full loop, on a 2500-word article, takes me about 90 minutes including human edits at every step. The same article from a blank page takes 4–6 hours. The win isn't speed though — it's that the brief and outline are forced to exist as artefacts you can critique, so the draft starts from a defensible structure.
Landing page work is the highest-leverage growth activity most operators under-invest in. A 10% lift on a page handling 30,000 visitors a month is worth more than a month of content output. This workflow uses two skills, runs in about an hour, and produces a testable variant.
Run landing-page-critique against the live URL. The skill walks the page top-to-bottom and grades hero clarity, primary CTA visibility, social proof density and quality, objection handling, scannability, and friction (form length, payment options, trust signals near the CTA).
/landing-page-critique url="https://acme.com/checkout" \
audience="first-time-buyer" \
goal="start-trial"You'll get back a numbered list of issues ordered by expected impact on conversion. The first 3–5 items are where you focus. The skill is opinionated — if it says your hero copy is generic, take that seriously and don't argue. Generic hero copy is the single most common landing page failure and the easiest to fix.
Run competitor-page-diff against the two or three competitor pages your target customer would also evaluate.
/competitor-page-diff yours="https://acme.com/checkout" \
theirs="https://competitor1.com/pricing,https://competitor2.com/pricing"Look for claims they make that you don't, social proof they have that you lack, and objections they handle that you ignore. Don't copy them — find the gap you're uniquely positioned to fill. The diff is a thinking aid, not a checklist.
Take the top 3 critique findings and the top 2 gap findings. Write a brief in your own words for the variant page — what changes, why, and what you expect to lift. Then ask Claude for the rewritten hero, body, CTA, and FAQ in your tone. Do not let Claude restructure the page without your explicit framing — the skill is good at copy, bad at IA on a page it can't see being used.
/landing-page-rewrite [email protected] \
tone="confident, technical, dry humour" \
preserve="page structure, image positions"Push the variant to your A/B tool (Plausible Experiments, GrowthBook, VWO, etc.), define success as primary CTA click-through plus downstream conversion, and let it run to statistical significance. Resist the urge to call it after 200 visitors. The discipline that makes A/B work is leaving the test alone.
One caveat: this workflow assumes you have enough traffic to A/B meaningfully (~1000 conversions per variant for a 10% lift detection at typical SaaS effect sizes). Below that, ship the variant as the new default and trust the critique.
The post-launch retro is where most teams leave money on the table. You launched, something happened, you moved on to the next thing. This workflow forces you to extract structured learning from the launch you just ran so the next one is 20% better.
Before you fire any skill, collect: the launch plan (what you said you'd do), the actual timeline (what you did), the channel-by-channel results, customer reactions (social, support tickets, sales calls), and at least one piece of qualitative feedback per channel. The skills are useful here but they can't manufacture the input data.
Export GA4 or Plausible data for the launch week + the prior baseline week. Run ga-export-reader on both.
/ga-export-reader [email protected] [email protected] \
goal="trial-signup"The output tells you what moved, by how much, and where the lift came from (channel, page, source/medium). Pay attention to what didn't move — if the launch was a 15% lift overall but organic search was flat, your launch had zero on the audience you were trying to reach long-term.
Pull revenue from Stripe, conversions from each ad platform, and goals from analytics. Run attribution-sanity-check across all three.
/attribution-sanity-check [email protected] \
[email protected],@meta-ads.csv \
[email protected]This is the step that exposes whether your “Meta drove 40% of signups” story is true or a function of Meta's last-click optimisation eating credit it didn't earn. The skill flags discrepancies >15% as worth investigating and the smaller ones as noise.
Open a doc and write five sections, in this order, by hand or with a retro-template skill: What we said we'd do, What actually happened, What worked — with evidence, What didn't — with evidence, What we'll do differently next time. The evidence requirement is the whole point. “Twitter felt flat” is not a finding; “Twitter drove 4% of clicks vs 12% of effort, and the top-performing post was the unscheduled reply, not the launch thread” is.
The retro that lives in a Slack DM might as well not exist. Drop it in a retros/ folder in your team wiki with the launch date in the filename. When you plan the next launch, the first step is reading the last three retros. You will be tempted to skip this. Don't.
Half the catalogue is noise for growth operators. These are the categories I'd skip, with reasoning.
Virality is a function of timing, audience trust, and topical relevance — not copywriting. A skill that generates “viral hooks” produces tweets that sound like they were written by someone trying to go viral, which is the exact thing that doesn't go viral. Write your own tweets in your own voice and treat virality as a downstream outcome of consistent posting, not a thing you optimise for per-tweet.
You don't have a topic-ideation problem. You have a topic-evaluation problem — which of the ten ideas you already have is worth your week. A keyword-brief skill that pressure-tests one idea is worth a hundred idea-firehose skills.
Meta descriptions are written page-by-page, in the voice of the page, with the page's actual selling proposition. A skill that generates 50 metas from a spreadsheet of URLs produces 50 generic metas. CTR moves on specificity, and specificity comes from context the skill doesn't have.
The transformation is mechanical, and the output reads like it. If your blog post can be turned into a thread by chopping it up, your thread is going to read like chopped-up blog post, because that's exactly what it is. Threads need their own structure (hook, escalation, payoff) that doesn't map onto blog structure (intro, body, conclusion).
Anything that promises to generate your “90-day growth plan” from a one-paragraph product description is producing a strategy template, not a strategy. Strategy comes from looking at your specific data and saying no to most of the things you could do. A skill can't do that for you.
If your content needs a humaniser because it sounds like a robot wrote it, the fix is to either rewrite it as a human or accept that the content shouldn't ship. The detection arms race is a distraction from the actual question, which is whether the content is worth a reader's time.
LinkedIn scrapers, Twitter scrapers, search-result scrapers — they break every few weeks when the platform updates, and the time you save when they work is dwarfed by the time you lose when they don't. Pay for the API, accept the constraints, or do the work by hand for the small batches where it matters.
The best growth skills are the ones you write for the moves you make every week. The catalog gives you a strong starting set, but your specific positioning, audience, and channels are unique enough that a generic skill will plateau at 70% of the value of a custom one. The trigger for writing your own is repetition: if you've written the same kind of artefact (brief, retro, ad set, sequence) three times by hand in the last month, you've earned a skill.
Writing a skill is mechanically simple. Make a directory under ~/.claude/skills/ with your slug as the name, drop a SKILL.md with frontmatter and a body. Here's the minimal template I start from for a growth skill.
---
name: acme-keyword-brief
description: Turn a target query into a structured keyword brief for Acme's content pipeline. Use when the user shares a SERP query, a competitor URL, or asks for a brief.
user-invokable: true
allowed-tools: [Read, Write, WebFetch]
model: claude-sonnet-4-5
---
# Acme Keyword Brief
## When NOT to use this skill
- Generic content ideation without a target query
- “What should we write about?” questions
- Anything outside Acme's three product pillars (developer tools, MLOps, observability)
## What this skill does
Produces a one-page brief with: query, search intent, target reader,
primary + secondary keywords, must-cover subtopics, recommended H2 outline,
draft H1, draft meta description.
## Input shape
- Required: target query
- Optional: SERP paste, competitor URLs, internal subject-matter notes
## Output shape
A markdown document with the eight sections above, in order, ready to paste
into our content tracker.
## Style notes
- Lead with the intent classification before any keyword analysis.
- Cap secondary keywords at five — we don't optimise for more than that.
- Match our voice: direct, technical, no superlatives in headings.
- For meta descriptions, write 150–158 chars and never start with the brand name.
Three things to invest in when you write your own. First, the anti-trigger section — what the skill should not do. This is where you stop the skill firing on tangentially related prompts and producing junk. Second, concrete style notes that reflect your team's actual house style. “Match our voice” is useless; “direct, technical, no superlatives in headings” is testable. Third, a worked example. If you can paste one input and one ideal output into the body of the skill, the model has something to anchor on that no amount of instruction can substitute for.
Iteration cadence: ship the v1 with a known failure case in mind, use it for a week, list what it got wrong, edit the SKILL.md, repeat. Most of my custom skills hit good-enough at v3 and stabilise. The few that don't were skills I shouldn't have written in the first place — the underlying move was either too one-off or too taste-driven for a skill to add leverage. Killing a skill is fine; some moves are just human moves.
The skills above are leverage. The habits below are what turn leverage into output. Most of them are obvious; the trick is doing them.
Even a 90-second brief beats no brief. A bullet list of “query, intent, angle, who reads this, what we want them to do next” takes two minutes and saves the hour where you and the model spend the draft arguing about scope. The brief is also the artefact you go back to in the retro to ask whether you achieved what you set out to do.
The most common authoring mistake is the kitchen-sink skill that “does keyword research, writes briefs, drafts content, and generates social posts”. None of those four steps gets done well, the anti-trigger gets vague, and the skill fires on everything and excels at nothing. If your skill description has “and” in it more than once, split it.
The fastest way to ruin your growth work is to start trusting Claude to be right. The model is great at structure and pattern, mediocre at facts, and unable to know what your customer actually said in last week's sales call. Read every draft top to bottom. Edit aggressively. The 30 minutes you save by not reading the draft are the 30 minutes that put a wrong statistic in your published article.
Drop your ~/.claude/skills/ directory under git. When a skill changes behaviour, you want to know which commit and roll back if the change made it worse. Skills drift over time as you nudge them — without version control you lose the lineage of what worked.
If a competitor's landing page nails an objection you've been ducking, take the objection-handling move and adapt it. Don't take the copy. The point of the critique workflow is to see the moves your competitors are making well, not to clone them. Adapt, don't copy, and attribute the inspiration when it matters.
Once a quarter, take a brief you wrote by hand that produced a piece of content that worked. Run the same query through your current skill stack. Compare the two briefs. If the skill brief is meaningfully worse, your skill needs editing. If the skill brief is meaningfully better, congratulations, you've levelled up your house style — update your manual workflow to match. If they're identical, the skill is calibrated and you can trust the loop.
Skills you installed and don't use, kill. Workflows that haven't produced output in a month, kill. Templates that you keep meaning to fix but haven't, kill. The growth stack is high-maintenance — every skill is a tiny bit of attention tax, and a stack of 40 skills you never use is worse than a stack of 8 you trust. Run a cull every 90 days. Browse /category/growth/ for replacements when something doesn't earn its slot.
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.