# Howard Builds Markster — the 6-week Claude learning plan

Howard learns to work with Claude by building the real Markster product (EU trademark registration, 939 EUR all-in). Six weeks, 15-20h/week, 80 tasks in three threads. He does not learn to code — he learns to direct: complete prompts, good questions, and challenging answers.

- THREE THREADS: Technical (weekdays, 65 tasks — how Claude works, builds the Markster app end-to-end), Business (Saturday mornings, 12 tasks — Bogdan's BONO method for analyzing a business idea, ending in a scored GO/REFINE/PIVOT/PARK verdict), and the PRD thread (Fridays, 3 tasks — Howard questions the PRD in W1, redlines it in W3, rewrites it as v2 in W5; his version goes to Prodi).
- Plan home: hlb.bgn.ro — hosts the downloads: markster-prd-en.md (the PRD in English; also readable in the plan's PRD tab) and this file. The plan moves to Howard's own domain in week 6 (T55).
- It starts at T00: account setup, Pro plan, and the three faces of Claude (browser / Cowork desktop / Claude Code) — each installed exactly when the plan needs it.
- Levels: W1 prompts provided+explained · W2-3 fill-in-the-blanks · W4-6 Howard writes prompts (checklist + reference)
- Every task: prompt → "Why this prompt works" → "Challenge the answer"
- Rituals: one brave question daily; the WORD PARKING LOT; Friday review with Bogdan; stuck rule: 3 attempts, then call Bogdan.
- From T41, Claude Code may tick tracker tasks ONLY after Howard explicitly confirms. PRD edits follow the same rule: Howard proposes, Bogdan approves.

## The business method (reference)

Challenger, not validator: never start from the product — start from the need. Scorecard dimensions (1-5 each): A Need, B Customer, C Market, D Differentiation, E Profit formula. Deal-breakers (auto-PARK): no identifiable need; customer is "everyone"; no distribution path. Revenue Reality Check: accessible customers × conversion rate × price = year-1 revenue, bottom-up only; compare with ambition (Lifestyle 50-300K / Growth 300K-3M / VC 3M+). Verdicts: GO / REFINE / PIVOT / PARK. Sources: JTBD (Christensen), Mom Test (Fitzpatrick), YC 6 problem traits + 5 unfair advantages (Kevin Hale), Sequoia PMF archetypes, Aulet/MIT beachhead + LTV≥3xCAC, Lean Startup, pre-mortem, Revenue Reality Check (original BGN).


## Week 1 — Foundations & first wins (Level 1: Prompts provided — study the anatomy, 15 tasks, ~17.5h)

### T00 · Mon · 1h · Setup — Before anything — get Claude (account, plan, and the three faces)

**Do this first — no Claude needed yet:**
- Create your account: in Chrome, go to claude.ai and choose Sign up. "Continue with Google" is the easiest if you have a Gmail address; otherwise use your email and the code it sends you. You type every password yourself — never share one with anyone, Claude included.
- Subscription: start with the Pro plan (in claude.ai: your initials, bottom-left → Settings → Upgrade). Weeks 4-6 lean hard on Claude Code — if you ever hit usage limits there, upgrading to Max fixes it. Ask Bogdan before paying anything you're unsure about.
- Meet the three faces of Claude — just read, don't install anything extra today: (1) Claude in the browser, at claude.ai — chat, artifacts, Projects; weeks 1-3 live entirely here. (2) The Claude desktop app (Cowork) — the same Claude, installed on your computer, able to work with your local files; you install it in week 3 (T29). (3) Claude Code — the builder: works in the terminal, creates real files and real apps; that's week 4 (T32). The plan installs each face exactly when you need it, never earlier.
- Bookmark two pages in Chrome's bookmarks bar: claude.ai and hlb.bgn.ro (this plan).
- Create a folder called Markster (on your Desktop or in Documents). Every file you download for this plan — the PRD, your exports — lives there. You'll thank yourself daily.

**Prompt:**

```
Hi. I'm Howard, 65. This is the first message I have ever sent you. I'm starting a 6-week plan (it lives at hlb.bgn.ro) where I'll learn to work with you by building a real product called Markster.

Three questions to start us off:
1. What exactly are you, in plain words - and what's the difference between you here in the browser, the desktop app, and something called Claude Code? I'll be using all three over the next six weeks.
2. What should I know about how to talk to you? Any rules of the road?
3. What happens to what I type here - who can see it, and will you remember this conversation tomorrow?
```

**Why this prompt works:** Notice: your very first message already follows the recipe — who you are (context), what you're doing (goal), numbered questions (format). You were prompting properly before you knew the word. And question 3 is deliberately there: what's private and what's remembered is the right FIRST question to ask any tool — not the last.

**Challenge the answer:** Claude's answer to question 1 will be confident and tidy. Ask the follow-up that tests it: "What are you bad at? What shouldn't I trust you with?" Save the answer in a note. In week 6's retrospective (T63) you'll compare it with your own list, built from six weeks of real experience — and see which of you knew Claude better on day one.

### T01 · Mon · 0.5h · First win — Quick win — your first artifact (30 minutes of magic)

**Prompt:**

```
Build me a very simple HTML artifact (pure HTML + CSS, no libraries) showing one large card with:
- the title "Markster" in a big bold font with a pink-to-magenta gradient
- one line of description: "EU trademark registration - simple, fast, AI-native"
- a placeholder button that says "Start your free check"
- a soft background, modern clean design, Inter font

No JavaScript. Just HTML + CSS.
```

**Why this prompt works:** Look at how specific this prompt is: exact texts, exact colors, exact structure, and one explicit constraint (no JavaScript). Every detail you give removes a guess Claude would otherwise make for you. Specificity is not pedantry — it's predictability. And don't worry that the prompt is full of words you don't know yet — HTML, CSS, artifact. You don't need to understand them to USE them today: click any dotted word for a one-line idea, park the rest (see the parking lot in Overview), and by Wednesday's brave-question hour you'll ask about them properly. In this plan, using comes first; understanding follows a few days later, on schedule.

**Challenge the answer:** When the card appears, ask: "What decisions did you make that I didn't specify?" The list you get back — font sizes, spacing, shades — is a preview of what a truly complete prompt would have covered. Then change ONE thing ("make the gradient softer") instead of re-asking from scratch. Iterating beats restarting.

### T02 · Mon · 1.5h · Discovery — Meet Markster — read the PRD with Claude as your guide

**Prompt:**

```
I'm attaching the Markster PRD (the product requirements document). I downloaded it from hlb.bgn.ro - the same page this plan lives on - as the file "markster-prd-en.md". Before I read the whole thing myself, do two things for me:

1. A 10-bullet abstract — one line each — covering: who the customer is, what they get, what it costs, how it's different from lawyers, and how an application moves through its statuses.
2. A short glossary: every term in the document that a person who has never worked in trademarks or software would need explained (EUIPO, Nice classes, state machine, API...) — each in one plain-English sentence.

I'll read the full document after, using your abstract as my map.
```

**Why this prompt works:** Two patterns here worth stealing forever. "Give me the essence before I read" turns any long document into a guided read. And asking for a glossary is asking Claude to adapt to YOU — you set the level, it meets you there. (Practical notes: the PRD download link is at the top of the Markster tab — one click, save it in your Markster folder. And attaching in Claude.ai is simple: click the + / paperclip next to the message box and pick the file, or just drag the file from your folder straight onto the chat.)

**Challenge the answer:** While reading the full PRD afterwards, find one thing the abstract missed or oversimplified — there's always at least one. Tell Claude: "Your abstract missed X. Update it." You just corrected Claude on day one. Notice that nothing bad happened.

### T03 · Mon · 1h · Setup — Create your Markster Project — a Claude with memory

**Prompt:**

```
I want to create a Project in Claude.ai dedicated to Markster. Guide me step by step, waiting for my "done" after each step:

1. How to create the Project in the Claude.ai interface
2. Which documents to upload to its knowledge base. I have two files downloaded from hlb.bgn.ro: the Markster PRD (markster-prd-en.md) and this learning plan (howard-markster-plan.md)
3. Write the exact custom instructions text I should paste in. It must say: I'm Howard, 65, smart but not technical, learning to work with Claude by building Markster. Always define jargon the first time you use it. Before doing anything big, show me your plan first. Never treat any of my questions as too basic. When I'm wrong, tell me directly and kindly.
```

**Why this prompt works:** Custom instructions are a standing prompt — you write who you are and how you like your answers ONCE, and every conversation in the Project starts from there. This is the difference between using Claude and having your own Claude. Notice also: "wait for my done after each step" turns Claude into a patient guide instead of a firehose.

**Challenge the answer:** Test the setup: in the new Project, ask a question whose answer will contain jargon ("how does the Markster availability check work?"). Did Claude define the terms without being asked? If not, ask: "Which part of my custom instructions should I strengthen so you always do this?"

### T04 · Tue · 2h · Tracker app — Tracker v1 — build an app with memory (localStorage)

**Prompt:**

```
Build me a standalone HTML artifact (pure HTML + CSS + JS, no external libraries) — a progress tracker for my 6-week Markster learning plan.

FUNCTIONALITY:
- shows my task list grouped by week and day (I'm attaching the list)
- each task: a checkbox, the task ID, name, and estimated hours
- clicking the checkbox marks it done; the state is saved in localStorage under the key "howard_markster_progress"
- when I reload the page, my checkmarks are still there
- at the top: "X of Y hours done this week" and an overall percentage

DESIGN:
- pink accent #E8386F, Inter font, clean modern cards, subtle shadows, rounded corners
- styled checkboxes (not the browser default)

The final result: a single HTML file I can open in Chrome and it just works.
```

**Why this prompt works:** This prompt has labeled sections — FUNCTIONALITY and DESIGN — and Claude mirrors your structure. Writing prompts in blocks like this is the single easiest upgrade to your results. Also notice the last line: describing the finished experience ("open in Chrome and it just works") is a constraint too.

**Challenge the answer:** Before accepting it, ask: "If I open this file on my phone instead of my computer, will my checkmarks be there?" The answer is no — and making Claude explain WHY (localStorage lives in one browser on one device) is your first real systems lesson. You'll fix this limitation yourself in week 3.

### T05 · Tue · 1h · Prompting — Prompt anatomy — take the recipe apart

**Prompt:**

```
Here is a prompt I used earlier (I'm pasting my tracker prompt from T04). Do three things:

1. Dissect it into the four parts of a good prompt: Context, Goal, Format, Constraints. Show me which sentence does which job.
2. Show me what you would have built if I had only written: "make me a tracker app". List the 10 biggest decisions you'd have had to guess.
3. Now I'll give you a deliberately bad prompt: "make me a website". Don't build anything — instead, list the questions you would need answered before you could do a good job.
```

**Why this prompt works:** You're not collecting recipes — you're learning the recipe format itself. Part 3 is the secret weapon: asking Claude "what would you need to ask me?" turns it into your prompt-writing coach, for free, forever.

**Challenge the answer:** Ask: "Rank the four parts of my tracker prompt by how much each one changed the result." Then decide whether you agree with the ranking. Disagreeing with Claude — out loud, with a reason — is a skill this plan will keep asking you to practice.

### T06 · Wed · 1.5h · Iteration — Change without breaking — iterating on the tracker

**Prompt:**

```
Here is my working tracker (attaching the current version). I want ONE change:

Add a small notes field to each task — a place where I can type a short note (like "took me 2 sessions" or "ask Bogdan about this"), saved in localStorage together with the checkmarks.

IMPORTANT: keep absolutely everything that already works — the checkboxes, the saved state, the week grouping, the hour counters, the design. Change nothing I didn't ask for.
```

**Why this prompt works:** Iteration prompts name what must NOT change, not just what should. "Keep everything that already works" is the seatbelt sentence — use it every time you touch something functioning. One change at a time, so when something breaks you know exactly what broke it.

**Challenge the answer:** After the change, verify the old features yourself — click every checkbox, reload, check the counters. Then ask question #10 from the Playbook: "What did you change that I didn't ask you to change?" The honest answer is sometimes 'nothing' and sometimes not — both are worth knowing.

### T07 · Wed · 1h · Courage — The brave question hour

**Prompt:**

```
I'm going to ask you five questions I'd be slightly embarrassed to ask a person. Rules for your answers: plain English, short, no jargon, and never a hint that a question was basic. After each answer, ask me: "clear, or should I try again differently?"

My five questions:
1. [start with Monday's parking lot — e.g. What actually ARE the HTML and CSS I've been pasting since T01? What's an artifact really?]
2. [e.g. What's the difference between the internet and a browser?]
3. [e.g. What does "the cloud" actually mean — where are my things?]
4. [e.g. What is code, really? What happens when it "runs"?]
5. [e.g. What does "deploy" mean?]
```

**Why this prompt works:** This is the daily ritual, done as a full session once so you feel how it works. The rule you set — "ask me: clear or try again?" — creates a loop where saying 'not yet clear' is expected, not awkward. You're allowed to say it five times in a row.

**Challenge the answer:** Pick the answer you liked most and ask: "Now explain the same thing to a 10-year-old. Now to an expert." Feeling the difference between the three versions teaches you to ORDER the depth you want — which is a prompt skill, not a courage skill.

### T08 · Thu · 1.5h · Discovery — Role-play: Claude joins the team and interviews you

**Prompt:**

```
Role-play time. You are a smart new team member who just joined Markster. You have NOT read the PRD. Interview me — ask me 10 questions, one at a time, to understand: what we're building, for whom, why now, how the money works, and what happens after a customer pays.

I'll answer from memory, without looking at the PRD. After my ten answers, drop the role, read the PRD from the Project knowledge, and give me a scorecard: which of my answers were right, which were incomplete, and which contradicted the document.
```

**Why this prompt works:** Role-play flips the direction of the conversation — being questioned reveals what you actually know, which is different from what you've read. And the scorecard at the end turns a chat into a measurement. You designed a little exam for yourself inside one prompt.

**Challenge the answer:** For your weakest answer, don't just read the correction — ask: "Why do you think I misremembered that? What makes that part of the PRD confusing?" Sometimes the document is the problem, not your memory. If so, tell Bogdan on Friday — that's real product feedback.

### T09 · Thu · 1h · Explain back — Teach it back — the state machine in your own words

**Prompt:**

```
I'm going to explain the Markster application statuses (the "state machine" — the 12 states an application moves through) to you, in my own words, from memory. Your rules:

- Let me finish completely before commenting.
- Then point out my errors ONE at a time. After each one, ask if I want to try re-explaining that part before you reveal the right version.
- Be direct — don't soften a wrong into a "almost right".

Ready? Here's my explanation: [type your explanation]
```

**Why this prompt works:** Explaining back is the strongest test of understanding — stronger than re-reading, stronger than quizzes. Notice that the prompt sets rules for HOW to be corrected. You can design the feedback experience you want; Claude will honor it.

**Challenge the answer:** At the end, ask question #4 from the Playbook: "What question about the state machine should I be asking that I haven't?" (A good candidate: who decides when a flagged application is safe to file — and what happens if Iulia disagrees with the AI?)

### T10 · Fri · 1.5h · Skeptic — Catch Claude being wrong — on purpose

**Prompt:**

```
(Do this OUTSIDE the Markster Project, in a plain new chat, so Claude has no documents to lean on.)

Answer from your general knowledge, without searching the web: What are the current EUIPO fees for registering an EU trademark in one class, two classes, and three classes? How long does registration typically take? What is the SME Fund and how much does it reimburse?

Give me specific numbers.
```

**Why this prompt works:** You're setting a trap, ethically. Without documents or web access, Claude answers from memory — fluently, confidently, and possibly out of date or wrong. Now verify each number against the PRD and euipo.europa.eu. This teaches the most valuable calibration lesson there is: confidence is not accuracy.

**Challenge the answer:** Go back to Claude with what you found: "These two numbers were wrong. Why did you state them so confidently?" Then ask question #8: "How confident are you in each of these, and what should I verify at the source?" — notice how much better that framing works BEFORE you trust numbers, not after. Rule from today: prices, dates, laws, statistics — always verify at the source.

### T11 · Fri · 1h · Review — Week 1 review with Bogdan

**Prompt:**

```
Help me prepare my week 1 review. From our conversations this week, help me assemble:
1. A 5-line summary of what I built (tracker v1, the Project, the corrected abstract)
2. My best prompt of the week and why it worked
3. The story of catching you being wrong on the EUIPO fees
4. Three questions for Bogdan
5. Empty my parking lot: here are the words still foggy after week 1 - [paste your list]. Explain each one using something I actually built this week as the example.

Then save the final version as a note I'll add to the Project knowledge base, titled "Week 1 — learned".
```

**Why this prompt works:** Reviews are also a Claude task — it remembers your week better than you do. Building the habit of a written weekly note gives your Project a growing memory of your own progress.

**Challenge the answer:** On the call, show Bogdan the fee-catching story first. Saying "I caught the AI being wrong" out loud, in week one, sets the tone for everything after.

### P01 · Fri · 0.5h · PRD thread · PRD THREAD — The PRD is yours too — your first five questions

**Prompt:**

```
This week I read the PRD (T02), got interviewed on it (T08), explained its state machine back (T09), and caught you being wrong about its fees (T10). Now the last step of week 1: help me write my "Five questions for the PRD" list.

Go through our week together and help me find the 5 places where the PRD seemed unclear, suspicious, or incomplete TO ME - not generic critiques, mine. For each one: what the PRD says, what I found unclear, and exactly what I'd ask Bogdan.

Format it as a short list I can read out loud at tomorrow's review.
```

**Why this prompt works:** This starts a thread that runs the whole plan: the PRD is not scripture — it's a working document, and you are becoming one of its authors. Week 1 you question it, week 3 you correct it (P02), week 5 you rewrite it (P03). Ownership starts with permission to ask.

**Challenge the answer:** At the review, watch Bogdan: which of your five questions makes him pause before answering? That one goes to the top of your P02 list. A question that makes the author think is worth ten that get quick answers.

### B01 · Sat · 1.5h · Need-first · BUSINESS TRACK — Product or need? — the reframe that starts everything

**Prompt:**

```
Today we start the business track. Teach me the single most important move in analyzing any business idea: the reframe from PRODUCT to NEED.

1. Explain Jobs to Be Done (Clayton Christensen's idea): people don't buy products, they "hire" them to do a job. Tell me the famous milkshake story.
2. Exercise: give me 5 well-known products one at a time (a drill, Instagram, a Rolex, a gym membership, tax software). For each, I'll tell you what job people actually hire it for. Grade my answers - be honest.
3. Now Markster: what job does an EU entrepreneur hire Markster for? Help me write the job statement in this exact format: "When [situation], I want to [motivation], so that [outcome]."
4. Last question, and don't let me off easy: which parts of that job statement do we actually have EVIDENCE for, and which are assumptions?
```

**Why this prompt works:** Every business analysis at BONO starts with this one move: reframing from "what we build" to "who needs what". Nine out of ten founders start from the product and never recover. The job statement format you learned today is the tool the next five Saturdays are built on.

**Challenge the answer:** Ask: "Give me a famous product that failed because it was a solution in search of a problem - and tell me what a need-first analysis would have caught before launch." Then the harder one: "If the need Markster serves is real, why hasn't the market already solved it well?" Sit with that answer - it previews week 4.

### B02 · Sat · 1h · Mom Test · BUSINESS TRACK — The Mom Test — why you can't ask 'would you use this?'

**Prompt:**

```
Teach me the Mom Test (Rob Fitzpatrick) - the rules for talking to customers without them politely lying to you.

1. The 3 rules: talk about their life not your idea; ask about specific past behavior not future opinions; talk less, listen more. Explain each with an example about trademark registration.
2. The 3 types of toxic data: compliments, hypotheticals ("I would totally use that!"), and wishlists. Why does each one feel like gold and act like poison?
3. Trap exercise: role-play my enthusiastic friend hearing about Markster. Give me 6 responses - some genuinely useful data, some toxic. I'll sort them. Grade my sorting.
4. Rewrite exercise: here are 5 bad questions - "Would you pay 939 EUR for this?", "Don't you hate how slow lawyers are?", "Would you use an AI for legal stuff?", "Isn't this a great idea?", "How much would you pay?". Help me rewrite each into a Mom Test question about the past.
```

**Why this prompt works:** The Mom Test is the antidote to polite lies - and notice it's the SAME skill as challenging Claude: compliments are toxic data in both worlds, and specific past behavior beats confident opinion everywhere. You've been training for this track since week 1 of the technical one.

**Challenge the answer:** After the trap exercise, ask: "Which of my 6 responses were you most confident I'd mislabel, and why?" Then the meta-question: "When you answer MY questions about Markster's prospects, which of your answers are compliments, hypotheticals, or wishlists?" Claude produces toxic data too - now you can name it.


## Week 2 — Prompt craft: landing page & research (Level 2: Fill in the blanks, 12 tasks, ~16.5h)

### T12 · Mon · 2h · Landing page — Markster landing page v1 — your intent, our skeleton

**Prompt (fill in the [blanks]):**

```
Build me a landing page for Markster as an HTML artifact.

CONTEXT: Markster registers EU trademarks for small businesses — €939 all-in vs €1,500-3,000 with a lawyer, 15 minutes instead of weeks. (Full PRD is in the Project.)

GOAL: one page whose only job is to make a visitor click "Start your free check".

THE VISITOR: [describe them in 2-3 sentences - who are they, what just happened in their business, what are they afraid of?]

SECTIONS I WANT: [list 4-6 sections in order - e.g. hero, how it works, price comparison, FAQ... your call]

TONE: [pick and describe: reassuring like a good accountant? energetic like a startup? calm and premium?]

CONSTRAINTS: pink accent #E8386F, Inter font, mobile-friendly, no fake testimonials — leave a placeholder section instead.
```

**Why this prompt works:** The blanks are the parts only a human can supply: who the visitor really is, what order tells the story, what the page should feel like. Claude can generate structure all day — intent is yours. Notice the 'no fake testimonials' constraint: you can encode your ethics into prompts.

**Challenge the answer:** When it's done, ask: "Act as a first-time visitor matching my description. Scroll the page. What would stop you from clicking Start?" Then — important — decide which critiques you BELIEVE before fixing anything. Claude generates critiques as fluently as pages; your judgment picks the real ones.

### T13 · Mon · 1h · Critique — Hire Claude as your harshest critic

**Prompt (fill in the [blanks]):**

```
Now switch roles completely. You are a senior conversion copywriter reviewing this landing page for a client who pays you a lot. Rules:

- Find the 5 biggest problems, ranked by impact on whether visitors click Start.
- No praise. Not one compliment. Only problems and how to fix them.
- For each problem: [choose what you want per problem - e.g. why it hurts, the fix, and a rewritten example?]
```

**Why this prompt works:** Three levers make critique useful instead of polite: a demanding persona, an explicit 'no praise' rule, and ranked output. Without them Claude defaults to encouragement. With them you get an editor.

**Challenge the answer:** Pick the ONE critique you disagree with and push back with your reason. Watch what happens: does Claude defend its position or fold instantly? If it folds, ask: "Were you actually wrong, or just agreeing with me?" Learning to detect the polite fold is week 2's most important lesson.

### T14 · Tue · 1.5h · Landing page — Landing page v2 — one change at a time

**Prompt (fill in the [blanks]):**

```
We're applying the top 3 fixes from the critique, but one at a time.

Fix #1: [name the fix you chose]
Keep everything else exactly as it is. After you show me the result, wait — I'll say "next" when I've compared it to the previous version.

(then Fix #2, then Fix #3, same rules)
```

**Why this prompt works:** Batching changes hides which one helped and which one hurt. Sequential changes with a pause between them keep YOU in the judge's seat. The 'wait — I'll say next' instruction sets the pace to yours.

**Challenge the answer:** After each fix, ask: "What got slightly worse because of this change?" Every design change has a trade-off (a stronger headline is often a longer one). If Claude says 'nothing got worse', be suspicious — push once.

### T15 · Tue · 1h · Setup — Claude in Chrome — your browser gets a copilot

**Prompt (fill in the [blanks]):**

```
I want to set up Claude in Chrome (the browser extension that lets you see and drive my browser). Guide me:

1. Step-by-step installation, waiting for my "done" after each step
2. Then explain, before we use it at all: what will you be able to see and do in my browser? What can you NOT do? When will you ask my permission?
3. First supervised exercise: [pick a harmless first task - e.g. open euipo.europa.eu and summarize what's on the homepage]
```

**Why this prompt works:** Tools change what 'ask' means — questions can now include 'go look'. But the pattern to copy is step 2: before granting any tool access, make Claude explain the boundaries of that access. That habit transfers to everything (Claude Code included, in week 4).

**Challenge the answer:** During the exercise, watch what it does. If any step surprises you, stop it and ask: "Why did you do that?" You are the supervisor — interrupting is not rude, it's the job. Practice interrupting once even if nothing is wrong.

### T16 · Wed · 2h · Research — Competitor recon with Claude in Chrome

**Prompt (fill in the [blanks]):**

```
Research Markster's competitors using Claude in Chrome. Visit the sites of Trama, and 2-3 other EU trademark registration services you find.

Build me a comparison table with EXACTLY these columns:
[decide your columns - e.g. price all-in, what's included, speed promised, who does the legal work, what happens if the mark is rejected... pick 5-6 that matter for Markster]

For every cell: note which page of their site the information came from.
```

**Why this prompt works:** Naming the table columns BEFORE the browsing starts turns a wander into an extraction. And 'note which page it came from' builds sourcing in from the start — you'll thank yourself in T17.

**Challenge the answer:** Three questions, straight from the Playbook: "Where exactly did each price come from? Which of these numbers might be out of date? What did you NOT check?" The third one is the killer — the honest answer (competitors' hidden fees, non-EU services, reviews) is your real research backlog.

### T17 · Wed · 1h · Skeptic — The source interrogation

**Prompt (fill in the [blanks]):**

```
From our competitor table, I want to verify one claim myself. Ask me which cell I picked, then:

1. Tell me exactly where you found it (URL, section of the page)
2. Walk me to it with Claude in Chrome so I can see it with my own eyes
3. If what I see doesn't match the table: [decide the rule - fix the table? flag the cell? re-check the whole row?]
```

**Why this prompt works:** One manual verification calibrates how much to trust the other twenty cells. This is how professionals use research assistants: spot-check, then trust proportionally.

**Challenge the answer:** Before picking your cell, ask: "Which cell of this table are you LEAST confident about?" — then verify exactly that one. Asking for the weakest point first is question #2 doing real work.

### T18 · Thu · 2h · Tracker app — Tracker v2 — richer data + export

**Prompt (fill in the [blanks]):**

```
Upgrade my tracker (attaching current version). This time I'm writing the functionality spec myself:

FUNCTIONALITY:
[write this block yourself. Cover: what states can a task be in beyond done/not-done? what extra data per task (timestamps? notes?)? what buttons for export/import JSON and how should they behave? what must survive a page reload?]

CONSTRAINTS: keep everything that already works. Same design language. Still one HTML file.
```

**Why this prompt works:** Week 1 gave you this block written out; now the FUNCTIONALITY block is yours. Use the checklist questions in the blank as your scaffold — a spec is just answers to 'what data, what actions, what must persist'.

**Challenge the answer:** Export your progress as JSON and actually READ it. Ask Claude to walk you through what each part means. If you can read your app's data with your own eyes, the app has no secrets from you — that feeling is the point of this task.

### T19 · Thu · 1h · Concepts — JSON, explained until it's boring

**Prompt (fill in the [blanks]):**

```
Teach me JSON properly, using my own tracker export as the textbook. Rules:
- Start from my real file, not abstract examples
- After each concept, I'll re-explain it back to you in my own words - correct me
- [add one rule of your own about how you learn best]
```

**Why this prompt works:** Using YOUR data as the textbook keeps it concrete, and the explain-back loop (from T09) is now a reusable pattern you can apply to any concept, forever. The third rule is yours: you're learning to customize how you're taught.

**Challenge the answer:** Ask: "What's the most common mistake people make with JSON?" Then look for it in your own export. You probably won't find one — and asking Claude WHY your file is safe from that mistake teaches you more than the mistake itself.

### T20 · Fri · 1.5h · Research — EUIPO developer portal — a map in plain English

**Prompt (fill in the [blanks]):**

```
With Claude in Chrome, explore the EUIPO developer portal (dev.euipo.europa.eu). I want a plain-English map:

- Every API they offer, one sentence each, no jargon
- For each: [decide what you want to know - e.g. what Markster would use it for? whether the PRD lists it as critical?]
- Format: [decide - table? grouped list?]
```

**Why this prompt works:** You're doing real work now — this map orients the actual product. Constraining the output ('one sentence, no jargon') is what turns developer documentation into something you can genuinely use to make decisions.

**Challenge the answer:** Cross-check without Claude: open the PRD's integration table yourself and compare it to the map. Did Claude's map match the PRD's priorities? If anything differs, bring it to the Friday call — you may have found drift between the docs and reality.

### T21 · Fri · 1h · Review — Week 2 review + the prompt rewrite

**Prompt (fill in the [blanks]):**

```
Two things today.

1. Pick my weakest prompt from week 1 — here it is: [paste one]. Help me rewrite it using the full recipe (context / goal / format / constraints). Then run BOTH versions and show me the two results side by side.

2. Assemble my week 2 review for Bogdan: what I built, best prompt, what I caught in the research verification, three questions. Save as "Week 2 — learned" in the Project.
```

**Why this prompt works:** The side-by-side is proof, not theory: same intent, better prompt, visibly better output. This is the exercise that convinces you the recipe is real.

**Challenge the answer:** Show Bogdan the side-by-side on the call and let HIM guess which output came from which prompt. If he can't tell, interesting — discuss why.

### B03 · Sat · 1.5h · Customer · BUSINESS TRACK — Who exactly buys? — the next-10-customers test

**Prompt (fill in the [blanks]):**

```
Business Saturday #2: the customer. Bill Aulet's rule at MIT: "everyone" is not a customer - a beachhead is.

1. Here's my description of Markster's beachhead customer, in my own words: [write it - one specific type of founder: what business, what country, what just happened to them, what are they afraid of. Steal from the PRD but make it yours]
2. Challenge my beachhead: is it specific enough? Reachable enough? Would Aulet approve?
3. The brutal test: help me figure out whether the team could NAME 10 real people or companies who would buy Markster this month. What would the list look like? Where would those names come from?
4. Decision-Making Unit, light version: for my beachhead customer, who actually decides, who pays, and who could veto? [think: solo founder vs. a founder with a co-founder and an accountant]
```

**Why this prompt works:** On Bogdan's scorecard, 'everyone' as the customer scores 1 out of 5 and can PARK the whole idea by itself. The next-10-customers test is the cheapest reality check that exists: if nobody can produce ten names, the beachhead is a guess wearing a suit.

**Challenge the answer:** For three names on the hypothetical list, ask: "What would make this specific person NOT buy - even though they have the problem?" The blockers you collect (trust, timing, 'my cousin knows a lawyer') are worth more than the list itself - they're week 4's differentiation homework arriving early.

### B04 · Sat · 1h · Interviews · BUSINESS TRACK — Interview practice — Mom Test, live

**Prompt (fill in the [blanks]):**

```
Live interview practice. You'll play two customers, one at a time, and I'll interview each using the Mom Test rules.

Persona 1: [design them - e.g. an e-commerce founder who registered a trademark last year through a lawyer and found it painful]
Persona 2: [design them - e.g. a SaaS founder who KNOWS they should register but keeps postponing]

Rules: stay fully in character; be realistic, not helpful - include vagueness, tangents, and one polite compliment I should ignore. I get 8 questions per persona.

Afterwards, break character and grade me: which questions followed the Mom Test rules, which were leading, and what did I NOT ask that a pro would have?
```

**Why this prompt works:** Designing the personas yourself is the fill-in-the-blank that matters: one who bought (past behavior to mine) and one who postponed (the mystery of non-buying - often the bigger market). Realistic vagueness in the role-play is what makes the practice transfer to real conversations.

**Challenge the answer:** Ask: "Which of my questions most shaped your answers?" Leading questions manufacture the data you hoped for - that's the danger in interviews AND in prompts. Then ask Claude to show you how the same interview goes with its 3 best questions instead of your weakest 3.


## Week 3 — The clickable prototype (Level 2: Fill in the blanks, 13 tasks, ~18h)

### T22 · Mon · 1h · Planning — Plan before build — the prototype kickoff

**Prompt (fill in the [blanks]):**

```
This week we build a clickable Markster prototype: landing → AI chat → summary. Before ANY code:

1. Give me your build plan - what you'd build in what order, and why that order
2. Ask me the 5 questions you need answered before starting
3. Tell me what we should deliberately leave OUT of a prototype

My answers to your questions will be the spec. Here's what I already know I want: [describe in your own words what the 3 screens should do - lean on the PRD's "Ecrane" section]
```

**Why this prompt works:** For big requests, the first deliverable is a plan, not a product. Approving plans is how you direct without coding — and answering Claude's 5 questions IS writing the spec, in interview form instead of essay form.

**Challenge the answer:** Reject one part of the plan, even if it looks fine — "do the summary screen before the chat screen" — and watch the plan adapt. Feeling the plan bend under your hands is the point: you steer this, not Claude.

### T23 · Mon · 2h · Prototype — The chat screen — heart of Markster (scripted mock)

**Prompt (fill in the [blanks]):**

```
Build the chat screen as an HTML artifact. IMPORTANT: this is a MOCK — a scripted conversation, no real AI behind it.

The script: the assistant asks about [what? - pull the questions from the PRD's Step 1: brand name, products/services, country...], the visitor picks from suggested answers or types, and the conversation ends with "checking availability...".

Make it feel real: [decide the details - typing indicator? message delays? progress dots showing step 1/2/3?]

CONSTRAINTS: same Markster design language. One HTML file.
```

**Why this prompt works:** The word MOCK, in capitals, up front, is doing heavy lifting: without it Claude may try to wire real AI in and the task balloons. Scope words — mock, scripted, placeholder, real — are among the highest-leverage words you can put in a prompt.

**Challenge the answer:** Ask: "What will be different when this is connected to a real AI? List every gap." Get the gap list NOW and save it to the Project — in week 5 you'll check items off it, and nothing about the real version will surprise you.

### T24 · Tue · 2h · Prototype — Three screens, one app: landing → chat → summary

**Prompt (fill in the [blanks]):**

```
Combine everything into one multi-screen artifact: my landing page (attached) → the chat screen → a new summary screen.

STATE THAT MUST FLOW BETWEEN SCREENS: [name it explicitly - e.g. the brand name typed in chat must appear on the summary screen; the products chosen must appear as Nice classes; the price must match the class count]

The summary screen shows: [decide from the PRD's screen 3 - the mark, the classes, the price breakdown 89 + 850...]

Navigation: [decide - can the user go back from summary to chat and change an answer? what happens then?]
```

**Why this prompt works:** Multi-screen prompts live or die on one thing: naming the state explicitly — what information travels between screens. 'The brand name from chat appears in the summary' is one sentence for you and an architecture for Claude.

**Challenge the answer:** Try to break it: go back mid-flow, refresh the page, type a 200-character brand name. Report what broke — one issue at a time, with what you did, what you expected, what you saw. That three-part shape is a professional bug report, and it's yours now.

### T25 · Tue · 1h · Prototype — Traffic light — the mock availability check

**Prompt (fill in the [blanks]):**

```
Add the availability check to the prototype, between chat and summary. MOCK again: three canned outcomes.

- 🟢 GREEN when the brand name is [pick your trigger - anything not on a small "taken" list?]
- 🟡 YELLOW when [decide - name is similar to a taken one?]
- 🔴 RED when [decide - exact match with a taken one?]

For each outcome the screen shows: [decide what the customer sees and what they can do next - continue anyway? try another name? per the PRD's Step 2]
```

**Why this prompt works:** Enumerating the cases IS the specification. You just wrote a decision table in plain English — the same thing an analyst would be paid to produce — and Claude fills in everything beneath it.

**Challenge the answer:** Ask the product question hiding in the mock: "In the real product, who decides where yellow ends and red begins?" The answer (an AI confidence threshold, and Iulia beyond it) is the actual heart of Markster's design. You've just reached it through a toy.

### T26 · Wed · 2h · Debugging — Debug Day — it breaks today, on schedule

**Prompt (fill in the [blanks]):**

```
Today I learn to handle things breaking. Three exercises with my prototype:

1. Teach me the Console: guide me to open Chrome DevTools (F12), explain what the Console shows, and let me see what a healthy page looks like there.
2. Break it on purpose: give me one small edit to make in the artifact code that will break something visibly. Let me experience the error, find it in the Console, and report it to you properly.
3. Then I'll report it using this shape: what I did, what I expected, what I saw (with the exact error text pasted). You fix it - but explain what was wrong BEFORE you show the fix.
```

**Why this prompt works:** Breaking things on purpose, once, with a guide, removes the fear permanently. The report shape — did / expected / saw + exact error text — is the universal key: every future bug, in any tool, gets reported this way.

**Challenge the answer:** Rule from the Playbook, #9, now live: "Explain what was wrong before you fix it." If the explanation doesn't make sense to you, don't accept the fix — say 'explain it differently'. A fix you don't understand is a debt you'll pay later.

### T27 · Wed · 1h · Recovery — When Claude goes in circles — the recovery moves

**Prompt (fill in the [blanks]):**

```
Sometimes a conversation stops converging - each fix breaks something else, answers get longer and less useful. Teach me the recovery moves, then we practice one:

1. Explain when to use each: (a) ask for smaller steps, (b) ask "what's the weakest part of your last answer?", (c) roll back to the last good version, (d) start a FRESH chat with a summary + the working version + one clear ask.
2. Practice move (d) with me right now: help me write the perfect fresh-start message for my prototype work, then I'll actually open a new chat with it.
```

**Why this prompt works:** Recovery is a prompting skill, not luck. The fresh-start move is the strongest and the least used, because it feels like giving up. It isn't — a clean context with a good summary routinely beats a long tangled one.

**Challenge the answer:** Compare honestly: did the fresh chat handle your next request better than the old long one would have? Notice the difference — and notice that 'starting over' took 3 minutes, not the hour you feared.

### T28 · Thu · 2h · Tracker app — Tracker v3 — into the cloud with Supabase

**Prompt (fill in the [blanks]):**

```
Big day: my tracker gets a real cloud backend, so my progress syncs across devices and Bogdan can see it. Guide me like a patient setup guide - step by step, wait for my "done" each time, explain each step's PURPOSE in one sentence before we do it:

1. Create a free Supabase account (I type all passwords, you never see them) and a project
2. Create a table for my progress - explain what the columns mean
3. Get the "anon key" - and STOP: before we use it, explain anon key vs service key like I'm new to all of this
4. Update my tracker HTML to save/load through Supabase instead of localStorage
5. Add a read-only view at ?view=bogdan - [decide what Bogdan should see - progress chart? last activity?]
```

**Why this prompt works:** This prompt turns a scary setup into a guided walk: purpose-first explanations, confirmation gates, and a hard STOP before the security-sensitive part. You wrote the safety rails into the prompt yourself.

**Challenge the answer:** Do not proceed past step 3 until you can answer, in your own words: "What could a stranger do with my anon key if I posted it publicly? And with the service key?" If your answer is fuzzy, ask again. This is Playbook question #11 guarding real stakes for the first time.

### T29 · Thu · 1h · Setup — Cowork desktop — Claude on your computer

**Prompt (fill in the [blanks]):**

```
I want to install the Claude desktop app and understand what changes when Claude runs on my computer instead of in a browser tab.

1. Guide the installation step by step
2. Before I grant ANY access: explain what you'll be able to do with it, what you can NOT do, and when you'll ask permission
3. First exercise: [pick something small and useful - e.g. create a folder called Markster on my Desktop and put a notes file in it]
```

**Why this prompt works:** Same Claude, new reach — and you're rehearsing the boundary-first habit from T15 on a bigger stage. Next week this becomes Claude Code; today's small folder exercise is the gentle on-ramp.

**Challenge the answer:** Ask: "What's the riskiest thing I could accidentally ask you to do with this access?" Knowing where the edge is makes you confident everywhere that isn't the edge.

### T30 · Fri · 1.5h · Demo — The skeptical customer test

**Prompt (fill in the [blanks]):**

```
Role-play: you are [design the persona - age, business, tech comfort, what they're afraid of - make them SKEPTICAL of putting €939 into a website].

Walk through my prototype screen by screen as that person. Think out loud. Tell me:
- where you hesitate, and why
- where you'd abandon, and what exactly triggered it
- what would make you trust this site with your money
```

**Why this prompt works:** Personas stress-test through eyes you don't have. Designing the persona yourself — their fears, not just their age — is the fill-in-the-blank that decides whether the test bites.

**Challenge the answer:** The trust question is the real one. Take the persona's trust objections and ask: "Which of these can a prototype fix, and which need the real company to fix (reviews, guarantees, a human phone number)?" That split is your feedback to Bogdan and Isi.

### T31 · Fri · 1h · Review — Week 3 review — the training wheels come off

**Prompt (fill in the [blanks]):**

```
Assemble my week 3 review: the prototype demo flow, the tracker-in-the-cloud story, my debug day report, the skeptical customer findings, three questions for Bogdan. Save as "Week 3 — learned".

Then one more thing: from next week I write ALL prompts myself. Ask me: what am I most unsure I can write a good prompt for? Then coach me on exactly that, using examples from my own last three weeks.
```

**Why this prompt works:** Naming your weakest spot before week 4 turns anxiety into a syllabus. And notice: you now have three weeks of your OWN prompts as teaching material — Claude coaches best from your history.

**Challenge the answer:** On the Friday call, drive the demo from Bogdan's read-only tracker view — let the data tell the story of three weeks of daily work.

### P02 · Fri · 1h · PRD thread · PRD THREAD — Redlines — the prototype corrects the PRD

**Prompt (fill in the [blanks]):**

```
Three weeks in, I have now BUILT what the PRD only describes: the landing page, the chat, the traffic light, the summary. Building teaches things reading can't. Help me write my first redlines:

1. Here's what I noticed while building that the PRD doesn't cover, or gets wrong: [list 3-5 things - think about: the chat question order, what happens when someone goes back mid-flow, where yellow ends and red begins, what the summary screen must show...]
2. For each one, draft the exact edit: what the PRD says now → what it should say → why, with the prototype as evidence
3. Format it as a "proposed changes" note for Bogdan - he approves or rejects each one, that's his call
4. After his answers: apply the approved edits to my copy of markster-prd-en.md, and add a changelog line at the top with today's date.
```

**Why this prompt works:** Redlining a document you've tested against reality is one of the most senior things a non-technical person does on a product team. And notice the rule inside step 3: you propose, the owner decides — the same confirmation discipline as the tracker rule in T41, applied to documents.

**Challenge the answer:** Ask: "Which of my redlines would a trademark expert like Iulia push back on, and why?" The PRD serves three masters - customers, builders, and the legal reality of EUIPO. An edit that helps one can quietly break another; finding that tension yourself is the review before the review.

### B05 · Sat · 1.5h · Market · BUSINESS TRACK — How big, how urgent — scoring the problem

**Prompt (fill in the [blanks]):**

```
Business Saturday #3: is this problem worth solving? Two frameworks today.

1. Y Combinator's 6 problem traits (Kevin Hale): Popular, Growing, Urgent, Expensive, Mandatory, Frequent. Explain each in one sentence, then I'll score Markster's problem on each, 1-5, with my evidence: [do the scoring yourself - use the PRD numbers and our week-2 competitor research]. Challenge every score where my evidence is thin.
2. Sequoia's three kinds of product-market fit: "hair on fire" (urgent, crowded market), "hard fact" (known problem, no good solution), "future vision" (they don't know yet). Which one is Markster? I say it's [your pick] because [your reasoning]. Argue with me.
3. Size, bottom-up: ~197,000 EU trademark applications per year, roughly 60% from small businesses. Walk me through what slice Markster could realistically address - and what number would make this exciting vs. merely fine.
```

**Why this prompt works:** YC's six traits turn 'is this a real problem?' from a feeling into a checklist - a problem doesn't need all six, but it needs 2-3 strong ones with evidence. And the Sequoia archetype determines the whole go-to-market: a hard-fact product sells by convincing, a hair-on-fire product sells by differentiating.

**Challenge the answer:** Whichever archetype you picked, ask Claude to argue Markster is one of the OTHER two, as convincingly as it can. Then decide which argument actually survives contact with the evidence. Holding your position against a good counter-argument - or updating it - is the score that matters today.

### B06 · Sat · 1h · Timing · BUSINESS TRACK — Why now? — the timing question

**Prompt (fill in the [blanks]):**

```
Every good idea has a "why now" - something that recently changed that makes the old solutions beatable. Today we find Markster's.

1. Here's my list of what changed: [write it - think: EUIPO's free APIs, AI conversation quality, the SME Fund reimbursing fees, the cost of building software collapsing]. For each, challenge me: is this genuinely NEW, and does it genuinely matter?
2. Now play devil's advocate, hard: "If the timing is so good, why hasn't Trama - who already has customers and lawyers - built this? Why won't they copy it in 3 months once Markster launches?"
3. End with one honest paragraph: Markster's why-now, written like we'd say it to an investor who has heard a thousand why-nows.
```

**Why this prompt works:** 'Why now' separates ideas whose time has come from ideas that are merely nice. The devil's advocate question - why hasn't the incumbent done it - has only a few honest answers (they can't, they won't, they don't see it), and knowing which one applies to Markster shapes everything about speed and secrecy.

**Challenge the answer:** Pick the strongest claim in your why-now (probably the SME Fund dates or the EUIPO API terms) and verify it at the source, yourself, today. A why-now built on an expired program is a why-then. This is the B-track version of the week-1 fee-checking lesson: timing claims age faster than any other kind.


## Week 4 — Claude Code: commanding a builder (Level 3: You write the prompts — checklist + hidden reference, 13 tasks, ~17h)

### T32 · Mon · 1.5h · Setup — Install Claude Code — meet the builder

**Mission:** Get Claude Code installed and running, and understand — before building anything — how it differs from the Claude you've used for three weeks.

**Your prompt must cover:**
- Who you are and that you want step-by-step guidance with confirmation gates
- Ask what Claude Code can do that claude.ai chat cannot — and what's riskier about it
- Ask how to verify the installation actually worked
- Ask where its 'permission questions' will appear and what your options are

**Reference prompt (write yours first):**

```
I'm Howard - you know me from three weeks of Markster work, but this is my first Claude Code session. Before anything else:

1. Confirm you're installed correctly - run whatever check proves it and show me the result
2. Explain: what can you do here that the claude.ai website cannot? And what's RISKIER here? Be specific about files.
3. Explain your permission system: when will you ask before acting, and what are my choices?
4. Then just say hello and wait. No building today until I understand the ground rules.
```

**Why this prompt works:** From today you write every prompt. Notice what the checklist keeps insisting on: boundaries before power. Claude Code can create and change real files on your computer — the five minutes spent on ground rules is what makes the next three weeks fearless.

**Challenge the answer:** Ask: "What's the worst thing that could happen if I approve requests without reading them?" Then set your personal rule: you read every permission request out loud before approving. Yes, out loud. It works.

### T33 · Mon · 1h · Basics — Files, folders, and the truth about the terminal

**Mission:** Using only plain-English requests, have Claude Code create a Markster project folder, put a test file in it, show it to you, and delete the test file — while showing you every command it runs.

**Your prompt must cover:**
- Ask it to show and explain each command BEFORE running it
- Create a folder for the Markster project in a place you choose
- Create, view, and delete a test file
- Ask what the terminal actually is, now that you've seen it used

**Reference prompt (write yours first):**

```
Let's learn the basics, slowly. For everything in this session: show me the command you intend to run and explain it in one sentence BEFORE running it.

1. Create a folder for our Markster project at [where you want it]
2. Inside, create a file called hello.txt containing one sentence
3. Show me the file exists and what's in it
4. Delete hello.txt - and tell me: is it in the trash, or gone forever?
5. Finally: I've now watched you use the terminal. Explain what the terminal IS, in plain English, using the commands I just saw as examples.
```

**Why this prompt works:** 'Show and explain before running' turns every command into a tiny lesson — the terminal stops being a hacker screen and becomes what it is: chat with your computer, in a stricter grammar. The delete question in step 4 matters: command-line deletion usually skips the trash.

**Challenge the answer:** Ask: "If I typed these commands myself and made a typo, what's the worst that could happen?" The answer teaches you why you delegate typing to Claude — and why you still read what it types.

### T34 · Tue · 2h · Build — The tracker becomes a real project

**Mission:** Move your tracker app from a claude.ai artifact into real files in your Markster folder, open it in Chrome from disk, and make one small improvement to prove the loop works.

**Your prompt must cover:**
- Give Claude Code the current tracker HTML (paste it or point to the downloaded file)
- Ask for the file structure it recommends and why
- Ask how to open it in Chrome and verify Supabase sync still works
- One small improvement, with 'keep everything that works'

**Reference prompt (write yours first):**

```
Here's my tracker app, currently one HTML file from claude.ai (attached/pasted). Move it into the Markster folder as a proper little project:

1. Propose a file structure first - and justify it in plain English. One file or several? Why?
2. Set it up, then tell me exactly how to open it in Chrome
3. I'll verify myself that my checkmarks and the Supabase sync still work - wait for my confirmation
4. Then one improvement: [your choice]. Keep everything that already works.
```

**Why this prompt works:** The verify-myself step (3) is the new habit for the Claude Code era: after every migration, YOU confirm the old behavior survived, before any new behavior gets added. Claude waits; you test; then you proceed.

**Challenge the answer:** Ask: "If I delete this folder by accident, what do I lose — and what does the claude.ai artifact version still have?" The answer sets up tomorrow's task: real files need real save-points.

### T35 · Tue · 1h · Git — Save points — git without tears

**Mission:** Have Claude Code set up git in your project, make your first commits, view the history, and — the important part — deliberately roll back and return, so you feel that undo is real.

**Your prompt must cover:**
- Ask for a plain-English explanation of git as save-points, using your project
- First commit of the tracker as it is now
- Make a change, commit again, view the history
- Roll back to the first commit, look around, then return to the latest

**Reference prompt (write yours first):**

```
Teach me git by doing, on my real project:

1. Explain git in plain English first - I've heard it's "save points for your work"; is that right? What's a commit, in one sentence?
2. Set it up in the Markster folder and make our first commit
3. I'll change something small in the tracker with you - commit again with a message that says what changed
4. Show me the history in a way a human can read
5. Now the real lesson: roll us back to the first save point. Let me SEE the change is gone. Then bring us back to the latest. Prove nothing was lost.
```

**Why this prompt works:** Step 5 is the whole task. Reading about undo changes nothing; performing a rollback and safe return once changes how brave you are forever after. If you can always go back, you can always dare.

**Challenge the answer:** Ask: "What can git NOT undo?" (Hint: files never committed, and things outside the folder — like your Supabase data.) Knowing the limits of the safety net is part of trusting it.

### T36 · Wed · 1.5h · Memory — CLAUDE.md — the rulebook of your project

**Mission:** Write the project's standing rules with Claude: what Markster is, the design constants, and how you want Claude Code to behave with you — then prove the file actually works.

**Your prompt must cover:**
- What Markster is + where the PRD lives, so every session starts oriented
- Design constants (pink #E8386F, Inter, the tone)
- Your working rules: explain before big changes, ask before deleting, plain English, define jargon
- A rule about mocks: EUIPO and payments stay mocked unless Howard says otherwise

**Reference prompt (write yours first):**

```
Let's write the CLAUDE.md for the Markster project - the rulebook you'll read at the start of every session. Draft it together with me, covering:

1. WHAT THIS IS: Markster in three lines, where the PRD is, that Howard directs and Claude builds
2. DESIGN: pink #E8386F, Inter, clean cards - the constants every screen follows
3. HOW WE WORK: plan before big changes; ask before deleting anything; explain in plain English; define jargon on first use; one change at a time on working code
4. SCOPE: EUIPO and payments are MOCKED. Never wire real payment or filing without an explicit request from me.

Draft it, let me edit, then save and commit it.
```

**Why this prompt works:** CLAUDE.md is your custom-instructions trick from week 1, graduated to the project level. Everything you've learned to ask for in every prompt — plain English, plan first, keep what works — now gets written once and enforced always.

**Challenge the answer:** Test it like you tested the Project in T03: start a completely fresh session and give a lazy, rule-free instruction ("add a button to the tracker"). Does Claude follow the rulebook unprompted — plan first, plain English? If not, ask which rule needs firmer wording, fix it, commit it.

### T37 · Wed · 1h · Planning — Plan mode — approve before it builds

**Mission:** Use plan mode for a medium-sized feature: read the plan critically, change one thing in it, approve it, and only then let Claude build.

**Your prompt must cover:**
- Ask Claude Code to explain plan mode and when to use it
- Request a feature big enough to deserve a plan (e.g. a weekly progress chart in the tracker)
- Read the plan and change at least one step before approving
- After the build: verify against the plan — did it do what it said?

**Reference prompt (write yours first):**

```
I want to learn plan mode on a real feature: add a simple weekly progress chart to my tracker (hours done vs planned, per week).

1. First explain: what is plan mode, and when should I insist on it?
2. Enter plan mode and show me your plan for this feature
3. Wait - I'll read it and I may change parts of it before approving
4. After building: walk me through what you did versus what the plan said. Any differences? Why?
```

**Why this prompt works:** Plans are where you exercise judgment without technical skill: order, scope, and 'why this step?' are all readable in plain English. Step 4 closes the loop — comparing the plan to the delivery is how a director checks a contractor.

**Challenge the answer:** Find one step in the plan you don't understand and refuse to approve until it's explained to your satisfaction. That's not slowing things down. That IS the job — and it's Playbook rule 'you are the supervisor' with real teeth.

### T38 · Thu · 2h · Build — The real Markster app — the skeleton

**Mission:** Scaffold the actual Markster application with Claude Code — a real project with the landing page from week 2 as its first working page, running on a local dev server you can see in Chrome.

**Your prompt must cover:**
- Point to the prototype work and the PRD as the source of truth
- Ask Claude to choose the technical stack and justify it in plain English — including what it did NOT choose and why
- The landing page from week 2 becomes the first real page
- Ask how to start and stop the dev server yourself, and write those steps down

**Reference prompt (write yours first):**

```
Today we start the real Markster app. Use plan mode.

CONTEXT: everything we've built - the landing page, the 3-screen prototype, the PRD in the docs folder. CLAUDE.md rules apply.

1. Choose the stack for a web app that will have: several screens, a Supabase database, mocked EUIPO/payments, and deployment to a public URL in week 6. Justify the choice in plain English - and tell me what you considered but rejected, and why.
2. Plan the scaffold, wait for my approval
3. Build it with the week-2 landing page as the first real page
4. Teach me to start and stop the dev server myself, and put those instructions in the README
```

**Why this prompt works:** 'What did you NOT choose and why' is the strongest form of 'give me options with trade-offs' — it forces the reasoning into the open even after a decision. And insisting on operating the dev server yourself keeps you the owner of your own app, not a spectator.

**Challenge the answer:** Make Claude defend the stack: "What would a professional developer like Prodi say about this choice? What would he have picked?" You can't judge the stack technically — but you CAN judge whether the defense is coherent. That's exactly the judgment executives use.

### T39 · Thu · 1h · Verification — Trust, but verify — reading Claude's reports

**Mission:** Turn 'done ✅' from a claim into evidence: establish your personal verification routine for everything Claude Code reports as finished.

**Your prompt must cover:**
- Ask, about yesterday's scaffold: what did you actually test vs assume?
- Have Claude propose a verification checklist for 'a page is done'
- Run the checklist yourself on the landing page — clicks, mobile size, reload
- Decide together what proof future 'done' reports must include

**Reference prompt (write yours first):**

```
Yesterday you reported the scaffold done. Today I learn not to take that on faith - nothing personal.

1. About yesterday: what did you actually TEST, and what did you ASSUME works? Honest list, two columns.
2. Propose a "definition of done" checklist for any page we build: what should I personally check every time?
3. I'll run it on the landing page right now - stay with me and help me interpret anything odd.
4. New standing rule for CLAUDE.md: every "done" report from you must include what was tested and what wasn't. Draft the rule, I'll approve, commit it.
```

**Why this prompt works:** The two-column answer in step 1 is always revealing — there are ALWAYS assumptions. Step 4 turns today's lesson into permanent infrastructure: you're not just learning verification, you're installing it into the project's rulebook.

**Challenge the answer:** Keep a tally this week: how many times does your personal check find something the report missed? Even one is the lesson. Report the tally to Bogdan on Friday — it's the most senior-sounding thing you'll say all week.

### T40 · Fri · 1.5h · Build — The chat screen joins the app

**Mission:** Bring the scripted chat flow from the week-3 prototype into the real app as a proper page, wired to the landing page's Start button.

**Your prompt must cover:**
- Point to the prototype chat as the reference for behavior and script
- Plan mode, since this touches multiple files
- State what must survive: the script, the feel (typing indicator, steps), the mock-ness
- Verify with your T39 checklist before accepting done

**Reference prompt (write yours first):**

```
Bring the chat screen from our week-3 prototype into the real app. Plan mode.

- Reference: the prototype's chat (attached) - same script, same feel, still a MOCK
- The landing page's "Start your free check" button now leads here
- What must not change: the conversation script, the typing indicator, the step progress
- When you report done, use our new done-format - tested vs assumed - and I'll run my checklist before we commit
```

**Why this prompt works:** This prompt is short because the infrastructure you built all week is carrying the weight: CLAUDE.md holds the rules, plan mode structures the work, the done-format structures the report. Good process makes prompts shorter — that's the sign it's working.

**Challenge the answer:** Ask: "What did you reuse from the prototype and what did you rewrite? Why?" The answer teaches you how prototypes relate to real apps — and whether your three weeks of artifact work was foundation or throwaway. (Spoiler: foundation.)

### T41 · Fri · 1h · Integration — Teach Claude to tick your tracker

**Mission:** Wire your two worlds together: teach Claude Code to mark tasks done in your Supabase tracker through its API — but only ever after you say so. Your first time watching two systems talk to each other.

**Your prompt must cover:**
- Give Claude Code the tracker's Supabase table details and anon key — the same database your tracker page uses
- THE RULE, in the prompt AND added to CLAUDE.md: Claude never marks a task done without your explicit confirmation
- A live test: mark this very task done from the terminal, then open the tracker page and watch the checkmark appear
- Ask to see the actual API call before it's sent — what does one look like up close?

**Reference prompt (write yours first):**

```
My tracker app stores my progress in Supabase (table name and anon key attached). I want you to be able to tick my tasks for me:

1. Explain first: how would you, from this terminal, change a row in my tracker's database? What IS an API call, up close? Show me the exact request you intend to send BEFORE sending anything.
2. THE RULE, forever: you only mark a task done after I explicitly say "mark T-something done". Never on your own judgment, even if we obviously finished it. Add this rule to CLAUDE.md now.
3. Live test: mark T41 as done. Then I'll open my tracker page in Chrome and watch the checkmark appear - the same checkmark I've been clicking by hand for four weeks.
4. New habit: at the end of every session, ask me which tasks we finished, and tick them only after my confirmation.
```

**Why this prompt works:** The plan is eating its own cooking: week 2's API research and week 3's anon-key lessons combine into something you'll use every day. And the confirmation rule is this whole curriculum in one line — Claude performs the motion, Howard makes the call.

**Challenge the answer:** Ask: "Could you also UN-tick a task? Could you wipe my whole progress? What actually stops you?" The honest answer — nothing but the rule and your supervision — is worth sitting with. It's exactly why the rule lives in CLAUDE.md and not just in your head.

### T42 · Fri · 1h · Review — Week 4 review — commanding vs doing

**Mission:** Assemble the week 4 review with a special theme: what changed when you moved from chatting to directing a builder. Demo the running app and the git history to Bogdan.

**Your prompt must cover:**
- The demo path: dev server on, landing → chat, git log as the week's story
- Your verification tally from T39
- One moment you refused to approve something — and what happened
- Save 'Week 4 — learned' both in the Project and as a file in the repo

**Reference prompt (write yours first):**

```
Assemble my week 4 review for Bogdan:

1. Demo script: start the dev server, walk landing → chat, then show the git history as the story of the week
2. My verification tally: times my personal check caught something the "done" report missed
3. The story of the plan step I refused to approve until explained
4. Three questions for Bogdan
5. Save it as "Week 4 - learned" in the claude.ai Project AND as docs/week4.md in the repo - our history lives in both places now.
```

**Why this prompt works:** The git log as narrative is a beautiful trick: your week of work, told by its save-points. And storing the review in the repo starts the documentation habit that week 6's README for Prodi will depend on.

**Challenge the answer:** Ask Claude before the call: "Based on this week, where do I still act like a passenger instead of a director?" Bring the honest answer to Bogdan. Naming your passenger-moments is how they end.

### B07 · Sat · 1.5h · Differentiation · BUSINESS TRACK — The unfair advantage audit

**Mission:** Run Y Combinator's five unfair advantages over Markster, grade each honestly with evidence, and end with the one-sentence answer to 'why do WE win?'

**Your prompt must cover:**
- The five categories explained and then graded: founders, market, product, acquisition, monopoly
- Evidence per grade — the week-2 competitor table and the PRD are your sources, not vibes
- Harsh grading rules stated up front: 'a bit better' scores zero; only 10x or unique counts
- The closing line: why Markster wins, one sentence, no hedging

**Reference prompt (write yours first):**

```
The unfair advantage audit. Be harsh - flattery ruins this exercise.

1. Explain YC's five unfair advantages: founders (are we among the few who CAN build this?), market (growing 20%+/year?), product (10x better, not slightly better?), acquisition (can we get customers free/organically?), monopoly (does it get stronger as it grows?).
2. Grade Markster on each, 0-5, with evidence from our competitor research and the PRD. Grading rules: "a bit better" = 0. "We work hard" = 0. Only unique or 10x counts.
3. My own guesses before you grade: [write yours - e.g. the direct EUIPO API integration, Iulia as legal rep, the price]. Tell me where I'm flattering us.
4. Close with one sentence, no hedging: why does Markster win?
```

**Why this prompt works:** By week 4 you write these prompts yourself - and notice what the checklist forces: grading rules BEFORE grading, evidence sources named, and a ban on hedging in the conclusion. The audit only works if 'a bit better' scores zero; almost every founder's list of advantages evaporates under that one rule, and what survives is the real strategy.

**Challenge the answer:** Ask: "Which of our surviving advantages would evaporate first - if EUIPO changed its API terms, if Trama dropped prices 30%, if a lawyer network launched an AI tool?" An advantage someone else can switch off is a dependency wearing an advantage's clothes. Note which ones those are; they feed next Saturday's pre-mortem.

### B08 · Sat · 1h · Pre-mortem · BUSINESS TRACK — Pre-mortem — how Markster dies

**Mission:** Run a pre-mortem: it's 18 months from now and Markster is dead. Write the five most likely obituaries, ranked, each with the early-warning sign we should watch for — and check which deaths our current metrics wouldn't even detect.

**Your prompt must cover:**
- The pre-mortem frame set explicitly: assume it's ALREADY dead, explain why — no hedging into 'might'
- Five causes of death, ranked by likelihood, each with its earliest visible warning sign
- Cross-check against the riskiest assumptions (Teresa Torres style): which assumption failing causes which death
- The uncomfortable finale: which deaths would the PRD's success metrics fail to detect in time

**Reference prompt (write yours first):**

```
Pre-mortem. The frame: it is 18 months from now. Markster launched, struggled, and shut down. You are writing the honest post-mortem.

1. Write the 5 most likely causes of death, ranked. Full sentences, past tense, no "might have" - it already happened, tell me why.
2. For each death: what was the EARLIEST visible warning sign, and in which month would we have seen it?
3. Map each death to the assumption that failed (customers don't trust AI with legal? the 89 EUR fee can't fund acquisition? EUIPO changed the rules?).
4. Now open the PRD's success metrics table and tell me: which of these five deaths would those metrics NOT have caught in time? What should we watch instead?
```

**Why this prompt works:** A pre-mortem beats a risk list because pretending it already failed makes everyone honest - 'might struggle' becomes 'died because'. And step 4 is the rare question almost nobody asks: whether the dashboard we're proudly building would even show the disease before the funeral.

**Challenge the answer:** Pick the number-one cause of death and ask: "What would we do THIS MONTH, cheaply, to test whether this is actually happening?" A pre-mortem that doesn't change next month's to-do list was just scary storytelling. Bring the answer to Bogdan on Friday - it's real input for the actual Markster team.


## Week 5 — Markster end-to-end (Level 3: You write the prompts, 13 tasks, ~18h)

### T43 · Mon · 2h · Build — Summary & pricing — the money screen

**Mission:** Build the summary/review screen in the real app: the mark, the Nice classes, and a price that calculates itself correctly from the class count (€850 first class, +€50 second, +€150 each additional, +€89 service).

**Your prompt must cover:**
- The pricing rules stated exactly, from the PRD — don't make Claude guess money
- What flows in from the chat screen (brand name, classes)
- Plan mode + the done-format
- Your own test plan for the math before you accept it

**Reference prompt (write yours first):**

```
Build the summary & review screen. Plan mode.

- Shows: the mark (from chat), the Nice classes with their goods/services, the applicant details, and the price breakdown
- PRICING RULES (exact, from the PRD): EUR 89 service fee + EUR 850 EUIPO first class + EUR 50 for the second class + EUR 150 for each class from the third up. Show the math itemized.
- The customer can go back and change answers; the price recalculates
- Done-format report, then I test the money myself before we commit
```

**Why this prompt works:** Money is where 'roughly right' dies. Notice the prompt doesn't say 'price it correctly' — it states the exact rules. For anything with numbers-that-matter, the rules go IN the prompt, verbatim, even when the PRD is in the project. Redundancy on money is professionalism, not distrust.

**Challenge the answer:** Test the math yourself: 1 class (939?), 2 classes (989?), 3 classes (1139?), 6 classes. Work them out on paper first, THEN compare to the screen. If any differ, this is the best bug you'll ever find — wrong money is a dead product, and you caught it.

### T44 · Mon · 1h · Build — The state machine lives

**Mission:** Put the 12 application statuses from the PRD into the app as real code, with the legal transitions between them — then have Claude quiz YOU on it.

**Your prompt must cover:**
- Point to the PRD's state machine table as the single source of truth
- Ask what an application 'is' in code, in plain English
- The rule that some transitions are forbidden (no going back from Paid to Draft)
- End with a role reversal: Claude quizzes you, 5 questions

**Reference prompt (write yours first):**

```
Implement the Markster state machine - the 12 statuses from the PRD's table, with the allowed transitions.

- Source of truth: the PRD table. If anything in it seems ambiguous to you, ask me instead of deciding.
- Explain to me in plain English: what IS an application in our code now?
- Enforce the forbidden moves - e.g. once Paid, never back to Draft
- Then flip roles: quiz me with 5 questions about our state machine, one at a time, and grade me honestly.
```

**Why this prompt works:** 'If anything seems ambiguous, ask me instead of deciding' is the professional's clause — it routes judgment calls to the human. And the quiz at the end catches the classic trap of delegation: the builder understanding your product better than you do.

**Challenge the answer:** Ask: "Which transitions did you NOT implement, and why?" There are always judgment calls hiding in a table (what happens to Needs Info if the client never answers?). Every skip should be a decision you ratified, not an accident you discover later.

### T45 · Tue · 2h · Build — Client dashboard — 'where's my trademark?'

**Mission:** Build the customer's dashboard: a visual timeline of their application moving through the statuses, with mock application data, and a clear next action in every state.

**Your prompt must cover:**
- The PRD's screen 6 as reference
- Mock applications in several different statuses so you can see every variant
- Your quality bar: in every status, the customer knows what happens next
- Done-format + your checklist

**Reference prompt (write yours first):**

```
Build the client dashboard. Plan mode.

- Reference: PRD screen 6. A timeline showing where the application is among the 12 statuses, what's done, what's next
- Seed it with mock applications in at least 5 different statuses so we can see the variants
- MY QUALITY BAR: in every single status, the screen must answer "what happens next, and do I need to do anything?" If a status has no clear answer, the screen isn't done
- Done-format, then I'll click through every status myself
```

**Why this prompt works:** 'My quality bar' is a new block worth keeping forever: one sentence that defines done in the customer's terms, not the builder's. It gives Claude a target no checklist of features can express.

**Challenge the answer:** Walk every status as the skeptical customer from T30: in which status would you feel abandoned? (Classic answer: Published — three months of silence during the opposition period.) Ask Claude how the screen should handle long quiet periods. That's product thinking, and it's now yours.

### T46 · Tue · 1h · Build — Mock EUIPO search — the traffic light gets real-ish

**Mission:** Replace the prototype's canned availability check with a proper mock: a small invented database of existing marks, similarity logic, and the green/yellow/red outcome wired into the real flow.

**Your prompt must cover:**
- A mock dataset of ~20 invented existing trademarks in various classes
- Plain-English explanation of how 'similar' is decided in the mock
- The three outcomes wired into chat → summary for real
- The gap list from T23 — check off what this closes, note what stays open

**Reference prompt (write yours first):**

```
Upgrade the availability check from canned to a real mock:

1. Create a small fake database of ~20 invented trademarks across a few Nice classes
2. Implement a simple similarity check - explain your approach in plain English before coding it (exact match? similar spelling? same class matters?)
3. Wire the 🟢🟡🔴 outcomes into the real flow: chat → check → summary
4. Then open our gap list from week 3 (T23): which gaps does this close? Which remain for the real EUIPO API? Update the list in docs.
```

**Why this prompt works:** Step 4 is the payoff of week 3's discipline: the gap list you banked then becomes today's acceptance criteria. Past-you keeps making present-you look organized — that's what the docs folder is for.

**Challenge the answer:** Ask: "What will the real EUIPO API return that our mock can't simulate?" (Phonetic similarity, figurative marks, half a million real records...) The honest answer belongs in the README for Prodi — write it there now, not in week 6.

### T47 · Wed · 2h · Backend — Supabase joins the app — real data, real database

**Mission:** Connect the Markster app to its own Supabase project: applications created in the chat flow get stored, and the dashboard reads real rows instead of hardcoded mocks.

**Your prompt must cover:**
- A new Supabase project for Markster (separate from the tracker's) — you create it, Claude guides
- What gets stored: the application, its status, its history
- The dashboard now reads from the database
- Your T28 key-safety questions, asked again unprompted — this time it's the product's data

**Reference prompt (write yours first):**

```
Connect Markster to a database. Plan mode, patient-guide style like our tracker setup:

1. Guide me through creating a NEW Supabase project just for Markster (I type all credentials)
2. Design the tables: applications, their status, their status history. Explain each column's purpose in one sentence.
3. The chat flow saves a real application; the dashboard reads real rows
4. Before we touch keys: same drill as the tracker - which key goes where, and what's safe to expose? I want to answer this myself first; check me.
```

**Why this prompt works:** Step 4's 'I want to answer this myself first; check me' is the graduation version of the explain-back loop — you're now using Claude to verify YOUR understanding instead of asking it to explain again. That inversion is what week 6's playbook will be full of.

**Challenge the answer:** Open the Supabase table editor in your browser and find the exact row your test application created. Seeing your app's data with your own eyes, in the raw table, is the moment 'backend' stops being a word and becomes a place. Screenshot it for Friday.

### T48 · Wed · 1h · Security — Where does my data live? — the security walk

**Mission:** Have Claude walk you through the complete journey of one application's data — browser to database and back — and interrogate what a stranger could see or do.

**Your prompt must cover:**
- The full data journey in plain English, one hop at a time
- What's visible in the browser's source to anyone
- What Row Level Security is and whether you need it yet
- Concrete answers, not reassurance — 'nothing' is not an acceptable answer

**Reference prompt (write yours first):**

```
Security walk. No code changes today - just truth:

1. Trace one application's data journey: from the customer's keyboard, through our app, into Supabase, back to the dashboard. One hop at a time, plain English.
2. What can a stranger reading our page's source code see? What could they DO with it?
3. Explain Row Level Security and give me a straight recommendation: do we need it before the team demo, or is it Prodi's job later?
4. Rule: I don't accept "nothing to worry about". Every answer names something specific, even if small.
```

**Why this prompt works:** 'I don't accept nothing-to-worry-about' forces specificity — the security version of banning praise in T13. You can't evaluate the technical details, but you CAN evaluate whether the answers are concrete. Vague reassurance is the red flag, in AI and in contractors alike.

**Challenge the answer:** Whatever the RLS recommendation is, make Claude argue the opposite for one paragraph, then decide. Deciding a real security trade-off — with full information, in plain English — is something most people twice as technical as you never actually do.

### T49 · Thu · 2h · Build — The team's screens — Isi's dashboard & Iulia's queue

**Mission:** Build light versions of the two internal screens: Isi's operator dashboard (all applications, statuses, simple metrics) and Iulia's expert review queue (flagged applications with approve/reject).

**Your prompt must cover:**
- PRD screens 7 and 8 as reference — light versions, and say what 'light' excludes
- Reachable at /admin (no login yet — note it as a known gap)
- Mock a few flagged applications so Iulia's queue isn't empty
- Ask what was skipped from the PRD versions — every skip a decision

**Reference prompt (write yours first):**

```
Build the internal screens, light versions. Plan mode.

1. Isi's operator dashboard (PRD screen 7): list of all applications from our database, filter by status, and three simple numbers up top - total, paid, flagged
2. Iulia's review queue (PRD screen 8): flagged applications with the flag reason, and approve / needs-info / reject buttons that actually move the status
3. "Light" means: skip exports, skip charts. Tell me anything ELSE you're skipping from the PRD screens - I want every skip to be my decision
4. No login yet - add it to the known-gaps list in docs. Seed 3 flagged applications so the queue is alive.
```

**Why this prompt works:** Defining 'light' yourself — and demanding disclosure of any additional skips — is scope control, the hardest part of directing builders. The skips are where products silently drift from their spec; you've routed them all through your desk.

**Challenge the answer:** Use Iulia's queue to approve one flagged application, then watch it move in Isi's dashboard AND the client dashboard AND the database row. One action, three visible consequences — trace all three yourself. If any doesn't update, you've found a real integration bug the 'done' report missed.

### T50 · Thu · 1h · Understanding — Guided tour of your own codebase

**Mission:** Have Claude walk you through the Markster codebase like a museum guide — every folder, what lives there and why — and ask at least five real questions along the way.

**Your prompt must cover:**
- Folder by folder, plain English, purpose before contents
- Connect each part to something you built ('this is the chat script from week 3')
- Your five questions asked as they arise, not saved for the end
- End by explaining the structure back in your own words

**Reference prompt (write yours first):**

```
Give me the guided tour of our codebase. Museum-guide style:

- Folder by folder: what lives here, why it's separate, and which week of our work it came from
- I'll interrupt with questions as we go - at least five, that's a promise
- At the end, I'll explain the whole structure back to you in my own words. Correct me kindly.
- One extra: which file would you be most nervous about a beginner editing, and why?
```

**Why this prompt works:** You'll never write this code, but owning the map of it changes your questions forever after — 'is that in the state machine or the dashboard?' is a director's question. The explain-back finale is T09's loop, now applied to a codebase you commissioned.

**Challenge the answer:** Pick one file at random from the tour and ask: "What breaks if I delete this?" Then — with git as your safety net from T35 — actually delete it, see the app break, and restore it. Controlled demolition: the deepest possible proof that you understand both the structure and the undo.

### T51 · Fri · 1.5h · QA — Bug hunt Friday

**Mission:** Spend an hour genuinely trying to break Markster — weird inputs, wrong orders, refreshes mid-flow — writing every finding as a proper report, then direct the fixing of the top three.

**Your prompt must cover:**
- A written issues list, each in the did/expected/saw format from T26
- Your severity ranking — you decide what matters most
- Fixes one at a time, 'explain what was wrong first', keep-what-works
- Re-test after each fix, including the things NEAR the fix

**Reference prompt (write yours first):**

```
Bug hunt. First me, then you:

1. I've spent an hour trying to break the app. Here are my findings, in did/expected/saw format: [your list]
2. Help me rank them by severity - but I have final say on the order
3. Fix the top 3, ONE at a time: explain what was wrong before fixing, keep everything that works, and after each fix tell me what else your change could have affected so I can re-test exactly that
4. The rest go into a known-issues file in docs, honestly written.
```

**Why this prompt works:** 'Tell me what else your change could have affected' is the mature version of question #10 — you're asking for the blast radius BEFORE testing, so your re-test is targeted instead of blind. A known-issues file, honestly kept, is worth more to Prodi than a false 'no bugs'.

**Challenge the answer:** For one fix, ask: "Could this fix have broken something that used to work? What did you re-check?" Then re-check one of those things yourself anyway. Your verification tally from T39 continues — bring the week's total to Bogdan.

### T52 · Fri · 1h · Review — Week 5 review + first Loom to Isi

**Mission:** Record a five-minute Loom demo of the full Markster flow for Isi — scripted and rehearsed with Claude — and run the week 5 review with Bogdan.

**Your prompt must cover:**
- A demo script: the customer journey first, then the team screens
- Rehearse once with Claude as audience, get cuts — five minutes is a constraint
- What to say about mocks, honestly, without underselling
- Week 5 notes saved in both homes (Project + repo)

**Reference prompt (write yours first):**

```
Help me ship my first Loom to Isi:

1. Write a 5-minute demo script: customer journey (landing → chat → traffic light → summary → dashboard), then Isi's dashboard and Iulia's queue with the approve-flow
2. One honest sentence about what's mock and what's real - confident, not apologetic
3. I'll rehearse it to you once - time me, then cut whatever doesn't fit in five minutes
4. Then assemble the week 5 review for Bogdan: verification tally, bug hunt results, the Supabase screenshot story. Save in Project + docs/week5.md.
```

**Why this prompt works:** 'Confident, not apologetic' matters: mocks are method, not shortfall (remember the Markster tab). The rehearsal with cuts is Claude as your speaking coach — a use you'll keep long after this plan ends.

**Challenge the answer:** After sending the Loom, ask Claude: "What questions will Isi most likely ask after watching this?" Prepare answers for the top three. Anticipating your audience's questions is the last skill of a demo — and the first skill of a leader.

### P03 · Fri · 1h · PRD thread · PRD THREAD — PRD v2 — the builder's edition

**Mission:** Produce PRD v2: merge your accumulated questions and redlines, the truths the real app taught you, and the business track's findings into a revised PRD with a changelog — the version Prodi will actually receive in week 6.

**Your prompt must cover:**
- Everything accumulated: the P01 answers, the approved P02 redlines, and the judgment calls made while building the state machine and dashboards this week
- Cross-examination against the business track: do the PRD's targets survive B10's Revenue Reality Check? Does its customer match B03's beachhead? Note every tension honestly
- A changelog at the top — one line per change, each naming its evidence
- Bogdan approves the diff before it becomes docs/prd-v2.md — propose, don't decide

**Reference prompt (write yours first):**

```
PRD v2 day. In Claude Code, with the repo open:

1. Gather my PRD thread: the week-1 questions and Bogdan's answers, the approved week-3 redlines, and everything the real build taught us since - the state machine judgment calls from T44, the dashboard gaps, the mock-vs-real list from docs
2. Cross-examine the PRD against the business track: do the success metrics survive the Revenue Reality Check from B10? Does the beachhead from B03 match the PRD's customer? List every tension - honestly, no smoothing
3. Draft PRD v2 as docs/prd-v2.md: same structure, updated content, changelog at the top - one line per change, each naming its evidence
4. Produce a clean summary of the differences for Bogdan. He approves before we commit. My name goes in the changelog as co-author - after five weeks, I've earned it.
```

**Why this prompt works:** The graduation of the document thread: the PRD you were once nervous to read now carries your name in its changelog. Step 2 is where this plan's two tracks finally meet on paper — the app you built and the business you analyzed, reconciled in one document.

**Challenge the answer:** Ask: "What in v2 will Prodi STILL find ambiguous?" - then fix the top answer before it ships. The test of a PRD is never whether its authors understand it; it's whether the next stranger does. Prodi is your next stranger.

### B09 · Sat · 1.5h · Economics · BUSINESS TRACK — Unit economics — the profit formula

**Mission:** Work out the profit math of ONE Markster customer: what they pay, what they cost to win and serve, LTV vs CAC — and face the uncomfortable question of the one-time €89 fee.

**Your prompt must cover:**
- The money anatomy of one sale: €939 in, €850 straight to EUIPO — where does the €89 have to stretch?
- CAC estimated per channel (cold outreach, SEO/content, referrals, paid ads) with realistic conversion rates
- LTV honestly: is this a one-shot €89, or is there renewal (10 years), monitoring upsell, referral value?
- The Aulet test applied: LTV ≥ 3× CAC — pass, fail, or 'depends on what'?

**Reference prompt (write yours first):**

```
Unit economics Saturday. One customer, all the math, no averages hiding anything.

1. Anatomy of one sale: customer pays 939 EUR, 850 goes straight to EUIPO. The 89 EUR has to cover: AI costs, payment fees, Iulia's review time on flagged cases, support, and customer acquisition. Estimate each piece - plainly, with your assumptions visible.
2. CAC per channel: what does one paying customer cost via cold outreach, via SEO/content, via referrals, via paid ads? Use realistic conversion rates and show the math.
3. LTV, honestly: is a Markster customer 89 EUR once and goodbye? Or: renewal in 10 years, monitoring upsell, opposition services, referrals to founder friends? Put numbers on each with your confidence level.
4. The Aulet test: LTV >= 3x CAC. Where do we land, per channel? And the hard question: is a one-time 89 EUR fee a business - or a feature of a bigger business we haven't named yet?
```

**Why this prompt works:** Money math with assumptions visible is the business version of the 'tested vs assumed' rule from the technical track. And the closing question is the deepest one in Markster's whole model: a €89 one-shot can't afford paid acquisition — which means the business either lives on organic/referral channels or grows a recurring layer. Knowing which is strategy, not accounting.

**Challenge the answer:** Ask: "Which single number in this whole calculation are you least confident about?" Then move that number 50% in the bad direction and re-run. If the model dies from one soft number, the model IS that number - and validating it just became the top priority. That move - sensitivity testing - is how professionals read any financial model, including ones made by AI.

### B10 · Sat · 1h · Reality check · BUSINESS TRACK — Revenue Reality Check — Bogdan's formula

**Mission:** Run the bottom-up Revenue Reality Check on Markster: accessible customers × conversion rate × price → year-1 revenue. Compare against the team's actual targets, classify the business (Lifestyle / Growth / VC-scale), and project two year-2-3 scenarios.

**Your prompt must cover:**
- The formula bottom-up, never top-down: customers we can actually REACH in year 1, by named channel — not a % of TAM
- Reference conversion rates per channel applied honestly (cold 1–3%, content/SEO 2–5%, referrals 10–25%)
- The comparison: estimate vs the PRD's targets (~€5K/month in month 1, ~€25K/month by month 3) — Match, Stretch, or Mismatch
- Classification (Indie/Lifestyle · SMB/Growth · Startup/VC) and two scenarios for years 2–3, conservative and invested

**Reference prompt (write yours first):**

```
The Revenue Reality Check - the formula is: Accessible Customers x Conversion Rate x Price = Year-1 Revenue. Bottom-up only; the moment you catch yourself saying "just 1% of the market", stop me.

1. Accessible customers, year 1: through which concrete channels can Markster reach founders, and how many per channel? (Isi's network, content/SEO, the SME Fund angle, partnerships with incubators/accountants?) Numbers per channel, with reasoning.
2. Apply honest conversion rates per channel: cold 1-3%, content 2-5%, warm referrals 10-25%, partnerships 15-30%.
3. Multiply by 89 EUR of service revenue per customer (the 850 EUR is pass-through, remember). Year-1 revenue: what do we get?
4. Compare with the PRD's targets: ~5,000 EUR/month in month 1 growing to ~25,000 EUR/month by month 3. Match, Stretch, or Mismatch? Say it plainly.
5. Classify the business as the model shows it today - Indie/Lifestyle (50-300K), SMB/Growth (300K-3M), Startup/VC (3M+) - and project year 2-3 twice: organic, and with real marketing investment.
```

**Why this prompt works:** This is Bogdan's own addition to the standard frameworks, and its philosophy matters: small ideas are not disqualified — a €150K/year niche product run by two people is a perfectly valid win. The check exists so ambition and math meet BEFORE the launch, not after. Mismatch isn't failure; unexamined mismatch is.

**Challenge the answer:** If the verdict is Stretch or Mismatch against the PRD's targets, ask: "What would have to be true to close the gap - more reachable customers, higher conversion, higher price, or a recurring revenue layer?" Get one concrete scenario for each lever. Then the meta-check: "Which of these levers did you make optimistic just to give me a path?" - hope sneaks into models through the levers.


## Week 6 — Ship it (Level 3: You write the prompts, 14 tasks, ~19h)

### T53 · Mon · 2h · Polish — The polish pass — ugly things, ranked

**Mission:** Run a full consistency-and-polish audit: Claude lists the ugliest and most inconsistent things in the app, you choose which five matter, and they get fixed one at a time.

**Your prompt must cover:**
- An audit against CLAUDE.md's design constants: spacing, colors, empty states, error states
- Ranked by how much a first-time viewer would notice
- YOU pick the five that get fixed — taste is your department
- One at a time, keep-what-works, verify each

**Reference prompt (write yours first):**

```
Polish day. Audit before touching anything:

1. Walk every screen and list the 10 ugliest / most inconsistent things - judged against our CLAUDE.md design rules and against "would a first-time viewer notice?"
2. Rank them. No fixing yet.
3. I'll pick 5. Fix those one at a time, keep-what-works, and I verify each before the next.
4. Special attention: empty states (a dashboard with no applications) and error states (Supabase unreachable). What does a customer see in those moments? Show me.
```

**Why this prompt works:** Audit-then-rank-then-I-pick separates diagnosis from treatment and keeps taste — the one thing that was always yours — in charge. The empty/error states in step 4 are where real products differ from demos; asking about 'those moments' is a pro's question.

**Challenge the answer:** For one item Claude ranked high, disagree: "I don't think anyone would notice this. Defend it or drop it." By now you can feel whether a defense is substance or reflex. That feel took six weeks to build — notice that you have it.

### T54 · Mon · 1h · Deploy — Markster goes live

**Mission:** Deploy the app to Vercel and get a real public URL — then open it on your phone, from your couch, like a civilian.

**Your prompt must cover:**
- Patient-guide style: you create the Vercel account, Claude guides every click
- Ask what deploying means and where the app physically goes
- What about the Supabase keys in a public deployment — the T28 question, third time, unprompted
- Verify on a device that isn't your computer

**Reference prompt (write yours first):**

```
Deployment day. Patient-guide style, I confirm each step:

1. First explain: what does "deploy" actually mean? Where will the app physically be? What's Vercel's role?
2. Guide me through the Vercel account (I type credentials) and connecting our project
3. STOP before we push: our Supabase keys - what happens to them in a public deployment? Walk me through what's exposed and why that is or isn't OK. I'll explain it back before we continue.
4. Deploy. Give me the URL. I'm going to open it on my phone.
```

**Why this prompt works:** You asked the key-safety question unprompted for the third time — in week 3 it was scripted for you, now it's a reflex. That progression, more than the URL, is what this plan was for. (But the URL is pretty great too.)

**Challenge the answer:** Open it on your phone AND send it to one person who has no idea what you've been doing, with no explanation. Their first confused question is the most honest usability test Markster will ever get. Bring it to the retro.

### T55 · Tue · 1.5h · Deploy — Your own corner of the internet — a domain of your own

**Mission:** Buy your own domain — your permanent address on the internet — point it at the deployed Markster app, and move this learning plan from Bogdan's site to yours. Ownership, in the most literal sense.

**Your prompt must cover:**
- Ask what a domain, DNS, and a subdomain actually ARE before any money moves
- Registrar options with trade-offs — including renewal prices and hidden costs — and you decide
- You buy it yourself: your card, your typing, Claude guiding beside you
- Connect the domain to Vercel, then move the plan page from hlb.bgn.ro to your domain

**Reference prompt (write yours first):**

```
Domain day. Patient-guide style, and no money moves until I say so:

1. Explain like I'm new: what is a domain? What is DNS? What's a subdomain? Where does my money actually go every year, and to whom?
2. Give me 3 registrar options with trade-offs - INCLUDING the renewal price after year one and any sneaky costs. Recommend one, but I decide.
3. I'll buy it myself - my card, my typing. Then guide me step by step to connect it to our Vercel deployment, and explain what we're changing when we "point" it.
4. This learning plan currently lives on Bogdan's site (hlb.bgn.ro). Move it to my domain - my house now. Then tell me exactly what to send Bogdan so he can retire his copy.
```

**Why this prompt works:** Money decisions run through 'options with trade-offs, I decide' — and the registrar checkout page, with its pre-ticked upsells, is a masterclass in why you always ask about renewal prices. Moving the plan onto your own domain isn't symbolic fluff: it's the moment the infrastructure of your learning belongs to you.

**Challenge the answer:** Ask: "What happens if I forget to renew this domain next year? Who could take it, and what would break?" Ownership comes with maintenance — put the renewal reminder in your calendar, not in Claude.

### T56 · Tue · 2h · QA — The full journey — end to end, live

**Mission:** Run the complete customer journey on the LIVE site — landing to registered (mock) — as three different invented customers, documenting every friction point, then challenge Claude's pre-launch checklist.

**Your prompt must cover:**
- Three personas you invent, incl. one who makes mistakes and changes their mind
- The full loop including Iulia's approve moving the status
- Friction log: every hesitation, however small
- Ask for a pre-launch checklist — then strike two items and defend the cuts

**Reference prompt (write yours first):**

```
Full dress rehearsal on the live URL:

1. I'll run the whole journey as 3 invented customers - one smooth, one indecisive (goes back, changes answers), one careless (typos, weird inputs). I'll log every friction point, however small.
2. For each customer, complete the loop: application lands in the database, gets flagged or not, Iulia approves, status moves on the client dashboard.
3. Then give me your pre-launch checklist for a demo like Friday's.
4. I'm going to STRIKE TWO items from your checklist as not applicable - and defend each cut to you. Argue back if I'm wrong.
```

**Why this prompt works:** Striking items — and defending the cuts — is the final form of challenging answers: not just questioning Claude's output but editing it with authority. A checklist you've argued with is yours; one you obeyed is homework.

**Challenge the answer:** Ask afterwards: "Which of my two cuts was riskier? Be straight." If Claude pushes back hard on one, reconsider — the goal was never winning arguments, it was making the call with open eyes and adjusting when the counter-argument is better.

### T57 · Wed · 1h · Skills — Your first skill — the Markster email drafter

**Mission:** Build a custom Claude Code skill that drafts Markster's customer status emails (from the PRD's communication table) in a consistent voice — your first piece of reusable, packaged instruction-writing.

**Your prompt must cover:**
- Ask what a skill is and when one is worth making, before making it
- The PRD's communication table as the source: triggers, variables
- Define the voice in your own words — warm, plain, no legalese?
- Test on two statuses before calling it done

**Reference prompt (write yours first):**

```
I want to build my first skill: a Markster email drafter.

1. First explain: what exactly is a skill, and how is it different from just asking you nicely each time? When is a skill worth the trouble?
2. The skill: given an application status, draft the customer email per the PRD's communication table - right trigger, right variables filled with the application's real data
3. The voice, my spec: warm and plain, like a competent friend who happens to know trademark law. Never legalese. Short.
4. Build it, then we test on "Filed" and "Needs Info" before I believe it works.
```

**Why this prompt works:** A skill is a prompt that graduated: instructions written once, well, and reused forever. Everything you've learned about complete prompts — context, voice, format, constraints — is exactly what a skill file is made of. You've been training for this without knowing.

**Challenge the answer:** Test the edge: ask for an email for a status the communication table doesn't cover (Draft, say). What does the skill do — invent one, refuse, ask? Then decide what it SHOULD do, and encode your decision. Handling the uncovered case is what separates instructions from good instructions.

### T58 · Wed · 1.5h · Skills — Test, break, and shrink the skill

**Mission:** Harden the email drafter by testing it across statuses — then discover which of its instructions actually matter, by deleting them one at a time.

**Your prompt must cover:**
- Run it on 3+ statuses, judge the voice yourself against your spec
- Fix wording in the skill file, not by re-asking each time
- The deletion experiment: remove one instruction, re-run, observe
- Keep the skill as small as it can be while still working

**Reference prompt (write yours first):**

```
Let's harden the email drafter:

1. Run it on Registered, Rejected, and Opposition. I'll judge each draft against my voice spec - fixes go into the SKILL FILE, not into one-off corrections.
2. Now the experiment: ask me which instruction in the skill I think is doing the most work. Then DELETE it and re-run. Was I right?
3. Repeat with one more instruction. Anything whose deletion changes nothing gets cut permanently.
4. Goal: the smallest skill file that still produces emails I'd send.
```

**Why this prompt works:** The deletion experiment is how you learn what actually steers the model — by subtraction, not accumulation. Most people's prompts and skills grow forever; yours will shrink to the load-bearing sentences. That editing instinct is rare and valuable.

**Challenge the answer:** Ask: "If Isi wanted to change the email voice next month, could she edit this skill file herself without breaking it? What would you add to make it safe for her?" Making your work editable by the next person is the last mile of building anything.

### T59 · Thu · 1.5h · Journal — The learning journal — learn.your-domain goes live

**Mission:** Publish your six weekly 'Week N — learned' notes as a small journal site on a subdomain of your new domain, with your tracker's progress alongside — the public story of these six weeks, in your own words, at your own address.

**Your prompt must cover:**
- Gather all six notes first — weeks 1-3 live in the claude.ai Project, weeks 4-6 in docs/ — into one place
- Your words, lightly cleaned, never rewritten by Claude
- A subdomain (learn.your-domain) set up on Vercel — and you explain back how subdomains work
- A privacy pass before publishing: what should NOT be public?

**Reference prompt (write yours first):**

```
My journal goes live today:

1. First, gather: my week 1-3 notes are in the claude.ai Project, weeks 4-6 are in docs/. Help me copy them all into docs/journal/ so the repo holds the full set.
2. Turn them into a simple journal site - one page per week plus a homepage that tells the six-week arc. RULE: my words, lightly cleaned up, never rewritten. If a sentence sounds more like you than me, put mine back.
3. Guide me to publish it at learn.[my domain] - and before we do, I'll explain back to you how a subdomain works. Check me.
4. Add my tracker's progress view (the Bogdan view) or a link to it. Then a privacy pass: walk me through everything on these pages and flag anything that shouldn't be public - keys, emails, names?
5. Design: Markster-ish, but it's MY site - propose 2-3 small touches that make it mine. I pick.
```

**Why this prompt works:** This is why you wrote a note every Friday: six weeks later, they're a site, not a chore. The 'my words, never rewritten' rule keeps the journal honest — its value to future-Howard (and to anyone learning after you) is that it sounds like a real person on week 2, not a polished retrospective. And the privacy pass is question #11, applied to your own life.

**Challenge the answer:** Send the journal link to one friend who knows nothing about AI, with no explanation. Ask them later which week they found most interesting - the answer tells you what to write about next, and whether your six weeks read from outside the way they felt from inside.

### T60 · Thu · 1h · Handover — The README for Prodi — honesty as a feature

**Mission:** Write the handover document for the professional developer who inherits your foundation: what's real, what's mock, what's known-broken, and what he'll want to criticize.

**Your prompt must cover:**
- What exists and works, with the URL and how to run it locally
- Every mock and known gap, from the lists you've kept since week 3
- Ask: 'what will a professional developer criticize?' — and include the answers
- Readable by a human in ten minutes

**Reference prompt (write yours first):**

```
Write the README for Prodi - the developer who takes this to production. Together:

1. What Markster is, the live URL, how to run it locally, where the docs live
2. The honest inventory: every mock (EUIPO, payments, no login), every known issue, every gap-list item still open - pull from our docs, don't soften anything
3. Now the hard question: what will a professional developer CRITICIZE about this codebase? List it yourself, honestly. Those answers go in the README under "Known trade-offs" - I'd rather Prodi read them from us than discover them smirking.
4. Ten-minute read, maximum. I'll review every word before we commit.
```

**Why this prompt works:** Pre-empting criticism in writing is the most senior move in the whole plan — it converts weaknesses into documented decisions. 'I'd rather he read them from us' is a sentence worth keeping for the rest of your working life.

**Challenge the answer:** Send the README to Bogdan before Prodi sees it, with one question: "What's missing?" A handover reviewed by someone who knows the terrain is twice as good. Also — notice you just used a human the way you've been using Claude: targeted question, specific artifact. The skills transfer both ways.

### T61 · Thu · 1h · Meta — Write your own Question Playbook

**Mission:** Write YOUR playbook — the questions and prompt patterns that actually worked for you — each entry earning its place with a true story from these six weeks. This document is the graduation certificate.

**Your prompt must cover:**
- Mine the six weeks of conversations for your best questions and patterns
- Every entry has a story attached — no story, no entry
- Your words, your ordering, your names for things
- Saved in the Project, the repo, and printed on paper for the desk

**Reference prompt (write yours first):**

```
We're writing MY Question Playbook - not a copy of the one in the plan.

1. Go through our six weeks and surface the 15-20 moments where a question or prompt pattern of mine changed the outcome
2. I'll pick the ones that FELT most powerful and tell you the story of each from memory - the story goes in the playbook next to the question
3. Rules: my words, my names for things (if I call it "the seatbelt sentence", that's its name), and any entry without a story gets cut
4. Format it beautifully, save it everywhere, and give me a version I can print and put on my desk.
```

**Why this prompt works:** The story requirement is what makes this document yours instead of Claude's — patterns without lived stories are decoration. A playbook with your own names for things ('the seatbelt sentence') is the proof that the knowledge moved from the plan into you.

**Challenge the answer:** Final check, ask: "Which important pattern from our six weeks did I NOT include - and should I?" Consider the answer seriously, then feel free to say no. It's your playbook. Declining Claude's last suggestion, with a reason, is a perfectly Howard way to graduate.

### T62 · Fri · 1.5h · Demo — The final demo — Loom to the whole team

**Mission:** Deliver the graduation demo: the live app, the six-week story, and three concrete moments where you caught or corrected Claude — rehearsed against a hostile audience first.

**Your prompt must cover:**
- Structure: the live product first, the learning story second, short
- Your three caught-Claude moments, told with relish
- Rehearse with Claude playing a tough audience interrupting with 3 hard questions
- Under 8 minutes, sent to Isi, Iulia, Bogdan (and Prodi with the README)

**Reference prompt (write yours first):**

```
My final demo. Help me build and rehearse it:

1. Structure: (a) the live Markster URL, full customer journey + team screens - 4 min; (b) what I learned in six weeks, told through my three favorite moments of catching you being wrong - 3 min; (c) what happens next - Prodi, the README - 1 min
2. Draft the script with me, my words not yours - polish, don't replace
3. Then rehearse: play a tough audience. Interrupt me with 3 hard questions mid-demo (about mocks, about security, about what I'd do without you). Grade my answers.
4. Cut until it's under 8 minutes.
```

**Why this prompt works:** 'My words, not yours - polish, don't replace' guards the thing that makes the demo land: it must sound like Howard. And rehearsing against interruptions turns the scariest part of demos — the questions — into the part you've already practiced.

**Challenge the answer:** The third hostile question — 'what would you do without Claude?' — deserves a real answer, so work it out honestly in the rehearsal. (A true one: 'Less. But I'd know exactly what to ask for, from any builder, human or AI. That's what the six weeks actually taught me.')

### T63 · Fri · 1.5h · Retro — The retrospective — and the next 30 days

**Mission:** Run an honest six-week retrospective with Claude, then design your own next-30-days plan — because the learning doesn't stop, it just stops needing a curriculum.

**Your prompt must cover:**
- What got easier, what's still hard, backed by real examples from the chats
- The dependence question, asked straight
- Three things you want to do with Claude next that have nothing to do with this plan
- The next 30 days: your design, Claude advises

**Reference prompt (write yours first):**

```
Six-week retrospective. Be straight with me:

1. Comparing my week 1 and week 6 conversations: what measurably changed in how I work with you? Quote real examples.
2. The dependence question: what do I still lean on you for that I could now do myself? And the reverse - what do I still do manually that I should be delegating to you?
3. I'll name three things I want to do with Claude next that have nothing to do with Markster. For each: what should I know before starting?
4. Then I design my next 30 days myself - you advise, I decide. Format it like this plan's weeks, but it's mine.
```

**Why this prompt works:** The retro prompt asks for evidence ('quote real examples'), not vibes — you hold your own review to the same standard you learned to hold Claude's reports. And the plan for the next 30 days being YOUR design is the plan working as intended: curricula end, direction doesn't.

**Challenge the answer:** Take question 2's answer to the Friday call and discuss it with Bogdan as a real question, not a confession. Everyone who works with AI has a dependence profile; knowing yours precisely — that's not a weakness, that's literacy.

### T64 · Fri · 0.5h · Celebrate — 100% — ship the screenshot 🎉

**Mission:** Tick the last box in the tracker you built in week 1, screenshot the 100%, and send it to the team — from the app that watched the whole journey.

**Your prompt must cover:**
- The final checkmark, ticked in your own cloud-synced app
- Screenshot of 100%, sent to Bogdan, Isi, Iulia
- One sentence with it, yours alone — no drafting help this time

**Reference prompt (write yours first):**

```
No prompt for this one. Tick the box. Take the screenshot. Write the sentence yourself.

(All right, one small thing: afterwards, come tell me what sentence you wrote. I've been curious for six weeks.)
```

**Why this prompt works:** The tracker was always the quiet hero of this plan: built in week 1 when a checkbox felt like magic, moved to the cloud in week 3, its data visible to Bogdan all along. Its last checkmark is data proving six weeks of showing up.

**Challenge the answer:** None. You've challenged enough answers for one curriculum. Go celebrate — and maybe ask Howard's own favorite brave question one more time, just for the pleasure of not being embarrassed by it anymore.

### B11 · Sat · 1.5h · Verdict · BUSINESS TRACK — The verdict — Markster on the full scorecard

**Mission:** Assemble everything from five Business Saturdays into the full BONO scorecard — Need, Customer, Market, Differentiation, Profit Formula — check the deal-breakers, issue the verdict (GO / REFINE / PIVOT / PARK), and write it up as an honest memo to Isi and Bogdan with a concrete validation experiment attached.

**Your prompt must cover:**
- All five dimensions scored 1–5 from YOUR previous Saturdays' work — Claude assembles, you score, it challenges
- Deal-breaker check: no identifiable need, 'everyone' as customer, or no path to customers = automatic PARK regardless of total
- The verdict with its consequence: GO → validate with interviews; REFINE → which dimension first; PIVOT → toward what; PARK → said out loud
- The memo ends with a validation experiment + 5 Mom Test questions for real prospects — analysis that doesn't end in action is decoration

**Reference prompt (write yours first):**

```
Verdict Saturday. Assemble my five Business Saturdays into the full scorecard.

1. Pull from our previous sessions: the job statement (B01), the beachhead and 10-customers test (B03), the problem scores and archetype (B05), the why-now (B06), the advantage audit (B07), the pre-mortem (B08), the unit economics and Revenue Reality Check (B09-B10).
2. Score the five dimensions, 1-5 each: NEED (clarity, intensity, frequency), CUSTOMER (specificity, reachability), MARKET (size, dynamics), DIFFERENTIATION (insight, alternatives), PROFIT FORMULA (revenue model, unit economics, distribution). I score first, from my notes; you challenge every score up or down with evidence.
3. Deal-breaker check: need unclear, customer = "everyone", or no distribution path - any of these means PARK, whatever the total says.
4. The verdict: GO / REFINE / PIVOT / PARK - with its consequence spelled out.
5. Write it as a 1-page memo to Isi and Bogdan: scores, verdict, the 3 weakest points said plainly, one validation experiment we should run next month, and 5 Mom Test questions for real prospects. Direct tone - they can handle it; what they can't use is politeness.
```

**Why this prompt works:** The scorecard isn't a grade on Markster — it's a grade on the quality of the thinking about Markster, and its output is always an action: validate, fix this dimension, turn, or stop. The memo format matters too: analysis delivered as a document with a verdict is worth ten conversations of 'I think it's promising'.

**Challenge the answer:** Before sending the memo, ask Claude to argue every score exactly one band lower - the full bear case. Where the defense holds, keep the score. Where it wobbles, lower it. A scorecard that survives its own bear case is the only kind worth sending - and running that gauntlet on purpose is what separates analysis from advocacy.

### B12 · Sat · 1.5h · Capstone · BUSINESS TRACK — Capstone — your own idea through the machine

**Mission:** Graduation: take an idea of YOUR own — any size, a business, a community project, a product for people like you — and run the entire analysis yourself, from reframe to verdict, writing every prompt solo. Present both verdicts (Markster's and yours) in the final demo.

**Your prompt must cover:**
- Your idea, stated first as a product, then reframed to the need — show both versions
- The full arc compressed: job statement, beachhead + 10 names, problem scores, why-now, advantages, quick pre-mortem, Revenue Reality Check with YOUR ambition level
- The scorecard and an honest verdict — including accepting PARK if that's where the numbers land
- A 5-minute segment in Friday's final demo: your idea, your analysis, your verdict

**Reference prompt (write yours first):**

```
(Write the whole session yourself - you know the machine now. The reference below is only a shape, not a script.)

My idea: [describe it as you first thought of it - the product version]

1. Reframe me: force the product-to-need move on my own idea. What's the job statement?
2. Compress the arc: who exactly is the customer and can I name 10? Which of YC's problem traits does it have, with what evidence? What's my why-now? What's my unfair advantage - graded harshly? Give me the 60-second pre-mortem.
3. Revenue Reality Check at MY ambition level: [state it honestly - is this a 20K/year side project, a 100K/year business, more?] Accessible customers x conversion x price - where does it land vs. what I want?
4. Scorecard, deal-breakers, verdict: GO / REFINE / PIVOT / PARK. Challenge my scores. No mercy, no flattery - I've had six weeks of practice being challenged and I intend to enjoy it.
```

**Why this prompt works:** Markster was the training ground; this is the proof. Every technique from six Saturdays runs in one session, on an idea you actually care about — which is exactly when the discipline gets hard and exactly why it's the graduation exercise. Ambition-level honesty matters most here: Bogdan's framework doesn't judge small ideas, it judges unexamined ones.

**Challenge the answer:** The hardest test in the whole plan: if the verdict is PARK, accept it out loud, in the demo, with a straight face - and say what you'd explore instead. Killing your own darling with grace, in public, because the analysis said so: that is the entire business curriculum in one move. (And if the verdict is GO - even better. You know exactly which 10 people to interview first, and how.)


## Vocabulary

- **anon key** — Supabase's public key — like the street address of your database: fine for the world to know, because separate rules decide what visitors may actually do. Its sibling, the service key, is a master key and must stay secret. Example: Your tracker page uses the anon key; the service key never leaves your Supabase dashboard.
- **API** — Application Programming Interface — a way for one program to ask another for information or actions, like a waiter carrying orders between your table and the kitchen. Example: Markster asks EUIPO's API "are there trademarks similar to this name?" and gets a list back.
- **artifact** — In Claude.ai, an artifact is a live mini-page or mini-app that Claude builds beside the chat — you see it working immediately, no installation. Example: Your tracker starts life as an artifact; so does the Markster landing page.
- **backend** — The behind-the-scenes half of an app: the database and logic running on a server, invisible to the user. The other half — what you see and click — is the frontend. Example: When your tracker syncs to Supabase, Supabase is its backend.
- **beachhead** — The small first market you can dominate before expanding — Bill Aulet's term, borrowed from the D-Day landing beaches. Example: Romanian e-commerce founders could be a Markster beachhead.
- **CAC** — Customer Acquisition Cost — what you spend, on average, to win one paying customer. Rule of thumb: LTV should be at least 3× CAC. Example: If ads cost €500 per paying customer and the customer brings €89, the math has a problem.
- **CLAUDE.md** — The rulebook file of a Claude Code project — Claude reads it at the start of every session and follows it without being reminded. Example: Yours says: plain English, plan before big changes, ask before deleting, never tick a task without Howard's confirmation.
- **cloud** — "The cloud" = other people's always-on computers, rented over the internet. Data in the cloud is reachable from any device — unlike data stored only in one browser. Example: Tracker v3 moves your checkmarks from your browser into the cloud, so your phone sees them too.
- **commit** — One saved snapshot in git, with a short message saying what changed. Example: "Add weekly progress chart" is a commit message; the commit holds the project exactly as it was at that moment.
- **conversion rate** — The percentage of people who take the next step — visitors who start, starters who pay. Example: Cold email converts 1–3%; warm referrals 10–25%. The channel decides the math.
- **CSS** — The language that describes how a web page looks: colors, fonts, spacing, layout. Example: "Pink #E8386F, Inter font" becomes a few lines of CSS.
- **custom instructions** — A standing note to Claude inside a Project: who you are and how you want answers. Written once, applied to every conversation there. Example: Yours say: "I'm Howard, define jargon, show me your plan before big work."
- **database** — An organized store of data — think of a spreadsheet with strict rules — that apps write to and read from. Tables hold rows; each record is a row. Example: Every Markster application is one row in the applications table.
- **deploy** — To copy your app from your computer onto a machine that's always on, so anyone can open it at a web address. "Deployed" = live on the internet. Example: In T54 you deploy Markster to Vercel and open it on your phone.
- **dev server** — A small program on your own computer that runs your app while you build it — visible only to you, updating instantly when the code changes. Example: "Start the dev server" then open localhost:3000 to see Markster as you build it.
- **DevTools** — Chrome's built-in inspection panel (press F12). Its Console tab shows what the page is doing — and the exact error messages when something breaks. Example: On Debug Day you read your first real error message in the DevTools Console.
- **DNS** — The internet's address book: it translates a domain name into the actual computer to connect to. "Pointing your domain at Vercel" means editing DNS. Example: When DNS for your domain points at Vercel, typing your domain opens your app.
- **domain** — Your address on the internet — like markster.eu. You rent it yearly from a registrar; it's how people find you. Example: In T55 you buy your own domain and point it at your deployed app.
- **EUIPO** — The European Union Intellectual Property Office — the official EU body where trademarks are registered. Markster files applications there. Example: An EU trademark filed at EUIPO covers all 27 member states at once.
- **frontend** — The half of an app you can see and touch: pages, buttons, forms, running in your browser. The invisible half is the backend. Example: Everything you built in weeks 1–3 is frontend.
- **git** — A save-point system for your project. Every commit is a snapshot you can always return to — which means you can experiment without fear. Example: Break something on Tuesday? Roll back to Monday's save-point in one command.
- **gross margin** — What's left of the price after the direct cost of delivering it — before salaries, rent, and marketing. Example: Of Markster's €939, the €850 EUIPO fee passes straight through; the margin lives inside the €89.
- **hosting** — Renting space on someone's always-on computers so your website is reachable day and night. Example: Vercel hosts your app; a registrar rents you your domain name.
- **HTML** — The language that describes a web page's content and structure: headings, paragraphs, buttons. Example: Your first artifact in T01 is pure HTML plus CSS.
- **JavaScript** — The language that makes web pages interactive — what happens when you click, type, or when data arrives. Example: The checkbox logic in your tracker is JavaScript.
- **JSON** — A simple text format programs use to write down structured data — names, values, lists — readable by both machines and humans. Example: Your tracker's export button produces JSON: {"T01": "done", ...}.
- **JTBD** — Jobs to Be Done — Clayton Christensen's lens: people don't buy products, they hire them to do a job. Ask what the job is, and the real competition appears. Example: An entrepreneur hires Markster to "protect my brand EU-wide without lawyer drama" — so the competition includes doing nothing.
- **knowledge base** — The documents you upload to a claude.ai Project so every conversation there starts already informed. Example: Your Markster Project's knowledge base holds the PRD and this plan — so you can ask "what does T28 want from me?"
- **localhost** — Your own computer's address, as seen by itself. An app on localhost runs on your machine only — nobody else in the world can open it. Example: http://localhost:3000 works on your machine and nowhere else.
- **localStorage** — A small memory inside your browser where a page can save notes for itself — per browser, per device. Close the tab, come back: still there. Open another device: gone. Example: Tracker v1 keeps your checkmarks in localStorage — that's why they don't show on your phone.
- **Loom** — A free tool that records your screen and voice into a short video you share as a link — the standard way to demo work to people who aren't in the room. Example: Your week 5 demo travels to Isi as a 5-minute Loom.
- **LTV** — Lifetime Value — everything one customer is worth over the whole relationship: first purchase, renewals, upsells, referrals. Example: A Markster client: €89 now, a renewal in 10 years, maybe two founder friends referred.
- **mock** — A realistic fake. A mock payment button pretends to charge a card; a mock search returns invented results. Professionals build with mocks first and connect the real services later. Example: Our EUIPO search is a mock: 20 invented trademarks instead of the real half-million.
- **Mom Test** — Rob Fitzpatrick's rules for customer conversations: talk about their life, not your idea; ask about specific past behavior, not future opinions; ignore compliments — even your mom will lie to you politely. Example: "When did you last deal with a trademark?" beats "Would you use this?"
- **MVP** — Minimum Viable Product — the smallest experiment that tests the riskiest assumption. Not a small product: a big question, answered cheaply. Example: Markster's MVP files real trademarks for 10 customers before any polish.
- **Nice classes** — The 45 official categories of goods and services used in trademark registration (named after Nice, the French city). The fee depends on how many classes you register in. Example: A bakery registers in class 30 (bread, pastry); a software company in class 42.
- **pivot** — Changing direction based on evidence while keeping what you learned — Lean Startup's word for a smart turn, not a failure. Example: If founders won't pay for filing but will pay for monitoring, Markster pivots.
- **PRD** — Product Requirements Document — the written plan of a product: who it's for, what it does, screen by screen. Markster's PRD is the source of truth you'll keep returning to. Example: "The PRD says the EUIPO fee for the first class is EUR 850."
- **pre-mortem** — Imagining the project already failed and writing down why — before you start. Pretending it's dead makes everyone honest about the risks. Example: "Markster died because founders didn't trust an AI with legal filings" — now, what's the early-warning sign?
- **product-market fit** — The moment a market pulls the product out of your hands — customers arrive faster than you can serve them. Before PMF you're searching; after it you're scaling. Example: Sequoia sorts ideas by how the fit will feel: hair on fire, hard fact, or future vision.
- **production** — The live, real version of an app that actual users touch — as opposed to the working copy on your machine. "Production-ready" means solid enough for strangers and real money. Example: Your Markster is a working foundation; Prodi makes it production-ready.
- **prompt** — The message you give Claude: context, goal, format, constraints. Writing complete prompts is the craft this whole plan teaches. Example: "Build me a tracker... FUNCTIONALITY: ... DESIGN: ..." is a prompt with labeled sections.
- **README** — The front-door document of a project: what it is, how to run it, what to watch out for. The first thing any developer reads. Example: Your README in T60 tells Prodi honestly what's real, what's mock, and what he'll want to fix.
- **registrar** — A company that rents out domain names. Prices look cheap in year one — always check the renewal price. Example: You'll compare three registrars in T55 before buying.
- **repository** — A project folder tracked by git — the code plus its entire history of save-points. "Repo" for short. Example: The Markster repo remembers every version of the app since T35.
- **Row Level Security** — Supabase rules that decide which rows of a table each visitor may see or change. RLS is what makes it safe for the anon key to be public. Example: With RLS, a visitor could read applications but never delete them.
- **scaffold** — The empty-but-working skeleton of a new app: folders, configuration, one page — generated first so building can start. Like framing a house before any rooms exist. Example: In T38 Claude scaffolds the Markster app, then you fill in the screens week by week.
- **skill** — A reusable instruction file you write once and Claude applies every time — a prompt that graduated. It lives as a file, so it can be tested, improved, and shared. Example: Your email-drafter skill turns any application status into a customer email, in your chosen voice.
- **state machine** — A list of every state something can be in, plus the allowed moves between them. Sounds fancy, is just a table with rules. Example: A Markster application has 12 states (Draft, Paid, Filed, Registered...) and rules like "once Paid, never back to Draft".
- **Stripe** — The service most internet businesses use to accept card payments online. Example: In our app the Stripe checkout stays a mock — no real cards, ever.
- **subdomain** — A named section in front of your domain — free to create once you own the domain. Example: learn.howard.com is a subdomain of howard.com; your journal lives on one.
- **Supabase** — An online service that gives your app a real database in the cloud, free to start. You create an account, it hands you a database plus an API to talk to it. Example: Tracker v3 and the Markster app both store their data in Supabase.
- **TAM** — Total Addressable Market — the yearly value of everyone who could conceivably buy. Useful for scale, dangerous when abstract. Example: ~197,000 EU trademark applications a year is Markster's raw TAM.
- **terminal** — The text window where you talk to your computer in typed commands instead of clicks. Claude Code lives there — you speak English, it speaks terminal. Example: In T33 you watch Claude create files by typing commands in the terminal.
- **token** — The small pieces of text — roughly word-fragments — that AI models read and write. Claude subscriptions measure usage in tokens, which is why heavy building weeks can hit limits. Example: "Unbelievable" is about three tokens; a long Claude Code session uses millions.
- **unfair advantage** — The reason YOU win even after others copy the idea. Y Combinator counts five kinds: founders, market, product, acquisition, monopoly — and "a bit better" counts as none. Example: Markster's direct EUIPO API integration — which nobody else uses — is a product advantage.
- **unit economics** — The profit math of ONE unit — one customer, one sale: what they pay, what they cost, what's left. If one unit loses money, a million units lose more. Example: Markster's unit: €939 in, €850 to EUIPO, €89 to run everything else.
- **URL** — A complete web address — the domain plus the path to a specific page. Example: https://markster.eu/pricing is a URL: domain markster.eu, page /pricing.
- **Vercel** — A hosting service that takes your web app and puts it live on the internet — free for small projects. Example: Markster, your journal, and this plan can all live on Vercel.