← All sessionsHomeSearch
AI Catalyst C3·Core Sessions - Week 6·2:20:39

Session 11: Overview of Claude Code & Key Concepts (Installs, Modes, Context Files, Skills, Hooks & MCPs)

Prakash Trainer — theory day of his two-day pair: what Claude Code is vs the chat app, three install routes, the mode/trust spectrum, the three context files, the anatomy of a skill (metadata vs prompt, lazy loading), hooks as guardrails, and MCP connectors — with his real business skills folder opened on screen · Niharika Cohort manager (opens the session, runs Slido and feedback at close)
▶local recording  ·  LMS lesson

Session map

WHAT IT IS & GETTING INTHE CONTROL SURFACETHE POWER FEATURESClaude vs Claude Codeanswers vs actionsThree ways interminal, desktop app, VS Code — same t…Five modes on one trust spect…CLAUDE.md, memory.md, .claude…/init, /plan, /model, /clear,…Anatomy of a skillmetadata always, prompt only on useDownloading skillsthe marketplace, portability, and the t…Hooksif X happens, Y must happen — guardrail…Connectors are MCPsgiving Claude hands in your other apps
What it is & getting inThe control surfaceThe power features
click a node — its card pops up (drag it anywhere, × to close)
Concept

The map reads left to right — what it is & getting in flow into the control surface, then into the power features. Click any node to open that idea here; every timestamp jumps into the recording.

The short version

  1. The dividing line drawn first and repeated: 'Chat can only give you answers… Claude Code can do actions on your behalf' — files created, edited, and deleted on your own machine, which is why it must be installed and must run inside a folder.
  2. Claude Code positioned for non-engineers: 'it's not exactly for engineers — it's for you to become an engineer using Claude.'
  3. The control surface: five modes on a least-trust→full-trust spectrum, an effort slider distinct from model choice, and the everyday slash commands (/init, /plan, /model, /clear, /compact, /code-review).
  4. The context architecture: CLAUDE.md (the folder's goal), memory.md (long-term memory), and the .claude folder (skills, hooks, settings) — including the self-updating hack of writing 'update claude.md every time user chats' INTO the file itself.
  5. The skills deep-dive is the session's core: a skill is one folder + one SKILL.md = metadata (always sent) + prompt (loaded only on use) — 'how cool is it that a single MD file can turn a generic AI into a specified employee?' — with marketplace downloads, exact-naming rules, and honest trust warnings.

The concepts

01

Claude vs Claude Code: answers vs actions

0:28:49

Ask both to build a website: chat hands you code to paste somewhere; Claude Code creates the site inside your own folder while you watch.

The chat app (claude.ai) is a chatbot: it fetches and formats information, and everything it makes lives in the conversation. Claude Code operates your machine: it creates, edits, renames and deletes files, which is exactly why it requires installation and a folder to work in — and why its trust modes exist. The positioning is aimed at non-engineers: you don't write code in Claude Code; it writes code for you from plain prompts.

His own usage list makes the case concrete: finance management, career management, his business, and new products all run through Claude Code, not chat — including an enterprise-level product he built. The comparison extends in Q&A: 'if you remove the technicality, that is Claude Cowork for you' — same models, different surfaces.

Worked example · from the session

Live demo pair: 'Build a 1-pager website on Claude Code and benefits' typed into Claude Code produces the file in his machine; the same request in chat would produce copy-paste text he can't act on.

Why it matters

This one distinction motivates the whole session: modes, context files, skills and hooks all exist because Claude Code touches your real machine.

People get this wrong

Claude Code is the developers' version of the chat app.

It's the ACTING version — the audience is anyone who wants outcomes on their machine; the code it writes is its means, not your prerequisite.

Same models, different powers Claude (chat app) answers — text in a browser tab Claude Code actions — real files on your machine fetches & formats information output lives in the conversation copy-paste to act on anything creates / edits / deletes files runs inside a folder you choose builds, deploys, automates vs 'Chat can only give you answers. Claude Code can do actions on your behalf.'
The chat app gives you text to copy; Claude Code creates the files on your machine
It's not exactly for engineers. It's for you to become an engineer using Claude.0:10:36
Chat can only give you answers. It cannot do actions on your behalf. Claude Code can do actions on your behalf.1:13:28
If you remove the technicality, that is Claude Cowork for you.1:17:30
For your projects

["His Cowork description is literally this environment — worth quoting on the KB's orientation page."]

This idea elsewherereappears inthe hands-on day that assumes this distinctionbuilds onthe portal's chat-to-agent ladder, tool-side
Go deeper

In one line: The chat app answers; Claude Code acts — creating and modifying real files inside a chosen folder on your machine, via plain-language prompts. Requires install (terminal, desktop app, or IDE) and a Pro/Max plan; all sibling products (chat, Code, Cowork) share the same underlying models.

'It is playing around with your files… to be able to do that, we want to install Claude Code' (0:10:36)

'It's not exactly for engineers. It's for you to become an engineer using Claude' (0:10:36)

Without a folder, Claude Code cannot run — every session binds to one (1:21:35)

Cowork placed in the family: 'more of a surface-level bot for your machine… everything is utilizing different models of Claude' (1:17:30)

Codex named the direct competitor (OpenAI's); 'you cannot use one inside the other' — though GPT models can be used within Claude Code (2:09:02, 2:17:04)

Try it now

Ask both surfaces for the same small artifact and note where the output physically lives — that's the entire difference in one experiment.

▶ Watch this taught: 0:28:49

Check yourself

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

Why does Claude Code require an install and a folder when chat needs neither?

Because it acts on your real filesystem — creating, editing and deleting files — so it needs machine access and a bounded workspace, which is also why trust modes exist.

02

Three ways in: terminal, desktop app, VS Code — same tool, choose your comfort

how-to0:12:37

The scariest step of the whole course is one pasted command and the word 'claude.'

Three installation homes, one tool. The terminal is the native, lightest surface; the desktop app removes the terminal entirely; VS Code wraps the same CLI in a window where you can watch files appear as Claude creates them — 'basically a dashboard.' He demos all three, then defuses the which-is-better question deliberately: whatever UI you're comfortable in. What's non-negotiable is the folder: Claude Code sessions bind to a directory, and the empty-folder-per-project habit keeps work tidy and context clean.

Worked example · from the session

The full tour: brew-style one-liner in Terminal → 'claude' → the CLI UI (version, model, effort, plan, directory, his custom token statusline); the app's Code tab doing the same; VS Code showing index.html appear in the file tree as it's written.

Do it in this order

Gotchas["All three are the same Claude Code — 'there is no difference at all'; the choice is pure UI comfort", "The cohort's live reaction ('people are not liking terminal') is what pushed the session toward the app — and shaped session 12 entirely", "An empty, dedicated folder per project is the stated good practice — 'things are very tidy, very clean'"]

Why it matters

Removing the install barrier is the session's job — every later concept assumes you're inside a folder-bound session somewhere.

People get this wrong

The terminal version is the 'real' Claude Code and the app is a lite edition.

'Everything remains the same' — the app IS Claude Code; the terminal just came first and suits people who like shells.

For your projects

['Session 14 taught the same trio with billing emphasis; this is the comfort-first version — the KB now has both framings.']

This idea elsewherereappears inthe same trio, billing-first framing
Go deeper

In one line: Claude Code installs via a one-line terminal command, the desktop app's Code tab, or inside any IDE's terminal (VS Code shown); all are the same tool. Sessions bind to a folder (workspace-trust approval required); one empty folder per project is the taught practice.

Install instructions found by searching 'claude code install' — one command per OS (0:14:38)

VS Code's value is visibility: files appear in the tree as Claude writes them (0:18:42)

'Whatever UI makes you comfortable, that's good for you' — repeated verbatim twice under questioning (0:26:49, 0:45:14)

Folder binding: 'without a folder, Claude Code cannot run' (1:21:35)

Workspace-trust error decoded in Q&A: approve it or Claude can't act there (2:13:03)

Try it now

Install by whichever route matches your comfort, make an empty folder named for one real project, and open it — stop there; that's the whole first session.

▶ Watch this taught: 0:12:37

Check yourself

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

What's actually different between running Claude Code in the terminal, the app, and VS Code?

Nothing functional — same tool, same capabilities; the differences are visual comfort and whether you can watch the files appear.

03

Five modes on one trust spectrum — plus the effort slider beside the model

0:32:51

Every mode answers one question: how much do you trust Claude with your machine right now?

The full menu, cycled live with Shift+Tab: ask-permissions (approve every action — least trust), accept-edits (file edits flow automatically), plan mode (no execution — Claude interviews you, gathers context, builds the plan; 'if an employee comes into my company, I want that employee to ask questions first'), auto mode (his daily driver — edits, creates, moves and deletes without asking), and bypass permissions (full control, can install and delete software — 'quite risky, but Claude will run without any interruption').

Beside the model picker sits the separate effort slider: model is intelligence class, effort is how long that model thinks. More effort = smarter, slower, more tokens; his setting is 'extra or max' as the balance point.

Worked example · from the session

Shift+Tab cycling on screen through plan → auto → agents → accept-edits; then the app's mode menu showing all five named, with the trust-spectrum whiteboard from least (ask) to full (bypass).

Why it matters

The spectrum framing turns five checkboxes into one dial — and pairs naturally with the effort slider as the session's two safety/quality controls.

People get this wrong

Auto mode and bypass are the same recklessness.

Auto executes normal work freely but still brakes on destructive actions; bypass removes even that — it's the far end of the spectrum, not the default.

For your projects

["Effort-vs-model is the same distinction Harshit's /effort menu taught in session 14 — two trainers, one dial."]

This idea elsewherereappears inre-quizzed and exercised the next dayreappears ineffort dial at extra-high, terminal-side
Go deeper

In one line: Five modes ordered by trust: ask-permissions, accept-edits, plan (interview + plan, no execution), auto (free execution, his default), bypass (full machine control, riskiest). Cycled via Shift+Tab or the app's mode menu. Effort is a separate dial — thinking depth per response — distinct from model choice.

Trust spectrum named explicitly: 'least trust to full trust… people will have their own give and take' (0:34:55)

Plan mode's employee analogy: interview first, build after — the generic-website failure is the cautionary tale (0:36:55)

Bypass 'can delete softwares from your system as well' — power and risk stated together (0:41:01)

Effort ≠ model: 'how much that model spends on thinking… smarter but slower and costlier'; his setting extra/max (0:43:02)

Shift+Tab cycle includes an agents mode in the current build — surface churn visible on stage (0:24:44)

Try it now

Find your own default: run one small task in ask-permissions, the same in auto — the annoyance difference tells you where you sit on the spectrum.

▶ Watch this taught: 0:32:51

Check yourself

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

What's the difference between switching model and moving the effort slider?

Model changes intelligence class; effort changes how long that same model thinks — quality/cost/speed within the model you already picked.

04

CLAUDE.md, memory.md, .claude/ — and the self-updating memory hack

0:47:14

The cleverest line of the session is one sentence written INTO a file: 'update claude.md every time user chats with Claude' — a memory that maintains itself.

The taught trio for any serious folder: CLAUDE.md holds the folder's objective — business, goals, what you're building — and gets attached to every prompt automatically; memory.md is long-term memory of what's been done, surviving across sessions where chat context dies; the .claude folder holds the machinery — skills, hooks, settings.json, activity log. Together they eliminate re-explaining: 'you don't have to pass in the context every single time.'

The self-update hack closes the loop: because CLAUDE.md is sent with every message, an instruction inside it to update itself executes on every chat — 'a automatic running loop.' And scope applies: these files exist at project level (the folder) or user level (machine-wide), which is how his user-scope context auto-filled his real company name into a demo website.

Worked example · from the session

/init run live in the empty 'real business' folder → CLAUDE.md created → one prompt ('the goal of this folder is to make a website for my restaurant business') writes the goal in → the file now rides with every future chat in that folder.

Why it matters

This is the context-engineering foundation everything later sits on — skills and hooks are just more files in the same architecture.

People get this wrong

Claude Code remembers your project on its own.

Memory is files you architect — CLAUDE.md and memory.md are the remembering; without them, each session starts as amnesiac as a fresh chat.

For your projects

['Your open-items.yaml discipline is this pattern at project scale — the KB can present them as one doctrine.']

This idea elsewherereappears inthe /init walkthrough, day tworeappears inthe scope model, fully diagrammed next dayreappears inmemory.md grown into loop memory
Go deeper

In one line: The folder context architecture: CLAUDE.md (objective; auto-attached to every prompt; updatable by request or by a self-update instruction written into it), memory.md (long-term action memory), and .claude/ (skills, hooks, settings, logs) — each existing at project or user scope.

CLAUDE.md 'gets passed in every single chat' — that's both its power and the mechanism of the self-update hack (1:01:20, 1:09:24)

memory.md: 'a long-term memory for Claude Code to know what all it has done inside the folder' (0:53:20)

.claude/ contents shown: hooks, skills, settings.json, activity.log (0:51:18)

Scope proof: a demo website auto-picked his real company name from user-scope context (1:21:35)

Casual chat use needs none of this — 'but if you want the true power, you want these 3 files' (0:51:18)

Try it now

Add the self-update line to one project's CLAUDE.md and watch whether the file actually evolves over a week of use.

▶ Watch this taught: 0:47:14

Check yourself

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

Why does writing 'update claude.md every time user chats' inside CLAUDE.md actually work?

Because the file is attached to every prompt — so the instruction is re-delivered every chat, making the update loop self-sustaining.

05

/init, /plan, /model, /clear, /compact, /code-review — the working command set

0:53:20

One command shrank a 331k-token conversation to a tenth of its size without losing the thread.

The set, each demoed: /init writes CLAUDE.md; /plan enters plan mode by command; /model switches models — essential in the terminal where there's no picker button; /clear wipes chat and context entirely; /compact summarizes a long conversation down — his demo took a 33%-full million-token context to ~10%, with the reasoning spelled out: past the token limit, 'your LLM can start hallucinating.' /code-review closes the loop for builders: Claude reviews its own generated code for breaking changes and deploy-readiness — 'AI can generate a lot of code, but if there is no one to review it, softwares will start breaking.'

The metanote he attaches: don't memorize any of this — slash shows the list with descriptions, and use builds the habit.

Worked example · from the session

The compact demo on a real project chat: 331k tokens → ~10% of the window, chat continuity preserved; Q&A confirms compact itself costs tokens but nets savings over the following turns.

Why it matters

These six commands are the difference between wielding Claude Code and just chatting inside it — cost, context, and quality controls in daily reach.

People get this wrong

/clear and /compact do the same cleanup.

/clear destroys the context entirely; /compact preserves the thread in summary form — one is a reset, the other is a diet.

For your projects

['Your fresh-chat-per-sitting practice is /clear; the summary-that-continued-this-conversation is /compact — both patterns, lived.']

This idea elsewherereappears inre-quizzed with thresholds, day tworeappears inthe same window read through /context, Devesh-side
Go deeper

In one line: Working command set: /init (create CLAUDE.md), /plan (plan mode), /model (switch models; the terminal's only picker), /clear (wipe context), /compact (summarize context to prevent hallucination; costs tokens, nets savings), /code-review (self-review generated code for breaking changes). Discoverable via slash — no memorization.

Hallucination framing for compact: token limits exceeded → degraded reasoning; compact restores headroom (1:07:23)

Live numbers: 33% of 1M tokens → ~10% after compact (1:07:23–1:09:24)

/model matters most in the terminal — no button there (1:05:21)

/code-review: self-review for breaking changes, 'can we deploy to prod or not' (1:11:28)

Q&A: compact spends tokens to save tokens — net positive over subsequent turns (2:11:03)

These commands are Claude Code-specific — not available in the chat product (1:11:28)

Try it now

On your longest-running chat: read the context percentage, /compact, read it again. The delta is your recovered runway.

▶ Watch this taught: 0:53:20

Check yourself

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

What's the cost-benefit shape of /compact?

It spends tokens once to summarize, then every subsequent turn rides on the smaller context — net savings grows the longer you continue.

06

Anatomy of a skill: metadata always, prompt only on use

1:36:25

Claude knows all his skills exist without ever reading them — until the moment one is needed, when the full prompt floods in.

A skill is a folder containing a file named exactly SKILL.md, in two parts. The metadata — name plus description — is what rides along in every chat: it's how Claude knows 'weekly brief, offer proposal, LinkedIn post, blog post, meeting notes' exist the moment he says hello. The prompt body — often a full page of context-engineered instruction — stays on disk until Claude decides the skill fits the request, and only then is copied into the chat: 'only when the skill was required, it utilized that information — saving us the precious token.'

The framing is his intern analogy: a fresh LLM is a bright intern with no idea how you work; each SKILL.md trains one specialized employee. Skills can also nest — a skill's .md can point to sibling folders of learnings, transcripts, playbooks — 'there can be a tree of skills.'

Worked example · from the session

His presentation skill, opened live: metadata up top, then the prompt — 'You are a world class presentation designer and storytelling expert…' — and the session's own slide deck as the output proof: 'this entire presentation was created by Claude' using that skill.

Why it matters

Lazy loading is the economic heart of skills — capability at zero standing cost — and the metadata is the selection interface, which is why its description quality decides whether skills get used at all.

People get this wrong

Installing more skills always adds capability for free.

Every skill's metadata rides in every chat — 'hundreds or even thousands of skills' degrade efficiency by flooding the context with descriptions (his own Q&A warning).

One folder, one SKILL.md — two very different loading rules presentations/SKILL.md METADATA name + description PROMPT BODY the full trained-employee instruction Rides in EVERY chat how Claude knows the skill exists Loads ONLY on invocation copied into chat when the task matches 'Only when the skill was required, it utilized that information — saving us the precious token.' Selection lives in the description: write it as if it is all the model will ever see
One folder, one SKILL.md: the metadata travels with every chat; the prompt body loads only when the skill is invoked
How cool is it that a single MD file can basically turn a generic LLM, a generic AI, to a specified employee?1:44:32
Only when the skill was required, it utilized that information. If not, it is not utilizing it, saving us the precious token.1:54:46
For your projects

["This is the third trainer teaching skills in five sessions (11, 13, 14) — the KB's skills topic now has a complete beginner→economics→security arc."]

  • A 'metadata audit' pass over your own installed skills: read only descriptions, flag any you couldn't select correctly from.
This idea elsewherereappears inthe loading economics, formalized next weekreappears inskills as harness componentsbuilds onthe basecamp seed of the idea
Go deeper

In one line: A skill = one folder + one SKILL.md (exact name) with two parts: metadata (name + description; sent with every chat; the selection signal) and prompt body (full context-engineered instruction; loaded only on invocation). Skills nest via reference folders; each defines one specialized 'employee.'

Naming is strict: 'it has to be named exactly SKILL.md, no other nomenclature'; one skill folder each, under .claude/skills (2:15:04)

The hello test: greeting Claude surfaces all skills by name — metadata in action (1:48:44)

Lazy loading spelled out end-to-end: metadata known, prompt unknown, full copy on invocation (1:52:45–1:54:46)

His skills folder is a business org chart: presentations, offers, sales agent, sales funnel, LinkedIn, GTM engineering (1:40:29)

Skill trees: reference folders (learnings, transcripts, playbooks) invoked from within a skill (1:58:51)

Prompt engineering redeemed: 'this is prompt engineering… we are creating a skill with all these detailed prompts' (1:44:32)

Try it now

Open any installed skill's SKILL.md and read just the metadata: could Claude pick this skill correctly from that description alone? If not, you've found your first edit.

▶ Watch this taught: 1:36:25

Check yourself

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

What exactly does Claude know about your skills before any is invoked?

Only each skill's metadata — name and description. The prompt bodies stay on disk until a request matches one.

07

Downloading skills: the marketplace, portability, and the trust warnings

1:54:46

Two million skills are a Google search away — which is exactly why his last word on them is 'be aware of that.'

Search 'claude skills marketplace,' pick a directory (2M+ skills cited on the first), download or copy any listing — it lands as a SKILL.md like any you'd write, so 'you can pick up the best skill out in the market… leverage that highly skilled employee into your own business.' Portability follows from the format: SKILL.md is just a file in a folder, so Codex, Antigravity or any folder-reading tool can use it, with minor per-platform optimization.

Then the caveats, delivered straight: a downloaded skill is someone else's prompt running with your agent's powers — 'make sure it is not doing anything secretive… do your own research'; too many installed skills degrade efficiency because every metadata line ships with every chat; and his IP warning — that skill contents may be used for model training — means 'if there is anything related to security and IP, I would not suggest putting it inside SKILL.md' (claim flagged in freshnessNotes)."

Worked example · from the session

Live search → marketplace → an Instagram-post skill located → download-or-copy-prompt shown; plus the curl-command question resolved: different install route, same SKILL.md landing.

Why it matters

Marketplaces make the skill economy real for beginners — and the same session honestly prices the risks that session 14's vetting doctrine later systematizes.

People get this wrong

A popular marketplace skill is a vetted skill.

Popularity isn't audit — the file is readable text, and reading it yourself is the whole due diligence he asks for.

Whenever you're trusting a prompt from someone else, you should be doing your own research on that.2:13:03
For your projects

['The IP-training claim needs checking before the KB asserts it — paid-plan training policies differ from his blanket statement; flagged in freshnessNotes.']

This idea elsewherereappears inthese warnings, systematized into vettingreappears inthe install flows, demoed in depth
Go deeper

In one line: Skills are downloadable from marketplace directories (2M+ listings cited) and portable across folder-reading agents since SKILL.md is plain text. Risks priced honestly: audit third-party prompts before install, cap installed count (metadata tax), and keep secrets/IP out of skill files.

'I can copy that skill very easily and start using it in my own business' — the acquisition framing (1:56:47)

Cross-platform: 'inside the folder, if there is SKILL.md, any of the tools will utilize it' (2:15:04)

Trust rule: 'you're trusting someone else's prompt — do your own research' (2:13:03)

Efficiency ceiling: hundreds of skills = metadata × hundreds in every chat (2:06:58)

IP warning as stated: skill prompts 'sent to Anthropic's team for their training' — recorded as his claim, verification flagged (2:11:03)

Try it now

Before your next marketplace install, read the SKILL.md in full — it's one text file; 'doing your own research' takes five minutes.

▶ Watch this taught: 1:54:46

Check yourself

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

What are the three costs of marketplace skills he names alongside the benefit?

Trusting a stranger's prompt (audit it), the metadata tax of over-installing, and the risk of exposing IP/secrets placed in skill files.

08

Hooks: if X happens, Y must happen — guardrails, not suggestions

1:58:51

A skill is how you'd LIKE the employee to work; a hook is the rule they physically cannot break.

Hooks are fixed, code-backed instructions bound to events: when X happens, Y executes — every time, deterministically. His example set: task completes → notify me (email/WhatsApp); file deletion attempted → block it; file edited → auto-format; any change → write a log; even time rules ('don't work after 12 AM'). The contrast with skills is the point: 'skill is more like prompt' — guidance the model interprets — while a hook 'is a particular piece of code… if X happens, Y should definitely happen.'

Placement guidance from Q&A: hooks mostly belong at project scope, with a few universal protections (never delete X) at user scope. And hooks chain onto skills: a LinkedIn-post skill plus a hook that publishes whatever the skill produces turns advice into automation.

Worked example · from the session

The employee framings: 'you cannot work after 5 PM' as a time hook; the LinkedIn pair — skill writes the post, hook posts it — as the skill+hook automation unit.

Why it matters

Hooks are the enforcement layer that makes unattended operation safe — the difference between hoping the agent behaves and guaranteeing specific behaviors.

People get this wrong

Hooks are just stronger prompts.

They're not prompts at all — they're event-bound code. The model can't talk its way past one, which is the entire value.

Skills advise; hooks enforce SKILL a prompt the model interprets HOOK code that fires on an event — every time IF: task completes THEN: notify me (email / WhatsApp) IF: file deletion attempted THEN: BLOCK it IF: file edited THEN: auto-format + write a log IF: LinkedIn post created (skill) THEN: publish it (hook completes the automation) Placement: project scope by default; universal protections (never delete X) at user scope
Skills advise; hooks enforce — fixed X→Y rules that fire on events, every time
Skills are what enhances our Claude Code, but hooks are what is guiding our Claude Code.2:09:02
For your projects

["Session 15's guards/hooks harness component is this concept matured; the KB arc is now hook-intro (11) → harness enforcement (15)."]

This idea elsewherereappears inguards/hooks as 'enforcement, not advice'reappears inthe recap quiz's hook definition, next day
Go deeper

In one line: Hooks are deterministic event-action rules (X→Y) enforced in code, not interpreted from prompts: notifications on completion, blocks on deletions, auto-format on edit, logging on change, time cutoffs. Mostly project-scoped, with universal protections at user scope; they chain with skills to complete automations.

'These are some guardrails, some fixed instructions… if X happens, it should do Y' (1:58:51)

Example inventory: notify on done, block delete, auto-format, log changes, time cutoff (2:00:52)

Skill vs hook boundary: prompt-interpreted vs code-enforced (1:58:51)

Skill+hook chaining: create the post AND post it (2:13:03)

Scope advice: project scope default; universal never-delete rules at user scope (2:15:04)

Not a webhook: 'webhook is an endpoint for an API — hook is used in these agentic tools; quite different' (session 12 recap, taught here first)

Try it now

Write your first hook as a protection, not an automation: pick one file or folder Claude must never delete, and encode exactly that.

▶ Watch this taught: 1:58:51

Check yourself

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

Why can't a well-written skill replace a hook for 'never delete this file'?

A skill is prompt guidance the model interprets and can weigh against other goals; a hook is code that fires on the event regardless — enforcement vs advice.

09

Connectors are MCPs: giving Claude hands in your other apps

2:00:52

Claude already runs your machine — connectors extend that reach into Gmail, Slack, and every app that offers one.

The plus-icon's connectors button IS MCP: each connector grants Claude direct access to another app — read your Gmail, draft and send replies, work Slack — 'you don't have to copy paste your email or anything like that.' His connected set (Slack, Glean, Atlassian) shows the professional shape. Anything without a listed connector can still join by prompt: 'add Zapier as an MCP server' and Claude guides the setup. Scope applies here too — MCPs default global but can be project-scoped.

The session leaves depth to later (session 12 wires Gmail live); here the job is the concept: machine access plus app access equals an agent that acts across your whole stack.

Worked example · from the session

The Gmail scenario, narrated end-to-end: fetch emails, summarize, draft the follow-up, send — versus the copy-paste shuffle the chat app forces.

Why it matters

Connectors complete the acting-agent picture this session opened with — and set up both the power demos and the token-tax warnings of the following two sessions.

People get this wrong

If an app isn't in the connectors list, Claude can't touch it.

Any app with an MCP server can join by prompt — the browse list is a storefront, not a boundary.

For your projects

["The Cowork settings advice you asked about earlier is this concept's operational form."]

This idea elsewherereappears inwired live the next day, failures includedreappears inthe cost side, one week on
Go deeper

In one line: Connectors (the app's term for MCPs) grant Claude direct read/act access to external apps — Gmail, Slack, Atlassian, and by-prompt additions like Zapier. Scoped global or per-project. They extend file-level agency into stack-level agency.

'Connector as well as plugin — these are actually very powerful things' — the two plus-icon buttons decoded (0:41:01)

By-prompt additions: 'ask Claude, add Zapier as an MCP server, and it can guide you through it' (2:04:55)

MCP scope: 'usually global on profile, but you can also define project scope' (2:09:02)

His live set: Slack, Glean, Atlassian — enterprise-shaped (2:00:52)

Plugin vs connector boundary restated: plugins bundle skills; connectors are MCPs to apps (0:41:01)

Try it now

Name the one app you copy-paste into most from Claude — that's your first connector, and 'add [it] as an MCP server' is the whole install attempt.

▶ Watch this taught: 2:00:52

Check yourself

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

What's the difference between what a plugin gives Claude and what a connector gives it?

A plugin adds skills — internal capabilities; a connector adds reach — direct access to an external app's data and actions.

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.

01Claude vs Claude Code: answers vs actionsThe chat app answers;0:28:49›

The chat app answers; Claude Code acts — creating and modifying real files inside a chosen folder on your machine, via plain-language prompts. Requires install (terminal, desktop app, or IDE) and a Pro/Max plan; all sibling products (chat, Code, Cowork) share the same underlying models.

'It is playing around with your files… to be able to do that, we want to install Claude Code' (0:10:36)

'It's not exactly for engineers. It's for you to become an engineer using Claude' (0:10:36)

Without a folder, Claude Code cannot run — every session binds to one (1:21:35)

Cowork placed in the family: 'more of a surface-level bot for your machine… everything is utilizing different models of Claude' (1:17:30)

Codex named the direct competitor (OpenAI's); 'you cannot use one inside the other' — though GPT models can be used within Claude Code (2:09:02, 2:17:04)

02Three ways in: terminal, desktop app, VS Code — same tool, choose your comfortClaude Code installs via a one-line terminal command, the desktop app's Code tab, or inside any IDE's termi…0:12:37›

Claude Code installs via a one-line terminal command, the desktop app's Code tab, or inside any IDE's terminal (VS Code shown); all are the same tool. Sessions bind to a folder (workspace-trust approval required); one empty folder per project is the taught practice.

Install instructions found by searching 'claude code install' — one command per OS (0:14:38)

VS Code's value is visibility: files appear in the tree as Claude writes them (0:18:42)

'Whatever UI makes you comfortable, that's good for you' — repeated verbatim twice under questioning (0:26:49, 0:45:14)

Folder binding: 'without a folder, Claude Code cannot run' (1:21:35)

Workspace-trust error decoded in Q&A: approve it or Claude can't act there (2:13:03)

03Five modes on one trust spectrum — plus the effort slider beside the modelFive modes ordered by trust: ask-permissions, accept-edits, plan (interview + plan, no execution), auto (fr…0:32:51›

Five modes ordered by trust: ask-permissions, accept-edits, plan (interview + plan, no execution), auto (free execution, his default), bypass (full machine control, riskiest). Cycled via Shift+Tab or the app's mode menu. Effort is a separate dial — thinking depth per response — distinct from model choice.

Trust spectrum named explicitly: 'least trust to full trust… people will have their own give and take' (0:34:55)

Plan mode's employee analogy: interview first, build after — the generic-website failure is the cautionary tale (0:36:55)

Bypass 'can delete softwares from your system as well' — power and risk stated together (0:41:01)

Effort ≠ model: 'how much that model spends on thinking… smarter but slower and costlier'; his setting extra/max (0:43:02)

Shift+Tab cycle includes an agents mode in the current build — surface churn visible on stage (0:24:44)

04CLAUDE.md, memory.md, .claude/ — and the self-updating memory hackThe folder context architecture: CLAUDE.md (objective;0:47:14›

The folder context architecture: CLAUDE.md (objective; auto-attached to every prompt; updatable by request or by a self-update instruction written into it), memory.md (long-term action memory), and .claude/ (skills, hooks, settings, logs) — each existing at project or user scope.

CLAUDE.md 'gets passed in every single chat' — that's both its power and the mechanism of the self-update hack (1:01:20, 1:09:24)

memory.md: 'a long-term memory for Claude Code to know what all it has done inside the folder' (0:53:20)

.claude/ contents shown: hooks, skills, settings.json, activity.log (0:51:18)

Scope proof: a demo website auto-picked his real company name from user-scope context (1:21:35)

Casual chat use needs none of this — 'but if you want the true power, you want these 3 files' (0:51:18)

05/init, /plan, /model, /clear, /compact, /code-review — the working command setWorking command set: /init (create CLAUDE.md), /plan (plan mode), /model (switch models;0:53:20›

Working command set: /init (create CLAUDE.md), /plan (plan mode), /model (switch models; the terminal's only picker), /clear (wipe context), /compact (summarize context to prevent hallucination; costs tokens, nets savings), /code-review (self-review generated code for breaking changes). Discoverable via slash — no memorization.

Hallucination framing for compact: token limits exceeded → degraded reasoning; compact restores headroom (1:07:23)

Live numbers: 33% of 1M tokens → ~10% after compact (1:07:23–1:09:24)

/model matters most in the terminal — no button there (1:05:21)

/code-review: self-review for breaking changes, 'can we deploy to prod or not' (1:11:28)

Q&A: compact spends tokens to save tokens — net positive over subsequent turns (2:11:03)

These commands are Claude Code-specific — not available in the chat product (1:11:28)

06Anatomy of a skill: metadata always, prompt only on useA skill = one folder + one SKILL.md (exact name) with two parts: metadata (name + description;1:36:25›

A skill = one folder + one SKILL.md (exact name) with two parts: metadata (name + description; sent with every chat; the selection signal) and prompt body (full context-engineered instruction; loaded only on invocation). Skills nest via reference folders; each defines one specialized 'employee.'

Naming is strict: 'it has to be named exactly SKILL.md, no other nomenclature'; one skill folder each, under .claude/skills (2:15:04)

The hello test: greeting Claude surfaces all skills by name — metadata in action (1:48:44)

Lazy loading spelled out end-to-end: metadata known, prompt unknown, full copy on invocation (1:52:45–1:54:46)

His skills folder is a business org chart: presentations, offers, sales agent, sales funnel, LinkedIn, GTM engineering (1:40:29)

Skill trees: reference folders (learnings, transcripts, playbooks) invoked from within a skill (1:58:51)

Prompt engineering redeemed: 'this is prompt engineering… we are creating a skill with all these detailed prompts' (1:44:32)

07Downloading skills: the marketplace, portability, and the trust warningsSkills are downloadable from marketplace directories (2M+ listings cited) and portable across folder-readin…1:54:46›

Skills are downloadable from marketplace directories (2M+ listings cited) and portable across folder-reading agents since SKILL.md is plain text. Risks priced honestly: audit third-party prompts before install, cap installed count (metadata tax), and keep secrets/IP out of skill files.

'I can copy that skill very easily and start using it in my own business' — the acquisition framing (1:56:47)

Cross-platform: 'inside the folder, if there is SKILL.md, any of the tools will utilize it' (2:15:04)

Trust rule: 'you're trusting someone else's prompt — do your own research' (2:13:03)

Efficiency ceiling: hundreds of skills = metadata × hundreds in every chat (2:06:58)

IP warning as stated: skill prompts 'sent to Anthropic's team for their training' — recorded as his claim, verification flagged (2:11:03)

08Hooks: if X happens, Y must happen — guardrails, not suggestionsHooks are deterministic event-action rules (X→Y) enforced in code, not interpreted from prompts: notificati…1:58:51›

Hooks are deterministic event-action rules (X→Y) enforced in code, not interpreted from prompts: notifications on completion, blocks on deletions, auto-format on edit, logging on change, time cutoffs. Mostly project-scoped, with universal protections at user scope; they chain with skills to complete automations.

'These are some guardrails, some fixed instructions… if X happens, it should do Y' (1:58:51)

Example inventory: notify on done, block delete, auto-format, log changes, time cutoff (2:00:52)

Skill vs hook boundary: prompt-interpreted vs code-enforced (1:58:51)

Skill+hook chaining: create the post AND post it (2:13:03)

Scope advice: project scope default; universal never-delete rules at user scope (2:15:04)

Not a webhook: 'webhook is an endpoint for an API — hook is used in these agentic tools; quite different' (session 12 recap, taught here first)

09Connectors are MCPs: giving Claude hands in your other appsConnectors (the app's term for MCPs) grant Claude direct read/act access to external apps — Gmail, Slack, A…2:00:52›

Connectors (the app's term for MCPs) grant Claude direct read/act access to external apps — Gmail, Slack, Atlassian, and by-prompt additions like Zapier. Scoped global or per-project. They extend file-level agency into stack-level agency.

'Connector as well as plugin — these are actually very powerful things' — the two plus-icon buttons decoded (0:41:01)

By-prompt additions: 'ask Claude, add Zapier as an MCP server, and it can guide you through it' (2:04:55)

MCP scope: 'usually global on profile, but you can also define project scope' (2:09:02)

His live set: Slack, Glean, Atlassian — enterprise-shaped (2:00:52)

Plugin vs connector boundary restated: plugins bundle skills; connectors are MCPs to apps (0:41:01)

Tools referenced

ToolCoverageMomentContext
Claude Codedemonstrated0:12:37All three installs, modes, effort slider, commands, context files, skills folder, connectors — the full orientation
VS Codedemonstrated0:18:42Installed and toured as the visual home; integrated terminal runs the same CLI
Slidodemonstrated2:02:53Closing Q&A board
Gmail MCPexplained2:02:53The narrated connector scenario; wired live in session 12
Coworkexplained1:17:30'If you remove the technicality, that is Claude Cowork for you' — surface-level bot for your machine
Slackmentioned2:00:52On his connected list
Gleanmentioned2:00:52On his connected list
Atlassianmentioned2:00:52On his connected list
Zapiermentioned2:04:55The add-by-prompt MCP example
skills.shmentioned1:38:27'Not exactly the same thing' as Claude skills; marketplace trust rule applied in Q&A
Codexmentioned2:09:02Named competitor (OpenAI); can't nest inside Claude Code, though GPT models can be used within it
Gemini CLImentioned2:13:03Cost alternative — 'even on free tier'
Cursormentioned0:26:49Asked about early; comparison deferred
Antigravitymentioned0:04:35Listed among the tools of the 'top 10% of AI users'
n8nmentioned0:08:36His YouTube content subject; his agency builds these automations

Session materials

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

vtt
GMT20260704-140035_Recording.transcript.vtt
152 KB

Action items

Resources mentioned

Resources
  • docFirst-contact prompt (verbatim) 0:16:39
  • docChat-vs-code demo prompt (verbatim) 0:28:49
  • docCLAUDE.md goal prompt (verbatim) 0:59:20
  • docThe self-updating memory line (verbatim; written INSIDE CLAUDE.md) 1:09:24
  • docPresentation skill prompt opening (verbatim from his SKILL.md on screen) 1:44:32
  • docMeeting-notes skill metadata description (verbatim) 1:48:44
  • docMCP-by-prompt pattern (verbatim) 2:04:55
  • docClaude Code install documentation 0:14:38
  • docTerminal statusline add-on (model + token display) 2:06:58
  • docBest-practices summary PDF (promised) 1:15:30
  • docClaude skills marketplace directory (2M+ skills cited) 1:54:46
  • docTrainer's LinkedIn / YouTube / 1:1 call link (QR on screen) 0:08:36

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
chart / charts (throughout)chat / chats — same collapse as session 12
cloud / clod / plot code / CloudCore / CloudApp / CloudScaleClaude / Claude Code / Claude app / Claude skills
forward slash inert / mortal / code driven/init, /model, /code-review
Versus codeVS Code
JARGPT / Charge GPT / Charge GPDChatGPT
HaikyuHaiku
codecsCodex
EntropicAnthropic
anti gravityAntigravity
MCB / MCG (occasionally)MCP
Narika / NehaNiharika
small group (the auto-picked company name)his real company name, as heard — garbled; verify from his LinkedIn when harvested
LLL modelsLLM models
skill dot m tSKILL.md
co workCowork

True on recording day — verify before relying