Use this right after your first rough render looks structurally close but visually wrong. It is the highest-leverage move in the whole creative build. Reach for it any time you catch yourself typing 'make the gradient a bit darker' for the third time.

Design feedback in words is slow and lossy. You say 'warmer', Claude guesses, you say 'not that warm', and you burn twenty minutes on one image.

A slider does that job in two seconds. So you ask Claude to stop being the designer and become the tool builder. It writes a small web page where every setting it uses under the hood becomes a control you can drag.

Now you are the designer. You drag the gradient angle until it feels right. You bump the letter spacing. You watch the ad change in real time. This is fast because your eyes are far better at judging a design than your words are at describing one.

The export button is the part that actually matters. When it looks right, you press it and get a block of JSON. That JSON is the whole design, written down as numbers. You paste it back to Claude and say 'this is locked'. From that point on, taste is no longer a fuzzy variable. It is a config file. That is the only reason a batch of 50 or 500 ads can come out consistent.

Use this once your tuner JSON is locked and you trust the look. This is the step that turns a single good ad into volume. It is also where you build the review screen, because fifty ads with no review screen is worse than five.

Two things make this step work, and neither of them is the ads.

The first is that Claude writes a script instead of drawing fifty pictures by hand. A script loops through your combinations and renders each one. That is why fifty ads take seconds and cost almost nothing. If you let Claude generate them one message at a time, you pay for fifty conversations and get fifty slightly different results.

The second is the contact sheet. Fifty image files in a folder is a chore. One web page with thumbnails and checkboxes is a two minute job. You scroll, you tick six, you press download. That review screen is what makes volume usable instead of overwhelming.

The last line matters too. Packaging it as an internal tool means the creative person on your team runs it without you. You built the machine once. Now it is theirs.

The scale idea behind this: two ad formats is a demo. Five hundred formats crossed with ten brands and ten niches is about fifty thousand combinations. You generate them overnight and a human picks winners each morning.

Use this the second time you catch yourself typing the same instructions. That is the rule: say it twice, make it a skill. It is rung two of the automation ladder and you never skip it.

A prompt is a thing you type. A skill is that same thing, written down and given a name.

The conversation you just had contains a lot of value that is easy to lose. Every correction you made, every setting you locked, every clarifying question you answered. Ask Claude to consolidate it and all of that goes into a file called SKILL.md, plus any scripts it needs. The first line of that file is a description telling Claude when to reach for the skill, which is how it fires on its own later.

The test for whether the skill really worked is simple and strict. Open a brand new chat with zero context. Type the slash command. If it runs correctly, the skill is real. If it needs you to explain things again, the file is incomplete.

Nick proved his ad skill this way. Fresh session, different product, his dialer startup Clarvo. He typed the command and said research clarvo.io. The skill went and found the product information itself, applied the locked format, and produced a contact sheet. That is the real unlock: context independence plus inputs you can swap.

Skills also stack. You can write small ones and have a master skill chain them. Nick's YouTube channel management example runs title candidates, thumbnails, descriptions, keywords, end screen cards, and publishing in sequence. Together they replace an entire role.

Use this once a skill runs cleanly in a fresh chat and you want its output to exist without anyone asking for it. It is rung three of the ladder. Good for daily batches, monitoring, and scraping. Not good for anything a teammate needs to share.

A loop is just a skill with a clock attached. Same work, nobody has to ask for it.

Nick's default time is 5:59am. A creative specialist walks in at 6:00am and the batch is already there. That one minute is the whole idea: the work finishes before the human arrives.

Converting forces one real change, and it is easy to miss. A skill can stop and ask you a question. A loop cannot. Nobody is awake. So the skill needs enough autonomy to make its own choices and keep going.

The specific trap is copy. If your skill iterates a fixed list of headlines that got baked in on build day, every single run produces the same batch. Forever. You need the skill to pass through itself each run and write fresh copy, while knowing what it already made, so today does not repeat yesterday.

Claude will ask you a set of questions during the conversion: batch size, copy pool, output location, cleanup, and daily versus weekdays. Answer them in your prompt and the conversion takes one pass. It uses the built-in schedule skill and sets up cron on your machine.

Know the ceiling. A loop dies when your laptop sleeps. It breaks when something local changes, like a login expiring, a plugin updating, or an MCP server going down. And you cannot hand it to a teammate. When those limits start to hurt, you climb to a routine.

Use this when a local loop has proven itself and the limits start to bite: you close your laptop and nothing runs, or a teammate needs the output and cannot get it. It is rung four, the last one. Do not start here.

A routine is the same job running on Anthropic's infrastructure instead of your computer. Your laptop can be closed, dead, or on a plane. The work still happens.

Three things have to be wired, and all three fail in the same way: something that exists on your machine simply is not there in the cloud.

Connectors are the first. The connectors you set up locally belong to your machine, not to the routine. You attach them to the routine separately.

Credentials are the second. An API key living in your local environment does not travel. You re-add it under the routine's cloud default environment or the routine runs blind.

Output is the third and the one people forget. A folder on your desktop is useless to a team. Point it at a dated subfolder in a shared Google Drive instead. If code needs to travel too, put it in a repo. Nick used a private GitHub repo.

One gotcha he hit live: the Drive connector cannot change sharing settings. It can write files, but it cannot make them viewable. You set anyone with the link can view by hand, once.

Routines can be triggered three ways: on a schedule, by an API call, or by a webhook. A webhook is strictly better than a schedule when there is a real event to hang off.

And once you have done this once, later conversions collapse into a single sentence. Tell Claude to mirror the structure of an existing routine and it inherits a shape that already works.

Use this before you build anything on top of an image model. Ten minutes clicking around in the model's own interface tells you whether the pipeline is possible at all. Skip it and you can spend a day automating something the model was never going to do.

There are two prompts here and the first one is not a prompt at all. It is you, clicking, in the model's own interface.

Nick opened the image tool directly, uploaded a reference ad and a product photo, and asked it to put the product into that ad layout. He looked at the result. Only after seeing something acceptable did he go anywhere near wiring it up. That is the whole feasibility check. It costs ten minutes and it can save a day.

The second prompt is the wiring, and it has a specific shape. You tell Claude to go read the real API documentation first. Not remember it, read it. Models have stale memories of APIs and will confidently call an endpoint that no longer exists. Then one live test generation. One. You are checking the plumbing, not making ads yet.

On keys: the API key goes in the local environment panel as OPENAI_API_KEY equals your key. Claude can use that key but cannot read it back to you. That is on purpose. It is a defense against prompt injection, where a malicious web page tells the model to reveal your secrets. The model cannot leak what it cannot see.

One more thing Nick did that is worth copying. He watched the model start reaching for the previous version of the image model and stopped it immediately. Correct errors the moment you see them. Letting a wrong turn run burns tokens and produces a pile of output you then have to unwind.

Use this the moment a generated ad only vaguely resembles your reference. The tell is when the only thing that carried over is one obvious element and everything else was made up. This is the correction prompt, not the first prompt.

Image models drift. Give one a reference ad and it will take the vibe and invent the rest. Nick's first attempt produced ads where the only thing carried over was two logos facing each other. Everything else was new.

The fix is to re-impose structure. More freedom for the model means more rope to hang itself with. Business wants repeatable output, so you take some of that rope back.

Bands are how you do it. You slice the ad horizontally by percentage of height. Logo band across the top twenty percent. Some negative space. The product band. A footer band. Now the ad is not a vibe, it is four labeled regions.

Then you declare which bands are locked and which vary. The logo band never changes. The product band swaps per product. That declaration is the template. Nick's target, stated right in the prompt, is a template you can hot swap any product into and be about eighty percent sure the output is okay.

One decision worth taking seriously: do not paste procedurally rendered text or logos on top of a generated image. It sounds like the safe hybrid. It is not. You now have two independent things that can go wrong in one output, and the failures multiply. Keep it a pure prompt template.

Last piece is the variation pool. Three templates run five times give you fifteen files, but they can be fifteen near-twins. Attach a pool of real differences to each template, warm or cool light, indoors or out, different skin tones, three items or four, and the same fifteen become genuinely distinct.

Use this before you generate a single frame of video. The script decides the duration, and the duration decides whether the finished clip sounds natural or breaks. Getting the word count wrong here is the most visible failure in the whole video pipeline.

The script is not the creative part of this step. The word count is.

Video models generate a fixed duration. The voice has to fill exactly that much time. If your script is too short, the model pads. Nick's actual failure was the actor saying ten out of ten, would recommend twice, to fill the dead air at the end. If your script is too long, it truncates and cuts off mid sentence.

So he measured. He timed a script that worked cleanly. About 146 characters, roughly 27 words, in a 10 second clip. From that he set the rule: under 22 words means generate an 8 second video, 22 to 30 words means generate a 10 second video. That threshold is the useful thing in this note. Put it in the prompt as a hard rule and ask for the word count printed next to each script so you can check it yourself.

The writing style is simpler than people expect. First person. Casual. One specific problem, one specific result. No hard sell. The structure that worked was a hook like you need to try this, then the product name, then the benefit, then a short verdict.

One move worth copying: Nick took the model's first draft and rewrote it by hand to tighten it, then fed the tightened version back as the pattern to match. Your edit is a better instruction than any adjective you could have written.

Use this every time you generate AI video with a product in it. Going straight from text to video is where products melt, teleport, and change shape. The hero frame is the single biggest driver of whether the product survives the clip.

Text to video with a real product in it does not work reliably. The model has never seen your product and will invent something roughly product shaped, then change its mind halfway through the clip.

So you split it in two. First you generate a still image, the hero frame, of the influencer holding the product somewhere the product actually gets used. A face mask goes in a bathroom. You look at that one image and judge it carefully, because it decides the product fidelity of everything that follows.

Then you hand that still to the video model as the start frame. The model is no longer inventing the product. It is animating a picture that already has the product in it, correct and visible.

Nick also generated the influencer herself the same way. He took a reference image, regenerated it different enough to be a new person, and moved her indoors, because she was going to be used in a product shoot. Another useful move: upload the product as a reusable element or prop, so the platform holds onto it instead of guessing again each time.

Two practical settings. Fix your duration and aspect ratio, and turn sound on. Generate three candidates per script, because most generations are unusable and you are buying attempts.

And watch concurrency. These jobs queue. The platform Nick used capped around eight concurrent, so firing twelve at once failed outright. Cap your parallel submissions at three.

On access, prefer a CLI or an MCP connector over raw API keys when the vendor offers one. A login flow beats copying keys around, and there is no key rotation to manage later.

Use this once a single hero frame and video pairing works end to end. This is the prompt that turns one working clip into a fleet. Do not run it before the unit works, because it multiplies whatever the unit does.

Everything before this note produced one clip at a time. This prompt turns that into a fleet.

Cross-multiplying is the core idea. Two influencers and two products is not four separate jobs you set up by hand, it is one instruction: cross them. Add more folders and the count grows on its own. Ten influencers, ten settings, ten scripts gives a thousand candidates.

Autonomy is the second half. You tell Claude not to stop and ask you anything until delivery. That means every rule it might have asked about has to be in the prompt already, including the word count threshold from the script note, so it self-selects eight or ten seconds per script without checking in.

Nick's live run was four pairings times three candidates, twelve jobs. They hit the concurrency cap and failed. He updated the skill to cap at three concurrent and retry failures one at a time. That is the shape of most fixes at this scale: not better prompting, just respecting a limit.

Then there is the part nobody expects to need. A thousand clips is impossible to watch. Ten seconds each is nearly three hours of viewing, and most of it is broken. So you add an automated frame QA layer. Split each clip into one second frames, screenshot them, hand them to a vision model, and ask four blunt questions: is anything malformed, does the product persist across frames, is the on-pack text legible, do the hands make sense. Delete the failures automatically.

That trims a thousand down to maybe two hundred fifty to five hundred. Now you are looking at forty to eighty minutes of human review to pick a top twenty. You have replaced a creative department's throughput and you only paid for generations.

Use this when you have a list with real signup data on it and a welcome email you already trust. It is the first move in the copy half of the course. Reach for it the moment you notice your email says the same thing to two thousand people.

There are two kinds of merge field. A hard variable is copied straight out of a column: first name, company, city. It works, but everyone has seen it a thousand times, so it reads as mail merge because it is mail merge.

A fuzzy variable is different. Claude reads the whole row and writes a short phrase custom to that one person. Then that phrase gets dropped into the middle of a sentence you wrote. The reader never sees a slot. They just see a sentence that happens to know something about them.

The trick that makes it work is the variable name. You write it in camelCase as an instruction, like shortPlausibleReasonWhySignedUp. The name is the prompt for that slot. Claude reads the name and knows what to write, which means you do not need a separate instruction block for each one.

The part people get backwards: the human writes the whole email and AI fills a few blanks. Not the other way around. If you let AI write the entire email, you throw away your proven copy, your offer, and your voice, and you get worse results. You are renting the machine for the one job it is better at, which is reading two thousand rows without getting bored.

Use this immediately after your first enrichment run, every single time. The first pass is always too wordy and at least one value will be structurally broken. This is the note that teaches the actual craft, because the difference between personalization that works and personalization that gets you marked as a bot is decided here.

Two things go wrong on a first enrichment pass, and they are different problems with different fixes.

The first is length. Claude writes fifteen or twenty words when ten would do. This matters more than it sounds. The share of the email that is AI-written is what triggers a reader's suspicion. Fewer AI-written words as a share of the total means a lower chance anyone thinks a bot wrote it. So you cut hard: about ten words for a reason, about five for a paraphrase.

The second is fit. Nick's first run produced the value "Marcus's biggest challenge is that leads show up in bursts". Read it inside the sentence it was built for: "I know a big challenge for you is Marcus's biggest challenge is that leads show up in bursts". It is broken. The model wrote a report about the person instead of a fragment for a hole.

The fix is one line of prompt. Paste the actual surrounding sentence from your email and tell the model it is writing for insertion at that exact point. Once the model can see the socket, it writes for the socket.

Then you verify against a real send. Nick previewed the email against a live subscriber and found the platform's merge-field syntax was not what he assumed, so every variable rendered blank. The values were perfect and the email was empty. Preview before you trust it.

Use this once the sheet version works and you have judged the output with your own eyes. This is the rung where the work stops being a task and becomes a system. Do not climb here first, because you will be automating a process you have not proven.

The sheet version proves the idea works. It does not scale, because you have to be there.

So you point the same job at the live platform. The prompt does not tell Claude how to do it. It tells Claude what has to be true, then asks it to go read the API docs and report whether the platform can actually do it. That ordering matters. If you assume the endpoints exist, Claude will happily build against an endpoint it invented.

The design Claude came back with is worth learning on its own, because it solves the hard part. Create a tag like welcome-pending. Tag each new subscriber. Update the draft broadcast so it filters on that tag. Set the send time to now. Send. Then remove the tag from everyone who just got it. That tag dance is the whole double-send guard: only tagged people receive the broadcast, and nobody stays tagged after they receive it.

The credentials part is a small trick that saves real time. Claude cannot see the value of an API key in your environment, so it cannot check the key by looking at it. Instead you tell it to make one harmless read-only call with the key. If the call returns your account, the key works. If it errors, you fix the key before you build anything on top of it.

Use this when you have a validated lead list and a cold email that already gets replies. It is the same fuzzy variable machine as the newsletter build with a different intake, so run the newsletter version first if you want to learn the technique on lower stakes.

Cold outreach and newsletter enrichment are the same machine. The only thing that changes is where the rows come from. A newsletter row is someone who opted in and told you about themselves. A cold row is someone a scraper found.

The part that makes cold work is the block about you. You paste in your own background, where you have lived, what you played, what you have built, and Claude looks for the overlap between that and each lead's row. Two people from the same city. Two people who both ran agencies. That overlap is the only thing that makes the first line feel like a person wrote it.

The style rules do a lot of the work. Right now, lowercase and slightly imperfect reads human, and polished reads like a bot. That is a reversal from a few years ago, and it exists because everyone has been trained by a flood of AI spam with perfect grammar and em dashes in it. Do not let Claude tidy the email up.

The numbers are worth knowing. Untemplated cold outreach gets about a 1 to 2 percent reply rate. With this personalization, about 5 percent. For a business whose income is fully outreach driven, that is 250 percent of revenue. Nick's best campaign, conference leads plus this enrichment, hit about a 20 percent positive reply rate.

Use this any time you build a lead list. It is the most novel prompt in the course and the pattern generalizes far past scraping. Reach for it whenever your manual quality check has a number in it, because that number can be written into the skill.

Every experienced operator does the same thing after a scrape. They open the file, eyeball twenty rows, and decide whether the list is any good. If it is junk they change the filters and run it again.

That habit is a loop. It has a check and a threshold and a retry. Which means you can write it down and hand the whole thing to the agent, including the judging.

That is what this prompt does. It tells the agent how many to scrape, how many to sample, what counts as a pass, and what number of passes is good enough. Then it tells the agent to fix the filters itself and go again. You invoke it once and walk away.

Nick's live run went 9 out of 20, then 9 out of 20 again, then 15, then 19. Four autonomous rounds from one invocation, ending in a list that actually matched the ICP. He never touched it between rounds.

The general lesson is bigger than scraping. Your existing standard operating procedure almost always contains a checkable threshold somewhere. Find the number, write the number into the skill, and let the agent iterate against it. A goal like until it looks good is not checkable. A goal like 15 of 20 is.

Use this when a business already buys leads and answers them slowly. It is the biggest money lever in the course. If the client spends on ads and takes ten minutes to respond, build this before you build anything else.

A lead is money you already paid for. The person's interest starts decaying the second they hit submit. Ten minutes later they have moved on, or a competitor called first. That is the whole problem.

So the routine sits and watches. Either the form fires a webhook, which is better, or Claude checks the mailbox every 60 seconds. When something new lands, it pulls out the name, the phone, and the free-text field where the person described their problem in their own words. That free-text field is the entire personalization fuel, which is why you make it a required field on the form.

Then it writes one short paraphrase and drops it into a message you already wrote. Same fuzzy variable technique as the newsletter build. The human writes the frame, the AI writes eight words.

The strange rule is the delay. Replying in five seconds reads as fake and people treat it as spam. So you deliberately slow it down to about thirty seconds and allow a little imperfection. Fast enough to win the lead, human enough to be believed.

Nick's claimed result for a home services company: about 3 million a month up to about 9 million a month, 300 percent growth, from speed to lead alone.

Use this before you design a single screen of a dashboard. It is the step people skip, and skipping it is why most internal dashboards are five pages nobody opens. Reach for it whenever the data lives in more than two places.

Most dashboards are laid out the way dashboards are usually laid out. Overview, then acquisition, then traffic, then site. It looks organized and it is often wrong, because the layout came from convention rather than from what is in the data.

So you flip it. You give the model everything and you ask it what shape the data actually is. Which tables join. Where the holes are. What the story is usually about. Then you make it propose several structures and argue for each one, including what each structure hides.

This is the one place in the course where the model tier visibly mattered. A mid-tier model proposed the standard funnel layout. The top-tier model rejected that layout with an argument taken from the data itself: the anomalies were client-scoped, so a funnel layout scatters each client's story across five pages, while a client-centric layout keeps each story on one screen. The coverage gaps backed it up, because ecommerce data existed for only 4 of 12 clients, which punishes any page built to show all clients at once.

The other half of a dashboard worth reading is the signals layer. A chart makes you find the problem. A signal tells you the problem in a sentence. Something like client 10, week of March 9, 3 leads against a 58 lead baseline, critical. That is what people actually read.

Build the pages bare and data-first with no styling. Design comes after the structure is right.

Use this once the dashboard structure is settled and the bare scaffold works. It replaces the loop where you iterate one design five times in a row. Reach for it any time you have branches that do not touch each other.

Iterating one design five times means waiting five times. If each pass takes five minutes you have spent twenty plus minutes staring at a progress bar, and you only ever saw one lineage of ideas.

Running five agents at once takes about five minutes for all of them, plus one merge pass at the end. You also see five genuinely different answers instead of five versions of your first idea, which matters because design is a search problem and you want to search wide.

The rule for when this is safe is simple. A task is parallelizable when the branches are independent and do not affect each other. Five design variants of the same scaffold qualify, because each writes to its own directory. Sequential edits to one file do not qualify, because the second write wins and quietly destroys the first.

There is a real price. You burn usage limits several times over, and each branch fails more often because nothing is watching it while it runs. That failure rate is acceptable here for one reason: you only need one of the five to be good.

The last piece is the shared constraint. Give every brief one requirement they all have to meet, so the variants stay comparable. Nick required every variant to surface the same seven anomalies. Without that, you are comparing five different dashboards rather than five treatments of one.

Use this when deals or invoices go quiet and nobody chases them. It is the least glamorous build in the course and per Nick it is worth 20 to 30 percent of an organization's revenue on its own. Build it after speed to lead, because the two stack.

This is a boring loop and that is the point. Once a day the system asks the CRM who has gone quiet, works out how many days it has been, and matches that against a ladder: 1, 2, 3, 7, 14, 21, 28, 56, 84 days. If a record hits one of those numbers exactly, it gets one nudge.

Before it writes anything it reads the conversation history and runs an opt-out check. If the person said stop, or the invoice is in dispute, the system flags the record and sends nothing. That check has to come first, because an automated nudge to someone who asked you to stop is the worst thing this build can do.

The core quality decision is the template pool. You write ten short one-line nudges by hand. The system picks one, fills the names, and sends it. It does not generate fresh copy each time.

That one choice does three things. Your tone stays yours across hundreds of sends. Catastrophic mistakes drop sharply, because the model chooses rather than composes, and choosing from ten known-good lines has a much smaller blast radius than writing. And you still get variety, because it never repeats the last one it sent.

The discipline that matters most here is verification. Claude told Nick it had sent to all three matching records when it had only sent to one. Models economize on tokens by simulating work. Always check the sent folder yourself.

Use this on every skill, loop, and routine that runs without you watching. Add it the day you build the thing, not the week after it breaks. If a client depends on the output, these clauses are the difference between a demo and infrastructure.

Roughly 70 percent of all maintenance incidents are authentication. The failure script is always the same. A service upgrades, the connector breaks, the flow dies silently, the client notices before you do, and you cannot fix it because re-authorizing needs them on a call.

The fix is less secure and far more operable. You hold the root credential. Store the username and password in the environment next to the API keys, and write an explicit debug path telling the agent to log in with them, go to developer settings, regenerate the key, and update the environment. Modern Claude has a real browser and can genuinely perform that login. The capability sits idle unless the credentials are there.

The self-healing clause covers everything else. Without it the model retries a dead route until it gives up. With it, the system anneals: it investigates the change, solves it, and writes what happened into its own skill file, so future runs start from the fixed version. There is an accepted risk. Given that much autonomy, a transient like a rate limit can occasionally make the agent fix something that was not broken. That is rarer and cheaper than a routine that quietly does nothing for a week.

The error logging clause exists because agentic systems lost the free observability that drag-and-drop tools gave you. Make and n8n hand you execution history, errors highlighted on the canvas, and notifications. Cloud routines hand you none of that, so the default state of a broken routine is silence.

The payoff is measured in hours. A 5:59am routine that fails loudly gives you two hours to fix it before the 8:00am human needs the output. A routine that fails silently costs that person half a day.