← All sessionsHomeSearch
AI Catalyst C3·Core Sessions - Week 6·2:47:02

Session 12: Claude Code — Design & Building Agents (App-First: a Game, a GTM Board, and a Live Deploy)

Prakash Trainer — runs the whole session in the Claude Code desktop app for a terminal-shy cohort; quiz-driven recap of session 11, then two complete builds (a typing arcade game and a GTM launch board), Gmail MCP wired live with real failures, and a GitHub+Vercel deploy to a public URL · Niharika Cohort manager (Slido Q&A, CSAT, will repost the two workbook PDFs)
▶local recording  ·  LMS lesson

Session map

RECAP: THE CONTROL SURFACEBUILD ONE: THE GAMEBUILD TWO: BUSINESS + SHIPThe three modes as a trust sp…The everyday slash commands/init, /plan, /model, /clear, /compactCLAUDE.mdthe project brain /init writes for youChat, project, userwhere information livesWord Rushone-line prompt → plan questions → comm…Plugins vs skills vs connecto…The GTM launch boardmd-as-intermediate, then an app from th…Gmail MCP, warts and alladd by prompt, fail, paste the error, s…From folder to URLGitHub + Vercel by one prompt — includi…
Recap: the control surfaceBuild one: the gameBuild two: business + ship
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — recap: the control surface flow into build one: the game, then into build two: business + ship. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. The session's shape: yesterday's theory (session 11) put to work — a quiz-format recap of modes, commands, skills, hooks, connectors and scopes, then two full builds without touching a terminal.
  2. Build one: a retro typing arcade game ('Word Rush') from a one-line prompt via plan mode's clarifying questions, revised through the app's comment-on-plan feature, iterated with screenshots, and improved with the front-end design skill.
  3. Build two: a GTM launch board via the md-as-intermediate pattern — prompt 1 makes a GTM strategist write gtm-plan.md; prompt 2 turns that file into a drag-and-drop Kanban with KPI cards; prompt 3 adds CRUD, assignees and progress tracking.
  4. The connective tissue: Gmail MCP fetching and drafting real outreach emails mid-build (with OAuth failures debugged by pasting the error back), and a GitHub+Vercel deploy that first shipped the WRONG app — fixed by naming the right one.
  5. The cost thread runs throughout: /compact at 40–50% context, cheap models for small edits, tokens spent once at build time — 'to play the game, we are not using AI, so that's fine.'

The concepts

01

The three modes as a trust spectrum — and plan-then-auto as the working rhythm

0:09:12

The cohort itself defines the modes in chat — ask-permissions is 'least risk,' bypass is 'danger' — and the trainer arranges them into one idea: how much do you trust Claude right now?

Ask-permissions confirms every action; plan mode gathers context and interviews you without executing; bypass (auto) executes freely, pausing only for destructive commands. The taught rhythm uses the two ends deliberately: plan mode to front-load questions and context, then accept-and-auto-mode to execute the approved plan without babysitting. He models the discipline by catching his own lapse — 'I was not following the basic principles... I was running it on auto mode; I should be running it on plan mode' — and re-doing the GTM prompt in plan mode.

Worked example · from the session

The game build: plan mode asks three scoping questions (game mechanic, visual vibe, tech stack) before a line of code; approval flips it to auto mode where 772 lines land unattended.

Why it matters

Mode choice is the app-side version of session 14's permissions discussion — the control is the reviewed plan, not per-action clicks.

People get this wrong

Auto mode means nothing is ever checked.

Auto executes the approved plan but still halts on destructive commands — and the taught habit puts a reviewed plan in front of it every time.

I was not following the basic principles… I was running it on auto mode. I should be running it on plan mode.1:56:58
For your projects

['Matches how you run this chat: pre-registered scope (plan) then long unattended runs (auto) with hard rules as the destructive-command brake.']

This idea elsewherereappears inthe terminal-side version, two days later
Go deeper

In one line: Claude Code's modes form a trust spectrum — ask-permissions (confirm everything), plan (interview and plan only), auto/bypass (execute freely, stop on destructive commands) — with plan-then-accept-into-auto as the taught default rhythm for building.

Cohort-sourced definitions confirmed live: 'every time Claude will ask' / 'it only plans, it doesn't build' / 'danger… big risk… just execute' (0:09:12)

Auto mode still brakes on destructive commands — 'it is going to stop automatically' (0:45:36)

/plan the command and plan mode the toggle are the same thing (0:15:13)

Self-correction modeled: the GTM prompt is re-run in plan mode after he catches himself in auto (1:56:58)

Q&A close: plan mode is also the answer to 'AI changed things I didn't want' — review the intent before it touches the app (2:42:44)

Try it now

Next app-side build: refuse to press enter until you're in plan mode; approve, then switch to auto and walk away.

▶ Watch this taught: 0:09:12

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What still stops an auto-mode run, and what's the taught rhythm around it?

Destructive commands trigger a stop even in auto; the rhythm is plan mode for context and approval, then accept-and-auto for unattended execution.

02

The everyday slash commands: /init, /plan, /model, /clear, /compact

0:11:12

You don't memorize the commands — you press slash and read; the skill is knowing which five matter.

The working set: /init builds the project brain (next concept); /plan enters plan mode; /model switches models — 'speed versus smart,' Fable/Opus for complex tasks, Sonnet/Haiku for renames and small edits, 'basically saving up money by utilizing cheaper models'; /clear wipes the chat; /compact shrinks context. Compact gets the most airtime: run it around 40–50% context usage to head off hallucination, and know that Claude auto-compacts if you hit the ceiling. Commands work identically in the desktop app (slash key, or the plus icon → slash commands).

Worked example · from the session

Live: /compact drops a 36%-full context window back toward 5–10%; the context readout (bottom-right percentage icon) shows the split — 10k tokens on skills, 7k on MCPs, 100k on messages.

Why it matters

These five commands are the whole cost-and-context control surface a beginner needs — everything else can be discovered by pressing slash.

People get this wrong

Slash commands are terminal-only.

Asked directly and corrected live: the app runs them all — slash key or plus-icon menu.

For your projects

['His compact-at-40–50% rule is the in-chat version of your fresh-chat-per-sitting practice.']

This idea elsewherereappears inthe same readout, terminal-side, next day
Go deeper

In one line: Core command set: /init (create CLAUDE.md), /plan (enter plan mode), /model (route smart-vs-cheap by task), /clear (reset chat), /compact (summarize context; recommended at 40–50% usage; automatic at the limit) — available identically in app and terminal.

Model routing rule of thumb: 'complex task → Fable or Opus; changing a file name → Sonnet or Haiku' (0:17:13)

/compact 'helps you save tokens… reduces token usage in the future'; auto-compact fires at 100% (0:19:13)

Threshold guidance: compact at ~40–50% context fill (0:19:13)

Commands discoverable via slash or the plus-icon menu — no memorization (0:15:13)

Context readout demystified for the app: the percentage icon bottom-right, with per-category token split (1:09:54)

Try it now

Open the context readout in your own session and note the three-way split before and after a /compact.

▶ Watch this taught: 0:11:12

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

When should you compact, and what happens if you never do?

Around 40–50% context fill; if you exhaust the window, Claude auto-compacts for you at the ceiling.

03

CLAUDE.md: the project brain /init writes for you

0:13:13

One command turns a folder of work into a memory that every future chat inherits.

/init summarizes the project into CLAUDE.md — 'the entire knowledge base of your project': what the app is, how to run it, the architecture, conventions, and verified approaches. Every subsequent conversation in that folder sends this brain automatically, which both saves tokens (no re-explaining) and keeps context right (the architecture rides along). It's not a first-command ritual — run it whenever you want the brain created, and update it by simply asking Claude to update CLAUDE.md after the project changes direction.

Worked example · from the session

Run live on the game folder mid-build: the generated file contains the app name, purpose summary, a run/preview command for index.html, architecture, conventions, and verified approaches — read through section by section on screen.

Why it matters

It's the beginner-accessible version of the harness idea: externalized project memory that makes each future prompt cheaper and better-grounded.

People get this wrong

/init must be the first command in a project.

It can run at any point — it summarizes whatever exists; the habit is having it before the project gets long, and updating it as direction changes.

For your projects

['Session 15 treats CLAUDE.md as harness part one; this is its gentlest on-ramp — good KB cross-link for beginners.']

This idea elsewherereappears inCLAUDE.md as the first harness component
Go deeper

In one line: CLAUDE.md is the folder-level project memory created by /init (summary, run instructions, architecture, conventions), automatically included in future conversations in that folder; updated on request rather than regenerated, and creatable at any point in a project's life.

'A brain for Claude… whenever we ask anything, it will use that brain' (0:13:13)

Cohort framing accepted: CLAUDE.md as mind map / master system prompt for the project (0:13:13)

Architecture in the file 'is helping us save the tokens in the future and provide the right context' (1:00:05)

Timing is flexible — 'totally depends whenever you want to activate your brain'; update by asking, not re-running (0:58:04–1:00:05)

Try it now

Run /init in your most-used project folder, read the file it writes, and correct one thing in it — the correcting is what makes it yours.

▶ Watch this taught: 0:13:13

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What does every new chat in a folder automatically receive once CLAUDE.md exists?

The file's contents — project summary, architecture, conventions — sent as standing context without re-prompting.

04

Chat, project, user: where information lives

0:27:16

Tell the chat app your business name and the next chat has forgotten it; tell Claude Code inside a folder and every future session in that folder knows.

Chat-level scope is the claude.ai default: information lives and dies in one conversation. Project-level scope comes from working in a folder — goals, plans, skills, hooks and MCPs attached to that folder persist across every new session opened there. User-level scope is machine-wide: the hidden .claude folder in your home directory (named for your account) holds plugins, hooks, and personal facts that follow you into every folder and chat. The design intent he names: 'distributing information with different guardrails.'

Worked example · from the session

Shown on disk: the master directory ('Praca Gupta' — his username) containing .claude with plugins and hooks; versus the project folder holding CLAUDE.md and index.html — the two memory tiers side by side in Finder.

Why it matters

Scope answers the recurring beginner mysteries — why the chat app forgets, why the same folder must be reopened, and where installed skills actually live.

People get this wrong

Claude remembers you across chats by default.

The chat app is chat-scoped by design; persistence is something you architect — by folder for projects, by ~/.claude for yourself.

Three rings of memory — choose the scope when you create things CHAT one conversation only the claude.ai default PROJECT — the folder goals · CLAUDE.md · skills · hooks · MCPs persist across sessions here USER — the machine (~/.claude) plugins · hooks · personal facts, in every folder and chat 'We are distributing information with different guardrails.'
Three rings of memory: chat-only, folder-wide, and machine-wide (~/.claude)
For your projects

["Sessions 13's project-vs-user skill placement is this concept applied; extracting both gives the KB a two-trainer consensus."]

This idea elsewherereappears inthe same scope choice at skill-save time, next day
Go deeper

In one line: Three information scopes: chat (single conversation, claude.ai default), project (a folder — plans, skills, hooks, MCPs persist across sessions there), and user (machine-wide via ~/.claude — plugins and personal facts in every context). Choose scope at creation time for agents and skills.

'Whatever information you're having inside the chat remains only inside the chat' — the chat-app limitation named (0:27:16)

Project scope: reconnect the same folder and 'the information I spoke in a different chat remains here as well' (0:29:16)

User scope lives in ~/.claude under your account-named home directory — shown in Finder (0:33:19)

Repeat-explained on request: the three-tier definition was re-delivered in full when a learner asked (0:31:18)

Try it now

Open your home directory's .claude folder and inventory what's user-level on your machine — that's what every session inherits.

▶ Watch this taught: 0:27:16

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

You want a skill available in every project on your machine — which scope, and where does it physically live?

User scope — under the .claude folder in your home directory, which every session on the machine reads.

05

Word Rush: one-line prompt → plan questions → comment revisions → screenshot iteration

how-to0:39:28

The game names itself wrong, ships without a menu button, and gets an ugly first design — and every one of those flaws becomes a one-line fix.

The loop teaches iteration as the native motion of app-building: vague prompt (on purpose, 'so that I can make some mistakes'), plan mode turning vagueness into choices, the comment feature making plan revision surgical, and screenshots making bug reports unambiguous. Model economics ride along: strong model to plan and build, cheap model for the home-button fix. Claude even self-tests toward the end — screenshotting the app itself to confirm rendering before declaring done.

Worked example · from the session

The finished loop output: a retro typing game with easy/medium/hard tiers (word length 3–4/4–7/7+), lives, sound effects, a main-menu button added on request, then a full Duolingo-style visual rebuild — with a learner (Shravan) shipping a Super Mario variant in parallel.

Do it in this order

Gotchas["One prompt is never the finished thing — 'one prompt, it's not the best thing' — the loop is the method", "Playing the game costs nothing: 'we built it once, tokens were utilized once… to play, we are not using AI'", "The comment feature threw the room — it's just select-text-then-type, no button; three questions in a row about it"]

Why it matters

This is vibe coding with guardrails for a terminal-shy audience — every session-11 concept (modes, models, commands) exercised inside one toy build.

People get this wrong

A better first prompt would have avoided the iteration.

The iteration IS the method — the vague prompt was deliberate, because plan questions, comments, and screenshots are cheaper than trying to specify everything up front.

Empty folder simple prompt, on purpose PLAN mode it asks the questions Comment on plan select text → 'Word Rush' Accept + AUTO 772 lines land Play it in the browser find the real flaws Screenshot + one line 'I don't see a back button' downshift to Sonnet for small fixes Build once, play free: tokens are spent at build time, not at run time 'One prompt — it's not the best thing.' The loop is the method. Redesign runs the same loop: plan mode → style questions → accept → auto
The app-side build loop: vague prompt in plan mode, clarify, comment on the plan, accept into auto, iterate with screenshots
We built it once. Tokens were utilized once. To play the game, we are not using AI, so that's fine.0:56:04
For your projects

["The build-once-run-free point is worth a KB callout — it's the single best beginner reframe of agentic-build economics in the course so far."]

This idea elsewherebuilds onthe same iterate-on-evidence doctrine, Cursor-sidebuilds onthe portal's plan-first rule, app-side
Go deeper

In one line: The app-side build loop: empty folder + plan mode + simple prompt → answer generated scoping questions → revise via select-and-comment on the plan → accept into auto mode → iterate with screenshot-plus-instruction, downshifting models for small edits.

Plan mode generated the scoping questions itself — mechanic, vibe, stack — each with selectable options (0:41:33)

Comment-on-plan: select text, type, plan revises — 'I just selected this word, and it opened this window' (0:45:36)

Screenshot-as-bug-report is the taught editing move (0:51:40)

Cost discipline inline: Opus for the build, 'switch the model from Opus to Sonnet just to save a bit of token' for the button (0:53:41)

Claude self-tested the redesign with its own screenshot before reporting done (1:11:55)

Try it now

Recreate it in one sitting: empty folder, the verbatim game prompt, and force yourself to fix the first flaw by screenshot rather than description.

▶ Watch this taught: 0:39:28

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What are the two cheap-iteration moves the loop leans on after the first build?

Select-and-comment on the plan for intent changes, and screenshot-plus-one-line for concrete flaws — both on a downshifted model when the change is small.

06

Plugins vs skills vs connectors — and the three worth installing

1:11:55

The vocabulary finally lands: a plugin is a bag of skills, a connector is an MCP, and once installed, Claude picks the right skill itself.

Definitions settled in one pass: a plugin is a group of skills (superpowers alone contains many); a connector is an MCP linking Claude to other apps; a skill is one trained capability. His starter three: superpowers (Anthropic — its brainstorming skill 'thinks in a logical sense of feasibility,' beyond plan mode's context-gathering), front-end design (Anthropic — 'a trained employee with highly UI/UX design ideas' vs generic output), and Context7. Marketplace skills install by pasted prompt: copy the install text from the listing (UI UX Pro Max demoed), paste it, Claude downloads and registers it.

Two operating rules: installed skills are auto-invoked — 'Claude can decide whenever the skill should be used… but for it to decide, it should first have it installed'; and don't run two skills on the same job — same logic delivered two ways 'will get hallucinated.'

Worked example · from the session

Live A/B: the game's landing page before any skill is 'very plain'; rebuilt with front-end design invoked, it's a full structured page — 'that is because we gave it a particular skill.' Brainstorming meanwhile chews on 'what can be improved in the game?' in a parallel chat.

Why it matters

This is the session's answer to generic AI output: specialization by installed skill, chosen automatically once present.

People get this wrong

More skills active on a task means better output.

Two skills with overlapping logic delivered differently is a hallucination recipe — one specialist per job.

Teach it 1 job, and you can reuse it forever.0:21:15
Skill is basically you're creating an employee for you with a particular role. One skill can do one particular thing, but it can do it exceptionally well.0:23:15
If you're adding same logics in different manner to the LLM, it will get hallucinated. So it's ideally not suggested to use 2 skills at the same time.1:20:44
For your projects

['His one-specialist-per-job rule is a useful lens on your own skills list — near-duplicate skills are a real cost here too.']

This idea elsewherereappears inthe terminal-side install flows, next dayreappears inwhat the easy install makes possible — and risky
Go deeper

In one line: Plugin = group of skills; connector = MCP to external apps; skill = one trained capability. Starter set: superpowers (incl. brainstorming), front-end design, Context7. Marketplace skills install via pasted prompt; installed skills are auto-selected by Claude; avoid two skills on one job.

Brainstorming vs plan mode distinguished: planning gathers context, brainstorming reasons about feasibility (1:16:21)

Front-end design as the specialist-employee metaphor; visible before/after on the landing page (1:18:41, 1:44:21)

Marketplace install = copy the listing's prompt, paste, done (1:22:44)

Auto-invocation requires installation first; then Claude picks skill and order (1:24:44)

Two-skills-at-once warning: overlapping logics hallucinate the LLM (1:20:44)

Q&A: skills.sh identified as the same kind of directory; AI output non-deterministic, so same skill ≠ same design (2:38:38, 1:24:44)

Try it now

Install superpowers and front-end design (plugins → browse), then rerun a recent design prompt and compare against your skill-less version.

▶ Watch this taught: 1:11:55

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What must be true before Claude can auto-select a skill for your task?

The skill must already be installed — Claude chooses among what's present; it can't reach for what isn't there.

07

The GTM launch board: md-as-intermediate, then an app from the plan

how-to1:54:57

The business app isn't built from a prompt — it's built from a FILE the first prompt wrote, which you got to read before any code existed.

The pattern taught: separate strategy generation from app generation with a markdown intermediate. Prompt 1 produces gtm-plan.md — human-readable, reviewable, editable. Prompt 2 consumes the file, so the Kanban's tickets and KPI cards are grounded in an artifact you approved, not in whatever the model remembers. Prompt 3 turns a display into a tool (CRUD, assignees, progress). It's the same md-as-contract idea that session 15 formalizes as goal files — here at beginner scale, for a business use case: 'everything about our business stays inside one app.'

Worked example · from the session

Nike-branded (his joke name) DTC athleisure running-shoe launch: gtm-plan.md with ICP through KPIs, then a dark-theme board with draggable tickets ('set up tracking', 'log the offer'…), mission-readiness meter, person A/B/C filters, and a live-created 'celebrations' ticket.

Do it in this order

Gotchas['The md-first split is the whole trick — strategy reviewable as text before any UI exists', "Progress math surprised the room: to-do→in-progress doesn't move readiness; only done does", 'The workbook PDF ends with two 7-day challenges (business tool, game) — the homework layer']

Why it matters

It's the session's transferable business pattern — any strategy-then-tracker workflow (launches, hiring, projects) is these same three prompts with a different first persona.

People get this wrong

Business apps need databases and backends from day one.

A single-file HTML board grounded in a markdown plan is a working tracker; auth/database/backend are explicitly deferred as 'the higher technical side.'

Prompt 1: strategist ICP · channels · 30/60/90 · KPIs gtm-plan.md a FILE, not an app Prompt 2: the board Kanban FROM the file Prompt 3: features CRUD · assignees · progress 'Use GitHub and Vercel' one sentence to a public URL Gmail MCP drafts outreach waits for a human The md-as-intermediate pattern: review the strategy as text BEFORE any code exists Live lesson from the deploy: two apps in one folder = Claude ships the default one Same pattern fits any strategy-then-tracker workflow — launches, hiring, projects
Three prompts, one pattern: strategist writes gtm-plan.md, the board is built FROM the file, features layer on
For your projects

["Prompt 1's persona+deliverables+format shape is a strong template for your own strategy docs."]

This idea elsewherereappears inmd-as-contract, formalized into goal filesreappears inthe business-tool framing, n8n-side
Go deeper

In one line: A three-prompt business-app pattern: (1) persona prompt writes a structured plan to a .md file only; (2) a single-file HTML Kanban is generated FROM that file (draggable cards, KPI header, dark theme, front-end skill); (3) a feature pass adds progress metrics, ticket CRUD, and assignee filtering.

Prompt 1's discipline: 'I'm not asking to create an app' — the file IS the deliverable (2:03:33)

Board grounded in the file: 'draggable cards loaded with the launch tasks from gtm-plan.md' (2:03:33)

Feature pass verbs: loading screen, mission readiness, add/edit/delete, per-person assign and filter (2:09:53)

Verified by use, on stage: drag, filter, create 'celebrations', edit — 'it is now a functioning product for me' (2:15:58)

Workbook PDF carries the full prompts plus two 7-day challenges — HARVEST when posted (1:42:18, 2:32:16)

Try it now

Run the pattern on something real: prompt 1 as a strategist for one initiative writing plan.md; prompt 2 building the tracker from the file; prompt 3 adding only the features you actually need.

▶ Watch this taught: 1:54:57

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why does the pattern insist the first prompt write a file instead of building the app directly?

So strategy is reviewable and editable as text before code exists — and so the app is grounded in an approved artifact rather than model memory.

08

Gmail MCP, warts and all: add by prompt, fail, paste the error, ship drafts

1:44:21

The OAuth flow failed twice on stage — and that was the most valuable part of the demo.

The connector adds by prompt ('Add Gmail MCP') if it isn't in the browse list; Claude runs the commands and opens the sign-in page. His auth failed, the page errored, tokens didn't stick — and the taught recovery was the session's best line: 'just give the error to Claude, and it will get the fix done.' Once live, the test ladder runs fetch (three latest emails read back) → send (live to volunteer learners, invoked as a Gmail send-email skill) → draft-not-send for the real workflow: three personalized ICP outreach emails from the GTM plan landing in his drafts folder, human review preserved.

The privacy boundary gets an honest answer: connecting Gmail hands personal data to Claude — 'you'll have to find a balance… some emails I'm comfortable sharing.' And the standing caution from the recap applies: every active connector feeds context, so don't keep connectors you aren't using.

Worked example · from the session

Drafts shown in his real Gmail: three emails, each with recipient, subject, body, personalized per learner-provided address — generated by prompt, waiting in drafts.

Why it matters

It closes the loop the recap opened: connectors are how Claude acts on your behalf, and drafts-not-sends is the beginner-safe pattern for real outreach.

People get this wrong

A failed OAuth or connector error means the setup is broken for you.

Paste the error to Claude — connector debugging is itself a promptable task, demonstrated twice in one session.

Whatever issue you face while working with Claude — it's easier to just give the error to Claude, and it will get the fix done.1:50:49
Whenever you're connecting different tools to Claude, you are essentially giving your personal information to Claude… you'll have to find a balance.2:44:50
For your projects

['His paste-the-error doctrine is also your fastest path in this project when DC or build scripts fail.']

This idea elsewherebuilds onthe cost half of the connector storyreappears inthe portal's email workflow, human-gated the same way
Go deeper

In one line: MCP connectors add by prompt with OAuth in the browser; failures are debugged by pasting errors back to Claude. Capability ladder: fetch → send → draft-for-review, with drafts as the safe default for generated outreach; connect only what you're comfortable sharing and keep unused connectors off.

'Add Gmail MCP' is the whole install prompt when the browse list doesn't show it (1:46:22)

Live failure recovered: prior stale tokens caused repeat auth errors; re-auth fixed it — narrated as intended learning ('I'm going to pretend this mistake is the planned one') (1:50:49, 2:11:54)

The learner correction that mattered: 'I see in the prompt — leave them in DRAFT' after he moved to send; drafts restored (2:20:01)

Privacy answer: balance, not absolutes — share what you're comfortable with (2:44:50)

n8n comparison in Q&A: fixed automations cheap to run, hard to build; Claude Code automations easy to build, expensive to run (1:54:57)

Try it now

Add one connector by prompt, and when anything fails, paste the raw error back instead of describing it — count how often that alone fixes it.

▶ Watch this taught: 1:44:21

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

What's the beginner-safe endpoint for AI-generated outreach, and why?

Gmail drafts — the generation is automated but a human reviews and presses send, which is exactly what the learner correction enforced.

09

From folder to URL: GitHub + Vercel by one prompt — including the wrong-app mistake

2:22:12

The deploy worked flawlessly — except it shipped the game instead of the launch board, because both lived in one folder.

Hosting for non-engineers: two accounts (GitHub for the code, Vercel as the free host), both pre-connected as connectors, and then the entire deploy is 'Use GitHub and Vercel.' If they aren't connected, Claude Code supplies the connect URLs and walks you through. The live mistake carried the real lesson: with the game AND the board in the same folder, Claude deployed the default one — the game. Diagnosis (a learner spotted it), then an explicit instruction to deploy the launch board, fixed it. Both URLs went to the cohort; a repo full of the session's code appeared on GitHub without a git command being typed.

Worked example · from the session

Public launch-board URL shared in Zoom moments after the fix; the earlier game URL a happy accident that demonstrated exactly why one-folder-one-app matters.

Why it matters

It completes the arc — build, improve, connect, ship — at the same no-terminal altitude as everything else, and its failure mode teaches folder hygiene better than a warning would have.

People get this wrong

Deploying requires knowing git.

The connectors carry it — repo, push, and hosting happened from one sentence; git knowledge is deferred exactly like databases were.

For your projects

['Your course-site is deliberately manual-push; this is the opposite end of the spectrum — worth having both patterns in the KB with their tradeoffs.']

This idea elsewherereappears inthe terminal CLI version, two days laterreappears inthe git fundamentals underneath this magic
Go deeper

In one line: Deployment via connected GitHub + Vercel accounts with a one-line prompt; Claude handles repo creation, push, and hosting to a public URL, guiding account connection if missing. Folder hygiene matters: multiple apps in one folder means Claude picks a default unless told which to ship.

Prerequisites named plainly: a GitHub account, a Vercel account — 'few technical things you may want to dive into, but if you don't, that's fine' (2:22:12)

The whole deploy prompt: 'Use GitHub and Vercel' (2:22:12)

Wrong-app incident: two apps, one folder, default picked; fixed by explicit naming — learner (Dharmesh) diagnosed it first (2:30:15)

Vercel defined for the room: 'a free cloud provider… to host your websites' (2:24:22)

Q&A boundary: logins/databases (Supabase, MongoDB) deferred to a future, more technical session (2:36:16)

Try it now

Deploy any single-file app with the one-line prompt — but first check what ELSE is in that folder.

▶ Watch this taught: 2:22:12

Check yourself

Answer from memory first — the recall attempt is what makes it stick. Then reveal.

Why did the first deploy ship the wrong app, and what's the prevention?

Both apps shared one folder, so Claude shipped the default; prevention is one-app-one-folder — or explicitly naming the app in the deploy prompt.

Every concept, three clicks deep

The same concepts as a quick reference: the closed row is the glance, open is the study card, and every timestamp jumps into the recording.

01The three modes as a trust spectrum — and plan-then-auto as the working rhythmClaude Code's modes form a trust spectrum — ask-permissions (confirm everything), plan (interview and plan…0:09:12›

Claude Code's modes form a trust spectrum — ask-permissions (confirm everything), plan (interview and plan only), auto/bypass (execute freely, stop on destructive commands) — with plan-then-accept-into-auto as the taught default rhythm for building.

Cohort-sourced definitions confirmed live: 'every time Claude will ask' / 'it only plans, it doesn't build' / 'danger… big risk… just execute' (0:09:12)

Auto mode still brakes on destructive commands — 'it is going to stop automatically' (0:45:36)

/plan the command and plan mode the toggle are the same thing (0:15:13)

Self-correction modeled: the GTM prompt is re-run in plan mode after he catches himself in auto (1:56:58)

Q&A close: plan mode is also the answer to 'AI changed things I didn't want' — review the intent before it touches the app (2:42:44)

02The everyday slash commands: /init, /plan, /model, /clear, /compactCore command set: /init (create CLAUDE.md), /plan (enter plan mode), /model (route smart-vs-cheap by task),…0:11:12›

Core command set: /init (create CLAUDE.md), /plan (enter plan mode), /model (route smart-vs-cheap by task), /clear (reset chat), /compact (summarize context; recommended at 40–50% usage; automatic at the limit) — available identically in app and terminal.

Model routing rule of thumb: 'complex task → Fable or Opus; changing a file name → Sonnet or Haiku' (0:17:13)

/compact 'helps you save tokens… reduces token usage in the future'; auto-compact fires at 100% (0:19:13)

Threshold guidance: compact at ~40–50% context fill (0:19:13)

Commands discoverable via slash or the plus-icon menu — no memorization (0:15:13)

Context readout demystified for the app: the percentage icon bottom-right, with per-category token split (1:09:54)

03CLAUDE.md: the project brain /init writes for youCLAUDE.md is the folder-level project memory created by /init (summary, run instructions, architecture, con…0:13:13›

CLAUDE.md is the folder-level project memory created by /init (summary, run instructions, architecture, conventions), automatically included in future conversations in that folder; updated on request rather than regenerated, and creatable at any point in a project's life.

'A brain for Claude… whenever we ask anything, it will use that brain' (0:13:13)

Cohort framing accepted: CLAUDE.md as mind map / master system prompt for the project (0:13:13)

Architecture in the file 'is helping us save the tokens in the future and provide the right context' (1:00:05)

Timing is flexible — 'totally depends whenever you want to activate your brain'; update by asking, not re-running (0:58:04–1:00:05)

04Chat, project, user: where information livesThree information scopes: chat (single conversation, claude.ai default), project (a folder — plans, skills,…0:27:16›

Three information scopes: chat (single conversation, claude.ai default), project (a folder — plans, skills, hooks, MCPs persist across sessions there), and user (machine-wide via ~/.claude — plugins and personal facts in every context). Choose scope at creation time for agents and skills.

'Whatever information you're having inside the chat remains only inside the chat' — the chat-app limitation named (0:27:16)

Project scope: reconnect the same folder and 'the information I spoke in a different chat remains here as well' (0:29:16)

User scope lives in ~/.claude under your account-named home directory — shown in Finder (0:33:19)

Repeat-explained on request: the three-tier definition was re-delivered in full when a learner asked (0:31:18)

05Word Rush: one-line prompt → plan questions → comment revisions → screenshot iterationThe app-side build loop: empty folder + plan mode + simple prompt → answer generated scoping questions → re…0:39:28›

The app-side build loop: empty folder + plan mode + simple prompt → answer generated scoping questions → revise via select-and-comment on the plan → accept into auto mode → iterate with screenshot-plus-instruction, downshifting models for small edits.

Plan mode generated the scoping questions itself — mechanic, vibe, stack — each with selectable options (0:41:33)

Comment-on-plan: select text, type, plan revises — 'I just selected this word, and it opened this window' (0:45:36)

Screenshot-as-bug-report is the taught editing move (0:51:40)

Cost discipline inline: Opus for the build, 'switch the model from Opus to Sonnet just to save a bit of token' for the button (0:53:41)

Claude self-tested the redesign with its own screenshot before reporting done (1:11:55)

06Plugins vs skills vs connectors — and the three worth installingPlugin = group of skills;1:11:55›

Plugin = group of skills; connector = MCP to external apps; skill = one trained capability. Starter set: superpowers (incl. brainstorming), front-end design, Context7. Marketplace skills install via pasted prompt; installed skills are auto-selected by Claude; avoid two skills on one job.

Brainstorming vs plan mode distinguished: planning gathers context, brainstorming reasons about feasibility (1:16:21)

Front-end design as the specialist-employee metaphor; visible before/after on the landing page (1:18:41, 1:44:21)

Marketplace install = copy the listing's prompt, paste, done (1:22:44)

Auto-invocation requires installation first; then Claude picks skill and order (1:24:44)

Two-skills-at-once warning: overlapping logics hallucinate the LLM (1:20:44)

Q&A: skills.sh identified as the same kind of directory; AI output non-deterministic, so same skill ≠ same design (2:38:38, 1:24:44)

07The GTM launch board: md-as-intermediate, then an app from the planA three-prompt business-app pattern: (1) persona prompt writes a structured plan to a .md file only;1:54:57›

A three-prompt business-app pattern: (1) persona prompt writes a structured plan to a .md file only; (2) a single-file HTML Kanban is generated FROM that file (draggable cards, KPI header, dark theme, front-end skill); (3) a feature pass adds progress metrics, ticket CRUD, and assignee filtering.

Prompt 1's discipline: 'I'm not asking to create an app' — the file IS the deliverable (2:03:33)

Board grounded in the file: 'draggable cards loaded with the launch tasks from gtm-plan.md' (2:03:33)

Feature pass verbs: loading screen, mission readiness, add/edit/delete, per-person assign and filter (2:09:53)

Verified by use, on stage: drag, filter, create 'celebrations', edit — 'it is now a functioning product for me' (2:15:58)

Workbook PDF carries the full prompts plus two 7-day challenges — HARVEST when posted (1:42:18, 2:32:16)

08Gmail MCP, warts and all: add by prompt, fail, paste the error, ship draftsMCP connectors add by prompt with OAuth in the browser;1:44:21›

MCP connectors add by prompt with OAuth in the browser; failures are debugged by pasting errors back to Claude. Capability ladder: fetch → send → draft-for-review, with drafts as the safe default for generated outreach; connect only what you're comfortable sharing and keep unused connectors off.

'Add Gmail MCP' is the whole install prompt when the browse list doesn't show it (1:46:22)

Live failure recovered: prior stale tokens caused repeat auth errors; re-auth fixed it — narrated as intended learning ('I'm going to pretend this mistake is the planned one') (1:50:49, 2:11:54)

The learner correction that mattered: 'I see in the prompt — leave them in DRAFT' after he moved to send; drafts restored (2:20:01)

Privacy answer: balance, not absolutes — share what you're comfortable with (2:44:50)

n8n comparison in Q&A: fixed automations cheap to run, hard to build; Claude Code automations easy to build, expensive to run (1:54:57)

09From folder to URL: GitHub + Vercel by one prompt — including the wrong-app mistakeDeployment via connected GitHub + Vercel accounts with a one-line prompt;2:22:12›

Deployment via connected GitHub + Vercel accounts with a one-line prompt; Claude handles repo creation, push, and hosting to a public URL, guiding account connection if missing. Folder hygiene matters: multiple apps in one folder means Claude picks a default unless told which to ship.

Prerequisites named plainly: a GitHub account, a Vercel account — 'few technical things you may want to dive into, but if you don't, that's fine' (2:22:12)

The whole deploy prompt: 'Use GitHub and Vercel' (2:22:12)

Wrong-app incident: two apps, one folder, default picked; fixed by explicit naming — learner (Dharmesh) diagnosed it first (2:30:15)

Vercel defined for the room: 'a free cloud provider… to host your websites' (2:24:22)

Q&A boundary: logins/databases (Supabase, MongoDB) deferred to a future, more technical session (2:36:16)

Tools referenced

ToolCoverageMomentContext
Claude Codedemonstrated0:37:26Desktop app throughout — modes, plan comments, /init, /compact, context readout, plugins UI; terminal deliberately avoided
VS Codedemonstrated0:35:23File viewer only — 'just to view the files'
Gmail MCPdemonstrated1:46:22Added by prompt; OAuth failed twice and was debugged live; fetch, send, and draft flows all shown
GitHubdemonstrated2:22:12Connector; repo created and pushed by prompt, no git commands
Verceldemonstrated2:22:12Connector; free hosting to a public URL; wrong-app incident and fix
superpowersdemonstrated1:11:55Anthropic plugin; brainstorming skill run on 'what can be improved in the game?'
front-end designdemonstrated1:18:41Anthropic plugin; before/after landing-page comparison is the proof
UI UX Pro Maxdemonstrated1:22:44Marketplace skill installed by pasted prompt as the install demo
Slidodemonstrated2:36:16Closing Q&A board
n8nexplained1:54:57Q&A comparison: fixed automations vs Claude Code's AI automations; Claude can write n8n JSON workflows
Context7mentioned1:11:55Third of his three starter skills; not exercised on stage
Ollamamentioned1:52:54Learner question; possible but 'not that smart a model' for automations — not recommended
Supabasementioned2:36:16Named (with MongoDB) as the database path deferred to a future technical session
MongoDBmentioned2:36:16Same deferral
Cursormentioned2:38:38Q&A comparison: both agentic coders; Cursor 'highly technical', Claude Code easier
Emergentmentioned2:40:39Q&A: 'very much like Lovable' — fixed website/app products vs Claude Code's customizability
Coworkmentioned2:42:44Q&A: 'Claude Cowork and Perplexity Computer are quite similar — working on your own machine'
skills.shmentioned2:38:38Identified in Q&A as an agent-skills directory like the marketplace demoed

Session materials

Archived locally on V: — click to open. Companion pages link to the LMS.

pdf
COURSE-BOOK.pdf
164 KB
vtt
GMT20260705-135958_Recording.transcript.vtt
140 KB

Action items

Resources mentioned

Resources
  • docGame build prompt (verbatim as typed) 0:39:28
  • docPlan-comment example (verbatim) 0:43:36
  • docScreenshot-iteration prompt (verbatim as typed, screenshot attached) 0:51:40
  • docRedesign prompt (verbatim as typed, in plan mode) 1:02:05
  • docBrainstorming-skill prompt (verbatim) 1:16:21
  • docGmail MCP install prompt (verbatim) 1:46:22
  • docGTM strategist prompt (workbook prompt 1, structure as recounted on stage; full text in the PDF) 2:03:33
  • docLaunch-board prompt (workbook prompt 2, verbatim as read) 2:03:33
  • docFeature-pass prompt (workbook prompt 3, content as recounted) 2:09:53
  • docDeploy prompt (verbatim) 2:22:12
  • docWorkbook PDF 1 — game build walkthrough + activities 0:35:23
  • docWorkbook PDF 2 — GTM launch board + 7-day challenges 1:42:18
  • docTrainer LinkedIn (Prakash) 2:38:38
  • docUI UX Pro Max skill listing (marketplace) 1:22:44

Extraction notes

This page was built from an auto-generated transcript, which garbles product and people's names. Those were corrected silently in everything above and logged here for transparency. The warnings flag claims that were true on the recording day but change fast.

Transcript corrections applied

The transcript saysThe trainer actually means
Praca GuptaPrakash Gupta (trainer; master-directory name on screen; host sign-off 'Thank you, Prakash')
cloud code / claud / plot code / Cloudboard / CloudCoh workClaude Code / Claude / (last:) Claude Cowork
chart / charts (throughout)chat / chats — the session's most persistent ASR collapse
cloud dot m d / claw dot m dCLAUDE.md
Versal / Wersl / verbalVercel
SuperBase / super baseSupabase
any 10 / Anytime / an end in / n a 10n8n
Olama / OlaumaOllama
dual lingoDuolingo (style reference for the redesign)
g t s 6GTA 6 (learner joke request)
skill dot s h / skill m pskills.sh / the skills marketplace
table (in 'which use this table')Fable (model name)
Harika / Naraka / NarikaNiharika
EntropicAnthropic
AIAN is indeterministicAI is non-deterministic
Damesh / DharmeshDharmesh (learner who diagnosed the wrong-app deploy)

True on recording day — verify before relying