The Claude Skills Worth Installing When You Are Shipping a SaaS

Planning and specs: what can a skill actually decide?

A planning skill is the highest leverage one to install first, because it changes what the agent does before it writes any code. What it encodes is your spec format: the sections you always want, the questions that must be answered before implementation starts, the requirement that a plan names the files it will touch, and the rule that unknowns are listed explicitly rather than guessed. The output is a document you review, not code you have to unpick afterwards.

It reliably removes the drudgery of restating context. Instead of typing out your architecture, your constraints and your definition of done every time, the skill carries them. It also catches a specific failure mode: agents tend to start editing immediately, and a planning skill forces a pause where the cheapest corrections happen. Rejecting a bad plan costs a minute, rejecting a bad implementation costs an afternoon.

What still needs you is every decision with a trade off attached. Whether to build the billing flow now or ship without it, whether a feature is worth the schema change, what the product should actually do for a confused user. An agent will produce a coherent plan for whichever direction you point it, and it has no stake in whether that direction is right. Scope and sequencing stay yours.

Frontend and implementation: where do skills earn their keep?

Implementation skills are mostly about consistency. Encode your component conventions, the styling approach, how state is handled, which primitives already exist so the agent stops inventing a fourth button component, accessibility requirements, and the file layout new code should follow. This is exactly the class of knowledge that is tedious to repeat and immediately visible when it is missing, which makes it a good fit for a skill.

They handle the mechanical work well: scaffolding a route with the same structure as the last twelve, wiring a form to an existing validation pattern, converting a design into markup that uses your tokens instead of arbitrary values, and refactoring a component to match a convention you changed last week. On a codebase with a clear structure, that is a large share of frontend work by volume, if not by difficulty.

What does not transfer is taste and interaction judgement. The agent will not notice that a flow requires three clicks where one would do, that an empty state is demoralising, or that a loading spinner appears in a place users read as a failure. It also will not tell you a feature is not worth building. Those judgements need someone who has watched a real person use the product.

This is also where the starting repo shows up most sharply. On a well organised project with a consistent stack, a frontend skill makes the agent fast. On a project with three styling systems and no conventions, the same skill produces confident output in whichever pattern it happened to read first. If you are choosing a foundation, /categories/NextJS is where the well trodden conventions are.

Testing, review and database work: what is safe to delegate?

Testing skills are among the most immediately valuable because writing tests is repetitive and generating them is genuinely mechanical. A skill can encode your test framework, naming conventions, how fixtures and factories work, what level of coverage you expect for a new endpoint, and the standing instruction to cover the error paths rather than only the happy one. Agents left unguided write happy path tests almost exclusively, so that instruction alone is worth the file.

Code review skills work differently. Rather than replacing review, they run a checklist pass that catches the boring category of problems: unhandled errors, missing validation on input, leaked secrets, N plus one queries, inconsistent naming, dead code left behind. Getting that pass done before a human opens the diff means the human spends their attention on design and correctness instead of typing "add a null check" for the hundredth time.

Database and migration work is where I would be most conservative. A skill can usefully encode your naming conventions, the requirement that migrations are reversible, the rule that you never drop a column in the same deploy that stops writing to it, and the expectation that indexes are considered for new query patterns. Generating the migration file is fine. Running it against production is not something to hand over, and every generated migration should be read line by line, because the failure mode is data loss rather than a red test.

Docs, deployment and marketing: the long tail

Documentation is the job skills fit best, because the work is high volume, low ambiguity and chronically deferred. A docs skill can keep your README structure consistent, generate API reference from the actual route handlers, write changelog entries from merged commits, and maintain the agent facing context file that tells future sessions how the project is organised. If you want a starting structure for that last one, /templates/agents-md is a working template rather than a description of one.

Deployment and ops skills should stay firmly on the read and prepare side of the line. Useful versions generate CI configuration, write deployment checklists, draft infrastructure as code, and diagnose a failing pipeline from its logs. Less useful, and considerably riskier, is anything that holds production credentials and executes changes. The asymmetry is simple: a wrong file is a revert, a wrong production command can be an outage with no undo.

Marketing assets are a real category and worth setting up once. Landing page copy, changelog posts, launch announcements, social copy, SEO metadata and screenshots all follow patterns you can encode, including your positioning and the words you refuse to use. What a skill cannot do is know which claims are true about your product, so every output needs a factual pass. Confident copy about a feature you have not shipped is the most expensive kind of mistake here.

Why does the starting codebase matter more than the skill list?

Skills do not fix a badly structured codebase. They are instructions layered on top of whatever the agent finds, and if what it finds is inconsistent, undocumented and full of implicit conventions that exist only in the head of whoever wrote it, no amount of written guidance compensates. The agent will read a sample of the code, infer conventions from it, and confidently apply whichever pattern it saw, which on a messy repo means adding a fourth way of doing something.

What actually determines agent productivity is boring structural stuff: predictable file layout, one obvious way to do each common thing, real type coverage so mistakes surface immediately, a fast test suite that gives feedback in seconds, and a context file that explains the architecture instead of making the model guess. Those properties compound with every skill you add, and their absence quietly cancels most of the benefit. /blog/ai-agent-ready-boilerplate-checklist covers what to look for concretely.

This is the practical reason the starting repo matters more than the skill list. A well structured project with two good skills outperforms a chaotic one with twenty, because every skill in the second case is arguing with the codebase. Boilerplates built with agent workflows in mind are collected under /categories/Agent-Ready, and if you want the reasoning behind a specific pick, /blog/best-boilerplate-for-claude-code goes through the criteria.

The order that works is: choose a foundation with clear conventions, add a planning skill, then add skills for whichever repetitive task is annoying you most that week. Adding skills to a repo the agent cannot navigate is optimising the wrong end of the problem, and it will feel like the tooling is failing when the codebase is.