Your first prompt

You are in your project directory. Claude Code is installed. You hit claude and the prompt blinks at you. You could just type — but a few decisions made before you hit Enter will determine whether the next five minutes feel magical or frustrating. This lesson is about those decisions.

Pick your permission mode first

You already know the three modes from the previous lesson. In practice, most first prompts use one of two: Approval or Plan mode. Shift+Tab cycles between them.

Approval mode (default). Claude asks permission each time it wants to edit a file or run a command. Slower, but nothing happens without you. Use this whenever you are not sure what Claude will do.

Auto-accept mode. File edits apply automatically. Commands still ask for approval. Use this when you trust the plan and want to stop clicking "yes" for every tiny edit.

There is no right answer — pick the one that matches how nervous you are about this particular change.

Use Plan mode for anything non-trivial

Plan Mode sits inside the Shift+Tab cycle and it is the single most underused feature in Claude Code. Here is what it does:

1. Takes your prompt.
2. Uses only read-only tools to analyse your codebase — no writes, no commands executed.
3. Asks clarifying questions when your request is ambiguous.
4. Returns a detailed plan it can execute later.

Plan Mode is the best place to course-correct. Reviewing a plan is cheap. Reviewing a half-finished refactor after Claude went down the wrong path is expensive. Use it for complex changes, multi-step feature work, and safe code review where you want insight without edits.

Walkthrough: add a dark mode toggle

Let's run through a realistic first prompt end-to-end. Assume you have an app with a light theme and you want a dark mode toggle in the header.

Step 1 — Enter Plan mode

From the root of your project, launch Claude Code:

claude

Hit Shift+Tab twice to switch into Plan Mode. The indicator at the bottom of the session will change to show you are planning, not executing.

Step 2 — Write a descriptive prompt

Vague prompts waste context. Descriptive prompts produce plans you actually want to execute. Here is the prompt to try:

My app needs dark mode implemented across the entire app. Can you create a toggle switch on the header that lets a user switch between light mode and dark mode? Find a good contrast color that works with my existing light theme.

Notice what this does:

• States what you want ("dark mode across the entire app").
• Says where it should live ("a toggle switch on the header").
• Defines correct ("contrast color that works with my existing light theme").

The instructor's guidance is explicit: be as descriptive as possible. A three-sentence prompt like this gives the model enough signal to make smart tool calls. A one-line "add dark mode" forces Claude to guess — and guesses cost context.

Step 3 — Review the plan

Claude will read some files, maybe ask a clarifying question, and come back with a step-by-step plan. Read it. If something is off — wrong component, wrong approach, wrong file — say so. Revising a plan takes one message. Revising a finished implementation takes far more.

Step 4 — Execute

When the plan looks right, drop out of Plan Mode and let Claude execute. In Approval mode you will confirm each step; in Auto-accept mode edits flow through but commands still pause for you.

At the end, Claude summarises what it did and why. You can trace each decision back to a specific line in the plan you approved.

The prompt principle

One sentence to carry out of this lesson: be as descriptive as possible. Specificity is not about writing long prompts — it is about giving the model the minimum context it needs to make good choices without exploring blindly.

Plan Mode is the gateway into the full structured workflow you will learn next — Explore, Plan, Code, Commit. Once you see how much cheaper it is to fix a plan than to fix a diff, you will never go back to typing prompts straight into execution.