Claude Code for Solo Founders: Skills, Hooks, Commands

You have no team to delegate to and no reviewer to catch the mistake before it ships. The only leverage you have is making the AI you already code with more consistent. Most founders run Claude Code like a smarter autocomplete and never touch the parts that compound: Skills, Hooks, and Slash Commands. This guide turns ad hoc prompting into a repeatable setup using those three built-in features, configured once and reused on every session.

Why solo founders should standardize their Claude Code setup

Every session, you re-explain the same conventions. Your API error format, your test command, the files Claude should never touch. That repetition costs real hours, and it still produces inconsistent output, because nothing remembers last week's correction.

The 2025 DORA report found that 90% of technology professionals now use AI at work and more than 80% say it has made them more productive. Its central finding is a warning, though: AI amplifies whatever process you already have. A team with strong habits gets faster. A solo founder with no process gets amplified chaos.

Developers now spend a median of about two hours a day working with AI tools, so the setup around that time is worth getting right. The payoff shows up in the numbers. DX's Q4 2025 impact report tracked daily AI users reaching their tenth merged pull request in 49 days instead of 91. Standardizing your setup is an afternoon of work against months of compounding speed.

Three features do the standardizing. Skills define what Claude knows. Hooks define what always happens. Slash Commands define what you trigger on demand. Together they turn repeated instructions into infrastructure.

What is the difference between Claude Code Skills and Slash Commands?

The two used to be separate systems, which is why the difference still trips people up. As of Claude Code v2.1.3, released in January 2026, custom slash commands were merged into Skills. Both now live as SKILL.md files, and the recommended path for anything new is .claude/skills/name/SKILL.md.

The practical distinction is how they fire. A Skill is auto-discovered: Claude reads its description and reaches for it on its own when a task matches. A Slash Command is user-invoked: you type a slash and its name to run it. After the merge, a single SKILL.md can do both, so the real question is invocation mode, not file type.

Your existing setup does not break. Files in .claude/commands/ still work as legacy, and if a command and a skill share a name, the skill takes precedence.

Concretely: a write-changelog skill is something Claude can pull in automatically when you describe a release, while a /deploy-check command is something you run by hand right before you ship.

When to reach for a Skill vs a Command

• Use a Skill for knowledge and standards Claude should weigh on its own, like your API conventions or naming rules.
• Use a Command for repeatable, on-demand tasks with a clear trigger, like a PR review or a release check you run at a specific moment.
• Rule of thumb: if you keep typing the same instruction, make it one or the other. If you only type it at one point in your flow, make it a command.

Building your first Skill and Slash Command

Creating one takes a file and about two minutes. Make a folder at .claude/skills/review/ and add a SKILL.md inside it with YAML frontmatter and a plain-language prompt body:

---
name: review-pr
description: Review a pull request diff and return issues by severity
---
Review the diff for PR #$ARGUMENTS. Return findings in three groups:
Critical, Important, and Minor. Flag security issues first.

Placement decides scope. Put the folder in your project's .claude/skills/ and commit it to git, and the skill travels with the repo. Put it in ~/.claude/skills/ instead, and you get it in every project on your machine. Project-level for shared standards, global for personal tools.

Invoke it by typing /review-pr 142. The $ARGUMENTS placeholder catches whatever follows, so 142 becomes the PR number the prompt fetches and reviews. You get back a structured Critical, Important, Minor list instead of a wall of prose.

Three starter skills worth building first

• A code review skill that plays the reviewer you don't have, run before every merge.
• A changelog or release-notes skill tied to your shipping rhythm, so notes get written while the context is still fresh.
• A codebase-explainer skill for the Monday you reopen code you wrote six weeks ago and no longer remember.

Using Hooks to enforce quality you would otherwise forget

You meant to run the tests. You were three commits deep, it was late, and you forgot. A hook is the fix, because it runs whether you remember or not.

Hooks are shell commands or prompts that fire automatically at lifecycle events. The harness runs them, not the model, so they cannot be skipped or talked out of. That matters given the trust gap. The DORA report found that about 30% of developers have little to no trust in AI-generated code, and research Snyk cites (a Georgetown University study) put close to half, 48%, of AI-generated code as containing security issues. Hooks are how you check that work without having to remember to.

Events fall into three cadences. Once per session: SessionStart and SessionEnd. Once per turn: UserPromptSubmit and Stop. On every tool call: PreToolUse and PostToolUse. PreToolUse is the one that runs before a tool executes and can deny it outright, which makes it the place to block edits to protected files or stop a dangerous command. The others react after the action.

For a solo founder that means: auto-format on PostToolUse so style is never a manual step, run your tests before a Stop is allowed so a turn can't finish red, and block writes to production config with a PreToolUse guard.

A copyable starter hook setup

Hooks live in .claude/settings.json:

1{
2  "hooks": {
3    "PostToolUse": [
4      {
5        "matcher": "Write|Edit|MultiEdit",
6        "hooks": [
7          { "type": "command", "command": "npx prettier --write \"$CLAUDE_TOOL_INPUT_FILE_PATH\"" }
8        ]
9      }
10    ],
11    "PreToolUse": [
12      {
13        "matcher": "Bash",
14        "hooks": [
15          { "type": "command", "command": "./scripts/block-destructive.sh" }
16        ]
17      }
18    ]
19  }
20}

• The PostToolUse matcher on Write or Edit runs your formatter (add your linter the same way) after every file change.
• The PreToolUse matcher on Bash points to a script that exits with code 2 when it spots a destructive command, which blocks it before it runs.
• Because settings.json lives in .claude/, you can commit it to git, and your guardrails travel to any future collaborator.

The three features as one productivity stack

Each feature is useful alone. Together they close the loop. A Skill encodes your standards, a Command triggers a workflow on demand, and a Hook guarantees the guardrails fire every single time.

Ship a feature and watch them compose. Your API-conventions skill shapes the code as Claude writes it. You run /review-pr to get a severity-sorted review. Then a Stop hook gates the commit on passing tests, so nothing lands red. Standards, trigger, guarantee, in one pass.

This is where the time actually comes back. DORA calls it the verification tax: the time you save writing code gets re-spent auditing it. For a solo founder doing both jobs, that tax lands entirely on you. A hook that runs tests and a skill that reviews diffs move the audit off your plate and into the setup.

Don't rebuild everything at once. Add one hook and one skill this week. An auto-format hook and a review skill cover the most common gaps, and you grow the stack from there.

Your leverage as a solo founder isn't more hours, it's consistency you don't have to recreate each morning. Claude Code Skills, Hooks, and Slash Commands turn the instructions you keep repeating into infrastructure that holds while you build. Configure one skill and one hook this afternoon, ship with them for a week, then add the next piece when the next repetition shows up.

The agent you code with is now configured. The next layer is the product you're building, and whether the agents your customers point at it can actually read it. That's the natural next step once your own setup is solid: read the MCP and agent-readiness guide on exposing your SaaS to agents.