If you are running an early-stage company alone or with one co-founder, your scarcest resource is not money or time — it is the cost of switching mental contexts. You move from debugging a SQL query to drafting an investor email to reading a SAFE to interviewing a candidate, sometimes inside a single hour. A good Claude Code skill is a way to spend half a sentence and a slash command instead of fifteen minutes of re-orientation.
This is a working shortlist of 12-15 skills that earn their place on a founder's machine. Each one compresses a real recurring task. I have left out anything that requires a team of three people to get value from, and I have flagged the skills that genuinely stop helping once you grow past 10 employees so you do not lean on them out of habit.
The standard advice when someone discovers Claude Code skills is to install everything that looks interesting. For a founder this is the wrong move. Claude loads every installed skill's metadata on session start, and your own attention loads every skill name every time you type a slash. A bloated ~/.claude/skills/ directory is not free — it is a cognitive tax that quietly raises the friction of every prompt.
The right framing is: how many distinct hats do I wear in a normal week, and what is the single highest-leverage skill per hat? In my own founder rhythm I count seven functional areas — writing, code, customer research, hiring, legal, finance, and the meta-area of self-management — and I aim for one or two skills per area. That is 12 skills, give or take, and it covers roughly 80% of the work where Claude can shave 20+ minutes off a task.
The reason 12 is roughly the right number, rather than 30, comes from how SKILL.md (the YAML-fronted markdown file that defines a skill, sitting at ~/.claude/skills/<name>/SKILL.md) actually works in practice. Each skill's description: field becomes part of Claude's mental shortlist for the session. When you have 50 skills, that list is long enough that Claude starts confusing similar ones, and you start forgetting which slash command is which. Twelve is roughly the upper bound at which you can hold all your skill names in working memory.
The picks below are organised by hat. Every skill listed is one I have either run in production or watched a founder I respect run in production. None of them require a team to be useful — that is the explicit selection bar. If a skill needs a project manager to coordinate inputs from three people before it does anything, it does not belong on this list.
One more framing note: founders should treat skills as disposable. Install one, use it for two weeks, and if you have not reached for the slash command unprompted in that period, delete it. The catalog is large enough that you will find a better replacement, and a 12-skill ceiling enforces this discipline naturally.
This is where most founders get the fastest return, because writing is both high-volume and high-stakes. You will write a landing page headline, an investor update, a hiring rejection email, and a customer apology in the same afternoon. The skills here are about consistency of voice, not flowery prose.
1. A brand-voice skill. The single most useful writing skill is one that captures your voice rather than a generic editor. Something in the family of brand-voice-enforcement or a custom-built voice guide. The pattern is: feed it three pieces of writing you are proud of, let it derive a style sheet (tone, sentence-length distribution, vocabulary preferences, dos and don'ts), and then route every external draft through it before sending. The reason this beats a generic copy-editor skill is that customer-facing writing in early stage is mostly about not sounding like a generic SaaS company — your voice is the differentiator.
2. A landing-page copy skill. Specifically one that knows the difference between a hero subhead and a feature bullet. Look for skills that ask for the problem, the specific buyer, and the state change before generating anything. Skills that just take "describe your product" and emit generic copy are not worth installing. The good ones cite Eugene Schwartz, April Dunford, or specific landing-page teardowns in their SKILL.md body — that is a tell for quality.
3. An investor-update skill. Not a generic email-drafter — one with a structure baked in. The convention I use is metrics, highlights, lowlights, asks, in that order. The skill should refuse to draft until you have given it the actual numbers; if it makes up plausible-sounding ARR figures because you left a placeholder, delete it.
One pattern across all three: founder writing skills should be opinionated about structure but agnostic about substance. They should push back when you give them a vague brief, and they should refuse to invent facts. Skills that produce smooth confident prose from nothing are dangerous — investors and customers can smell them, and the cost of being caught using one is high.
You are the engineering team. The right skills here are not the ones a senior engineer at a 200-person company would pick — those assume code review partners, a staging environment, and a CI/CD pipeline that someone else maintains. Founder code skills assume you are merging straight to main at 11pm.
4. A code-review skill that reviews your own diff. Specifically one that runs against git diff HEAD~1 or your staged changes and flags the obvious things — accidentally committed secrets, off-by-one errors, missing error handling, hardcoded values that should be environment variables. The bar for installing one of these is: does it catch the bug I just made, or does it produce generic "consider adding tests" feedback? Run it on a real recent commit before deciding.
5. A debugging skill with a structured reproduce-isolate-diagnose loop. The good ones force you through the steps in order: state what you expected, state what actually happens, write the minimal reproduction, then start hypothesising. Founders skip these steps and lose hours. A skill that makes you write the expected behaviour before you start tweaking code is worth installing for that reason alone.
6. A migration skill for whatever your specific stack rolls forward. Postgres major versions, React major versions, Node LTS jumps, a Stripe API version. You will do one of these every few months, and each one is high-stakes (data loss, broken payments). A skill that has the version-to-version changelog cached and walks you through breaking changes is more valuable than its slug suggests.
What to not install: anything that promises to "build your app from a description." These skills generate plausible-looking code that you then have to read, understand, and debug — which is more work than writing it yourself, because debugging unfamiliar code is harder than debugging your own. Save the AI-write-the-whole-thing pattern for spikes and prototypes you intend to throw away.
If you want a deeper dive on engineering picks specifically, the /learn/top-claude-code-skills-for-engineering/ page goes further. The selection here is the founder subset — skills that survive working solo with no review partner.
Founders under-invest here, partly because the tooling is genuinely weak. Until recently, customer research meant a Notion database of interview notes that nobody opened twice. Claude skills change the unit economics — synthesis that used to take a half-day now takes 20 minutes, which means you actually do it.
7. An interview-synthesis skill. Feed it the transcript or your raw notes from a customer call, and it should extract the customer's actual words for: their problem, the workaround they currently use, what they are willing to pay, and what would make them switch. The pattern to look for is quote extraction — the skill should pull verbatim phrases, not paraphrase. Paraphrasing loses the most valuable artifact, which is the customer's exact vocabulary for their pain.
8. A discovery-question skill. Specifically one that knows the Mom Test — does not ask leading questions, does not ask hypothetical-future questions, focuses on past behaviour. Useful before every customer call, both to prep the questions and to debrief afterwards. If a skill asks you to draft "would you use this if it existed?" style questions, it has read the wrong books and you should uninstall it.
9. A competitive-landscape skill that synthesises from public sources. Useful for the moment a candidate asks you about competitor X in an interview and you realise you have not looked at their site in six months. The good ones cite their sources and timestamp the synthesis so you know how stale it is. Skills that emit confident summaries without citing sources are doing a kind of weather-forecasting from intuition — useless for actual decisions.
The pattern across these three: the skill should respect the asymmetry between what your customer said and what you wish they had said. A customer-research skill that helps you confirm your hypothesis is worse than one that surfaces the inconvenient quote. Optimise for the latter.
Hiring is low-volume but extremely high-stakes for founders. One bad hire in your first ten people is a brand-defining mistake. The skills here are about consistency across candidates more than speed per candidate.
10. An interview-prep skill with role-specific question banks. Specifically one that takes a JD and outputs a question set across four buckets: technical competency, problem-solving, ownership/judgement, culture fit. The skill should refuse to generate culture-fit questions without first asking you what your culture actually is — generic ones ("are you a team player") are worse than useless because every candidate has been coached to answer them.
11. A reference-check skill. One that generates the actual questions to ask references — open-ended, specific, calibrated against the role. The good ones include the rejection-elicit pattern: "in what context would you not hire this person again?" If a skill in this category produces only positive-framing questions, it is doing a vibes-check, not a reference check. Uninstall.
Two skills, not three, because hiring volume for a founder is one or two roles a quarter at most. A draft-offer skill is occasionally useful but the offer letter is so standardised that a template in your password manager is faster than a slash command.
One skill that founders sometimes install but should not: an automated CV screener. The volume of incoming CVs is rarely high enough to justify the false-negative risk, and the legal-risk surface in some jurisdictions is non-trivial. Read every CV yourself for the first 50 hires. After that, hire a recruiter — do not deploy AI screening.
The broader category page at /category/general/ includes more people-ops adjacent skills if you want to browse, but be ruthless about admission — most of them assume an HR partner exists.
This is the area where Claude skills both add the most leverage and carry the most risk. A skill that explains a SAFE clause is genuinely useful. A skill that drafts a SAFE is genuinely dangerous if you treat its output as a finished document. The right posture is to use these skills for comprehension and first drafts, never for signature.
12. A plain-English contract-translator skill. One that takes a clause from a SAFE, term sheet, employment contract, or supplier agreement and explains what it actually does, what the standard market range is, and what to push back on. The good ones in this category cite the specific National Venture Capital Association or Y Combinator templates as the reference for "standard" terms. Skills that explain confidently without anchoring to a reference doc are guessing.
13. A cap-table modelling skill. Specifically one that takes your current cap table, a proposed round (amount, valuation, type), and outputs the resulting ownership percentages for each existing holder under different scenarios (pre-money vs post-money, with and without option pool expansion). This is the calculation founders most often get wrong by hand, and the consequence — diluting yourself by 5 extra percentage points — is one of the more expensive mistakes you can make in a single afternoon.
14. A vendor-review skill for the procurement decisions you will make as you grow. Stripe vs Paddle, AWS vs Hetzner, Notion vs Linear. The skill should force you to articulate evaluation criteria before looking at vendors, then score each vendor against those criteria. The reason this is high-leverage is that founders default to picking the vendor that gets the most search-engine love, which is a different signal from "the right fit for my company."
Crucial caveat across all three: every output from a legal or finance skill should be reviewed by a human with a licence before it informs a decision worth more than a few thousand dollars. The skills are there to make you a better-prepared client, not to replace the lawyer or accountant.
The skills above are individual moves. The real value comes when you chain two or three of them into a workflow that handles a recurring high-friction task end-to-end. Four examples from my own week:
Investor update draft (45 minutes, was 3 hours). Pull metrics from your dashboard. Run the investor-update skill against last month's draft so it matches the format. Run the brand-voice skill on the result. Read it once with fresh eyes the next morning. The reason this works is that the investor-update skill handles structure, the voice skill handles tone, and your second-day read catches anything that drifted. None of the three steps in isolation is enough — chained, they replace what used to be a half-day task.
Customer interview synthesis (20 minutes, was 2 hours). Record the call. Get a transcript. Run the interview-synthesis skill to pull quotes against the four buckets (problem, workaround, willingness-to-pay, switching cost). Append the quotes to a running document organised by theme. Once a quarter, run the discovery-question skill against the accumulated themes to refresh your interview script. The compounding effect — your interview questions get sharper because they are informed by what previous customers actually said — is the real win, not the per-call time saved.
First marketing landing copy (90 minutes, was 1-2 days). Take the three sharpest customer quotes from the synthesis above. Feed them to the landing-page-copy skill as the problem statement. Run the result through the brand-voice skill. Have a friend who is not technical read it cold and tell you what they think the product does. If their answer is wrong, the copy is wrong — go back to the landing-page-copy skill and rework. Iterate twice. Ship.
Term-sheet plain-English translation (30 minutes, was nervous-Googling for hours). Paste each clause into the contract-translator skill one at a time. Make a two-column table: clause text on the left, plain-English explanation plus market-range note on the right. Send to your lawyer with the questions you actually have, rather than asking them to walk you through the whole document. You will save legal fees and have a better conversation.
A subset of the picks above genuinely stop adding value once you cross certain thresholds — usually team size or volume. Knowing which ones lets you avoid leaning on them past their useful life.
The brand-voice skill stops scaling at about 8-10 employees. Up to that point, your voice is the company voice. Past that, you need a documented brand style guide that the whole team can reference, and a single skill that derives style from your writing samples becomes an active liability — it perpetuates the founder's voice instead of evolving toward a team voice. Replace it with a guide-from-document skill that reads from your written brand bible.
The interview-synthesis skill stops scaling at about 100 customer interviews. Past that volume you need a real research-ops setup with proper tagging, theme tracking across time, and the ability to query "how did this theme evolve from Q1 to Q3." A single-call synthesis skill cannot do that. It is still useful per-call, but the strategic value comes from systematic synthesis across calls, which is a different tool.
The code-review-your-own-diff skill stops scaling the day you hire your second engineer. At that point you have a real code review partner, and the skill becomes a crutch that lets you skip the partner step. Skip the partner step three times and you have a culture problem.
The cap-table modelling skill stops scaling at about a Series B. Past that round the cap table has enough preferred stock with different conversion mechanics, participating preferences, and tranched investments that a general-purpose skill cannot keep up. Buy Carta, use the spreadsheet your fund modelling lead builds, or hire a CFO.
The general principle: a skill is well-fit when it matches the complexity of your situation. When the situation outgrows the skill, deleting it and replacing it with something role-appropriate is the right move. Holding on to a founder-stage skill at a 30-person company is how founders end up doing 30-person-company work in a founder-stage way. Re-audit your installed skills every six months against this list — see /best/ for what is currently working at each scale.
Eventually you will hit a recurring task that no skill in the catalog covers cleanly. This is the right moment to write your own SKILL.md. The threshold is roughly: have I done this task at least four times in the past month, and is the prompt I keep writing roughly the same each time?
If the answer is yes, the cost of writing the skill — about 20-40 minutes for a first version — is usually paid back inside two weeks. Founder examples of when this kicks in: a weekly metrics dashboard format that pulls from a specific Notion page, a candidate-debrief template that matches your hiring loop's stages, a customer-onboarding email sequence that references the specific features they unlocked.
The mechanics are simpler than they look. A SKILL.md is a markdown file with YAML frontmatter at the top — name, description, and optionally allowed-tools, user-invokable, and a few others. The body is just the instructions you would have typed to Claude anyway, written once, in the structure you want them used. Place the file at ~/.claude/skills/your-skill-name/SKILL.md and Claude will pick it up on the next session.
A founder-specific operating rhythm I recommend: every Friday afternoon, spend 30 minutes reviewing the past week's longest Claude conversations. If you see the same prompt structure three or four times, that is a skill waiting to be written. Spend the remaining time of the slot writing one. Over a year this gives you 40-50 personal skills tuned to your exact workflow — and you can prune the ones that stopped earning their place at the same review.
The full mechanics — frontmatter fields, what to put in the body, anti-patterns to avoid — are covered at /learn/writing-a-skill-md-file/. Read it once before writing your first one. The structure pays back the upfront investment immediately because skills you write following the conventions feel like every other skill in your library, which lowers the cognitive switching cost we started this article worrying about.
One last note on founder-written skills: keep them under version control. The skills you write capture how you actually run your company, and losing them when your laptop dies would be expensive. A private GitHub repo synced to ~/.claude/skills/ is the lowest-effort solution. Treat your skills directory like your ~/.dotfiles — opinionated, personal, and worth protecting.
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.