Getting Set Up Without Terminal Fear

The promise in the module title is real and worth stating plainly: the Desktop app requires zero terminal knowledge, and the VS Code extension requires almost none. What is not optional are the concepts — permission modes, the project folder as the workspace, the instruction file, and the difference between exploring and editing. Designers who skip the concepts and rely on defaults end up either over-trusting the agent or too scared to use it.

Acknowledge the audience split. Some participants have already installed Claude Code and want to get to mockup conversion; others have actively avoided anything that looks like a command line for their entire career. The module is paced for the second group, and the first group still needs the permission-mode and CLAUDE.md material, because that is where most setup mistakes hide regardless of comfort level.

The end state to hold up: a working installation, pointed at a project the participant actually cares about, in the most conservative permission mode that still lets work happen. Module 1 made the case for why; this module is purely how, and it deliberately ends before any file is changed. The first edits happen in Module 3.

Walk the diagram left to right. The Desktop app is a standalone application: you pick a project folder visually, every proposed change appears as a side-by-side diff with accept and reject buttons, there is an embedded preview pane so Claude can see your running prototype, and connectors for tools like Figma or Slack are added through a settings screen rather than config files. It is the recommended start for this audience, with two honest caveats: it is not available on Linux, and heavy automation is easier from the CLI later.

The VS Code extension suits designers who already spend time in an editor — design engineers, prototypers, anyone who has touched front-end code. The agent panel sits next to the files it is editing, you can @-mention a file to pull it into context, and checkpoints let you rewind if a change goes wrong. The CLI is the full-featured surface and the one most documentation assumes, but it is also the one with terminal fear attached; position it as something to grow into when you want scripted, repeatable runs, not a prerequisite.

The shared band at the bottom is the strategic point. Because all three surfaces run the same engine and read the same project files, the instruction file you write this week and the permission habits you build are portable. Choosing the easy door now does not paint you into a corner. Facts about surface availability are accurate as of June 2026; check the current docs before standardising a team.

Keep this slide moving; the point is that installation is genuinely small, not to read out URLs. Three gotchas are worth naming because they account for most first-day failures. First, the free claude.ai plan does not include Claude Code on any surface — Pro, Max, Team, or Enterprise is required, and the Code tab in the Desktop app will prompt an upgrade rather than explain why. Second, on Windows the Desktop app needs Git for Windows installed before local sessions work; most Macs ship with Git already. Third, the Desktop app has three tabs — Chat, Cowork, and Code — and only the Code tab gives the agent access to your local files. Early users regularly sat in the Chat tab wondering why nothing could see their project.

For the CLI, resist the urge to walk every platform's install command on the slide. The official quickstart has one command per platform, and the two diagnostic commands worth remembering are claude --version to confirm the install and claude doctor when something is off. The most common CLI failure is the command not being found after install, which is a PATH issue with a documented one-line fix.

Date-stamp the requirements when presenting: paid-plan requirement, the VS Code 1.98 minimum, and the Windows Git dependency are all accurate as of June 2026 from Anthropic's documentation, and these details change. The durable advice is the shape of the path — download, sign in, point at a folder — not the specific version numbers.

This is the most important slide in the module, because permission modes are where terminal fear either gets resolved or gets confirmed. The fear underneath is reasonable: a system that can edit files and run commands could do damage. The answer is not reassurance, it is the permission system. In the default Ask mode, Claude Code cannot modify a single file without showing you a diff and waiting for you to accept it. In Plan mode it cannot modify files at all. The designer is not trusting the agent's good intentions; they are relying on a mechanism.

Walk the table top to bottom as an escalation ladder. Plan mode is read-only and is where this course asks you to live for the first week. Ask permissions is the long-term default for real work: every edit is a reviewable diff. Auto-accept is a speed mode for scratch work where the cost of a wrong edit is zero — it auto-applies file edits but still asks before other commands. Bypass exists for sandboxed and automated environments and should simply not be used on a designer's laptop. The Desktop app also lists an Auto mode with background safety checks on higher-tier plans; treat it as something to evaluate after the habits exist, not before.

Two practical notes. The mode is visible and switchable in the prompt area on every surface — a click in Desktop and VS Code, Shift+Tab in the CLI — so this is not a configuration ceremony, it is a per-session choice. And mode names and exact behaviours are as documented in June 2026; the principle of starting in the most conservative mode that still lets the work happen is the part that will not date.

Frame plan mode as a deliberate strategy rather than training wheels. The first week with an agent is when your mental model of it forms — what it reads well, where it guesses, how it describes your project back to you. Forming that model while the agent is read-only means every miscalibration is free. Forming it while the agent is editing files means miscalibrations cost cleanup and, worse, confidence.

Connect it back to the loop from Module 1 of Agentic Design Fundamentals if participants have seen it, or simply to the idea of reviewing a plan before work happens: the plan is the cheapest correction point because nothing has been built. For designers, the plan also doubles as a comprehension tool. Asking the agent to plan a change to a project you did not build — describe what would need to change to restyle this header — produces a readable map of the codebase in design-relevant terms, even if you never execute the plan.

Be honest about the limits. Plan mode does not make the output of later editing modes correct, and it is not a substitute for reviewing diffs. It also feels slow to people who have seen demo videos of agents flying through edits. The course's position is that the week of slowness is the price of knowing, rather than hoping, that you can supervise this thing on real work.

This trace is a composite of the first-session walkthroughs in the official quickstarts and the book's own setup chapter, run against a small real project — say so, and keep the claims modest. The pattern matters more than the specific answers: open a real project you care about but did not build, stay in plan mode, and ask questions in your own vocabulary rather than engineering vocabulary.

Call out the texture of steps 3 and 4. The agent answered with file paths, which means every claim is checkable — the designer can click the path, see the tokens file, and confirm the answer rather than take it on faith. The unprompted warning about a hard-coded colour in step 4 is typical and worth flagging: agents surface this kind of incidental finding often, and learning to note them without chasing every one is part of working calmly.

Step 5 is the bridge to the rest of the course. The plan it produced is exactly the artifact that Module 3 will teach you to review properly and then execute. Also worth naming: the questions the agent asked back — about whether the restyle should touch the shared header — are a quality signal. An agent that asks before assuming is doing what a good collaborator does, and a plan with no questions on a vague request deserves more suspicion, not less.

This slide exists because the first hour with an agent interface produces a specific kind of disorientation: things scroll past, panes appear, and the designer is unsure what they are supposed to be watching. The answer is that only a few elements carry the supervisory weight. The conversation shows what the agent is doing and reading — in the Desktop app you can switch view modes between a summary and a verbose trace of every file it opened. The diff is the heart of review: side-by-side, old and new, accept or reject. The permission mode indicator near the prompt box tells you what the agent could do right now without asking. And the session boundary matters because context accumulates within a session; starting a new session for a new task keeps the agent's attention on the current job.

Surface-specific niceties can be mentioned without dwelling: the Desktop app adds a preview pane for running apps, a usage ring showing how full the context window is, and a sessions sidebar where parallel sessions each get an isolated copy of the project; VS Code adds @-mentions and checkpoints you can rewind to; the CLI shows tool calls inline and uses Shift+Tab to switch modes. These are conveniences layered over the same four elements.

The practical instruction for the week: whenever the agent proposes a change, your eyes go to the diff, and before you type anything ambitious, your eyes go to the mode indicator. Those two habits are the supervision skill in miniature, and they transfer across every surface and every platform.

Demystify the file first: CLAUDE.md is not configuration syntax, it is a markdown document written in ordinary language, sitting in the project root, read automatically at the start of every session. Designers already write this kind of document — it is the same genre as design principles, contribution guidelines, and redline annotations — except this version is actually enforced in the sense that the agent reads it every time, whereas the PDF of brand guidelines is read once and forgotten.

Walk the example briefly. The 'what this is' section saves the agent from guessing the project's purpose. The rules section carries the standing constraints a designer cares about: tokens over hard-coded values, reuse over invention, semantic HTML, and a do-not-touch zone. The review line sets a behavioural expectation — plan before multi-file changes — that backs up the permission-mode habit with a written instruction. Keep the file short; a bloated CLAUDE.md gets skimmed by humans and dilutes the signal for the agent.

The maintenance habit matters more than the starter content: when you find yourself correcting the same thing twice in conversation — stop using that gradient, those are not our spacing values — that correction graduates into CLAUDE.md. This is the seed of the harness idea that the design-system and automation modules build on later. Also note that you can simply ask the agent to draft the file: 'create a CLAUDE.md with instructions for this project' is a legitimate first editing task once you leave plan mode.

The principle to land: the project folder is the agent's entire world. It reads inside it, edits inside it, and runs commands relative to it. That makes folder choice the most underrated safety control available — more consequential day to day than any single permission setting, because pointing the agent at the wrong folder gives every later decision the wrong scope.

The practical layout for a designer starting out: a playground folder for experiments where nothing matters and auto-accept is fine; real projects each in their own folder, under version control so changes are recorded and reversible — the Desktop app sets up much of this for you, and parallel sessions there each get an isolated copy of the project precisely so they cannot trample each other; and a convention for generated outputs, because an agent asked to produce screenshots, exports, or audit reports will otherwise scatter them wherever seems locally sensible. Naming an outputs folder in CLAUDE.md closes that loop.

The separation point deserves a sober sentence: do not point a session at a folder that mixes a client's confidential files with the project you want help on. The agent reads broadly to build context, and the simplest way to keep something out of context is to keep it out of the folder. This is also the habit that scales to team settings later, where access boundaries stop being personal preference and become policy.

Keep this slide factual and dated. Figures are as of June 2026 and drawn from the published pricing the school's plan-selection article tracks: Pro at roughly US$17–20 a month depending on billing term, Max at US$100 or US$200 for the 5x and 20x tiers, Team seats spanning roughly US$20–125 depending on seat type and term, and Enterprise or API billing for organisations. The free claude.ai plan does not include Claude Code at all. These numbers move; the decision logic is the durable part.

The decision logic for an individual designer: Pro is enough to learn the tool and run occasional sessions, and its usage allowance is shared with the Claude apps. The signal to upgrade is hitting usage limits during real work more than once or twice a week — that is evidence, and Max exists for exactly that pattern. Buying Max on day one because a demo was exciting is the common over-purchase.

For teams, the relevant questions are central billing, admin controls, and the ability to mix seat levels so the one designer doing daily agent work gets a premium seat while occasional users sit on standard ones. Cost governance for teams gets proper treatment in the MCP and team workflows module; here the only message is that plan choice is a reversible decision made on usage data, not a commitment to a level of seriousness.

The purpose of this slide is morale as much as troubleshooting. Designers who hit a setup wall on day one tend to attribute it to themselves — I am not technical enough for this — when the actual causes are mundane and shared with every other new user, including engineers. Naming the usual suspects in advance changes the experience of hitting one from evidence of unsuitability to a known speed bump.

The list maps to the official troubleshooting documentation as of June 2026: the paid-plan requirement behind the upgrade prompt, the Git for Windows dependency for Desktop local sessions, the Chat-versus-Code tab confusion, the PATH issue behind command not found, the VS Code minimum version and the reload-window fix, and authentication errors that resolve by completing the browser sign-in and restarting. Each has a short documented fix; do not walk through the fixes line by line in a live session, just establish that they exist and where the troubleshooting page is.

If participants are setting up during the module, this is the natural point to pause and let people get unstuck. The instruction for anyone still blocked after a few minutes: note the exact error message, move on with the module using a colleague's screen or the recorded walkthrough, and resolve it afterwards — the rest of the material does not depend on a working install today.

This exercise is the module's whole point made personal, and the constraint to enforce is the read-only one. Participants who skip ahead to editing on day one are not cheating themselves out of safety so much as out of calibration — the value of the week in plan mode is learning where this agent guesses, and that learning only happens if you check its answers rather than act on them.

The project choice matters. A sandbox or tutorial repo produces a pleasant but useless session, because the participant has no way to judge whether the answers are right and no stake in them. A real project — the product they design for, the design system repo, even a copy of the marketing site obtained from an engineer — produces answers they can verify against their own knowledge and their own frustrations. If access to a real codebase is genuinely impossible this week, the fallback is any open-source front-end project in a domain they understand, with the explicit note that the exercise should be re-run on real work as soon as access exists.

The verification step and the wrong-answer note are the two deliverables. Opening the files the agent points at builds the habit of checking claims against the artifact, which is the same habit later modules apply to diffs. The thing it got wrong becomes the first entry in CLAUDE.md, which means participants begin Module 3 with the instruction file already started — and started from evidence, not from a template.

Recap by walking the bullets, but emphasise the through-line: every item on this slide is a control the designer holds. The choice of surface, the permission mode, the folder the agent is pointed at, the rules in CLAUDE.md, and the plan being paid for are all decisions made deliberately rather than defaults accepted — which is the difference between a setup that earns trust and one that just happened.

Name the state participants should be in before starting Module 3: a working installation on one surface, a real project opened at least once in plan mode, five questions asked and at least two answers verified, and a CLAUDE.md that exists even if it only contains three lines. Anyone missing one of those should close the gap before continuing, because Module 3 assumes all of them.

Preview Module 3 concretely. The next module is the core skill of the course: giving the agent a mockup or screenshot, briefing the conversion with constraints rather than adjectives, and reviewing the generated code as a designer — structure, tokens, spacing, states — including a parity check between the mockup and what got built. The first accepted diff of the course happens there, which is exactly why this module insisted the habits exist first.