👇 After this module

Your repetitive work is automated. Custom skills, content engine, optional Postiz scheduling. The things you do every week, your system handles them now.

Custom skills and commands

The third time you find yourself explaining the same process to Claude, you have crossed the line into skill territory. The first time, you were figuring something out. The second time, you were checking your work. The third time, you are paying a tax on your own attention that you do not need to pay.

A skill is a short markdown file. A name, a one-line description of when to use it, and the instructions Claude follows when you call it. That is all a skill is. The rest is what you put in the instructions.

The shape of a skill

Skills live in two places. Personal skills, the ones you use across every project, sit in ~/.claude/skills/. Project skills, the ones tied to a specific repo (like your morning protocol or your CRM logger), sit in .claude/commands/ inside the project. Both are markdown files with a small frontmatter block at the top.

The frontmatter has three fields that matter. Name, the trigger word you type after a slash. Description, the one-line summary Claude reads to decide if your message matches this skill. Body, the actual instructions, in plain English, that Claude follows when the skill fires. Description quality is the difference between a skill that triggers when you want it to and one that sits there unused.

When to make one

Use the rule of three. The third time you say the same paragraph to Claude, write the skill. Not the first time (you are still figuring out the shape). Not the second time (you are still verifying). The third time. By then you know what the steps are, what the inputs are, what the output should be. The skill is just freezing that pattern so you do not have to re-explain it again.

Skills are not the right answer for every repetition. A skill is for the work that has a clear shape and a clear output. The questions you ask Claude during a brainstorm, the back-and-forth of a difficult email draft, the exploratory reading of a new dataset, those stay conversational. Skills are for the work where the shape is solved and the friction is the re-explanation.

A worked example

The /weekly-recap skill is a good first one for a solopreneur. Every Friday afternoon you want to know: what got shipped this week, who got a reply that I owe a follow-up to, which numbers moved, what is still open from the promises I made on Monday. By Friday at 4pm you are tired and the last thing you want is to think about the shape of that question. You want to type one word.

The skill body says, in plain English: pull the daily logs from this week. Cross-reference them against the CRM activities table. Surface the promises field for any contact where the due date is this week. Read the dashboard summary for the week. Produce a short markdown brief with five sections: shipped, replies owed, numbers moved, open promises, what to carry into Monday. End with a one-line emotional pulse based on what surfaced.

You write that skill once. You type /weekly-recap every Friday. The skill takes thirty seconds. The version where you re-explained the shape every time would take you fifteen minutes.

Mark complete Next Lesson

Workflow automation

A skill is a single recipe. A workflow is a chain of skills (and small judgment moments) that runs end to end. The morning protocol is a workflow. The new-client onboarding is a workflow. The Friday content push is a workflow. Each one calls multiple skills in sequence, with decisions in between, and produces something you used to spend forty minutes assembling by hand.

One note on the word. There is also a specific Claude Code feature called Workflows that writes itself a recipe and runs many helpers on its own. We map it against skills, helpers, and teams in Skills, helpers, teams, and workflows.

The first workflows that matter for a solopreneur are the ones that happen every week. The protocol shape (morning, evening, Monday planning, Friday recap) gives you predictable rhythm without thinking about it. Once those are running, the next ones are the workflows tied to events (new sale, new lead, new conversation) where the chain has to fire reliably or something gets dropped.

How a workflow is built

You write a short markdown file that says, step by step, what should happen. Each step is either a call to a skill you already have, a piece of work for Claude to do directly, or a check ("if X then Y else Z"). The file lives next to your other skills. You trigger it the same way: one word.

The difference between a workflow and a skill is just length and the presence of branches. A skill that does three things in order is already a small workflow. A workflow with twenty steps and three decision points is, by the same logic, a long skill. Do not get stuck on the distinction. Build the thing, then look at it later and decide if it needs to split.

Three patterns to know

Protocol.

The fixed-time workflow. Your morning protocol runs the moment you say "good morning". Steps are predictable: read today's daily log, check the calendar, sweep Gmail, pull the dashboard, brief you on what is in motion, ask one question that sets the day. The file lives at .claude/commands/morning.md. Same shape every day, different content because the data is different.

Trigger.

The event-driven workflow. New course sale fires a webhook into Supabase. Supabase fires an edge function that adds the buyer to the CRM, queues their welcome sequence, drops a Slack notification, and emails you the receipt. You did not do anything. The trigger pattern depends on something OTHER than you starting it (a webhook, a cron, a hook in your settings.json).

Compose.

The chain-of-skills workflow. The Friday content push calls /trend-scout to surface what is hot in your niche, then /voice-check against your last 30 posts, then /branded-post to generate the carousel, then /ig-post to schedule it. Four skills, one workflow file, one trigger word. The composition is the workflow. The individual skills stay reusable on their own.

When a workflow earns its place

A workflow earns its place when the chain has run cleanly three Fridays in a row. Before that, you are still tuning. After that, it is part of the system. The mistake is to write a 14-step workflow on day one and treat it as if it works. Build it skill by skill, run the first two together, then the first three, until the whole chain is reliable enough that you trust the output without watching every step.

Mark complete Next Lesson

Your content engine

Most content advice tells you to batch-create, plan a month ahead, follow a rigid calendar. That does not work for solopreneurs. Your energy changes, your life changes, your ideas change. You need a system that moves with you.

Your content engine has two modes. You choose which one fits the moment.

Mode 1: "What should I write about?"

Your system reads your past posts, finds what your audience actually responds to, and builds a bank of questions designed to draw out your best content. Not generic prompts. Questions based on YOUR data, YOUR patterns, YOUR top-performing posts. It asks you the right question. You answer. Your answer is the post. Your system formats it and schedules it. You never stare at a blank page.

Mode 2: "Create me a post about this"

When you need a branded carousel, a sales post, or a proof-of-value post, give your system the topic. It builds the visuals in your brand, writes the caption in your voice, exports the images, and schedules it. One prompt, published post.

The two modes never mix. Your personal posts stay personal. Your sales posts stay clean. That separation is what makes both work.

Your content toolkit

This module gives you six content skills that work together: /content-analysis reads your past posts and builds your personalized prompt bank. /campaign builds full multi-week launch runways. /trend-scout finds what is trending in your niche so you are never guessing what to write about. /social-pulse reads your analytics and tells you what is working. /product-carousel creates outcome carousels that show what people walk away with. And /flow-deck builds interactive presentations you can use for demos, workshops, or sales calls.

From idea to scheduled, in three moves

Three skills carry a post through your pipeline, and your dashboard's Content tab shows each stage. /content-vault ("add to vault") catches a raw idea the second it lands, so it never gets lost. /queue ("add to queue") works an idea up into a staged post, an image and/or a caption, that sits in your Queue ready but not yet out. /schedule ("schedule" or "post") sends a queued post to LinkedIn through Postiz, once you approve the exact caption and time. On the dashboard you see all three at a glance: ideas in the Vault, staged posts in the Queue, and what is going out on the calendar.

Mode 1 in practice

Run /content-analysis once. It reads everything you have posted in the last six months across LinkedIn, Instagram, and your newsletter. It clusters by engagement, by topic, by tone. It produces a prompt bank: forty to sixty questions, written in the patterns of your best posts, that draw out the kind of thinking your audience responds to. The bank lives in your repo. From then on, the daily loop is: open the bank, pick a question that lands with where your head is today, write the answer in your own voice, send it through /voice-check, schedule. Twelve minutes from open to scheduled.

Mode 2 in practice

You have a topic and you want a finished asset. Say it in one line: "Create me an Instagram carousel about why solopreneurs do not need a per-seat CRM." The mode-2 skill (/branded-post or /product-carousel for outcome posts, /linkedin-carousel for LinkedIn) writes the caption, generates the slide images in your brand colors and fonts, runs the voice check, and schedules through Postiz. You review and either approve or send back for one round of edits. Eight to fifteen minutes start to finish.

Mark complete Next Lesson

Posting on social media with Postiz

Most schedulers (Buffer, Later, Hootsuite) ask you to upload content into their dashboard, pay them monthly, and trust them with your queue. Postiz takes the opposite shape. It runs on your machine as a small set of containers, connects to your social accounts directly, and Claude posts through it from the terminal. Your scheduling data lives on your laptop. The fee is zero.

The point of bringing scheduling inside your root system is not the twelve dollars a month. It is that the schedule becomes part of your workflow. You finish a carousel in your repo, you say "schedule this for Tuesday at 9am London", and Claude posts it. There is no other tab to open, no other login to remember, no separate brand voice you have to sync.

The shape of the workflow

Postiz sits between three pieces. Your repo, where the content is made. Cloudflare R2, where the images live so Instagram can download them. The platforms themselves (Instagram, LinkedIn, others), where the post lands. Claude orchestrates all three through a single MCP connection.

You build the carousel (your branded slides, your voice, your topic). Claude uploads the images to R2 and gets back public URLs. Claude schedules the post via Postiz with those URLs. Postiz fires at the scheduled time, hands the URLs to Instagram, and the post goes live. Old images auto-delete from R2 after seven days so storage never piles up.

What to ask Claude for

Once Postiz is running and your accounts are connected, the language is plain:

• "Post this carousel to Instagram now" (with the image files)
• "Schedule a LinkedIn post for Monday at 9am London"
• "Draft an Instagram carousel about [topic] and queue it for Friday"
• "Show me my connected accounts"
• "What's scheduled for next week?"

You never visit the Postiz dashboard after setup. It runs in the background. Claude is the only interface you touch.

Before you decide

Postiz is not for everyone. Self-hosting means a one-time install and you own the result. The install asks for these things, so read the list before you commit your evening to it.

• A computer with at least 5 GB free disk space and 8 GB RAM
• Docker Desktop, a free app that runs Postiz on your machine in the background. You'll install it as the first step of the setup. Docker Desktop itself is around 2.5 GB on disk and uses 2 to 4 GB of RAM while running. Postiz containers add another 2 to 3 GB on disk.
• A Facebook account, a Facebook Page for your business, and an Instagram Professional or Creator account linked to that Page
• A Cloudflare account (free, but a payment card is required on file, same as AWS)
• If you also want LinkedIn: a LinkedIn account and a Company Page you own
• 30 to 45 minutes of focused time for Instagram only, 60 to 90 minutes for Instagram and LinkedIn together (plus a wait for LinkedIn to approve their Advertising API, which can take hours to days)

If any of those is a hard no, the paid alternative is fine. Buffer, Later, or Hootsuite all do the same job from someone else's cloud for about €10 to €20 per month for Instagram plus LinkedIn. You skip the install. They hold your queue. You pay rent every month and they own the schedule. Many solopreneurs run that way for years. The choice is whether you want to own the scheduler or rent it.

Mark complete Next: Other connectors and what to do with them

Other connectors and what to do with them

Postiz is a connector. So is Stripe. So is Resend. So is your Supabase database. A connector is just a way for Claude to read or write data somewhere outside this folder. The value is never in the connector itself. It is in the question you ask of the data flowing through it.

Slack, Notion, Krisp, and Google Workspace are the four most useful connectors for a solopreneur after the basics are in place. Each one becomes useful the moment you write a small skill that asks one specific question of it. The connector is the pipe. The skill is the question. The output is the thing that changes how your day goes.

This lesson takes each of the four in turn. For each, what it gives you, what skill is worth building first, and what to ask Claude for once it is connected. Setup steps live in the guides linked at the bottom.

Slack, the daily digest

If your team or community lives in Slack, the channels you should be reading are not the ones loudest in the morning. They are the ones where a decision was quietly made, a question was asked that nobody answered, or your name was mentioned in a thread you missed. Generic Slack reading does not surface those. A digest skill does.

The skill reads the channels you care about over the last 24 hours and produces one short page: decisions made, action items assigned, mentions of your name, unanswered questions, announcements you missed. Five buckets. Five lines per channel maximum. The point is that you scan one page and know what to engage with, instead of scrolling channels.

Ask Claude: "Build me a /slack-digest skill that scans #team, #wins, and #sales over the last day and gives me decisions, mentions, and unanswered questions."

Notion, the vault sync

Your content vault is local for a reason. It is fast, it is yours, it is part of your repo. But sometimes a collaborator needs to see what is in it, or you want to capture an idea from your phone where the repo is not. Notion is good at the surface layer: a shared database, friendly to read, easy to filter, accessible from any device.

The vault-sync skill takes any new idea from your local vault and pushes it to a Notion "Ideas Inbox" database with a title, the full body, a date, and a source tag. From Notion, anyone you have given access can read it, comment, add tags. The local vault stays the source of truth. Notion is the window into it.

Ask Claude: "Push this idea to my Notion Ideas Inbox", or build the skill: "Create a /vault-push skill that takes a content idea and adds it to my Notion database with today's date and source: vault-push."

Krisp, the transcript that becomes CRM updates

The hardest part of a call is not the call. It is the half hour after, when you have to write down what was discussed, what you promised, what they shared about their work, and what the next step is. Most of that information is in the transcript already. Krisp captures it. The /transcript skill turns it into the work.

The skill pulls your last meeting, identifies who you spoke with, looks them up in your CRM by email (not by first name, never by first name alone), extracts the key topics they shared, the decisions made, the promises both sides made, and the next step. It writes the summary to their CRM card, appends a meeting log to your daily log, and queues the promises in the CRM promises field. The whole post-call admin disappears.

Ask Claude: "Run /transcript on my last call and update Sarah's CRM card. Show me what you wrote before I confirm."

Google Workspace, the morning sweep

Your inbox is the place where money lands (Stripe receipts), new people arrive (signups), conversations start (replies), and your day gets reshaped (calendar invites). Reading it by scrolling top to bottom is the wrong shape. A sweep skill categorizes the morning's email into the buckets you actually care about, then prints a one-page brief.

The /gmail-sweep skill categorizes new mail into Stripe receipts, signups, leads, replies you owe within 48 hours, calendar invites, and newsletters (auto-labeled, not auto-archived until you trust it). One line per item with sender and the first useful phrase. A final tally line tells you what got swept. Calendar pulse goes one layer up: the week ahead with energy mapping so you can see where the back-to-back days are before they arrive.

Ask Claude: "Run /gmail-sweep for the last 24 hours and give me the brief." Or: "Build me a /calendar-pulse for next week. Tell me which days are heavy and which mornings I have free."

The pattern

All four connectors follow the same shape. Connect once at claude.ai/customize/connectors (the easy path) or via a self-hosted MCP server (more setup, more control). Then write a skill that asks one specific question of the data. Iterate the skill weekly. Within a month each one is a daily tool you cannot remember life without.

Do not connect all four today. Pick the one whose problem irritates you most this week. Build that skill. Use it for seven days. Add the next one only when the first feels like a tool you own.

Mark complete Next: Scheduled work that runs without you

Scheduled work that runs without you

Skills are things you call. Scheduled work is things that just happen. A morning brief lands in your inbox before you sit down. A weekly digest arrives Sunday night. A daily Gmail sweep happens at 7am whether your laptop is on or off.

This is the layer of automation that runs on its own clock. There are three different ways to schedule work in your stack. Each fits a different use case. Most people only need one.

Scheduling is the "when" layer. For the "how big" layer, which job needs a skill, a helper, a team, or a workflow, see Skills, helpers, teams, and workflows.

Option 1: In-session crons (the simplest)

Claude Code has a built-in scheduling tool. You ask Claude: "remind me at 6pm every day to wrap up." Claude creates a job that fires at 6pm and sends you a desktop notification. If you have Remote Control connected, it pushes to your phone too.

The catch: this only works while Claude Code is open and idle on your machine. If your laptop is closed at the trigger time, nothing fires. Recurring jobs auto-expire after 7 days, so you'll need to re-create them.

Option 2: Remote Claude routines (cloud-based)

Anthropic also runs scheduled Claude agents on their cloud infrastructure. You schedule a routine, and a fresh remote Claude session spins up at the trigger time, runs your prompt, and reports back via the Claude.ai inbox or mobile app. Works even when your laptop is off.

The catch: the remote Claude has no access to your local machine. It can read your GitHub repo and use any MCP connectors you've authorized at claude.ai/customize/connectors (Gmail, Calendar, Slack, etc.). If you want the remote agent to do real work, you connect those services first.

Option 3: Supabase pg_cron (server-side, the workhorse)

Your Supabase database has a built-in scheduler called pg_cron. You can schedule any function to run at any interval, server-side, completely independent of Claude or your laptop. This is what runs the email sequences, the relationship score decay, and the weekly cooling-contact alerts in your stack already.

The pattern: write a Supabase edge function that does the work, then schedule it with a cron expression. The edge function can read your tables, send emails via Resend, post to Slack, hit external APIs. Anything code can do.

Which one to use

Use case	Best option
Reminder while you're working	In-session cron
Daily morning brief from your business data	Supabase pg_cron + edge function + Resend
Weekly digest with light analysis	Supabase pg_cron, OR remote routine if you want Claude to write it
"Read my repo and summarize" daily	Remote Claude routine
Hourly email sequence processor	Supabase pg_cron (already running in your stack)

A worked example: the daily sales brief

Most useful starting point for solopreneurs: a daily sales brief that lands in your inbox at 8am. Not a to-do list (that's already overwhelming). Specifically the sales signal:

Plus a weekly priority email on Mondays at 7am: top cooling contacts to reach out to, promises due this week, pipeline movement targets.

This whole thing is a Supabase edge function (~150 lines) plus a one-line pg_cron schedule. Once it's running, it costs you nothing in attention. It just shows up.

A note on auth (for Phase 2 work)

The simple version of the morning brief uses only your own Supabase data: purchases, contacts, promises, leads. That works today with no extra setup.

If you want the brief to also include Gmail, Calendar, or Calendly data, each external service needs OAuth credentials stored as Supabase secrets. That's a one-time auth setup per service. Defer this until the simpler version proves itself useful.

Mark complete Next: What to keep, what to ditch, what to build

What to keep, what to ditch, what to build

You finish a module like the last one with a small thrill (Postiz from the terminal, edge functions running at 7am), and then a quieter question lands. If you can build this much yourself, what else are you paying for that you no longer need? And what should you keep paying for, because someone else solved it better than you ever will?

The decision is the same every time, and it sits in three buckets.

Keep

Tools that solve a problem you do not want to own. Stripe handles cards and tax compliance across 40 countries; nobody serious rebuilds Stripe. Resend deliverability; nobody serious rebuilds an SMTP reputation. The platforms your customers already live in (LinkedIn, Instagram, Substack) until your audience moves. The hosting provider that runs your static files. Anything where the work-to-replace cost is bigger than five years of subscription.

The test: would I rebuild this if it disappeared tomorrow? If the answer is no, keep paying. The fee is rent on someone else's hard problem.

Ditch

Tools that own data that should be yours, charge per seat for one user, or sit between you and your customers when there is no real reason for them to. Per-seat CRMs when you are one person. Newsletter platforms you cannot leave with your subscriber list intact. Form builders that own the responses. Scheduling tools that lock your bookings behind a paywall. Anything where you are renting back access to your own customers' information.

The test: if I cancelled this tomorrow, can I take my data with me, or do I lose it? If you lose it, you do not own your business, the vendor does. Migrate first, then cancel.

Build

Wrappers around a workflow you already do, that you want to do faster and with your own shape. Your CRM (you know your relationships, no SaaS does). Your content engine (your voice, your audience, your bank of past posts). Your dashboard (your numbers, your rhythm). Your morning brief (your priorities, your business data). Anything where the shape of the thing is your shape, and a generic tool would force you to bend.

The test: am I editing the tool to fit my work, or editing my work to fit the tool? If you are bending, build. The first version is rough and that is the point. You iterate it weekly. By month three it is exactly the tool you needed all along.

Mark complete Next: Skills, helpers, teams, and workflows

Skills, helpers, teams, and workflows

By now your system does real work. You have built skills, connected your tools, and started to hear words like helpers, teams, and workflows without a clear picture of when each one earns its place. This lesson is the map that puts all of it in order, so when a job lands on your desk you know which size of help to reach for. Most of the time the answer is small. Once in a while it is not, and there is now a tool for that too.

You set up and run all of these from the terminal, the same Claude Code you already use. There is no separate app to install.

There are only a handful of ways to hand a job to your system. They line up from the smallest everyday ask to the rare, very large job. The whole skill is matching the size of the help to the size of the job, and not reaching for something bigger than you need.

The ways to hand off a job

Smallest to biggest, with where you have already met each one.

The first five are about how big the job is. The last one, a routine, is about when it runs. You can put any of the first five on a routine.

The clearest way to tell them apart is one question: who is keeping track of the steps? When you just ask, you are. With a skill, Claude is, by following the recipe you wrote. With helpers and teams, Claude is, deciding each step as it goes. With a workflow, a short written recipe is, which is exactly why it can run far wider than a single conversation. Who holds the plan tells you which rung you are on.

Helpers and teams, up close

A helper, sometimes called a sub-agent, is a single Claude sent off to do one focused job in its own space, so the result comes back clean without burying your main chat. Most of the time you do not ask for one by name. When a task is heavy, like reading a sixty page report or searching across hundreds of files, Claude often sends a helper on its own and shows you only what it found. You can also ask outright: "send a helper to read this contract and pull out the three dates I need." Some of your own skills already work this way under the hood, sending out a handful of helpers to check your system from several angles at once.

A team is a few of those helpers working from one shared list, with one of them leading and keeping them in step. You reach for a team when a job splits into parts that have to stay coordinated: "set up a small team, one to draft the page, one to check it against my brand rules, one to format it." Claude hands out the parts and pulls the work back together. Teams are still an experimental feature, so you switch them on once before the first use. For most bigger jobs a helper or two is plenty, and a team is the step you take only when the parts genuinely need a leader.

A workflow is simply the next rung up from a team, for when even a coordinated handful would be too small or too hard to keep in order, and the job runs to dozens or hundreds of pieces.

The new rung: workflows

A workflow is for the rare big job with many separate pieces. Instead of working through them one at a time in your chat, Claude writes itself a short recipe and a runner carries it out in the background. It can have many helpers going at once and work through hundreds of pieces in a single run, while your chat stays free for other things. At the end you get one finished result: a report, a cleaned-up set of records, a batch of updated pages. Because a written recipe holds the plan, a workflow can also do something a single pass cannot. It can have independent helpers check each other's findings before anything reaches you, so the answer is more trustworthy.

Claude Code already ships with one workflow you can try: /deep-research. Workflows are still a new feature, so the first time you may need to switch them on. Run /config and look for the workflows row, or simply ask Claude to turn them on. Then give /deep-research a real question, for example "what do comparable small group programs in my field charge, and how are they positioned", and it fans out across many sources, checks them against each other, and hands you one report with its sources listed. Running it once is the safest way to feel what a workflow does.

How you start one

You ask in plain words. Say "use a workflow to ..." or add the word ultracode to your request. Claude plans the job into stages and shows you that plan first. You read the stages, check they match what you meant, and only then does it run. Nothing is a surprise, because you approve the plan before it touches anything. To watch it work, type /workflows. You do not have to watch. Go do other work and come back. When a run does what you wanted, open /workflows and press s to save it as your own command, like /quarterly-content-audit. Next quarter it is one word.

Which to reach for

Stay low on the ladder. Almost everything you do is a quick ask or a skill. Reach for a helper when a job is heavy enough to clutter your chat, a team when it splits into coordinated parts, and a workflow only for the rare, genuinely large job: a full review of everything you published this quarter, a pass across your whole client list, a real piece of market research. If you are not sure, you do not need a workflow. The newest tool is not the right tool just because it is new. Workflows are also still an early release, so treat your first runs as experiments and read the result before you act on it.

Mark complete Next: Full system audit

Full system audit (mandatory)

Before you call Part 2 done, audit the whole system. There are two ways to run it, and you want both: a fast workflow that sweeps everything at once, and a manual deep pass that tests your live infrastructure. Between them they catch whatever was skipped, misconfigured, or left half-done before a customer finds it.

The fast pass: run /system-audit

This is a workflow, the kind you met in the previous lesson. It sends nine specialists across your system at once, each checking one area, and hands you a single graded report (green, yellow, or red) with a "fix first" list. It covers your installs and integrations, your database and security, and your legal and GDPR pages, plus the things a manual pass usually misses: documentation that no longer matches reality, broken internal links, brand and design slips, and places where one part of your system contradicts another. It runs in the background while you keep working, and because it ships in your repo at .claude/workflows/ it is already in your command list. Type /system-audit, or /system-audit security to check a single area. Workflows are a new feature, so if it does not run, turn them on first (see the previous lesson).

The deep pass: guide 82

The workflow reads and reasons over your system. The one thing it cannot do from reading alone is fire live tests at your running services. Guide 82 does: copy-paste commands that actually hit your endpoints, check your CORS, and run a real test transaction through Stripe. Run the workflow first for the broad picture, then walk guide 82 for the hands-on infrastructure checks.

Together they are your graduation gate. If anything comes back red, fix it first. Re-run after any major addition, and before sharing your system with anyone.

Mark complete