Skills, Turning a Recurring Task into a Checklist

A permanent rule belongs in CLAUDE.md. A repeatable task doesn't. It belongs in a Skill instead, loaded only when you actually need it rather than sitting unused in every single session's starting context, which is the distinction this chapter works through, using two of my own examples instead of leaving it abstract.

What a Skill actually is

The economics matter here, not just the mechanics. I call Skills one of the more economically valuable ways I use Claude Code, and the wider pattern an "agentic workflow." A Skill, in my own telling, is just one way to build one. My own library shows the range: sorting leads, auto-generating proposals, the same proposal-generation platform I built earlier, spotting niche outliers, keeping email replies current, cutting YouTube videos, onboarding agency clients, applying to Upwork jobs, and watching community posts. That's my own list, not a required one.

The pattern underneath the list matters more than the list itself. That's the real point. Most of those entries are recurring tasks from my own daily work, turned into a checklist and handed to Claude so it executes the same way every time.

Anatomy: SKILL.md and its scripts

A Skill splits into two layers. SKILL.md is the orchestrator. It's the high-level plan for what needs to happen and in what order, covering the goal, the inputs, the available scripts, the process, verification rules, error handling, and the expected output. Separate scripts underneath do the exact, repeatable work itself, and they exist for one reason: consistency. Claude still supplies the reasoning and the orchestration, and the predictable parts of the job move into code it can call, instead of being reinvented on every run.

I reach for an orchestra-conductor analogy to describe the relationship, and it mostly holds: SKILL.md directs, the scripts perform. It breaks down at one point, though. A real conductor genuinely can't pick up a violin and play a missed passage, but Claude, running the "conductor" role here, actually could write the code itself instead of calling a script. It doesn't, on purpose. The whole reason to keep scripts around is that reliable, repeatable execution beats reinventing the wheel every single time.

FIGURE 29 — Skill anatomy. SKILL.md decides what happens next; the scripts underneath do the deterministic work.

Structurally, it's simple. Just a folder: an outer directory, scrape-leads/, say, holding a scripts/ subfolder for the actual operations, plus the SKILL.md file itself governing the whole workflow end to end.

One demonstrated run: scrape-leads

Lead scraping is recurring work for me. Finding, verifying, and preparing business-lead lists for my own businesses and clients, especially cold-email campaigns, by hand used to cost me roughly an hour or two every single time. So I converted that process knowledge into a Skill and asked Claude to scrape 1,000 dentists across the United States.

My own prompt for building it was specific rather than vague. Accept industry, location, and lead-count as inputs. Start with a roughly 25-lead test scrape and verify relevance before going further. Parallelize the full run for large requests, deduplicate, and use an LLM (large language model) to classify and verify each lead. Identify and enrich missing emails, but never invent contact information to fill a gap. Upload the verified leads to Google Sheets with named fields. And be resilient: on any failure, inspect the error, work out the cause, attempt a fix, retry when it's safe, and keep going instead of giving up on the whole run.

Try this with AI "Here's a task I do the same way every time: [describe it]. Write me a prompt for a Skill that covers the goal, the inputs, the process, and what should happen if a step fails."

Claude loaded the Skill on its own and started small, about 25 dentists, not the full thousand, so the results could be checked before anything bigger began. The sample passed. It then ran the real scrape in parallel across four processes, each pulling in roughly 250 leads. That replaced what used to be a separate, hands-on routine: setting filters, testing, checking, running the full scraper, uploading, then cross-checking again.

FIGURE 30 — scrape-leads Skill in action. One demonstrated run, start to finish: a structured prompt, a small test, a parallel scrape, a recovered error, and 1,000 leads in under two minutes.

Partway through, the Google Sheets upload hit a snag, a filename with characters it couldn't handle. Claude didn't stop. It spotted the error, changed its approach, checked the right API details, and finished the upload anyway. That's the real case behind a bigger point: a Skill can think through a failure and recover, instead of just running a fixed script blindly the way an old-style program would.

The whole run finished at roughly 1,000 leads in 87 seconds. The comparison is stark. I compare that to a manual version of the same job, which I estimate would have taken at least half an hour, sometimes longer, the comparison I use to argue that a Skill can carry real economic value once it automates a recurring piece of knowledge work.

FIGURE 31 — Economic value of a Skill. For this run, automating a many-minutes task brought it under two minutes.

Two things deserve a plain statement here. Fast Mode, used for this run, made the model about two and a half times faster at around three times the price, by my own numbers at the time, a real tradeoff worth knowing, not necessarily today's exact rate. I'm also upfront that I haven't reviewed every generated script's code line by line myself. I focus on describing the workflow clearly enough that Claude can build and maintain the scripts. A Skill "getting more reliable" after a failure like the upload error, in my own words, describes what happened in that one run, not something I've measured across many.

The same architecture, a different domain

Strip away the details and the lead-scraping run reduces to one repeatable shape: run the process with some settings, look at the results, retry or adjust if they're not good enough, check them against the target, classify, fill in whatever's missing, produce a clean output, and hand off the result. Orchestration just means the decisions on top of that chain, which script to run, what settings to give it, whether the output is good enough, and what to do if it isn't. It's not simply running a script.

That flexibility shows up in the details. How much enrichment a lead needs, for instance, depends on how many leads came back and what information is actually missing. Claude evaluates the intermediate output at each step and decides what happens next on its own, rather than following one fixed, hard-coded path regardless of what it actually finds along the way.

I show the same shape on a very different task: a Literature Research Skill. It searches academic sources like PubMed to answer a question, my example was the recommended daily vitamin D intake for a man in his early thirties, narrowing the search step by step. The pattern doesn't change: one clear goal, an orchestrating SKILL.md, its own scripts, a check-and-retry step, and a final structured result. Only the subject is different.

FIGURE 32 — One architecture, two domains. The same run, inspect, adjust, verify, deliver pattern, applied to lead scraping and academic research alike.

A weak academic query doesn't necessarily stall the workflow. It doesn't have to stop. Claude can retry it or adjust it and keep going, acting less like a single script that either works or doesn't, and more like a decision-making layer sitting between a series of deterministic operations.

I tie this to a familiar pattern in business. A lot of knowledge work still means sending instructions to another person, waiting, checking the result, asking for changes, and waiting again. A Skill does that whole cycle up front: the instructions and the scripts already exist, and Claude handles problems as they come up. I argue that can cut both the wait time and the need for outside contractors on repeat work, my own argument, not a measured figure from the wider industry.

Is this a good Skill candidate?

My own heuristic is simple enough to repeat verbatim: if you can already write the task as a conditional checklist, first do A, check B, if B fails try C, then process D, verify E, finally return F, it's a strong Skill candidate. The model supplies judgment between the steps. The scripts supply reliable execution.

FIGURE 33 — Is this a good Skill candidate? My own test, drawn straight from my example: if you can already write it as a checklist, hand it to a Skill.

I start sketching a new, unrelated Skill here, automated website generation from prospect data and templates, from nothing more than a bullet-point description of the desired behavior. What it demonstrates, even at this early stage, is that the starting point for a new Skill doesn't have to be complicated. It's not shown finishing yet. That comes next.

The website Skill, finished

I didn't leave that build unfinished for long. The new Skill needed to turn prospect information into a pitch-ready website that always matched one visual style, every time, regardless of which prospect's data went in. So I picked a reference design from a gallery, took a screenshot of it, and pasted that screenshot straight into the Skill-creation request. Prospect data would come from a Google Sheet. Images would come from the open web.

I deliberately tried to one-shot the whole thing rather than plan out every detail first. No pre-planning. Just Fast Mode and precise instructions, then see how far one pass gets. I handed Claude roughly 474 lines of the reference site's HTML so it could work out a style guide on its own, a shortcut that only paid off because of that upfront precision.

Claude asked a short round of setup questions before building anything: where to save the output, how to pull prospect data, how to source images, whether to build a mockup or a pitch page. Then it went further than I'd asked. It entered Plan Mode on its own judgment, unprompted, and I authorized Bypass Permissions before letting it build.

The first website wasn't close enough. So I told Claude to screenshot its own output and compare that screenshot against the reference design, then keep iterating until the two actually matched. That loop is the real technique here, not the website itself: give Claude a visual target, let it capture its own result, and have it compare directly against that target instead of trying to describe the gap in words. The second version came out substantially closer, correct prospect details and all, though with too many repeated images. A third version, run on a different row of prospect data, matched the pattern too, just with less relevant imagery, because I hadn't supplied an image-search API key.

Try this with AI "I'm going to show you a screenshot of what I want and a screenshot of what you just built. Compare them and list the three biggest visual differences, ordered by how much each one would matter to someone seeing this for the first time."

FIGURE 34 — One website, then ten at once. Parallelizing the same Skill ten ways turns a 30-second build into an effective three seconds per site — ten times more sites per 30 seconds, not one site finishing ten times faster.

Once the Skill reliably one-shot a customized site, I made a move I'd already made once in this chapter: turned it into a subagent so multiple copies could run at once. Ten parallel copies produced roughly ten sites every 30 seconds, an effective rate of about three seconds per site. From that one run, I extrapolated a 10,000-site batch at roughly eight hours. I'm not claiming that number as measured. It's one demonstrated rate, stretched out on paper.

FIGURE 35 — One afternoon's automated prospecting pipeline. Five Skills already built separately, chained on paper in a few minutes — a proposed next step, not a system that's actually been run end to end.

That extrapolation is what pushed me to sketch something bigger: chaining this Skill together with a lead scraper and an outreach-campaign Skill into one conceptual pipeline, scrape leads, build a prospect database, generate a website per prospect, generate a campaign, send outreach. I put that whole chain together in a few minutes. I haven't run it end to end as one working system yet. It's a next step, not a finished result.