Skills as operating instructions, repeatability over prompt drift, choosing the right interface, and keeping it all simple.
Quick refresher on what we've built so far — and what changes this week.
The first three weeks gave you tools. This week gives you doctrine.
This week is different. Instead of new tools, we're distilling the operating principles that make everything you've built actually stick. The difference between someone who uses AI once and someone who builds reliable systems? Doctrine.
"Tools without principles produce one-off wins. Principles without tools produce nothing. You need both — and now you have both."
A skill isn't a prompt. It's a reusable operating instruction that produces consistent results every time.
Most people treat AI like a search bar — type something in, hope for the best. A skill flips that model. Instead of hoping, you're specifying: who the AI should be, what context it needs, what prerequisites to gather, what constraints to follow, and what the output should look like.
Write me a marketing email for our new product launch.
You are a B2B SaaS copywriter. The product is [X], targeting [Y]. Use the AIDA framework. Keep it under 200 words. Include one CTA. Tone: professional but warm. Output: subject line + body.
When all five layers are defined, the skill becomes portable. You can hand it to a colleague, run it through Dispatch, schedule it for 3 AM, or embed it in an n8n workflow — and it produces the same quality output every time. That's the difference between a prompt and a system.
I want to turn this task into a reusable AI skill: Task: [describe the task you do repeatedly] Break it down into these five layers: 1. Role — Who should the AI act as? 2. Context — What background information does it need every time? 3. Prerequisites — What inputs/data should it gather or ask for before starting? 4. Constraints — What rules, tone, length, or format restrictions apply? 5. Output Format — What should the final result look like? Write the complete skill as a single prompt I can save and reuse. Include placeholders [like this] for the parts that change each time.
"A skill is a prompt that doesn't need you in the room. If you have to explain it every time, it's not a skill yet."
Why your AI outputs get worse over time — and how to fix it.
Prompt drift is what happens when you rely on conversation context instead of explicit instructions. In message 1, Claude knows exactly what you want. By message 40, it's interpolating from a messy conversation history and producing outputs that slowly diverge from what you actually need.
You've been chatting for an hour. Claude 'sort of' remembers your preferences. Outputs are inconsistent. You're constantly correcting.
Each task starts with a complete skill instruction. Every run is fresh. Output quality is identical whether it's the first use or the hundredth.
The solution is to make every skill stateless — it contains everything the AI needs, with no dependency on prior conversation. Think of it like a function in code: same inputs, same outputs, every time. If your skill needs the AI to "remember" something from earlier, that information should be in the skill itself.
Review these prompts I've been using with AI and tell me which ones are vulnerable to prompt drift: [Paste your saved prompts or common instructions here] For each one, identify: - Dependencies on conversation context (things that only work if the AI "remembers" something) - Missing prerequisites (information the AI has to guess at) - Ambiguous output formats (no clear spec for what "good" looks like) - Implicit constraints (rules you expect but haven't stated) Then rewrite the most critical prompt as a complete, stateless skill using the five-layer format.
"If your prompt only works on the third try, it's not the AI's fault — it's a skill that hasn't been finished yet."
The most overlooked step: making sure the AI has what it needs before it starts producing.
Most people give the AI a task and immediately expect output. But the best results come when you teach the AI to ask for what it needs first. A skill should include a prerequisite-gathering phase where the AI identifies gaps in its knowledge before producing anything.
Write me a proposal for the client meeting.
Before writing the proposal, ask me: (1) Who is the client? (2) What's the meeting agenda? (3) What's our goal — close, inform, or explore? (4) Any budget constraints? (5) What did we discuss last time? Then write the proposal.
When you front-load prerequisite gathering, two things happen. First, the AI produces dramatically better output because it's working from complete information instead of guessing. Second, you think more clearly about the task — the act of answering the AI's questions forces you to articulate what you actually want.
AI stops guessing and starts working from real data.
Get it right the first time instead of correcting through 5 rounds.
Anyone can run the skill because it asks for what it needs.
Answering the AI's questions clarifies your own intent.
I have this AI skill/prompt that I use regularly: [Paste your existing skill or prompt here] Rewrite it so that BEFORE producing any output, it: 1. Lists the information it needs to do the task well 2. Asks me to provide each piece of missing information 3. Only proceeds to output after all prerequisites are gathered 4. Uses reasonable defaults where I don't have an answer (and tells me what it assumed) Keep the same output quality but make it self-sufficient — it should never have to guess.
"A skill that asks the right questions before starting will outperform a skill with a better prompt that guesses at the answers."
Three ways to interact with AI — and how to pick the right one for each task.
Not every task belongs in a chat window. The interface you choose determines what's possible, how reliable it is, and how much effort it takes to maintain. Here's the decision framework:
Exploration, brainstorming, one-off tasks, learning. You're in the loop for every step.
Recurring tasks, scheduled workflows, MCP connections. Runs without you once set up.
Complex logic, custom data processing, high-volume operations. Maximum control.
Most people jump straight to code. Don't. The sweet spot for 90% of business tasks is chat to prove the concept, then integrations to automate it. Code is the exception, not the rule.
"If you're writing code to send a Slack message when an email arrives, you've over-engineered it. That's a three-click integration."
When one agent isn't enough — and when it absolutely is.
Multi-agent systems sound impressive, but most of the time a single well-prompted agent handles the job. The question isn't "should I use multi-agent?" — it's "does this task have distinct phases that benefit from specialization?"
Different inputs need different specialists. A triage agent sends work to the right handler.
Sequential steps where each agent's output feeds the next. Research → Draft → Review.
Multiple agents process different chunks simultaneously. Batch analysis at scale.
The most practical multi-agent pattern is the router: one agent reads the incoming request, classifies it, and routes it to the right specialist. This is how you build systems that handle diverse inputs without a single monolithic prompt trying to do everything.
A scheduler is just a router that runs on a clock. Instead of reacting to inputs, it fires at set intervals — daily briefings, weekly reports, hourly monitoring. You already have this in Claude: Schedule lets you set recurring tasks. Combine it with a routing skill and you have a lightweight multi-agent system without writing a line of code.
Help me design a router agent for my workflow. Here are the types of tasks I handle regularly: 1. [Task type 1 — e.g., "Customer support emails"] 2. [Task type 2 — e.g., "Internal status reports"] 3. [Task type 3 — e.g., "Data analysis requests"] For each task type, create a specialist skill with: - Role and context specific to that task - Prerequisites it should gather - Output format Then create a router prompt that: - Reads the incoming request - Classifies it into one of the task types - Routes it to the right specialist skill - Handles edge cases (unclear requests, multi-type requests)
"Don't build a multi-agent system because it sounds cool. Build one because a single agent can't maintain quality across all the steps. That bar is higher than most people think."
How to evaluate, test, and safely use skills created by other people.
As skill packs become more common, you'll encounter public skills shared by communities, marketplaces, and colleagues. A skill is just structured text — it can't execute code on its own. But a poorly written or malicious skill can instruct the AI to take harmful actions if you're not careful.
Always read the full instruction set. If you can't understand what it does, don't use it.
What actions does it request? Does it need write access, API calls, or file system access?
Test in a safe environment with dummy data before using on real work.
Never grant write permissions to a skill you haven't reviewed. Start read-only.
"Treat public skills like you'd treat any third-party code: read, review, sandbox, then trust. In that order."
The most important principle of all: complexity is the enemy of reliability.
Every layer you add — another agent, another integration, another branching condition — is another thing that can break. The best AI systems are the ones that are embarrassingly simple. One skill, one task, one output format. Chain them together when you need to, but keep each piece atomic.
A 12-step workflow with 3 agents, 2 API calls, conditional branching, error retry loops, and a fallback chain that emails you when something fails.
One skill that does the job. A second skill that checks the output. A cron schedule that runs them daily. Done.
From the session: students who built complex multi-step automations and then simplified them to two or three core skills that actually ran reliably. The pattern was always the same — start ambitious, simplify ruthlessly, end up with something that works every day without attention.
Started as a 7-step workflow. Ended as one skill: "Classify and summarize my inbox." Runs daily at 7 AM.
Started as a multi-agent pipeline. Ended as one skill with prerequisite gathering. Takes 2 minutes.
Started as an n8n workflow with 4 nodes. Ended as a Dispatch message: "Prep me for my 2 PM."
"The goal isn't the most sophisticated system. The goal is the system you actually use every day. Those are always simpler than you think."
"Week 1 you learned to talk to AI. Week 2 you learned to use it. Week 3 you connected it to everything. Week 4 you learned to build systems that stay built. That's the complete toolkit."
Real questions from the live office hours — practical answers you can use today.
Convert your prompts to skills, run the drift audit, and start your personal skill pack. Everything you need is in the homework above.