Level 2 · Advanced
Examples:
Aexagon · Learning Program · Level 2

Build your
system.

You know how to prompt.
Now stop starting from zero.

The three levels

Beginner: use Claude.

Advanced: build the system that uses Claude for you.

Master: run an operation on it and teach your team to do the same.

Graduated from Beginner? Good. Start here.

4 Layers refresher

Every strong prompt still has four layers, written in order: Objective (one sentence, the win), Context (the world, who you are, who Claude is), Output (the shape), and Workflow (the steps, when the path matters). Guardrails sit at the bottom, always on. Level 2 does not re-teach this. If it's rusty, read the full breakdown in Beginner · The 4 Layers, then come back. Everything here assumes you already write in 4 Layers by default.

Part 1 · Memory & Skills

Stop repeating yourself.

Every prompt you write twice is a system you haven't built yet.
Skills hold your playbooks. Memory holds who you are. Together they mean Claude shows up already knowing the job.

Part 1 · Module 1 Skills

From Prompt to Skill

Turn your best repeated prompt into a skill Claude applies automatically, forever. A skill is a playbook Claude loads only when the job matches. You stop pasting the same instructions every time.

You'll learn
  • What a skill actually is: a playbook loaded only when the job matches
  • The anatomy: a "use when" description plus a body with your rules
  • How to extract a skill from work you already repeat
  • When NOT to make a skill
You'll practice
  • Promote one reused Prompt Lab prompt into a named skill
  • Test it fires on the right task and stays quiet on the wrong one
  • Write the "use when" line so it triggers cleanly
Teardown · a real skill

Here's the live specimen: a small skill called "craft" that keeps output specific instead of generic. Two parts. First the trigger line, the "use when" that decides if Claude loads it at all:

Use when producing any output for a person (writing, content, scripts, code, analysis, plans, emails, messages, replies) before delivering it, and when a session grows long.

Then the body: the actual rules. Three of them, lifted straight from the skill:

  • · Take a point of view. No hedging. Commit to a recommendation and say why.
  • · Specific over vague. Replace adjectives with numbers and named tradeoffs. "Fast" becomes "200ms."
  • · Earn every sentence. If a line can be deleted without losing meaning, delete it.

That's the whole shape. A trigger that decides when, a body that decides how. Your skills look the same.

When NOT to make a skill

A skill is for a job you do the same way every time. If you've done something once, it's a prompt. If the rules change every time you run it, it's a prompt. Don't skill-ify a one-off. You'll spend more time writing the playbook than you'll ever save.

Sample prompt · promote a weekly client-update into a skill
OBJECTIVE Turn my weekly client-update prompt into a named skill Claude applies whenever I ask for a client update. CONTEXT I send every client a short weekly progress update. Same structure every time: what shipped, what's next, what I need from them. I've been pasting the instructions each week. I want it saved as a skill. OUTPUT A skill in two parts. A "use when" trigger line that fires on "write a client update" or "weekly update for [client]." A body with my structure and rules. WORKFLOW Draft the trigger line first. Then the body. Then show me one test case where it should fire and one where it should stay quiet. GUARDRAILS No em-dashes. Plain sections, no filler. Keep the body under 15 lines.
Sample prompt · build a listing-description skill
OBJECTIVE Build a listing-description skill Claude applies every time I ask for a listing writeup. CONTEXT I write listing descriptions constantly and they all follow my rules: lifestyle-first opening, never leads with square footage, one clear CTA. I keep repeating this. Save it as a skill. OUTPUT A skill in two parts. A "use when" trigger that fires on "write a listing description" or "listing copy for [address]." A body holding my rules: open with the lifestyle the home offers, never lead with square footage, ban the words "must-see" and "charming," end on exactly one CTA. WORKFLOW Before drafting any listing, the skill asks me 3 clarifying questions: who the buyer likely is, the one feature that sells the home, and the CTA I want. Then it writes. GUARDRAILS No em-dashes. No "must-see," no "charming." One CTA only. Never invent features I didn't give.
Part 1 · Module 2

Anti-Slop: Your Quality Bar

Name the difference between "reads fine" and "actually good," then make Claude hit the higher bar by default. Slop is the generic hedged average answer. It reads fine. That's exactly the problem.

You'll learn
  • Slop defined: the generic hedged average answer
  • The four anti-slop moves
  • How to build your own banned-phrase list
  • The delivery check and calibrating effort to stakes
You'll practice
  • Run your last three published pieces through the delivery check
  • Rewrite one of them
  • Save your banned list as a skill
The four anti-slop moves
  • · Take a point of view. No hedging. No "it depends" as an escape. Commit and say why.
  • · Specific over vague. Swap adjectives for numbers, named examples, real tradeoffs. "Better" means better than what, by how much.
  • · Cut clichés. "Unlock," "leverage," "seamless," "game-changer," "in today's fast-paced world." Banned on sight.
  • · Earn every sentence. If a line can be cut without losing meaning, cut it.
The delivery check

One question before anything ships: what would a sharp editor cut? Run it on your own draft. Then send the tightened version, not the first one. Match effort to stakes: a status ping gets a quick pass, a client deliverable gets the full check plus a read from the audience's side.

Sample prompt · de-slop a newsletter intro
OBJECTIVE Rewrite this company newsletter intro to cut every generic line and take a clear point of view. CONTEXT The current intro reads fine but says nothing. It hedges, it uses "excited to share" and "in today's landscape." Audience is customers who skim. I want them to actually keep reading. OUTPUT Two things. The rewritten intro, max 4 sentences. Then a short list of exactly what you cut and why. WORKFLOW Run the delivery check: flag every cliché and every vague claim first, then rewrite. Replace at least one vague claim with a concrete detail. GUARDRAILS No em-dashes. No "excited to," no "in today's." Take a position, don't hedge.
Sample prompt · strip the slop from a market-update email
OBJECTIVE Rewrite this market-update email so every vague claim becomes one real number. CONTEXT My draft leans on "the market remains dynamic" and "now is a great time." My audience is past clients in my farm area. They can smell filler. I have the real figures: days on market, list-to-sale ratio, month-over-month inventory. OUTPUT The rewritten email. Then a list of every vague claim you replaced and the number you put in its place. WORKFLOW First flag every phrase that says nothing. Then replace each one with a specific figure from the data I give you. If a claim has no number to back it, cut the claim. GUARDRAILS No em-dashes. Ban "dynamic," "great time to," "hot market." No number I didn't give you.
Part 1 · Module 3

Claude Memory

Stop telling Claude who you are every single chat. Memory follows you everywhere: every conversation, no Project required. Store the durable facts once and the Context layer starts writing itself.

You'll learn
  • Memory vs Project vs system prompt: memory follows you everywhere
  • What's worth remembering: voice, role, non-negotiables
  • What to keep OUT: client-confidential, fast-changing facts
  • How memory, skills, and Projects stack
You'll practice
  • Ask Claude what it already remembers about you
  • Correct anything wrong or stale
  • Add three durable facts, then run the memory audit
Memory vs Project vs system prompt
  • Memory · follows you into every chat, anywhere. Best for who you are.
  • Project · lives inside one Project. Best for one kind of recurring job.
  • System prompt · shapes one Project or one session. Best for behavior in a lane.

Keep out anything client-confidential or fast-changing. Memory is durable storage. A deal that closes next week does not belong there.

Sample prompt · store role, voice, and team
OBJECTIVE Save three durable facts about me to memory so I stop repeating them every chat. CONTEXT You keep asking who I am. I'm the founder of a small consulting firm. My voice is direct, no jargon. My team is Maya (ops) and Devin (design). OUTPUT Confirm exactly what you'll store, in three lines: my role, my voice rules, my team names. Then tell me anything you were storing before that I should correct. WORKFLOW First show me what you currently remember about me. I'll correct it. Then add these three. GUARDRAILS No em-dashes. Don't store anything client-confidential or anything that changes week to week.
Sample prompt · make the Context layer semi-automatic
OBJECTIVE Save my durable business facts to memory so my Context layer writes itself. CONTEXT Every prompt I start by re-typing the same background. I want it remembered: my farm area is [neighborhood], my average price point is [range], my brokerage is [name], and I mentor newer agents. OUTPUT Confirm the four facts you'll store, one line each. Then note anything stale you were already holding. WORKFLOW Show me what you remember now. I'll correct it. Then store these four so I don't have to write my Context layer from scratch again. GUARDRAILS No em-dashes. Keep out anything about active clients or open deals. Farm area and price point only, not addresses.
Part 2 · Projects & Context

Give Claude a workspace, not a folder.

A Project can be a briefed operator that produces on-brand work first try.
And a long session can stay sharp instead of going foggy. This part is about the environment Claude works inside.

Part 2 · Module 4 Projects

Projects Mastery

Turn a Project from a folder into a fully briefed workspace that produces on-brand work on the first try. The difference between a Project that helps and one that nails it is what you put in the knowledge and the system prompt.

You'll learn
  • Project knowledge done right: what to upload, what to leave out, keeping it current
  • System prompts that hold voice AND process
  • One Project per job
  • Layering conflicts: who wins between Project prompt, skill, and memory
You'll practice
  • Rebuild your "My Content" Project as an operating workspace
  • Judge first-draft quality on a real task
  • Refresh the knowledge as your business changes
Who wins when they conflict

When a Project prompt, a skill, and memory disagree, the most specific instruction to the task wins. A Project system prompt beats general memory inside that Project. An explicit instruction in your message beats them all. Don't let three sources quietly contradict each other. Keep each one in its lane.

Sample system prompt · a content engine Project
OBJECTIVE You are the content engine for [my business], run inside this Project. CONTEXT I'm an expert business owner. Audience is prospects and past customers. My voice is direct, warm, no jargon. Project knowledge holds my bio, my offers, my real case studies and numbers. OUTPUT Default to markdown. When I ask for content, produce it ready to publish, not an outline, unless I ask for structure. WORKFLOW Anchor every piece on something in Project knowledge, a real case study or a real number. If the knowledge doesn't cover it, ask before inventing. GUARDRAILS No em-dashes. No corporate filler. Never promise a result I can't back. Never invent a stat.
Sample system prompt · the "Listing Machine" Project
OBJECTIVE You are the Listing Machine for [my name], run inside this Project. CONTEXT I'm a real estate agent and team lead. Audience is buyers and sellers in my farm area. My voice is warm and direct. Project knowledge holds my market numbers, my past listings, and my brand guide. OUTPUT When I ask for listing content, lead with the buyer's lifestyle, then the home, then the proof. Markdown by default. WORKFLOW Anchor every claim on a number from Project knowledge. If I ask for something the knowledge doesn't support, ask before writing. GUARDRAILS No em-dashes. Never promise a sale price. Ban "must-see" and "charming." No stat that isn't in Project knowledge.
Part 2 · Module 5

Context Management

Keep long sessions sharp instead of foggy, and never lose work to a dead chat. Long conversations degrade: important details drift as the window fills. This is context rot. The fix is the handoff move.

You'll learn
  • Why long chats degrade, in plain English, and how to spot the moment
  • The handoff move: goal, decisions, done, left, gotchas
  • Fresh chat vs keep going
  • Offloading heavy reading and writing durable things to files
You'll practice
  • Take a sprawling open chat and generate a handoff note
  • Restart clean in a fresh conversation
  • Feel the difference in the first answer
Spotting the moment

When a chat starts feeling long or sluggish, or Claude starts mixing up details you settled earlier, that's your cue. Don't wait until it forgets. Hand off early, not late.

The three handoff prompts · copy and paste these

Use them at any natural stopping point in a long chat. These work for any kind of work, so there's no General or Real estate version here.

1 · Save a handoff note
Write a handoff note I can paste into a new chat to continue this work. Include: the goal, key decisions we made and why, what's done and verified, what's left to do, and any gotchas. Keep it clear and concise.

Do this first. Save the result somewhere you can find it again.

2 · Start a fresh chat
Open a new conversation. Then paste your handoff note from step 1, followed by: "Here's where we left off — please pick up from here."

A clean chat means faster, sharper answers.

3 · Or keep going in the same chat
Summarize everything important so far — the goal, decisions, and what's left — then continue. Drop the rest to keep things focused.

Use this when you'd rather not switch chats.

Example · handing off a long project thread
OBJECTIVE Write a handoff note for this project thread so I can restart clean and lose nothing. CONTEXT We've been in this chat for two hours planning a product launch. Lots of decisions, some reversed. It's getting slow and you're starting to mix up which version we chose. OUTPUT Five short sections: the goal, decisions we locked and why, what's done, what's left, gotchas to watch. GUARDRAILS No em-dashes. Only include decisions we actually settled, not options we discussed and dropped.
Example · handing off a 40-message deal chat
OBJECTIVE Write a handoff note for this deal chat before it gets any more confused. CONTEXT This is a 40-message thread on an active deal. It's started swapping the buyers' names and I don't trust it to keep the details straight anymore. OUTPUT Four sections: parties (get every name right), key dates, contingencies still open, next steps with owners. GUARDRAILS No em-dashes. Double-check every name and date against what I actually said. If a detail is unclear, flag it instead of guessing.
Part 2 · Module 6

Verification Habits

Make "never ship an unchecked number" a system, not a hope. Every factual claim you send under your name is a bet on your reputation. Build the check into how you work so you can't forget it.

You'll learn
  • The verification ladder: what needs a source, a second read, or nothing
  • Cite-or-mark-[unverified] as a default
  • The adversarial read: "argue against this draft before I send it"
  • Baking verification into skills
You'll practice
  • Force a research output to cite every factual claim
  • Verify the three that would embarrass you if wrong
  • Add "cite or mark [unverified]" to your research skill
The verification ladder
  • Needs a source · any number, date, or claim about the outside world.
  • Needs a second read · anything that would embarrass you if it's slightly off.
  • Needs nothing · your own opinion, your own voice, your own recommendation.

No vibes in a client-facing number. If it can't be sourced, it ships marked [unverified] or it doesn't ship.

Sample prompt · verify stats in a report summary
OBJECTIVE Summarize this industry report and cite a source for every factual claim. CONTEXT I'm going to quote this summary in a talk. If a number is wrong, it's my name on it. The report is attached. OUTPUT The summary, then a claims table: each stat, the source line from the report, and a confidence flag. WORKFLOW For every number or claim, point to where it appears in the report. If it isn't in the report, mark it [unverified]. Then tell me the three claims most worth me double-checking. GUARDRAILS No em-dashes. Don't infer numbers. Don't round in a way that changes the meaning.
Sample prompt · source every claim in a "why sell now" note
OBJECTIVE Draft a "why now is a good time to sell" note and source every claim to MLS data. CONTEXT This goes to sellers on the fence in my farm area. It has to hold up. I've attached the current MLS pull: days on market, inventory, list-to-sale ratio. OUTPUT The note, then a claims table: each claim, the MLS figure behind it, and whether it's a fact or my inference. WORKFLOW Tie every number to the MLS data I gave you. Flag anything that's an inference, not a fact. Mark anything you can't source [unverified]. GUARDRAILS No em-dashes. No vibes in a client-facing number. Never invent a market stat.
Part 3 · Automation & Delegation

Let Claude run the work.

Connectors go from connecting tools to orchestrating them.
Delegation lets Claude do more while you stay the one accountable. Then you wire it all into one system you run your week on.

Part 3 · Module 7 Connectors

Connectors as a Power Tool

Go from connecting tools to orchestrating them, and know exactly where the guardrails are. One instruction can chain four tools. Read-only vs write is a permission strategy, not a first-day rule you obey forever.

You'll learn
  • Chaining connectors in one instruction
  • Read vs write as a permission strategy, not a first-day rule
  • Parallel pulls: Claude reads four tools at once, just ask
  • Scheduled and triggered work, and where a human decision begins
You'll practice
  • Map one recurring multi-tool workflow
  • Write the single instruction that runs it
  • Run it read-only first, then decide what earns write access
Where the connector stops

A connector can read four tools, cross-reference them, and draft the next move in seconds. What it should not do is make the call that only you can own: sending the thing, committing the money, telling the client. Chain the reads. Hold the writes for a decision. That line is the whole strategy.

Sample prompt · a weekly ops digest across four tools
OBJECTIVE Build my weekly ops digest by pulling email, calendar, tasks, and chat in one pass. CONTEXT I run a small team. Every Friday I want one page: what moved, what's stuck, what needs me Monday. Sources are Gmail, Google Calendar, my task tool, and Slack. OUTPUT Markdown, four sections: shipped this week, overdue or stuck, next week's calendar with prep needed, top 3 things that need my decision. WORKFLOW Read all four tools in parallel. Cross-reference: if a calendar item has a related task, flag it. Read-only. Draft nothing, send nothing. GUARDRAILS No em-dashes. Skip newsletters and low-signal channels. Don't take any action, just surface.
Sample prompt · a "new lead" instruction across four tools
OBJECTIVE When I forward a new lead, run it across my CRM, Gmail, Calendar, and Slack in one instruction. CONTEXT I'm a real estate agent. Every new lead should get logged, get a first touch, get a follow-up scheduled, and get flagged to my team. Right now I do all four by hand. OUTPUT A summary of four actions: the CRM record created, the first-touch email drafted in Gmail, a 3-day follow-up added to Calendar, a note posted in team Slack. WORKFLOW Log the lead in the CRM. Draft the first-touch email but hold it for my approval. Add the follow-up to Calendar. Post the team note. Every draft waits for me before it sends. GUARDRAILS No em-dashes. Nothing goes out without my approval. Never message the lead directly without me.
Part 3 · Module 8

Delegation & Review Gates

Let Claude do more while you stay the one accountable for what ships. You met the trust ladder in Beginner. This is the operator version: assign each recurring task a rung, write it down, and build the queue that lets you approve a week's work in one sitting.

You'll learn
  • The trust ladder as a personal operating policy
  • Designing a review queue: Claude drafts all week, you approve in one sitting
  • Assigning each recurring task a rung, in writing
  • The weekly spot-check discipline, and why rung 4 is rare
You'll practice
  • Assign trust rungs to three recurring tasks, with reasons
  • Stand up a real draft-and-approve queue for one of them
  • Run it for a week and audit what shipped
The trust ladder, operator version
  1. Read-only. Claude pulls and surfaces. You do all writes.
  2. Draft plus approve. Claude writes, you review every output before it ships.
  3. Spot-check. Claude ships routine items. You audit weekly.
  4. Autopilot. Low-risk, high-frequency only. With logging.

Rung 4 is rare, and it's earned: a task proves itself at rung 3 for weeks before it graduates. Never start a new workflow above rung 1.

Example · rungs for three recurring tasks
  • Invoices · rung 2, draft plus approve. Money leaves the building, so I read every one before it sends.
  • Social replies · rung 3, spot-check. Low stakes, high volume. Claude ships routine ones, I audit the week on Friday.
  • Contracts · rung 1, read-only, never higher. Claude can summarize and flag, but no contract language ships without me writing it.
Example · rungs for three recurring tasks
  • Lead follow-up · rung 2, draft plus approve. Every re-engagement email is written by Claude and read by me before it goes.
  • Routine captions · rung 3, spot-check with a Friday audit. High volume, low risk. Claude ships them, I review the batch weekly.
  • Contract language · rung 1, never leaves read-only. Claude summarizes and flags, but no contract wording ships without me.
Part 3 · Module 9

Capstone: Your Personal Operating System

Wire memory, skills, a Project, and a review queue into one system you run your week on. This is where the eight modules become a single setup. Run a real week on it, measure the hours saved, and write the one-page doc.

You'll learn
  • How to assemble a1 through a8 into one setup
  • Documenting what lives where
  • Defining a trust rung per recurring task
  • Writing the one-page "how my system works" doc
You'll practice
  • Stand up the full system
  • Run your real week on it
  • Tally the hours saved and note where it broke
The one-page doc

Write down what lives where: which facts are in memory, which playbooks are skills, which job each Project owns, and the trust rung for every recurring task. This doc is not busywork. It becomes your Level 3 teaching kit, the thing you hand your team when you start running an operation on top of it.

Example · a consultant's operating system
  • Memory · role, voice rules, team names. Loaded into every chat.
  • Content Project · bio, offers, case studies in knowledge. Owns all published writing.
  • Proposal skill · fires on "write a proposal." Holds structure and pricing rules.
  • Inbox queue · rung 2. Claude drafts replies all week, I approve Monday morning in one pass.
Example · the agent's brand and business OS
  • Memory · farm area, price point, brokerage, and "I mentor newer agents." Loaded everywhere.
  • Content Project · market numbers, past listings, brand guide in knowledge. Owns my personal brand output.
  • Listing skill · fires on listing requests. Lifestyle-first, one CTA, banned words enforced.
  • Lead queue · rung 2, draft plus approve. Claude writes every follow-up, I approve the batch daily.
Reference

New words

Only the terms that are new at this level. Everything from Beginner still holds. For the rest, see the full glossary in Level 1.

Skill (authoring)

Writing your own playbook so Claude does a repeated job your way, automatically. Two parts: a "use when" trigger line that decides when Claude loads it, and a body holding your rules. You met skills as a concept in Beginner. Here you build them.

Memory

Durable facts Claude keeps about you across every conversation, no Project required. Store who you are, your voice, your non-negotiables. Keep out anything confidential or fast-changing. Memory follows you everywhere; a Project stays in its lane.

Context rot

The quality drop in a long conversation as the window fills with noise. Details drift, Claude mixes things up, answers get vaguer. Not a bug, just how long chats behave. The fix is the handoff move: save what matters, restart clean.

Handoff note

A short summary you generate before starting a fresh chat: the goal, the decisions and why, what's done, what's left, the gotchas. Paste it into a new conversation and pick up sharp instead of tired. Do it early, not late.

Review queue

A pattern where Claude drafts work all week and you approve it in one sitting. Instead of stopping to review each item as it appears, you batch the approvals. Turns a stream of interruptions into a single scheduled pass.

Scheduled task

Work that runs on a clock or a trigger instead of when you ask. A Friday digest that builds itself, a "new lead" instruction that fires when one arrives. The automation handles the trigger; you handle the decision at the end.

Subagent

A separate helper Claude spins up to do heavy work without cluttering your main chat. "Go read these files and report back" keeps the reading out of your window so your session stays clean. You get the conclusion, not the pile.

Next level

Finished Level 2?

You built the system that uses Claude for you. Level 3 is where you run an operation on it and teach your team to do the same.

Level 3 · Master →