You are going to ship something your team actually uses.

Setup and first contact

Get the app open, understand what you are actually talking to, and have it build your workspace for you.

The one idea that makes everything else make sense

You already ran the loop up top, in the demo. That is the entire product. Everything below is you doing that same four-step move on real work.

Claude Code is not a chat window. It is an agent with hands inside a folder. It can read the files in that folder, write new ones, change existing ones, run things, and reach out to tools you connect. When you ask it something, it does not just answer. It goes and does.

That is the whole difference. Chat gives you words back. This gives you files, pages, and jobs that run. It also means you want to be deliberate about which folder you point it at, which is why your entire first hour happens in a sandbox folder where nothing matters.

Install and open it

1. Download the Claude desktop app for Mac from claude.ai/download and run the installer. No terminal, no developer setup.
2. Sign in with your Workweek Anthropic account.
3. Click the Code tab. Chat and Code are different rooms in the same house. You want Code.
4. It will ask what you want to work on. Choose Local, then create and select a new folder in your home directory called becca-lab.
5. Leave the model on the default, and leave permission mode on Manual.

Permission modes, in plain language

This is the control that decides how much rope it has. There are four you will see:

You will spend this entire course in Manual except where a segment tells you otherwise. Manual is slower and that is fine. Watching it ask permission is how you learn what it is actually doing.

Build your workspace

Your first real prompt sets up everything the rest of the course needs. You are not going to create these files by hand. You are going to watch Claude create them, approve each step, and get your first feel for the loop.

Paste this in exactly as written.

You are setting up a training workspace for me. I am new to Claude Code and I work in
newsletter and podcast production operations at a media company. Create the following
inside this folder, exactly as specified. Explain each file in one line as you create it.

Create this structure:

  README.md
  CLAUDE.md
  progress.md
  data/sample-deliverables.csv
  data/sample-brief.md
  data/test-copy.md
  work/.keep

Contents:

1. README.md - a short orientation page. What this folder is (a training sandbox),
   what lives in each subfolder, and a one-line note that nothing here is connected
   to any production system.

2. CLAUDE.md - standing instructions for you whenever I work in this folder. Include:
   - Who I am: I run content and A/V production for a media company. Not an engineer.
   - Explain what you are about to do before you do it, in plain language.
   - When I ask for something with more than two steps, propose a plan first.
   - No jargon without a one-line definition the first time you use it.
   - Writing style for anything you draft for me: plain and brief, active voice,
     no em dashes or en dashes, no "isn't X, it's Y" constructions, and avoid the
     words: leverage, robust, seamless, delve, elevate, unlock, supercharge, holistic.

3. progress.md - a training log. Give it a title, a one-line explanation that graders
   append to it, and a markdown table with columns: Gate | Date | Result | Notes.
   Leave the table empty apart from the header row.

4. data/sample-deliverables.csv - 40 rows of realistic fake production deliverables.
   Columns: deliverable_id, brand, type, title, owner, due_date, status, days_late.
   Use brands: Hospitalogy, Fintech Takes, I Hate It Here, Marketingland, Go To Millions.
   Use types: newsletter_ad, branded_content, podcast_ad, virtual_event, social.
   Use statuses: not_started, brief_sent, copy_ready, approved, live, missed.
   Dates spread across the last 60 days. Some rows should be late, a few very late.
   Make the data realistic, including a couple of rows with a blank owner and one
   with a malformed date, because real exports are messy.

5. data/sample-brief.md - a deliberately messy creative brief for a newsletter ad.
   It should be the kind of thing a stressed person writes at 11pm: no headings,
   run-on paragraphs, the client name mentioned three different ways, the due date
   buried mid-sentence, two contradictory instructions about tone, and a list of
   assets that is half in prose and half in a broken bullet list.

6. data/test-copy.md - about 200 words of draft ad copy for a fictional sponsor.
   It must deliberately contain, without labelling them: at least three em dashes,
   at least four of the banned words listed in CLAUDE.md, at least two
   "it isn't X, it's Y" constructions, and one paragraph in passive voice.
   Do not mark or comment on these. They are planted for a later exercise.

7. work/.keep - an empty placeholder file.

Do not create anything else. When you are done, show me the file tree.

You will be asked to approve each file. Read what it is about to write before you approve it. That habit is worth more than anything else in this course.

Act as my training grader for Gate 00. Be strict and check evidence, not my claims.

Check these criteria against the actual files in this folder:
1. These exact paths exist: README.md, CLAUDE.md, progress.md,
   data/sample-deliverables.csv, data/sample-brief.md, data/test-copy.md, work/.keep
2. sample-deliverables.csv has a header plus 40 data rows, with columns
   deliverable_id, brand, type, title, owner, due_date, status, days_late
3. CLAUDE.md contains writing style rules including a banned word list
4. data/test-copy.md contains at least 3 em dashes AND at least 4 banned words
   from the CLAUDE.md list. Count them and show me the counts.

Then ask me one question: "In one sentence, what does Manual permission mode do?"
Wait for my answer. Accept it only if it conveys that Claude asks before changing
files or running commands.

Output format:
- One line per criterion: PASS or NOT YET, with the evidence you found
- Then an overall verdict: PASS or NOT YET
- If NOT YET, give me the exact fix for each miss, and stop
- If PASS, append a row to progress.md: | Gate 00 | (today's date) | PASS | (short note) |

How to talk to it

Most people plateau in week one for three reasons. All three are fixable in the next 45 minutes.

The three mistakes

One: under-briefing. "Clean this up" gets you a coin flip. You already know how to brief, because you brief creators and CMMs constantly. Use the same shape.

Try it on something small. Write a real instruction below, the kind you would actually send, and watch the four parts light up as your words cover them. Four green is a brief that will not come back to you with questions.

Two: one endless conversation. A session carries everything you have said so far. That is useful until it is not, when old context starts steering new work in the wrong direction. Three commands manage this:

• /context shows you how full the session is.
• /compact summarizes the conversation so far and keeps going. Use it mid-task when things are getting long but still related.
• /clear starts fresh. Use it whenever you switch to an unrelated task. This is the single most underused command.

Three: letting it act before it has a plan. /plan puts it in a mode where it investigates and proposes but changes nothing. You read the plan, you push back, and only then does it build. For anything with more than two steps, plan first. Every hour you spend in plan mode saves you two of untangling.

Build: rescue the 11pm brief

Open data/sample-brief.md and read it first. Really read it. You need to know what good looks like before you can judge the output.

First, switch to plan mode and do not change any files yet.

GOAL: turn data/sample-brief.md into a brief a community marketing manager could
act on tomorrow morning without coming back to me with questions.

INPUT: data/sample-brief.md only. Do not invent facts that are not in it.

CONSTRAINTS:
- One page. Clear headings. Scannable.
- Follow the writing rules in CLAUDE.md.
- Anything the original is ambiguous or contradictory about goes into an
  "Open questions" section at the bottom. Do not resolve it yourself.

DONE LOOKS LIKE: I can read it in 60 seconds and know what to produce, for whom,
by when, and what is still unresolved.

Show me your plan first. Tell me specifically what you found that is contradictory
or missing before you write anything.

Read the plan. If it did not flag the contradictory tone instruction or the buried due date, say so and make it look again. Then approve, and let it write to work/brief-v1.md.

Now do it a second time with a real messy brief of your own. That is where the value actually is.

Act as my training grader for Gate 01. Be strict. Check evidence, not my claims.

Read data/sample-brief.md and work/brief-v1.md, then check:
1. work/brief-v1.md exists and is under 400 words
2. It contains an "Open questions" section with 2 or more items
3. Every factual claim in it traces back to something in sample-brief.md.
   List any claim you cannot trace. Any untraceable claim is a fail.
4. It violates none of the writing rules in CLAUDE.md. Check specifically for
   em dashes and the banned word list. Show counts.
5. The two ambiguities the source deliberately contains (contradictory tone
   instruction, and a due date buried in prose) are both surfaced rather than
   silently resolved.

Then ask me: "Paste the first two lines of the plan Claude showed you before it
wrote the file." Accept only if it reads as a plan proposal, not as finished output.

Output format:
- One line per criterion: PASS or NOT YET with your evidence
- Overall verdict
- If NOT YET, the exact fix for each miss, then stop
- If PASS, append a row to progress.md: | Gate 01 | (today's date) | PASS | (note) |

Build something visible

Enough theory. You are going to make a working tool, put it on the internet, and send someone the link.

What you are building

A creative brief builder. Someone fills in a handful of fields, and it produces a properly formatted brief they can copy straight into Slack or Notion. It replaces the part of your week where people send you half-briefs and you send them back.

If a different tool would be more useful to you, build that instead. A launch checklist, an episode run of show, a sponsor recap generator. The requirements in the gate work for any of them.

Two things to understand first

A self-contained page. Claude will build this as a single HTML file, which is a whole working web page in one document: layout, styling, and behavior all in one. It needs nothing installed and nothing running. That is what makes it shareable.

Artifacts. Claude Code can publish a page to a private URL on claude.ai. You get a link. You press Share to let other people open it. When you change the page and publish again, the same link updates, so you never have to resend it.

Plan first, then build after I approve.

GOAL: a single self-contained HTML tool called work/brief-builder.html that turns a
short form into a formatted creative brief my team can paste into Slack or Notion.

FIELDS: brand (Hospitalogy, Fintech Takes, I Hate It Here, Marketingland, Go To Millions),
deliverable type (newsletter ad, branded content, podcast ad, virtual event, social),
sponsor name, the one thing this needs to accomplish, audience, key message,
must-include claims, things we cannot say, assets provided, due date, owner.

BEHAVIOR:
- As I fill fields, a formatted brief builds live on the right, or below on a phone
- A "Copy brief" button puts the formatted text on my clipboard as clean markdown
- If a required field is empty, the brief shows a clear "MISSING:" line for it
  rather than silently omitting it
- My entries persist if I reload the page

CONSTRAINTS:
- Everything in one file. No internet requests of any kind, no external fonts,
  no external scripts. It must work with no wifi.
- Must be usable on my phone
- Plain, professional look. Readable in both light and dark mode.

DONE LOOKS LIKE: I can produce a complete brief in under 60 seconds and paste it
into Slack without editing it.

After it works, publish it as an artifact and give me the link.

Then iterate, which is the actual skill

The first version will be about 80 percent right. Do not accept 80 percent. Use it as though you were a CMM in a hurry, find the three things that annoy you, and say them plainly:

• "The due date field lets me pick a date in the past. Stop that."
• "Copy brief gave me something with weird spacing when I pasted it into Slack. Fix the output format."
• "On my phone the form and the preview fight each other. The preview should go underneath."

Specific complaints get fixed. Vague ones ("make it better") get you a redesign you did not ask for.

Act as my training grader for Gate 02. Be strict. Check the file, not my description.

Read work/brief-builder.html and check:
1. It is a single file with no external requests. Search for src=, href=, @import,
   fetch(, XMLHttpRequest, and any http:// or https:// URL that loads a resource.
   List everything you find. Any external resource load is a fail.
2. It has responsive handling for small screens (a media query or a layout that
   reflows). Quote the relevant CSS.
3. Empty required fields produce a visible MISSING indicator. Quote the code that
   does it. If required fields are silently skipped, that is a fail.
4. It persists entries across reload (localStorage or equivalent). Quote the code.

Then ask me these two questions and wait for answers:
- "Paste the artifact URL."
- "Who did you send it to, and did they open it on a phone or a laptop?"

Reject a URL that is not a claude.ai artifact link.

Output format:
- One line per criterion: PASS or NOT YET with evidence
- Overall verdict
- If NOT YET, the exact fix for each miss, then stop
- If PASS, append a row to progress.md: | Gate 02 | (today's date) | PASS | (note) |

Make it good

What you built works. It probably looks like everything else Claude builds. This segment is about the gap between working and good, and the vocabulary that closes it.

Why the default looks the way it does

When you do not specify a look, you get the average of everything. Rounded cards, a purple or blue accent, evenly weighted sections, decoration that means nothing. It is competent and forgettable. The fix is not more adjectives. It is describing the three things below.

Hierarchy

What should someone see first, second, third? Most weak pages give everything equal weight, so the eye has nowhere to land. Say it out loud: "The generated brief is the point. The form is a means to it. The brand picker is the least important thing on the page and is currently the biggest."

Density

How much should be on screen at once? A tool people use forty times a week should be tight and fast. A page someone reads once should breathe. Those are opposite choices and you have to pick.

Restraint

One accent color, used for the thing that matters most, and nowhere else. Everything else is neutral. If three things are highlighted, nothing is.

Claude Design

Claude Design is a separate Anthropic product, included with your plan, and it is not part of Claude Code. It is a canvas where you describe an interface and watch it render, and you push on the look until it is right. It gives you the design plus the underlying styling, and you hand that to Claude Code to implement for real.

The workflow is worth learning because it splits two jobs that fight each other when combined: deciding what it should look like, and making it work.

1. Open Claude Design and describe your tool: what it does, who uses it, and the hierarchy, density, and restraint calls you just made.
2. Iterate on the canvas until it looks right. This is fast, so push further than feels necessary.
3. Bring the design output back to Claude Code with the prompt below.

I designed a new look for my brief builder in Claude Design. I am pasting the design
output below.

Rebuild work/brief-builder.html as work/brief-builder-v2.html using this design.

RULES:
- Every feature of v1 must still work: live preview, copy button, MISSING indicators,
  persistence across reload
- Still one self-contained file, still no external requests, still works on a phone
- Match the design's spacing and type sizes, do not approximate them
- If something in the design cannot work as a real interface, tell me what and why
  instead of quietly changing it

Then show me, side by side in writing, what changed between v1 and v2 and why each
change makes the tool easier to use.

DESIGN OUTPUT:
[paste here]

Act as my training grader for Gate 03. Be strict and specific.

Read work/brief-builder.html and work/brief-builder-v2.html, then check:
1. Feature parity. List every interactive feature in v1 and confirm each exists in
   v2. Any dropped feature is a fail, name it.
2. v2 still makes zero external requests. Search for external URLs and list them.
3. Restraint. Extract every color used in v2. If more than one non-neutral accent
   hue is used for emphasis, that is a fail. Show me the list.
4. Hierarchy. Based on font sizes, weights, and position, tell me which element
   reads as most important in v2. State it plainly.
5. v2 has responsive handling. Quote it.

Then ask me: "In one sentence, what look were you going for, and what were you
moving away from?" Reject an answer that is only adjectives like clean or modern.
It must name a comparison, a feeling, or a specific thing it should not look like.

Output format:
- One line per criterion: PASS or NOT YET with evidence
- Overall verdict
- If NOT YET, the exact fix for each miss, then stop
- If PASS, append a row to progress.md: | Gate 03 | (today's date) | PASS | (note) |

Working with real data

A spreadsheet in, an answer out. Plus the single habit that will protect your reputation for the rest of your career with these tools.

The habit, stated first because it matters most

Claude will hand you a confident, well formatted, completely wrong number. It happens most often with counts, date filters, and anything involving blank cells. It will not hedge, because it is not aware it is wrong.

When you forward that number, your name is on it, not Claude's. So the rule is simple and it is not negotiable: before a number leaves your hands, verify it a second way.

Verifying a second way means arriving at the same number through a different path. Filter the spreadsheet by hand and count. Ask for the underlying rows and check three of them. Ask a second, differently phrased question that should produce a consistent answer. What does not count as verification is asking "are you sure?" and being told yes.

Feel it first

Here is a health check Claude might hand you. It looks finished. It is formatted. It has a recommendation. One line in it is quietly, dangerously wrong in a way that would get past most people. Find it before you scroll on. Click the line you would not forward without checking.

Build: read the deliverables export

Your sample file has real-world mess in it on purpose: blank owners, a malformed date, statuses that overlap. Start by making Claude tell you about the mess before it tells you anything else.

Read data/sample-deliverables.csv but do not analyze it yet.

Tell me only this:
- How many rows and columns
- The distinct values in every categorical column, with counts
- Every row with a blank, malformed, or impossible value, quoted exactly
- Anything ambiguous about how I should interpret a column

Then tell me which questions this data can answer reliably, and which it cannot.
Do not calculate anything else yet.

Read that carefully. This step is where you find out that "missed" and "days_late over 0" are not the same population, which is exactly the kind of thing that quietly ruins a number.

Now analyze data/sample-deliverables.csv.

QUESTIONS:
1. Late rate by brand, most to least. Define late explicitly and tell me your
   definition before the numbers.
2. Which deliverable type slips most, and by how many days on average
3. Which owners have the most late items, and how many items each owns in total,
   because volume changes what the number means
4. Anything in this data that surprises you

RULES:
- State every assumption and every exclusion before the results
- Say exactly how you handled the blank owners and the malformed date
- Do not drop rows silently. If you exclude something, name it.

Then build work/deliverables-report.html: a single self-contained page with the
findings and charts. No external requests. Readable on a phone. One accent color.
Charts should have real axis labels and readable values, not decoration.

Now verify, and write it down

Pick the headline number, the one you would actually put in a Slack message. Verify it a different way, then record it.

I am going to verify your headline number independently.

First, tell me the exact filter that produces it, in words precise enough that I
could apply it by hand in a spreadsheet.

Then list the raw rows that make up that number, so I can count them myself.

Then create work/verification.md containing:
- The number being verified
- Its definition, stated exactly
- The second method I used to check it
- What that second method produced
- Whether they matched, and if not, which one was wrong and why

Leave the "what I did and what it produced" parts blank for me to fill in myself.
Do not fill them in for me.

Act as my training grader for Gate 04. Be strict. This gate has a hard requirement
that most people fail, so do not be generous.

Check:
1. work/deliverables-report.html exists, makes zero external requests, and contains
   charts with axis labels and readable values. List any external URL you find.
2. The report states an explicit definition of "late" in its own text. Quote it.
   No stated definition is a fail.
3. The report states how blank owners and the malformed date row were handled.
   Quote it. Silent row dropping is a fail.
4. work/verification.md exists and has no blank or placeholder sections.
5. THE HARD ONE: read the second method described in verification.md. It must be a
   genuinely independent path to the number, such as filtering the CSV by hand,
   counting rows directly, or recomputing from raw data. If it amounts to asking
   Claude again, asking "are you sure", or restating the first method, mark this
   NOT YET and say plainly that re-asking a model is not verification.
6. Independently recompute the headline number yourself from the raw CSV. Say
   whether you agree with it. If you disagree, show your work and say so loudly.

Output format:
- One line per criterion: PASS or NOT YET with evidence
- Overall verdict
- If NOT YET, the exact fix for each miss, then stop
- If PASS, append a row to progress.md: | Gate 04 | (today's date) | PASS | (note) |

Make Claude yours

Everything so far you did by typing. Now you teach it your standards once, and stop repeating yourself. This is where people go from using the tool to building with it.

Three levels of teaching it

Personal versus project

A CLAUDE.md inside becca-lab applies only in that folder. One at ~/.claude/CLAUDE.md applies everywhere you work. Same split for skills. Because you want your copy standards to follow you everywhere, you are building this one personally.

Create or update my personal instructions file at ~/.claude/CLAUDE.md. If one already
exists, show me the current contents first and propose changes rather than overwriting.

It should say:
- I run content and A/V production at a media company. I am not an engineer.
  Explain things in plain language and define jargon the first time you use it.
- Propose a plan before doing anything with more than two steps.
- When you give me a number, tell me how you got it and what you excluded.
- Never invent a fact, a name, or a date. If you do not know, say so.
- Writing style for anything you draft that a person will read: plain, brief,
  active voice. No em dashes or en dashes. No "isn't X, it's Y" constructions.
  Never use: leverage, robust, seamless, delve, elevate, unlock, supercharge,
  holistic, utilize.

Show me the file when you are done and explain what will change about how you work
with me.

A slash command

A slash command is a prompt you saved. Instead of re-explaining the brief checklist every time, you type /brief-check and point it at a file.

Create a personal slash command called brief-check at
~/.claude/skills/brief-check/SKILL.md

It should take a file path as an argument and check that brief against this list,
returning a table of PASS or MISSING for each, then a short list of what to fix:

- Names one specific outcome, not a vague goal
- Names the audience
- Has a due date that is a real date, not "ASAP" or "end of month"
- Names an owner
- Lists must-include claims
- Lists anything we cannot say
- Lists the assets provided and who provides them
- Has no open questions left implicit

End with a one-line verdict: "Ready to send" or "Send back to the requester".

Give the file proper frontmatter with a name, a description, and an argument hint.
Then explain to me how to run it and show me it working on data/sample-brief.md.

A skill, which is the real unlock

A skill encodes a judgement call. Yours will be a copy reviewer that applies your house style consistently, so a CMM gets the same review whether you looked at it or not.

Create a personal skill at ~/.claude/skills/copy-review/SKILL.md called copy-review.

WHAT IT DOES: reviews a piece of draft copy against our house style and returns
specific, line-referenced fixes. It is a reviewer, not a rewriter. It never
silently rewrites my copy.

IT MUST FLAG:
- Every em dash and en dash, quoted with its line
- Every use of: leverage, robust, seamless, delve, elevate, unlock, supercharge,
  holistic, utilize, in the weeds, at the end of the day
- Every "it isn't X, it's Y" or "not X, but Y" construction
- Passive voice where active would be shorter, quoted
- Any claim that sounds like a fact and would need a source
- Sentences over 30 words

OUTPUT FORMAT:
- A summary line: how many issues, by category
- A table: line, issue type, the offending text, the suggested fix
- Then, separately, a corrected version I can accept or reject as a whole

The frontmatter needs a name, a clear description of when to use it, and a
when_to_use line so you can pick it up automatically when I ask for a copy review.

After you create it, run it on data/test-copy.md and show me the output.

Here is a stripped-down, working version of the thing you just asked Claude to build, running right in this page. Paste in some copy, or use the planted sample, and see it flag the tells. Yours will be smarter, because it can read context and suggest fixes. This one just proves the idea is real.

Act as my training grader for Gate 05. Be strict, and actually run things.

Check:
1. ~/.claude/CLAUDE.md exists and contains the banned word list and the no-em-dash
   rule. Quote them.
2. ~/.claude/skills/brief-check/SKILL.md exists with valid YAML frontmatter
   containing at least name and description. Quote the frontmatter.
3. ~/.claude/skills/copy-review/SKILL.md exists with valid YAML frontmatter.
   Quote it.
4. THE REAL TEST: count independently, yourself, how many em dashes, banned words,
   and "isn't X, it's Y" constructions are in data/test-copy.md. Write down your
   counts. Then run the copy-review skill on data/test-copy.md and compare what it
   caught to your counts. It must catch at least 3 em dashes and at least 4 banned
   words. If it misses things you found, tell me exactly what it missed and that
   the skill needs tightening.
5. The skill's output includes a table with line references and keeps the corrected
   version separate from the review. A skill that just returns rewritten copy with
   no itemized review is a fail.

Output format:
- One line per criterion: PASS or NOT YET with evidence and your own counts
- Overall verdict
- If NOT YET, the exact fix for each miss, then stop
- If PASS, append a row to progress.md: | Gate 05 | (today's date) | PASS | (note) |

Connect the world

Up to now Claude has only seen files you gave it. Now it reaches into Slack and Notion. This is the segment with real consequences, so the safety part is graded.

What an API actually is

An API is a door into a system that is meant for software rather than people. Slack has a website you click, and a door programs use to ask the same questions. Same data, different entrance.

Four things are worth knowing, and then you can stop.

• A token is a key to that door. It proves who is asking and what they are allowed to do. Treat it exactly like a password. It goes in a settings file, never in a document, never in a Slack message, never in a screenshot.
• Permissions are per key. A read-only key cannot post, delete, or change anything, no matter what it is asked to do. That is not a preference, it is enforced on the other side of the door. It is your best safety tool.
• Rate limits exist. Every system caps how many questions you can ask per minute. Hitting the cap is normal and not a failure. It means the job needs to slow down or ask for less.
• Calls fail. Networks drop, keys expire, systems go down. Anything you build has to handle a failed call by saying so, not by silently producing an empty answer that looks like good news.

Touch it once, so it stops being magic

Ten minutes on this. It is worth it.

Teach me what an API call actually is, using a real one that needs no key.

1. Make one live request to a free public API that requires no authentication
   (for example a public holidays or timezone API). Show me the exact request.
2. Show me the raw response before you interpret it. I want to see what a computer
   sends back, ugly and all.
3. Explain the parts: the address, what I asked for, the status code, the body.
4. Now deliberately make a request that fails, and show me exactly what a failure
   looks like versus a success.
5. Finally, explain what would be different if this API needed a key, and where
   that key would live so it never ends up in a document.

Keep it under 300 words of explanation. Show me real output, not descriptions
of output.

Connect Slack and Notion

You do not manage tokens by hand for these. The desktop app has prebuilt connectors that handle the whole key exchange for you.

1. In the Claude Code desktop app, click the + and choose Connectors.
2. Add Slack. Sign in and approve the access when your browser opens.
3. Add Notion the same way.
4. Come back and ask Claude to list which connectors it can see. If one is missing, it did not connect, and it will not tell you unless you ask.

The question worth answering

This is the actual thing: which committed work has gone quiet. It is the question you cannot answer today without opening four places.

Read only. Do not post, create, or change anything anywhere. If you are about to
take any action that writes, stop and ask me first.

GOAL: find committed work that has gone quiet.

Step 1: from Notion, list the deliverables in [name your tracker] that are due in
the next 14 days and are not marked complete. Show me what you found and how many.

Step 2: for each one, search the relevant brand Slack channel for the most recent
message that mentions it or its sponsor. Tell me the date of that last mention.

Step 3: give me a table sorted by risk: deliverable, brand, owner, due date, days
since it was last mentioned anywhere in Slack, and your read on whether it is on
track, quiet, or silent.

RULES:
- If you cannot find something, say "not found" rather than guessing
- Tell me exactly which channels you searched, so I can tell you if you missed one
- Tell me where your access is incomplete. Missing data that looks like good news
  is the failure mode I care about.
- Do not include anyone's personal information beyond names and roles

The safety writeup

Before you automate anything, you write down what it could break. This takes fifteen minutes and it is the most valuable document you will produce in this course.

Help me write work/safety-plan.md for the daily production brief I am about to build.

Interview me one question at a time, and write down my answers. Cover:

1. Blast radius: if this posts something wrong, who sees it and how bad is that
2. What it reads, and what it must never read
3. What it will eventually write, where, and who else can see that place
4. What data must never leave: member personal information, revenue figures,
   anything about compensation, anything unreleased
5. How I turn it off in under a minute, and who else knows how
6. What "wrong" looks like, so I would notice before someone else does
7. When I stop and get an engineer instead of fixing it myself

Ask me one at a time. Do not answer for me. If an answer is vague, push back once
and ask for something specific.

Act as my training grader for Gate 06. Be strict, especially on safety.

Check:
1. List the connectors you can currently see. Slack and Notion must both be present.
2. work/safety-plan.md exists and has no blank or placeholder sections.
3. Blast radius is SPECIFIC. It must name actual people or an actual channel.
   "The team might see something wrong" is a fail. "It posts to #hospitalogy-av
   where 9 people including the client-facing CSM would see it" is a pass.
4. The kill switch is a concrete action someone could take in under a minute, and
   the plan names at least one other person who knows how. Vague answers fail.
5. The never-leaves list explicitly covers member personal information and revenue.
6. It names a specific point at which she stops and gets an engineer.

Then ask me two questions and wait for answers:
- "In your own words, what is a token and why does it never go in a document?"
- "Paste the risk table you produced from Slack and Notion."
Reject a token answer that does not convey that it is a credential like a password
that grants access. Reject a pasted table that has no Slack recency data in it.

Finally, confirm from our history that nothing was posted or written to Slack or
Notion during this segment. If anything was written, that is an automatic NOT YET.

Output format:
- One line per criterion: PASS or NOT YET with evidence
- Overall verdict
- If NOT YET, the exact fix for each miss, then stop
- If PASS, append a row to progress.md: | Gate 06 | (today's date) | PASS | (note) |

Automation

Something that runs without you is a different kind of object than something you run. It fails while you are asleep. Here is how to build one that fails safely.

The sequence, and do not skip a step

People skip straight from dry run to scheduled and shared. That is how a wrong number ends up in front of a client. A week of watching is not caution, it is the part where you find out what happens on a Monday after a holiday.

Two kinds of scheduling

They are genuinely different and picking wrong is a common early mistake.

A 7am brief that only arrives when your laptop happened to be open is worse than no brief, because people stop trusting it. You are using a Routine.

Build it in dry run

We are building my daily production brief. Today it only ever runs in dry run.
It must not post anything anywhere.

Create work/daily-brief/spec.md first, before any other work. It must state:
- What the job reads, naming the exact Notion tracker and Slack channels
- What it produces, section by section
- What it does when a source is unreachable
- What it does when it finds nothing, which must be an explicit "nothing to flag"
  and never silence
- Who it will eventually send to
- Its kill switch
- DRY_RUN behavior: writes to work/daily-brief/output/ instead of sending

Show me the spec and let me correct it before you build anything.

Then build the job so that running it in dry run produces a dated markdown file in
work/daily-brief/output/ containing:
- Deliverables due in the next 3 days, with owner and status
- Anything past due and not complete
- Anything not mentioned in Slack for 5 or more days
- An explicit "sources checked" line naming every channel and tracker it read
- An explicit "sources that failed" line, empty if none

Rules: any source it could not reach is named in the output, never omitted.
Never present partial data as complete.

Run it three days in a row before you go further. Read each output against what you know to be true. Wrong output caught in dry run costs nothing.

Live to yourself, then schedule

The dry run output has been right for three days. Move to live, to me only.

- It sends the brief as a Slack DM to me and to nobody else
- Any other destination is blocked in the job itself, not just left unset
- If sending fails, it still writes the dry run file, so I never silently lose a day
- Add a KILL line at the top of spec.md: the exact steps to stop this in under a
  minute, written so someone who is not me could follow them

Send one now so I can see how it lands in Slack. Then tell me exactly what to
change if the formatting is wrong there.

Set this up as a Routine so it runs in the cloud whether or not my laptop is open.

- Weekdays at 7:30am my time
- Sends to me only
- If a source is unreachable it still sends, with the failure named in the message
- Tell me exactly where I go to see its run history and turn it off

Then update work/daily-brief/spec.md with the schedule, where it runs, and the
kill steps. Show me the final spec.

Explain in plain language the difference between what you just set up and a desktop
scheduled task, and why we chose this one.

Act as my training grader for Gate 07. Be strict. This one has real consequences.

Check:
1. work/daily-brief/spec.md exists and covers: what it reads, what it produces,
   behavior when a source fails, behavior when nothing is found, recipients,
   schedule, and kill steps. Name any missing section.
2. work/daily-brief/output/ contains at least 3 dated dry run files.
3. Open those outputs. Each must contain an explicit "sources checked" line AND a
   "sources that failed" line. An output that omits either is a fail, because
   silence about a failed source is the exact failure mode this gate exists for.
4. Read the code or configuration. Confirm the recipient is limited to me and that
   other destinations are actually blocked, not merely unset. Quote the relevant
   part. If any teammate or shared channel could receive this today, fail it.
5. The kill switch in spec.md is written as numbered steps a person who is not me
   could follow without asking questions. Vague instructions fail.
6. Confirm the "nothing found" case produces an explicit statement rather than an
   empty or absent message. Show me where that is handled.

Then ask me: "Where do you go to see this Routine's run history and turn it off?"
Reject an answer that does not name a specific place.

Output format:
- One line per criterion: PASS or NOT YET with evidence
- Overall verdict
- If NOT YET, the exact fix for each miss, then stop
- If PASS, append a row to progress.md: | Gate 07 | (today's date) | PASS | (note) |

Capstone: ship the morning brief

Everything you have learned, aimed at the thing that actually costs your team time. This one is real, it goes to another human, and it has your name on it.

The problem you are solving

Right now the true state of production lives in four places and one person's head. Statuses get hand-loaded after the fact, which makes them a record of what someone remembered rather than what happened. People check several places and still miss things, and the first anyone hears about a slip is when it has already slipped.

The brief does not fix that. It does something narrower and more useful: it puts the same picture in front of everyone every morning, assembled from where the work actually happens, so nobody has to go looking.

Spec before you build. Yes, again.

Two hours of building against a wrong spec is worse than twenty minutes of arguing with the spec. Push on it until you would defend every line of it in a meeting.

We are finishing the daily production brief. Before we build anything more, read
work/daily-brief/spec.md and work/safety-plan.md, then challenge me on it.

Ask me hard questions, one at a time, about:
- What decision does someone actually make differently because they read this
- What is in it that nobody would act on, and should therefore be cut
- What is missing that would make someone check another place anyway, which would
  defeat the whole point
- What does it do the morning after a holiday, or on a week where a brand pauses
- What would make someone stop reading it after four days
- What happens on the day it is wrong, and how would we know

After the questions, propose a revised spec. Tell me what you cut and why. Be
willing to argue with me. A brief nobody acts on is worse than no brief, because
it costs attention every morning and returns nothing.

Build the daily production brief to the revised spec.

REQUIREMENTS:
- Dry run stays available permanently, not just during development
- Every output names sources checked and sources that failed
- Nothing found produces an explicit "nothing to flag today", never silence
- Formatted for reading on a phone at 7:30am: the thing needing attention first,
  detail below, no wall of text
- Every item says what it is and who owns it, in words someone outside my team
  would understand
- No personal information beyond names and roles, and no revenue figures

Then run it against the last 7 days of real data and show me the output for each
day. I am going to check these against what I know actually happened.

Write work/daily-brief/README.md for the person who receives this brief. One page,
plain language, no jargon. It must cover:

- What this is and why it exists
- Where every number comes from
- What it does NOT cover, so nobody assumes coverage it does not have
- How much to trust it, honestly, including what it is likely to get wrong
- What to do if something in it looks wrong
- Who owns it, which is me
- How to turn it off, in steps

Write it for someone who has never heard of Claude Code and does not need to.

Then widen it

After a week of reading it yourself every morning, add one person. Tell them plainly that it is new, that you want to know when it is wrong, and that you will turn it off if it stops being useful. That framing is what makes people tell you the truth about it.

Act as my final training grader for Gate 08. Be the strictest you have been. This
job is running for real and another person depends on it.

Check:
1. Read work/daily-brief/spec.md and the built job. List every place the built job
   does something the spec does not describe, or fails to do something it promises.
   Any drift is a finding, name it.
2. work/daily-brief/output/ contains at least 7 dated outputs. Each must have the
   sources checked and sources failed lines. Name any that do not.
3. Test the empty case. Show me what it produces when there is nothing to flag.
   Silence is a fail.
4. Read work/daily-brief/README.md. Rate it for someone who has never used Claude
   Code: does it say what the brief does not cover, and how much to trust it?
   Quote the honest-limitations part. A README with no stated limitations is a fail,
   because a tool that claims no weaknesses will be trusted past its evidence.
5. Confirm no personal information beyond names and roles, and no revenue figures,
   appear in any output. Search them and report.
6. Confirm the kill switch still works as written after all the changes.

Then ask me, one at a time, and wait for each answer:
- "Name one thing you found wrong when you checked 7 days against reality."
  An answer of "nothing" is a NOT YET. Seven days of real data always contains
  something, and finding nothing means the check was not really done.
- "What will this brief never catch?"
- "Who else receives it, and how would they tell you it is wrong?"

Output format:
- One line per criterion: PASS or NOT YET with evidence
- Overall verdict
- If NOT YET, the exact fix for each miss, then stop
- If PASS, append a row to progress.md: | Gate 08 | (today's date) | PASS | (note) |
  and then write me a short, honest assessment: what I am now genuinely capable of
  building alone, and what I should still hand to an engineer.

Prompt library

Twenty starting points. Copy, then replace the bracketed parts.

Building

• "Plan first, do not write anything yet. GOAL: [x]. INPUTS: [y]. CONSTRAINTS: [z]. DONE LOOKS LIKE: [w]."
• "Build this as one self-contained HTML file with no external requests. It must work with no wifi and on a phone."
• "Show me the smallest version that proves this works, before you build the whole thing."
• "That is 80 percent right. Three specific problems: [1], [2], [3]. Fix only those."
• "Publish this as an artifact and give me the link."

Analyzing

• "Do not analyze yet. First tell me what is wrong with this data: blanks, malformed values, ambiguous columns."
• "State every assumption and exclusion before you give me a single number."
• "Tell me the exact filter that produces that number, precisely enough that I could do it by hand."
• "Show me the raw rows behind that number so I can count them myself."
• "What would make this conclusion wrong? Argue against yourself."

Reviewing and fixing

• "Review this against [standard]. Do not rewrite it. Give me line references and specific fixes."
• "What is missing here that someone would have to ask me about?"
• "Explain what this does in plain language, as if I have never seen it."
• "Something is wrong with [x]. Do not guess at a fix. Find the cause first and tell me what it is."
• "You changed something I did not ask you to change. Show me every change you made and why."

Automating

• "Write the spec first. I want to correct it before you build anything."
• "Dry run only. Write the output to a file. Do not send or post anything."
• "What does this do when a source is unreachable? What does it do when it finds nothing?"
• "Block every destination except me, in the job itself, not just left unset."
• "Write the kill switch as numbered steps someone who is not me could follow."

When to trust it

Two questions decide it. How bad is it if this is wrong, and how easily can it be undone.

The pattern underneath: the risk is not that it is wrong. It is that it is wrong confidently, in a format that looks checked. Anything that will be believed without scrutiny needs scrutiny from you first.

Now with real stakes

The table is easy to nod along to. The instinct is harder. Here are five situations pulled from your actual week. Pick what you would really do, then see whether it holds up.

When to call an engineer

Build it yourself

• Anything living in your own folder or a page you share as a link
• Reading from Slack, Notion, Drive, or a spreadsheet
• Anything that posts only to you, or to one person who knows it is new
• Analysis, drafts, reviews, checklists, and briefs

Stop and get help

• Anything that writes into a system other people depend on
• Anything a client or advertiser sees without a human in between
• Anything touching a database, a deploy, or production code
• Anything handling member personal information at scale
• Anything you would struggle to explain if it broke

Cost and models

On a Pro, Max, or Team plan you are not paying per use, you are working within your plan's limits. So the practical question is not cost, it is fit.

• Leave the default alone unless you have a reason. It is the right pick for almost everything you will do.
• Switch to a faster model with /model for simple mechanical work: reformatting, renaming, straightforward extraction.
• Stay on the strongest model for anything involving judgement: specs, analysis you will act on, and anything that will run unattended.
• If you hit your limits often, that is usually a sign of long sessions rather than hard work. Use /clear between unrelated tasks.

Separately, there is an Anthropic API where you pay per use for things you build programmatically. You do not need it for anything in this course, and you should not set one up until you have a specific reason.

What will go wrong

Ten things that will actually happen, and what to do. None of them mean you did something wrong.