Production workflow

You've learned the individual pieces — file editing, shell commands, skills, MCPs, subagents. Now let's put them together into the workflow that experienced Claude Code users actually follow when shipping real features.

The professional workflow

Here's the pattern that works in production:

1. Set up your project with CLAUDE.md

Before your first session, create a CLAUDE.md file in your project root. This is the single most important file for Claude Code — it reads it at the start of every conversation and follows it throughout.

A good CLAUDE.md includes:

• Tech stack: frameworks, libraries, versions
• Code standards: naming conventions, patterns to follow/avoid
• Folder structure: where things live
• What NOT to do: common mistakes, forbidden patterns
• Build commands: how to typecheck, lint, test, build

# My Project

## Stack
Next.js 16, TypeScript strict, Tailwind v4, Drizzle ORM, Postgres

## Code Standards
- Server Components by default. "use client" only when needed.
- All data fetching in RSC or Server Actions.
- Never hardcode colors. Use CSS vars from theme.css.

## Commands
- `npm run typecheck` — must pass before commit
- `npm run lint` — zero warnings
- `npm run build` — must succeed

2. Start with a plan

Don't jump straight into implementation. Start every non-trivial task with planning:

> I need to add a dark mode toggle to the header.
  Let's plan first — explore the codebase and tell me
  your approach before writing any code.

Claude will explore your files, understand the existing patterns, and propose a plan. You review it, adjust if needed, then give the go-ahead. This prevents the most common problem: Claude building something that technically works but doesn't fit your architecture.

3. Implement with guard rails

Once the plan is agreed, let Claude implement. But set boundaries:

• Be specific: "Add the toggle to the header, between the search button and the theme toggle"
• Reference existing patterns: "Follow the same pattern as the locale switcher"
• Set scope: "Only touch the header component. Don't change the theme system itself."

4. Run hard gates before committing

After implementation, always run your project's verification commands:

> Run typecheck, lint, and build. Fix any errors.

This is non-negotiable. Claude Code will run the commands, read the errors, and fix them iteratively. Don't commit until all three pass.

5. Commit with context

Use the built-in commit skill:

> /commit

Claude reads the diff, understands what changed and why, and writes a commit message that explains the "why" — not just the "what." It follows conventional commit format and includes the right scope.

6. Review the result

Before pushing, review what Claude did:

> Show me a summary of all changes in this session.
  Flag anything that looks risky.

Or use the review skill on your own PR:

> /review-pr

Safety habits

These habits prevent the mistakes that cost time:

1. Never let Claude push to main without review. Commits are fine; pushes need your eyes.
2. Don't let Claude delete files it doesn't understand. If it suggests removing something unfamiliar, investigate first.
3. Watch for scope creep. Claude sometimes "improves" nearby code. If you asked for a bug fix, you should get a bug fix — not a bug fix plus a refactor plus new comments.
4. Keep sessions focused. One feature per session. Start fresh for the next task. Context degrades over long conversations.
5. Trust but verify. Claude's implementation may pass all checks and still be wrong in a way tests don't cover. Read the diff.

The real example

Here's what a complete professional session looks like:

$ claude
> I need to add an unsubscribe endpoint. Check how the existing
  webhook routes work, plan the approach, then implement.

[Claude reads src/app/api/webhooks/*, plans the approach]

> Looks good. Go ahead and implement. Run hard gates after.

[Claude implements, runs typecheck, lint, build — all pass]

> /commit

[Claude creates: "feat(newsletter): add /unsubscribe endpoint with
 token validation and undo support"]

> Review the diff for security issues.

[Claude reviews, flags one thing: "The token validation should use
 constant-time comparison to prevent timing attacks."]

> Fix that, re-run gates, then update the commit.

That's the workflow. Plan, implement, verify, commit, review. Every time.

Course complete

You now have everything you need to use Claude Code professionally. The next step is practice — pick a real project and use this workflow to ship something. Start small, build confidence, then tackle bigger tasks.

For advanced patterns — Remote Control, computer use, CI/CD integration, and team-scale workflows — take the Claude Code: Advanced Workflows course.