Claude skills for solo consultants: what they are, and the first three to build

Most solo consultants who use Claude run the same six or seven prompts over and over, and re-paste them from a Notes file every time. Discovery debrief. Meeting summary. Weekly client update. Scope draft. They open Claude, find the right prompt, paste it, customize three lines, run it. Then a week later they do it again. The prompts work; the workflow is paste-and-customize forever.

This is what Claude skills replace.

A skill is a small Markdown file that lives in ~/.claude/skills/ and tells Claude how to behave when a specific situation comes up. You describe the situation — "I just had a discovery call with a prospect" — and Claude auto-activates the right skill, loads its instructions, and produces the output. No paste, no customize, no hunt-the-Notes-file. Once you've built three of them, your workflow with Claude looks meaningfully different from the workflow most consultants are stuck with.

This article covers what a skill actually is, why it's better than a saved prompt for high-frequency consulting tasks, and the three skills I'd build first if I were starting from scratch.

What a Claude skill is (and what it isn't)

The simplest definition: a skill is a Markdown file with a frontmatter block describing when to activate, followed by the instructions Claude should follow when active. It lives in ~/.claude/skills/ (Claude Desktop, Claude Code) and is auto-loaded by Claude on every conversation. When a trigger phrase in the frontmatter matches what you've typed, the skill's instructions take over.

Not a prompt you paste in. Not a Custom GPT, although the concept is adjacent. Not a Claude Project (which is closer to a long-running conversation with shared context). A skill is closer to an installed plugin — Claude knows it exists, knows when to use it, and pulls it in automatically.

A minimal skill file looks like this:

---
name: discovery-debrief
description: Turns raw discovery-call notes into a structured one-page
  debrief. Triggers when the user mentions "just had a discovery call",
  "discovery notes", or describes a call they need to write up.
---

# Discovery Debrief

You are helping a solo consultant produce a structured debrief from
raw call notes. When the user pastes notes, return exactly six sections:

1. Who & what they do
2. The real problem
3. Budget signal
4. Decision process
5. Red flags
6. Recommended next step

Voice: sharp and direct, peer-to-peer. No corporate-speak. Don't
soften red flags.

That's a complete, working skill. Frontmatter tells Claude when to activate. The body tells Claude what to do. The whole thing is under 30 lines.

Skills can also be more elaborate — routing between multiple prompts depending on context, asking clarifying questions before running, enforcing specific output structures. The Proposal-Closer Pack ships a single skill that routes between eight different prompts in the same workflow (discovery → ICP check → scope → pricing → draft → objections → follow-up → debrief). Same file shape; more elaborate routing.

Why solo consultants benefit specifically

Most "AI productivity" advice is written for someone whose work is varied — a marketer doing 40 different things, a founder context-switching every hour. Solo consultants aren't that. The actual shape of consulting work, especially after the first 18 months, is a small number of high-frequency workflows, repeated with new clients. Discovery → proposal → kickoff → weekly update → wrap → case study. The variety lives inside each step (different clients, different situations) but the shape of each step repeats.

That's the workload skills were built for. Three reasons:

Repetition compounds. A skill you run 40 times a year — every discovery debrief, every weekly update — gets better the more you use it because you tune it once and the tune sticks. A saved prompt you paste in every time also gets better, but only if you remember to update the saved version. Most consultants don't. Their saved prompts drift; their skills don't.

Voice consistency. Skills bake your voice rules into the instructions. "Don't soften red flags." "Don't pad." Every output produced by the skill carries the same voice, which means your client-facing artifacts (briefs, status updates, debriefs) start to read like they came from the same person. They did — Claude is just the production engine.

Hands-off triggering. The biggest skill win is the auto-activation. When you've just wrapped a call and your context is fresh, you don't want to hunt for the right prompt. You want to type one sentence — "just had a discovery call with someone at a healthcare SaaS" — and have the skill load itself. That's the difference between using Claude as a tool and Claude operating as part of your workflow.

The first three to build

If I had to start over from scratch with no skills installed and no prompts saved, these are the three I'd build first, in this order.

Skill #1: Discovery debrief

The highest-frequency post-call task for any consultant doing inbound work. You have a 30-minute discovery call on Tuesday; you need a structured read by Wednesday so you can decide whether to write a proposal. Without a skill, you stare at messy notes Thursday morning and try to reconstruct the call from memory.

The trigger phrases should include: "just had a discovery call", "discovery notes", "just got off a call with a prospect". The output structure should be six sections — who/what, real problem, budget signal, decision process, red flags, next step. The voice rules should explicitly forbid softening red flags, which is the failure mode most discovery debriefs share when generated by AI.

If you'd rather not build it from scratch, we ship this one as a free standalone download — the Markdown file, the Claude skill in skill/discovery-debrief/SKILL.md, and an Acme Widgets worked example. Drop it in ~/.claude/skills/ and it auto-activates the next time you wrap a call. Treat it as the reference implementation; modify the voice rules to your own voice if it sounds too much like ours.

Skill #2: Meeting debrief (not the same as discovery)

The discovery debrief is about whether to take a deal. The meeting debrief is what you do during an engagement — after a Tuesday check-in, a stakeholder interview, an internal strategy session. The shape is different: less "is this worth proposing for" and more "what was decided, what's owed by whom, what's at risk."

Trigger phrases: "just finished a client call", "meeting transcript to actions", "need a debrief from this". Output structure: decisions made, action items with owners, open questions, risks raised. The voice rules should forbid the model from inventing action items that weren't in the transcript — the failure mode here is fabrication, not softening.

This skill pays back the most when you have it triggered straight from a transcript. Paste a 30-minute meeting transcript; get back a 1-page artifact you can email to the client an hour later. That email is also the thing that makes you look organized in the engagement; clients notice when the follow-up arrives same-day with structure.

The article "The client-meeting workflow that turns transcripts into next actions" walks the prompt structure if you want a starting point.

Skill #3: Weekly client update

The Friday 5 p.m. status email is the most slipped-on weekly artifact in solo consulting. You're tired, the week is closing, you write a status update from memory and ship it with three typos. A skill turns this into a 2-minute task.

Trigger phrases: "weekly update for [client]", "Friday status email". The output structure should be five sections — what shipped this week, what's in progress, what's blocked, what's coming next week, one open question for the client. The voice rules should force the skill to flag anything that's drifting (a deliverable that's been "in progress" for three weeks running), not just list it.

Inputs you feed it: your week's notes, your task tracker, your gut read on what's slipping. Output: a five-section email the client opens once on Friday and refers back to once on Monday. The operational procedure for this — the trigger, the structure, the paired Claude prompt, the pitfalls — is SOP 02 in The Solo Operator's SOP Bundle. The skill is how you produce the artifact; the SOP is the running procedure that fires the skill at the right cadence.

How to install (Claude Desktop and Claude Code)

A skill is a single .md file dropped into the skills directory. The exact path depends on which Claude surface you use:

• Claude Desktop: ~/.claude/skills/<skill-name>/SKILL.md — one folder per skill, the file always named SKILL.md
• Claude Code: same convention; Claude Code reads from the same directory

Once the file is in place, the next conversation Claude starts (or the next /skills reload) will register it. From that point on, Claude auto-activates the skill any time a trigger phrase from the frontmatter description matches your input. You don't need to invoke it manually.

You can verify a skill is loaded by typing /skills in Claude Code or by asking Claude directly: "what skills do you have loaded right now?" Both should list it.

If you build skills you want to share across machines, version them in a git repo and symlink the directory. A consultant operating from a laptop and a desktop should have the same skills available on both — otherwise the skill set drift becomes its own problem.

Pitfalls (the ones that bite)

Writing skills that are too generic. A skill that says "help the user draft a client email" loads on every email-related conversation and over-broadens what Claude does. Specific triggers + specific output structures beat broad ones every time. "Weekly Friday status email, 5-section format" loads only when relevant and produces a consistent artifact.

Over-engineering the first version. A skill doesn't need to handle every edge case. Build the 80% case, run it for two weeks, and tune the version-two based on actual failures. The temptation is to spec every possible scenario upfront; the result is a skill so detailed it never gets shipped.

Forgetting that the skill's voice is your client-facing voice. A skill that produces overly-formal output ships overly-formal artifacts to your client. If your real-life voice is sharper than the default Claude voice, encode that in the skill. "Use em-dashes. Don't open with 'I hope this finds you well.' Don't moralize."

Skipping the trigger phrases. Some consultants build skill files without any trigger language in the description and then wonder why Claude doesn't auto-activate them. The trigger phrases are the most important part of the frontmatter — they're what makes the skill self-loading instead of a saved prompt you still have to remember.

Building only one. A single skill is a curiosity. Three skills is a workflow. Once you have a discovery debrief, a meeting debrief, and a weekly update skill all installed, the way you use Claude during a week changes shape — most of your repeated work runs through skills, and the conversations you have with Claude become about the work that isn't repeatable.

Where to go deeper

The skill format itself is covered in Appendix B of The Solo Consultant's AI Playbook — the format, the frontmatter conventions, the difference between skills and Claude Projects, and recommendations for when to reach for which. The Playbook's framing is the broader operating model; this article is the tactical drill-down on one part of it.

If you want a worked example of a skill that routes between multiple prompts in the same workflow — closer to the elaborate end of the spectrum — the Proposal-Closer Prompt Pack ships a single skill (skill/proposal-closer/SKILL.md) that routes between eight prompts depending on which stage of a proposal cycle the consultant is in. Same file shape as the minimal skill above; more elaborate logic. It's the reference implementation for what a chained-workflow skill looks like.

The smallest version of all of this is one skill, installed today, on the workflow you run most often this week. Pick the one that maps to your calendar between now and Friday. Build it tonight. Use it on Tuesday's call.