Building Your First Feature with Claude Code

You have Claude Code installed, configured, and connected to your tools. Your CLAUDE.md describes your project. Now it is time to actually build something. Not a toy example — a real feature that touches multiple files, needs tests, and has to pass your CI pipeline.

This guide walks through a complete development cycle: understanding the requirement, implementing across files, running tests, debugging failures, and preparing a clean PR. You will see the exact prompts that keep Claude focused and productive.

What You’ll Walk Away With

• A repeatable workflow for feature development with Claude Code
• Prompts that produce production-quality code, not prototypes
• Strategies for keeping Claude on track during multi-file changes
• Patterns for incremental implementation with verification at each step

The Development Loop

Every feature follows the same basic loop:

1. Understand — Have Claude analyze the requirement and affected code
2. Plan — Get a structured implementation plan before any edits
3. Implement — Build incrementally, one component at a time
4. Verify — Run tests, type-check, and lint after each change
5. Review — Have Claude review its own work for issues
6. Commit — Create clean, descriptive commits

Let’s walk through each step with a real example: adding a search endpoint to a REST API.

Step 1: Understand the Codebase and Requirement

Start every feature by giving Claude the full context:

Tip

Copy-paste prompt to start a feature:

I need to add a full-text search endpoint to our API. Before writing
any code, I need you to:

1. Read the existing API routes and understand the current patterns
2. Check how the database is set up (schema, ORM, migrations)
3. Look at how existing endpoints handle validation and error responses
4. Identify the files I will need to create or modify

Do not make any changes yet.

Claude reads your codebase, identifies the relevant patterns, and gives you a summary. This step prevents the most common mistake: Claude generating code that does not match your existing patterns.

Step 2: Plan Before Coding

Once Claude understands the codebase, ask for a plan:

Based on your analysis, create an implementation plan for the search
endpoint. I want:

1. The route path and HTTP method
2. Input validation schema
3. Database query approach
4. Response format matching existing endpoints
5. Error handling following current patterns
6. Test cases we need

Number each step. Do not write code until I approve.

Review the plan. Push back where needed:

Change the database query to use a GIN index instead of LIKE.
Also, add pagination to the response -- our other list endpoints
use cursor-based pagination, not offset.

Step 3: Implement Incrementally

Do not ask Claude to implement everything at once. Build one piece at a time:

Implement step 1 from the plan: create the Zod validation schema
for the search endpoint in the existing validators file.

After Claude makes the change, verify:

Run the type checker to make sure the new schema is valid.

Then move to the next step:

Now implement step 2: the database query function. Use the existing
query patterns from the users module as a reference.

Tip

Copy-paste prompt for incremental implementation:

Implement the next step from our plan. After making the changes:
1. Show me exactly what files you modified
2. Run the type checker
3. Run the relevant tests
4. Tell me if anything failed

Do not move to the next step until this one passes all checks.

This incremental approach catches problems early. If Claude’s database query has a type error, you catch it before building the route handler on top of it.

Step 4: Verify at Every Step

Make verification a habit, not an afterthought:

# After each change, ask Claude to run checks
Run npm run type-check and npm run lint. Fix any errors before continuing.

# After implementing logic, run tests
Run the tests for the search module. If any fail, analyze the failure
and fix it before moving on.

# After all implementation is done, run the full suite
Run the complete test suite and the linter. Show me a summary of
any failures.

Note

If you have allowed Bash(npm run test *) in your settings, Claude can run tests without prompting you. This makes the verify step nearly instant. See the Configuration guide for permission setup.

Step 5: Self-Review

Before you commit, have Claude review its own changes:

Tip

Copy-paste prompt for self-review:

Review all the changes you have made in this session. Check for:

1. Missing error handling or edge cases
2. Security issues (SQL injection, unvalidated input, data leaks)
3. Performance concerns (N+1 queries, missing indexes, large payloads)
4. Inconsistencies with existing code patterns
5. Missing or inadequate tests

Be critical. What would a senior engineer flag in code review?

Claude will often catch issues it introduced — missing null checks, inconsistent error formats, or tests that do not cover edge cases. Fix these before the PR.

Step 6: Commit and Clean Up

When you are satisfied with the implementation:

Commit these changes with a descriptive message that explains what
was added and why. Use conventional commit format.

Or use the dedicated commit command:

claude commit

Claude generates a commit message based on the actual diff, not a generic description.

Practical Tips for Staying Productive

Keep Claude Focused

Long sessions lead to drift. If Claude starts losing context about your patterns:

Re-read our CLAUDE.md and the existing search module at
@src/modules/search/. Then continue implementing the response
formatter using the same patterns.

Break Large Features into Sessions

For features that take more than 30-40 minutes, break them into multiple sessions:

• Session 1: Schema and database changes
• Session 2: API route and business logic
• Session 3: Tests and integration
• Session 4: Review, polish, and PR

Use claude -c to continue the most recent conversation, or start fresh with claude if you want a clean context.

Use /compact When Context Gets Heavy

If Claude’s responses start to degrade or it seems to forget earlier decisions:

/compact

This summarizes the conversation and frees up context space. Follow it with a brief reminder of what you are working on.

Reference Specific Files

Instead of vague requests, point Claude at exact files:

# Instead of this:
Update the search module to add filtering

# Do this:
Add a category filter parameter to @src/api/routes/search.ts
following the pattern used in @src/api/routes/products.ts

Let Claude Run Your Dev Server

For web applications, Claude can start your dev server and check results:

Start the dev server, then make a curl request to the new search
endpoint with the query "typescript". Show me the response.

Tip

Copy-paste prompt for end-to-end verification:

Start the dev server if it is not already running. Then test the
new feature by:

1. Making a request with valid input and showing the response
2. Making a request with invalid input and showing the error response
3. Making a request that should return empty results
4. Checking that pagination works correctly

Report any issues you find.

The Anti-Patterns

Asking for everything at once — “Build a complete search feature with tests, pagination, caching, and monitoring” will produce mediocre code. Break it down.

Not verifying between steps — If you let Claude implement five files before running the type checker, you will spend more time fixing cascading errors than you saved.

Accepting code without understanding it — Claude will explain its changes if you ask. If you do not understand why something was done a certain way, ask: “Why did you use a cursor instead of an offset for pagination?”

Ignoring the CLAUDE.md — If Claude keeps generating code that does not match your patterns, your CLAUDE.md is missing critical information. Update it and tell Claude to re-read it.

When This Breaks

Claude modifies the wrong files — Be explicit about file paths. Use @-mentions to reference exact files rather than describing them by name.

Generated code does not compile — Run the type checker after every change. If Claude generates TypeScript errors, tell it: “The type checker found errors. Fix them before continuing.”

Tests pass but the feature does not work — The tests may not cover the actual behavior. Ask Claude to test the feature end-to-end with a real request, not just unit tests.

Claude gets stuck in a loop — If Claude keeps trying the same approach and failing, interrupt with a new direction: “Stop. That approach is not working. Instead, try [alternative approach].” Sometimes a /clear and fresh start is faster than fixing a confused session.

What’s Next

With your feature implemented, learn how to manage branches, create clean commits, and open PRs with Claude Code’s git integration.

Version Control Git integration, commits, and PRs

Error Recovery Handling failures and recovering from mistakes