Example: Build a Feature End-to-End

Concepts are easier to remember when you see them working together. This lesson walks through a single realistic scenario — adding a search feature to a small web app — from the first prompt to a merged pull request. Each step maps to a real command or pattern.

Start: frame the task

Before writing any code, tell Claude enough context to make good decisions. You do not need to manually point Claude at files — it will read what it needs. Start by orienting it to the project.

text

what does this project do, and what's the main data model?

text

I want to add a search endpoint that lets users filter products by name.
Explain how the existing API routes are structured before we start.

Plan before touching files

Once Claude understands the codebase, switch to plan mode so it proposes a detailed approach without making any edits yet. Press Shift+Tab to enter plan mode, then describe the feature.

text

# Press Shift+Tab to enable plan mode, then:
Add a GET /api/products/search endpoint that accepts a ?query= param
and returns matching products from the database. Show me the plan first.

Tip

Read the plan carefully. If Claude plans to put the route in the wrong file, or misses an auth middleware, correct it with a follow-up message before you approve. Fixing a plan costs nothing; fixing bad code does.

Implement with Claude

Once the plan looks right, approve it. Claude will create or edit files, showing you each change for confirmation. If a single step looks wrong, reject it and explain what you expected — Claude will try again.

text

looks good, go ahead and implement the search endpoint

Note

Claude asks for permission before each file write. You can approve edits one at a time, or enable 'Accept all' for the session if you trust the plan. You can switch back at any time by pressing Shift+Tab.

Verify with tests

After implementation, ask Claude to write tests for the new endpoint. Claude reads your existing test files to match your testing framework and assertion style automatically.

text

write tests for the new search endpoint covering:
- a query that returns results
- a query with no matches (expect empty array)
- a missing ?query= param (expect 400 error)

then run the tests and fix any failures

Review the diff and commit

Before committing, ask Claude to summarize what changed across all the files it touched. This is your final sanity check — a quick way to catch anything unexpected before it goes into version control.

text

summarize all the changes you made and flag anything I should double-check

text

commit my changes with a descriptive message

Open a pull request

Claude can create the pull request directly. It writes a title and description based on the changes in the session. You can refine the description before submitting.

text

create a pr

# or for more control:
create a pr with a description that explains the search algorithm
and notes that it uses a case-insensitive LIKE query for now

Tip

Review Claude's generated PR description before submitting. You can ask Claude to add context, mention caveats, or flag follow-up work in the description.

Picking up later

If review feedback comes in the next day, you do not start from scratch. Resume the session and pick up with full context intact.

bash

# Resume the most recent session in this directory
claude --continue

# Or choose from the session picker
claude --resume

Key takeaways

The full loop in six steps: (1) orient Claude to your codebase, (2) plan in plan mode before any edits, (3) approve and implement, (4) write and run tests, (5) review the diff then commit, (6) create a PR. Each step uses natural language — you are describing intent, not writing scripts. Full reference: code.claude.com/docs/en/quickstart.