Your First Claude Code Session

The first Claude Code session follows a pattern you will repeat dozens of times: orient, request, review, iterate. Getting comfortable with that loop early makes everything that follows faster. This lesson walks through a complete first session step by step — the prompts, what to expect from Claude Code's responses, and the approval flow that keeps you in control.

Starting a session

Open a terminal inside your test project:

cd my-cypress-tests
claude

You land at Claude Code's interactive prompt. It looks minimal, but it now has access to every file in that directory.

Orient before you request

Before asking for anything, give Claude Code a chance to understand your project:

> What test framework does this project use? Describe the folder structure 
  and any patterns I follow for test organisation.

Claude Code reads your package.json, your test files, your config files, and gives back a description of what it found. This is exactly what you would do when onboarding a new engineer — have them read the codebase before touching it.

This step matters. Without it, Claude Code generates code that is technically correct but does not match your conventions. With it, generated tests look like they belong in your project.

Your first real task

Once Claude Code understands the project, request something concrete:

> Generate a Cypress test for the contact form at /contact. 
  The form has name, email, message, and a submit button.
  Cover: valid submission, invalid email format, missing required fields.
  Save it to cypress/e2e/contact.cy.ts.

Watch what happens. Claude Code reads your existing test files for style context — it shows each file read as a tool call. Then it generates the test and writes it to the path you specified. Then it asks whether to run the test or stop there.

You see each step Claude Code takes displayed inline. That visibility is deliberate — you are never guessing what it changed.

Approval prompts

By default, Claude Code asks before running commands or making git commits. You will see prompts like:

Claude would like to run: npx cypress run --spec cypress/e2e/contact.cy.ts
Allow? [y/n]

Type y to allow, n to skip. This is your circuit breaker for anything Claude Code proposes that you are not sure about. Lesson 4 covers how to configure which commands run automatically — for now, approve the test run to see the full loop.

Iterating on output

Generated tests are first drafts. After reading what was written, refine it:

> The generated test uses cy.get('[type="submit"]'). 
  Our convention is data-testid attributes. 
  Update it to use cy.get('[data-testid="contact-submit"]').

Claude Code edits the file in place. You see the specific line changed. Continue iterating the same way:

> Add a test case that verifies the error message text when submitting 
  with an empty name field.

This loop — generate, review, refine — is the core of the workflow. Resist the urge to accept the first output wholesale. A five-minute review now prevents debugging a subtle assertion bug three weeks from now.

Useful session commands

• ? — list available slash commands
• /clear — reset conversation context (keeps your files, resets the chat history)
• /cost — see how many tokens this session has used
• /model — switch to a different Claude model for this session
• exit or Ctrl+C — end the session

What Claude Code shows you

Every tool call is visible. When Claude Code reads a file, you see Reading: tests/auth/login.cy.ts. When it writes, you see Writing: cypress/e2e/contact.cy.ts. When it runs a command, you see the command before it asks for approval.

This transparency is not just cosmetic. It is how you stay oriented about what is happening to your project, and it is your debugging surface when something goes wrong.

⚠️ Common Mistakes

• Jumping straight to generation without orienting. The quality difference between "write a Playwright test for login" and "read how I structure tests in tests/auth/, then write a test for login" is significant. The orient step takes 20 seconds.
• Approving test runs without reading the generated file. A test can pass while asserting nothing useful — for example, checking that the URL changed without checking what it changed to. Always read the file before running it.
• Treating session memory as persistent. /clear resets context. Starting a new claude process also resets it. Useful context lives in CLAUDE.md and your files — not in Claude Code's conversation state between sessions.

🎯 Practice Task

Run a complete first session on a real project. 20 minutes.

1. Navigate to a project that has at least a few existing tests.
2. Start claude and ask it to describe the project's test structure.
3. Ask it to generate one new test for a flow that isn't covered yet. Be specific about the file path and the scenarios.
4. Read the generated file before running it. Note anything that looks off.
5. Make at least one follow-up request to refine the output.

The next lesson covers project configuration — permissions, model selection, and CLAUDE.md — so every future session starts with the right defaults already in place.