The page in the Playbook.
In Unit 3 you built a setup. In this unit you turn the work you do on top of that setup into something Claude runs on command. By the end you'll have designed your first real Skill.
You've made it past where most professionals stop. Your Custom Instructions are tight. You have at least one Project doing real work. Claude opens already knowing who you are and what you need.
But you're still typing the same kinds of tasks. "Draft the kickoff email." "Pull together the weekly recap." "Generate the standard checklist." Same instructions, different inputs, week after week. Phase 4 ends that — by packaging the procedure once and triggering it on demand.
What you'll walk out with
A working model for what a Skill actually is. Two complete Skill specs you can copy. And two of your own — one designed from scratch, one refactored from a Phase 2 prompt you might already have lying around.
What Unit 4 covers
- The Phase 3 ceiling — why even a perfect setup leaves you typing.
- The mindset shift — from "describing the task" to "triggering the procedure."
- The four parts of a Skill — Trigger, Inputs, Procedure, Output. (The Skill version of RCTC.)
- Two worked examples — Maria builds a subject line Skill, Marcus packages his weekly pipeline recap.
- Three Skill mistakes — and how to avoid them on your first build.
- Two hands-on designs — your first Skill from scratch, plus a refactor of a Phase 2 prompt.
- The Phase 4 ceiling — what Skills can't do yet, and the doorway to Unit 5.
The work you keep doing.
A great Phase 3 setup quietly hides a new problem: the tasks themselves repeat. You stop noticing because the setup makes each one easier — but you're still typing the same instructions every time.
Watch yourself for a week and you'll see it. Every Friday afternoon you write the weekly recap. Every Monday morning you draft the standard team update. Every renewal cycle you send the same flavor of customer outreach. The CONTEXT (who you are, what your company does) is locked into your setup. The TASK (what to do, in what order, with what output) is still on you to compose.
Three signs you're hitting the Phase 3 ceiling
1. You're copying old prompts to start new ones.
You scroll up in Claude or dig in your notes for "that prompt I used last week." You modify a few values. You send. That copy-paste workflow is the Phase 3 ceiling staring you in the face.
2. You can describe the procedure faster than you can do it.
You catch yourself thinking "I just want to say 'run the weekly recap' and have it happen." That sentence is exactly Phase 4 calling.
3. New people on your team can't repeat your workflow.
The procedure lives in your head. You could write it down — but you haven't. Phase 4 forces you to write it down. The Skill becomes both a tool for Claude and a real SOP your team could use.
The rule of fives
The third time you do a task, you start sensing the pattern. By the fifth time, you should be packaging it. Anything you've done five or more times the same way is a Skill candidate. Most working professionals have ten to twenty Skill candidates sitting in their week — they just haven't named them yet.
Reflection · 2 minutes
Name three tasks you've done with Claude five or more times with substantially the same instructions. These are your first three Skill candidates.
Stop describing the task. Start triggering the procedure.
In Phase 3 your setup holds who and what. Phase 4 adds how. Once how is captured, your work becomes a trigger, not a description.
In Phase 2 every prompt had four ingredients (RCTC). In Phase 3 the Role and Context graduated into your setup. In Phase 4, the Task and Constraints graduate too — into a Skill that lives next to your Project, waiting to be run.
The slogan that does the work
If you're typing it five times, package it.
The rule scales. The third time you do a task, write it down. The fifth time, package it as a Skill. From then on, you trigger it — you don't type it.
The SOP analogy
Every real business runs on Standard Operating Procedures — the documented way you handle returns, the checklist for onboarding a new client, the steps in the monthly close. SOPs exist because nobody wants to re-invent the procedure every time, and they want consistency across runs.
A Skill is the AI version of an SOP. You write the procedure once. You name it. From then on, anyone with access to the Skill (you, your team, future-you) can trigger the same procedure and get the same shape of output.
The framing isn't metaphorical. The first Skill most working professionals build IS an SOP — the one they already had in their head and never wrote down.
What changes in your prompts
Before: "It's Friday. Pull together the weekly pipeline recap. Calculate WoW change in pipeline value. Identify the 3 biggest movers — positive and negative. Surface deals stuck in the same stage for 30+ days. Summarize top loss reasons. Give me a 200-word Slack-ready writeup with [structure]…"
After: "Run the pipeline recap. Here's this week's export."
Same output. One sentence instead of a paragraph. The procedure is in the Skill. The prompt is just the trigger plus this week's inputs.
The four parts of a Skill.
Every Skill you'll ever design has the same four parts. Miss any one and the Skill breaks or wobbles. Memorize the four — the rest is detail.
This is the Skill version of RCTC. If RCTC defined the four ingredients of a great prompt, T-I-P-O defines the four ingredients of a great Skill.
Trigger
The phrase, task name, or pattern that tells Claude "use this Skill." Without a clear trigger, your Skill sits idle while Claude keeps composing fresh answers from scratch.
Triggers can be specific ("run the weekly pipeline recap") or pattern-based ("any time the user asks for a customer renewal brief").
Inputs
The variables you provide each time you trigger the Skill. The point of inputs is to capture what changes between runs — and to make sure Claude doesn't try to guess the parts only you know.
Name every input explicitly. "This week's pipeline export." "The customer's name and tier." "Yesterday's incident report." Don't assume Claude will infer them.
Procedure
The steps Claude follows, in order. Pseudocode level — not click-by-click. Five to eight steps is usually right. Thirty steps is over-specifying and makes the Skill brittle.
Write each step the way you'd write it for a smart new hire: clear enough to follow, not so detailed it can't handle small variations in the inputs.
Output
The shape of the result. Format, length, structure, tone. If you don't specify the output shape, you'll get a slightly different format every run — and the whole point of a Skill is consistency.
The cleanest move: include an example output inside the Skill. Claude matches it. You get the same shape forever.
The 4-part test
Before you ship a Skill, walk through all four. Missing any one? Add it. Skills built without all four parts work the first time and break the third time — because Claude was filling in the gaps and your guesses changed.
Maria packages her subject line Skill.
Maria — the community bank marketer you've watched evolve through Units 1, 2, and 3 — has been generating email subject lines manually for months. Three campaigns deep, the pattern is obvious. Time to package it.
In Unit 2 she wrote the perfect Phase 2 brief. In Unit 3 she dropped her brand guide, past campaigns, and compliance rules into a Project called "Email Marketing." Now in Unit 4 she's writing the procedure. Here's the full Skill:
"Generate subject lines for [campaign]" — or any request to draft email subject lines for a specific campaign within the Email Marketing Project.
- Campaign name (e.g., "Spring CD Promo")
- Product/offer details (rate, term, key terms)
- Audience tilt (which member segment to lead with)
- Recent overused phrases (the ones we're rotating out)
- Generate 12 candidate subject lines drawing on the Project's brand voice and past-campaign examples.
- Filter against compliance: drop anything using "guaranteed," "risk-free," or any banned-word from the brand guide.
- Trim to subject lines under 50 characters (Outlook preview limit).
- Tag each surviving line with its dominant appeal:
rate,safety,convenience, ortrust. - Rank by predicted strength, balancing the four appeals across the top 10.
A markdown table with columns: Subject Line · Char Count · Appeal · Rank · Notes. Followed by a one-sentence recommendation of which three to A/B test.
What changes for Maria day-to-day
Before: every campaign, she'd open Claude, paste her Phase 2 brief, fill in this campaign's specifics, and review 10 generic-leaning subject lines. About 12 minutes per campaign.
After: she opens Claude inside her Email Marketing Project, types "Generate subject lines for the Spring CD Promo, 4.75% APY, 8 months, lead with safety, avoid 'limited time'" — and gets back a ranked, compliance-filtered, tagged table she can drop into her A/B testing tool. Two minutes per campaign. And the format is identical every time.
Marcus ships a Friday pipeline recap.
Marcus is head of sales operations at a 90-person B2B SaaS company. Every Friday at 3pm he writes a pipeline recap that goes into the leadership Slack channel. He's done it 60 weeks in a row. Time to package the procedure.
His Phase 3 setup: a Project called "Revenue Ops" with the current quarterly plan, last quarter's wins/losses retro, and the team's writing standards. His Custom Instructions handle the voice. The TASK he kept retyping was the pipeline recap itself.
"Run the pipeline recap" — or "Weekly pipeline recap" — within the Revenue Ops Project.
- This week's pipeline export (CSV from the CRM)
- This week's closed-won deals (deal name, ACV, segment)
- This week's lost deals (deal name, ACV, loss reason)
- Calculate week-over-week change in total pipeline value and weighted pipeline value.
- Identify the three biggest deals that moved (positive or negative) and one-line why.
- Surface any deal stuck in the same stage 30+ days that's not on the watch-list.
- Group lost deals by reason and summarize the top three.
- Write the leadership takeaway: what's the single thing the team should focus on next week?
- Compose a 200-word Slack-ready recap matching last week's structure.
A 200-word Slack message with headers: Headline · Movers · Watch list · Loss patterns · Next week. Bold the headline metric. Keep paragraphs under three lines.
What this Skill is doing under the hood
Notice the Procedure has only six steps. Not thirty. Each step is at the right altitude — Claude can do it without being walked through every keystroke, but specific enough that it won't drift. The Output section locks the format with a real example, so every week's recap looks like every other week's recap. Consistency is the point.
Marcus's Friday went from a 45-minute writing exercise to a 5-minute review-and-paste exercise. The Skill didn't replace his judgment. It just stopped making him re-type it.
Reflection · 3 minutes
Pick one of the Skill candidates you named on page 2. Sketch its four parts — trigger phrase, inputs, procedure (5–8 steps), output shape.
Three Skill mistakes that turn good procedures brittle.
These are the patterns that catch first-time Skill builders. Each one looks like rigor. Each one quietly makes the Skill harder to maintain.
Mistake 1 — Over-specifying the procedure.
You write a 30-step procedure when 6 would do. Every conditional. Every micro-decision. Every fallback. It feels thorough. The result is brittle: a Skill that works perfectly on the inputs you tested it on, then breaks on the 4th run when reality doesn't match step 17.
Mistake 2 — Undefined inputs.
You build a Skill that works the first time because all the inputs were in your head and you happened to paste them. The second time, you forget one. The third time, Claude invents what was missing. By the fourth run, you don't trust the Skill anymore.
Mistake 3 — Vague output shape.
You define Trigger, Inputs, Procedure — and skip Output because you assume it's obvious. It isn't. Every run looks slightly different. Headings move. Length wanders. Some weeks you get bullets, others prose. The whole point of a Skill is consistency, and a missing Output spec quietly removes it.
The debugging move
When a Skill stops feeling right, walk through T-I-P-O. Which part drifted? Nine times out of ten the procedure crept (someone added a step that didn't belong) or an input went undefined. The fix is in the Skill spec, not in the next prompt.
Your turn.
Two sample projects again. You'll design your own first Skill from scratch. Then you'll refactor a Phase 2 prompt into a Skill — the upgrade move you'll use a lot in the next few weeks.
Design your first Skill.
Pick a Skill candidate from page 2 — something you've done five or more times the same way. Spec it out. The goal is a complete, runnable Skill: trigger, inputs, procedure, output. Specific enough that you could trigger it tomorrow.
One way to spec this Skill — Customer Renewal Risk Brief
Trigger: "Run the renewal risk brief for [customer name]"
Inputs: (1) Customer name and current ARR. (2) Days until renewal. (3) Last 90 days of product usage trend (up / flat / down + magnitude). (4) Open support tickets, especially anything tagged severity 1 or 2. (5) Most recent QBR notes if available.
Procedure: (1) Score renewal risk Low / Medium / High based on usage trend, ticket pattern, and time-to-renewal. (2) Surface the top 2 concrete signals driving the risk score. (3) Recommend the one specific outreach move this week — call, email, exec touch, no action. (4) Draft the opening line of the outreach in our voice. (5) Note any internal coordination needed (engineering escalation, exec sponsor, billing).
Output: A four-section brief — Risk score · Drivers · Recommended move · Draft opener. Under 250 words. Match the format of last quarter's renewal briefs in this Project.
Notice the altitude. Five procedure steps, not fifteen. Inputs are named explicitly so the user doesn't have to remember what to paste. The output spec ties to past examples in the Project — so the format stays consistent across runs without re-specifying it every time.
Refactor a Phase 2 prompt into a Skill.
This is the move you'll use most over the next few weeks. Find a strong Phase 2 prompt you've used multiple times — pull the procedural part out — and re-spec it as a reusable Skill.
The Phase 2 prompt to refactor.
"You are a senior customer success manager at a small SaaS company. A long-tenured customer (3 years, mid-market plan, $24K ARR) was double-charged for their annual renewal due to a payment processor error on our side. The double charge has been refunded; refund will show in 3–5 business days. Draft a reply email from me to the customer's primary contact. Acknowledge the error, explain what happened in one plain sentence, confirm the refund and the timing, and offer one concrete gesture (a credit toward their next renewal). Warm but not gushing. No 'we apologize for any inconvenience.' Take real responsibility without over-explaining. Under 150 words. End with a direct line they can reply to me on."
Refactor this as a Skill. Pull the recurring procedure out (this kind of apology happens more than once a year) — and spec it so it's reusable.
One way to refactor this Skill — Billing Error Apology
Trigger: "Run the billing apology for [customer name]"
Inputs: (1) Customer name and primary contact's first name. (2) What the billing error was (double charge, wrong amount, wrong currency, etc.). (3) Customer tenure and plan tier. (4) Status of resolution (refunded? credit issued? still pending?) and timing. (5) Whether to offer a concrete gesture (yes / no) and what kind.
Procedure: (1) Open with a direct acknowledgment of the error, no preamble. (2) State what happened in one plain sentence. (3) Confirm the resolution status and expected timing in specific terms. (4) If a gesture is offered, name it concretely. (5) Close with a direct reply path to the CSM. (6) Keep tone warm but adult — no template apology language, no over-explaining.
Output: A reply email body, under 150 words, ready to paste into the customer's primary contact email thread. No subject line — this is a reply. No "we apologize for any inconvenience" or "I hope this finds you well."
Watch what got lifted out. The Phase 2 prompt baked in one specific customer ($24K, 3 years, double charge). The Skill pulls those out as inputs — so next time it's a different customer with a different error, the Skill still runs. Every Phase 2 prompt you reuse twice is hiding a Skill inside it.
The refactor habit
Once a week, scroll back through your Claude history. The prompts you reused — and especially the ones you slightly modified — are Skill candidates. Refactor one a week and within a quarter you'll have a personal Playbook of ten to fifteen Skills running your most recurring work.
Skills produce text. You're still the courier.
Once your Playbook fills out, you'll feel something different. The work is faster. The output is consistent. And one specific friction starts showing up — and it's exactly what Unit 5 is built to fix.
Phase 4 changes what you do inside Claude. Phase 5 changes what Claude can do outside Claude.
The new bottleneck
Marcus triggers his pipeline recap on Friday at 3pm. Claude produces a polished 200-word writeup in 10 seconds. Marcus reads it, approves it — and then spends another 2 minutes copying it into Slack, formatting the headers, and tagging the right channel members.
Maria runs her subject line Skill. Gets back a perfect table. Then copies the top three lines into her email marketing platform, sets up the A/B test, and clicks through five screens to launch it.
The Skill saved them the writing. It didn't save them the carrying. They are still the couriers between Claude and their real tools.
What Phase 5 actually fixes
Phase 5 — Connect — gives Claude hands. Through standard integrations (MCP and similar tools), Claude can reach directly into your Gmail, your Drive, your calendar, your Slack, your CRM. The Skill that used to produce text and stop now produces text AND sends it. Or files it. Or schedules it. Or posts it.
The Skills you built in this unit don't get thrown away — they get extended. The procedure gains a final step: "and then send it to the leadership channel" or "and then save to Drive in /reports/2026/Q3."
The signal you're ready for Phase 5
You stop being annoyed by Claude's answers and start being annoyed by Claude's limitations. You know exactly what should happen with the output — and you're the one having to do it. That feeling is the entire setup for Unit 5.
Reflection · 2 minutes
Take one of the Skills you sketched in this unit. What's the FIRST thing you currently do with its output by hand? (Send it? File it? Forward it? Schedule it?) That's the first thing Phase 5 will automate.
Are you ready to move to Connect?
Three questions to diagnose your readiness for Phase 5. If your Skills are still being built, Unit 5 will land flat — Phase 5 only pays off when there's something to automate first.
1. How many Skills are doing real work for you today?
2. After Claude finishes a task, what's the most common next step?
3. How often do you find yourself thinking "Claude could just do this if it had access to [tool]"?
Your readiness
Answer all three questions above to see your readiness for Phase 5.
Seven questions.
One per major idea in this unit. Click an answer for instant feedback. Your running score appears below.
0 of 7 answered · 0 correct so far
1. What is the Phase 3 ceiling — the reason a great setup still leaves you working?
2. The best way to describe a Skill in plain English:
3. The four parts of a Skill are:
4. The Trigger of a Skill is:
5. The most common Skill mistake — and the one that quietly makes Skills brittle — is:
6. The rule of thumb for when a task becomes a Skill candidate:
7. What is the Phase 4 ceiling — the limit even great Skills can't push through?
Finish the knowledge check to see your score.
Your Skill sketches and refactor are saved — come back to refine them anytime.
The new thought process.
Stop describing. Start triggering.
Recurring tasks are SOPs in disguise. Package the procedure once and trigger it on command.
The four parts of a Skill.
Trigger, Inputs, Procedure, Output. Miss any one and the Skill wobbles. Walk through all four every time you build one.
Pseudocode altitude.
5–8 procedure steps, not 30. Skills that try to be exhaustive break the first time reality doesn't match the script.
The courier problem is next.
Skills produce text. You still carry it into Slack, email, Drive, your CRM. Unit 5 ends that — Claude gets hands.