Claude Code Skills for Solo Developers: Picks That Actually Help You Ship

Published 1 June 2026 · 14 min read · By a long-time Claude Code practitioner

The real problem with solo dev

Solo dev is mostly a discipline problem dressed up as a technical one. Almost every indie hacker I know who stalled out told the same story afterward: it wasn't the database choice, the framework, or the hosting bill. It was three months of half-finished branches, a roadmap that quietly tripled in scope, and a Sunday night where the inbox had two angry customers and one billing question and no help on the way.

The technical skills you have are usually enough. What's missing is the structure a team provides without anyone naming it — the PM who asks is this in scope?, the senior who pushes back on the over-engineered abstraction, the support lead who triages tickets before they reach you. When you're alone, those roles are still there. They're just all you.

This is where a well-chosen set of Claude Code skills earns its keep. A skill is just a SKILL.md file (a markdown file with YAML frontmatter and a body of instructions, dropped into ~/.claude/skills/) that tells Claude how to behave when the situation matches. The good ones encode discipline. They make Claude push back on scope creep, force you through a checklist before a deploy, generate the boring artifact you'd skip if left alone — the changelog entry, the postmortem stub, the client email.

I want to be honest about a thing: a skill is not a substitute for taste. The skills below help you do the right thing faster, but they assume you already know roughly what the right thing is. If you install fifty skills hoping one of them will replace the work of thinking, you'll end up with a sluggish Claude context and the same backlog.

The picks here are deliberately small — thirteen, not fifty. I've used or extensively reviewed every one. The frame is: install only what matches a problem you actually have this week, uninstall the rest, and don't be precious about it. Skills are markdown files. You can put them back any time.

Picks for scoping and kickoff

The first place solo developers leak time is the gap between I want to build X and the first commit. Without a teammate to challenge the spec, you can spend a week researching libraries for a feature that turns out to be cosmetic. These three skills push back.

1. scope-cutter — argues you out of features

This skill kicks in when you describe a new feature or product idea. Claude becomes a slightly skeptical product manager who walks you through: what's the smallest version that proves the bet, what assumptions does it rely on, what would you cut if you only had one weekend, and what's the cheapest experiment that would tell you the assumption is wrong. The output is usually a one-page scope you can stick in a tracker. It's not magic — it just makes you do the conversation you keep avoiding.

2. mvp-spec — turns an idea into an explicit plan

Different beast from scope-cutter: this one assumes you've already decided to build something, and helps you write the spec. It produces a short structured document — user story, core flow, data model sketch, what's explicitly out of scope, success criteria. Most useful for side projects where you'll be away from the work for days at a time and need to remember what past-you was actually trying to build.

3. tracker-setup — generates a starter issue list

Once you have a scope, this skill turns it into a tracker-ready issue list. It can output Linear, GitHub Issues, or plain markdown checklist format. It's opinionated about issue size: each issue should be roughly half a day of work, with explicit acceptance criteria. The output is something like:

- [ ] Set up Postgres + basic users table
  acceptance: ./script/test-db succeeds locally
- [ ] Auth: email + password sign-up flow
  acceptance: can sign up, log in, log out via UI
- [ ] Auth: rate-limit sign-up endpoint
  acceptance: 5 sign-ups/min from same IP returns 429

For a one-person team, having explicit acceptance criteria is the single biggest reason work actually gets finished instead of dragging.

If you only install one from this group, install scope-cutter. The other two help, but the leak you're plugging is not having a teammate who'll tell you when an idea is too big.

Picks for focus and finishing

Picking the work is half the battle. The other half is staying on it. Solo developers don't have anyone standing up at 10am asking what they did yesterday, and that absence is more expensive than people admit.

4. standup-for-one — a daily check-in with yourself

This skill prompts you each morning (or whenever you run it) with three questions: what did you finish yesterday, what's the single most important thing today, what's blocked or scaring you. It writes the answers to a dated file in your project. The value isn't the log — it's the daily friction of having to admit I didn't finish what I said I would. Most solo devs who try this last about two weeks before facing a hard conversation with themselves about what's actually happening.

5. finish-the-branch — closes the open ones

Run this skill in a repo and it'll list all your local branches that have unmerged work, sorted by age. For each, it asks: is this still alive, what's the smallest thing to do to close it (merge, abandon, or salvage one chunk into a new branch). The pattern is shockingly common: solo devs accumulate 6-10 dead branches, each carrying a small amount of guilt, and that guilt taxes every new branch they start. Triaging branches is the kind of janitorial task you'd never schedule but always benefit from.

6. focus-block — keeps Claude on one task

This skill changes how Claude responds during a focused session. When you start a block, you tell it what you're working on. For the duration, Claude refuses to scope-creep — if you ask it about something off-topic, it'll note the question for later and bring you back. Useful for people whose own attention is the bug, not the codebase. It's a small skill (under a hundred lines) but the constraint is the point.

The honest version of focus tooling: none of these replace the underlying discipline. They make the discipline cheaper. If you genuinely cannot finish anything for weeks at a time, a skill won't fix that — talk to someone, take a real break, or accept the project is dead. But if you're 70% there and the last 30% is a wall of small finishing tasks, these help you grind through.

Picks for shipping discipline

Shipping is the moment a team usually catches your mistakes for you. Solo, the cost of skipping a pre-deploy check is borne entirely by you (and your customers) at 11pm on a Saturday. These four skills bolt the missing checks back on.

7. pre-deploy-checklist — the thing you keep forgetting

Runs a configurable checklist before any deploy: tests passing on the commit you're shipping, no console.log or TODO: remove in the diff, migrations idempotent or guarded, feature flags configured, rollback path identified, monitoring confirms previous deploy is healthy. Most of these are caught by CI in a healthy team. Solo, you wrote the CI, and you skipped the parts you found annoying. This skill puts them back in front of you.

8. changelog-from-diff — writes the entry you skip

Run this against a range of commits or a PR diff. It generates a user-facing changelog entry: what changed, who's affected, anything they need to do. The output is a single paragraph plus optional bullet list. For solo products with even a small user base, this is the difference between customers feeling looked after and customers wondering if you're still alive.

9. migration-safety-check — keeps you from corrupting your one prod database

Reads a migration file and walks through: is this online-safe (no table rewrites), are added columns nullable or defaulted, are removed columns dropped after a release that stops writing to them, does the rollback work, is the data backfill bounded. Solo devs ship migrations by hand, against a database with no replica, and the cost of getting one wrong is enormous. This skill is paranoid in a way that pays for itself the first time it catches a non-additive change.

10. release-notes-draft — writes the announcement

Similar to changelog-from-diff but pitched at marketing rather than ops. Takes a list of shipped features and produces a draft announcement suitable for email, Twitter, or a blog post. It's deliberately rough — you'll edit it. But the activation energy of starting a release-notes post from scratch kills most solo announcements, and a skill that hands you a working draft removes that excuse.

If you ship to real customers, install pre-deploy-checklist and migration-safety-check today. The other two are optional unless you're trying to grow.

Picks for solo on-call

You are on-call. There is no rotation. If the site goes down at 3am, your phone is the one that rings. This is the most underdiscussed problem in indie development and the place where good tooling has the highest leverage.

11. incident-response-solo — the runbook for one person

When triggered (you'd typically invoke it manually when something's on fire), this skill walks you through a structured incident response: first, is the user impact contained or growing; second, what's the cheapest revert; third, what do you tell customers right now (one-sentence status, no speculation); fourth, what's the actual diagnosis. The order matters because solo devs have a strong instinct to diagnose first and communicate last, which is exactly backward when there's no one else to handle the communication.

The skill body includes a status-update template you fill in, which forces you to acknowledge customers within the first ten minutes whether or not you have a fix. Companies have entire teams for this; solo, the skill is the team.

12. postmortem-stub — writes the after-action

Run after the incident is resolved. It generates a structured postmortem with timeline, root cause section, impact, what worked, what didn't, action items. You fill in the blanks. The discipline solo devs skip most often is the postmortem — the incident is over, you're exhausted, you want to move on. But postmortems are where you actually learn, and a stub that's 60% pre-written is the difference between writing one and not.

A note on solo on-call generally: you cannot fully cover for a team with skills. What you can do is make sure the moments when you are available are spent well, and make sure the moments you're not don't make things worse. Set up status pages, configure alerting that doesn't fire for everything, and accept that some incidents will happen while you're at dinner. The skills here help you respond well when you can, not respond at all times.

Picks for client communication

Freelancers and consultants have a different breed of problem. The work is usually clear; the relationship management is what burns hours. These two skills address the largest hidden cost.

13. client-status-update — generates the weekly email from your git log

You point this skill at a repo and a date range. It reads the git log, the closed issues, any deploy logs you've pointed it at, and drafts a client-facing status update: what shipped this week, what's in flight, what's blocked, what decisions are needed from the client. The tone is plain professional, no engineering jargon. You edit and send.

The reason this saves so much time is not the writing — it's the activation energy. Writing a status update from a blank page on Friday afternoon when you're tired is a 45-minute task. Reviewing a generated draft is ten. Over a year with a handful of clients, that's days of your life back.

A bonus pattern: many freelancers don't send status updates because they don't feel they have enough to report. A skill-generated draft that surfaces everything you actually did — including the small refactor and the bug investigation — usually reveals you did more than you thought. The client also feels looked after, which directly affects renewal.

Bonus: technical-translator — explains a change to a non-technical client

You paste a technical decision (e.g. we're switching from REST to GraphQL for the dashboard) and the skill generates a plain-English explanation: what's changing, why it matters to them (or why it doesn't), what it'll cost in time or money, what risks it carries. This is the conversation that goes badly when you wing it — clients hear I'm rewriting your thing and panic. A structured explanation that leads with impact rather than implementation usually lands fine.

If you're a freelancer who finds Friday afternoon emails the most draining part of the week, client-status-update is the highest-ROI skill on this entire list.

Three full workflows

Skills are most useful in combination. Here are three end-to-end workflows that string several of the picks together.

Project kickoff → MVP scope → tracker setup

You have an idea on Sunday night. You want to start coding Monday morning without spending the week researching.

# step 1: argue with yourself about scope
claude /scope-cutter
# describe the idea, let claude push back, decide what's in v1

# step 2: turn it into a spec
claude /mvp-spec
# claude produces docs/v1-spec.md with user story, data model, success criteria

# step 3: generate tracker issues
claude /tracker-setup --input docs/v1-spec.md --format github
# review the issue list, edit anything that's too big, gh issue create them

Done correctly this takes about 90 minutes and ends with a tracker full of half-day issues and a written scope you can refer to when feature creep tempts you in week three.

Client status update from terminal history

Friday afternoon, you owe three clients an update each. You're tired and the work this week was scattered.

# for each client repo:
git log --since='last friday' --author=you --pretty=format:'%h %s' > /tmp/work.log
gh issue list --state closed --search 'closed:>2026-05-25' >> /tmp/work.log
claude /client-status-update --input /tmp/work.log --client-name acme
# review draft, paste into email, send

Three updates in twenty minutes instead of two hours. The clients get a level of communication discipline that they assume comes from a larger operation.

Alone on-call — incident response for one person

Site is down. Your phone is the one that's ringing. Open Claude and run:

claude /incident-response-solo

It walks you through, in this order: confirm the impact (don't assume), find the fastest revert (usually the last deploy), write a customer-facing status sentence (post it within ten minutes), then diagnose. After the dust settles, even if it's the same night:

claude /postmortem-stub --incident-date 2026-05-30
# fills in the structure, you write the actual cause + action items

Doing the postmortem same-week is the highest-ROI hour you'll spend that month. A skill that pre-fills the structure is the difference between doing it and putting it off until you've forgotten the details.

Picks that fight burnout and scope creep

It's worth calling out which of the picks above explicitly target the failure modes that kill solo projects: burnout, over-engineering, and scope creep.

Against scope creep: scope-cutter and focus-block are the headline picks. scope-cutter attacks scope at the planning stage. focus-block attacks it during execution — when you're three layers deep in a feature and notice an unrelated bug, the skill notes the bug and steers you back. A teammate would do this. Alone, you need the constraint encoded.

Against over-engineering: there's a class of skills that push back on architectural ambition for small projects. mvp-spec does this implicitly by forcing you to write down the simplest version. A more explicit skill is the kind that, when you start adding abstraction layers or generalised interfaces, asks who's the second caller? — over-engineering usually starts when you build a generic system for one user. If you find yourself reaching for inheritance hierarchies in a side project, a skill that asks that question is genuinely useful.

Against burnout: this one's harder. Skills can't fix burnout, and anyone who tells you otherwise is selling something. But two of the picks indirectly help. finish-the-branch reduces the background guilt of half-done work — most burnout in indie dev has a partial-completion component, and clearing it lifts a real weight. client-status-update reduces the dread of Friday afternoons for freelancers, which is one of the most cited causes of burning out on client work. Neither solves burnout. Both remove specific contributors.

A pattern worth naming: every one of these skills is a constraint, not a capability. They don't make Claude more powerful. They make Claude (and by extension you) more disciplined. The reason this works for solo devs specifically is that discipline is exactly what's missing — you have the raw capability already, you just don't have the structure a team provides.

If you find yourself dismissing a skill because I can do that myself, that's usually the tell that you should install it. Of course you can do it yourself. The question is whether you do.

When to write your own

The catalog has thousands of skills. You should still write your own for a specific class of problem: the patterns that are unique to you and your project, which by definition no one else will publish.

Solo devs accumulate small idiosyncratic procedures: the way your deploy works, the way your client likes status updates phrased, the specific runbook for the one thing in your stack that keeps breaking. These are perfect skills. They're short, they're stable, they encode the kind of knowledge that lives in your head and would disappear if you got hit by a bus.

A good rule of thumb: any time you've done the same multi-step thing three times in three weeks, write a skill. The third time is the trigger because it proves the pattern is real, not a one-off. The skill is rarely longer than 100 lines. Frontmatter looks like:

---
name: deploy-acme-staging
description: |
  Use when shipping the Acme dashboard to staging. Handles the specific
  sequence of asset upload, cache bust, and smoke test that the Acme
  infrastructure requires. Not generic — Acme-specific.
allowed-tools:
  - bash
  - read
---

The body is the steps you'd otherwise have to remember, written as if explaining to a new collaborator who doesn't exist. The act of writing it down is half the value — you'll discover assumptions you'd been holding implicitly. The other half is that future-you, six months from now, will be the new collaborator.

Skills you should not write yourself: generic patterns that aren't specific to your work. If the catalog has a decent version of what you need, use it and customise via a thin wrapper if necessary. Time spent rewriting a generic skill is time not spent shipping. The case for writing your own is uniqueness, not perfectionism.

For the mechanics of writing a skill — frontmatter rules, anti-trigger discipline (telling Claude when not to use the skill), and the common failure modes — start with the guide on writing SKILL.md files. The structure is forgiving but the difference between a skill that fires when expected and one that ignores you is mostly in how clearly the description is written. Spend the time on that.

Last note: don't be precious about your skills. If one stops being useful, delete it. They're markdown files in a directory. The whole point of the format is that the cost of trying a skill, keeping it, or throwing it out is essentially zero. A solo developer's skill library should turn over constantly, because your problems do.

Found a bug or want a topic covered? Email [email protected] or open an issue via GitHub.