How to Use Claude Code: A Real Developer's Setup Guide (Not the Docs Version)

Most developers read the official Claude Code docs, install it, type a vague prompt, get confused output, and conclude the tool is overhyped.

We've been running Claude Code across a 12-person development team at Innovatrix Infotech — building Shopify stores, Next.js applications, and React Native apps for clients. What we've learned is that the tool isn't the variable. The setup is.

This guide skips everything that's already in the docs and gets straight to what actually matters.

The Installation Decision That Trips Up Most Teams

The official Anthropic documentation shows two installation paths: npm global install (npm install -g @anthropic-ai/claude-code) and the native installer.

Use the native installer. Every time.

# macOS/Linux
curl -fsSL https://claude.ai/install.sh | sh

# Or via Homebrew
brew install claude-code

The npm approach works, but it creates a dependency on your Node.js version and doesn't auto-update. When you're managing a team and you want everyone on the same version without anyone thinking about it, the native installer handles that invisibly. We switched to it across our entire team after too many "it worked for me but not for you" conversations traced back to version mismatches.

On Windows, use the PowerShell equivalent. Claude Code works on Windows 11 — avoid WSL if you can, the file system overhead is real on large codebases.

CLAUDE.md Is Not Optional — It's the Whole Game

The single highest-leverage thing you can do before writing a single prompt is investing 30–45 minutes in a CLAUDE.md file. This file lives at the root of your repository and tells Claude Code everything it needs to know about how your project works.

Here's a template we use for Next.js projects:

# Project Overview
[Client name] ecommerce platform — Next.js 15 with TypeScript, Tailwind CSS, and a headless Shopify backend via the Storefront API.

# Tech Stack
- Frontend: Next.js 15, TypeScript, Tailwind CSS
- Backend: Next.js API routes, Shopify Storefront API
- Auth: NextAuth.js
- Testing: Vitest, React Testing Library
- Deployment: Vercel

# Key Commands
- `npm run dev` — Start dev server on port 3000
- `npm run test` — Run all tests
- `npm run lint` — ESLint + TypeScript type check
- `npm run build` — Production build

# Code Standards
- Functional components only — no class components
- Named exports preferred over default exports
- Tailwind utility classes only — no custom CSS files
- All API calls must go through `/lib/api/` — never call Shopify directly from components

# Key Architecture
- `/app` — App Router pages and layouts
- `/components` — Shared UI components (atomic, no business logic)
- `/features` — Feature-specific components and hooks
- `/lib` — API clients, utilities, type definitions

# Workflow Rules
- Create feature branches before any changes
- Run tests before committing
- Never modify `/lib/api/shopify.ts` without testing against staging first

What makes a CLAUDE.md file actually useful isn't length — it's precision. The Anthropic best practices docs put it well: for each line, ask whether removing it would cause Claude to make mistakes. If not, cut it. An overly long CLAUDE.md is worse than a concise one because Claude loses track of the important rules buried in the noise.

One pattern we've adopted: run /init on a new repo first to get an auto-generated CLAUDE.md baseline, then heavily edit it down. The auto-generated version catches things you'd forget to document but tends to be verbose.

The Explore-Plan-Code-Commit Workflow

The docs mention this workflow. What the docs don't emphasize enough is that Plan Mode is the difference between Claude Code being useful and Claude Code being dangerous on a shared codebase.

Before Claude touches any code in a session:

Explore: Point Claude at the relevant files and ask it to explain what it sees before doing anything. Critical on projects you inherited.

Plan: Switch to Plan Mode (Shift+Tab twice from Normal Mode — it cycles through Normal → Auto-Accept → Plan Mode). Ask Claude to plan the change, then read the plan. If the plan touches files you didn't expect, ask why.

Code: Let Claude execute. Review the diff before accepting anything that touches shared components.

Commit: Commit after each logical change, not at the end of a long session. If Claude made a mistake, you want a clean revert point.

The most expensive mistake we've made with Claude Code is running it in Auto-Accept mode on a shared component that cascaded changes through 20 files. The fix took longer than the original task. Plan Mode would have caught it in 30 seconds.

MCP Servers: Where Claude Code Becomes a Real Workflow Tool

The native Claude Code installation gives you the ability to connect MCP (Model Context Protocol) servers, which give Claude direct access to your development environment. For a web agency, the practical wins here are significant.

For our Directus CMS work, we connect an MCP server so Claude Code can read the schema, query collections, and understand the full data structure when writing API integration code — without us having to copy-paste schema dumps into every prompt.

To add an MCP server, edit .claude/settings.json:

{
  "mcpServers": {
    "directus": {
      "type": "url",
      "url": "https://your-cms.domain.com/mcp?access_token=YOUR_TOKEN"
    }
  }
}

For Shopify work, MCP servers connect to the Partner API. For Next.js projects with a database, connecting Supabase or Postgres via MCP means Claude Code can generate correct queries against your actual schema instead of hallucinating field names.

Context Management for Long Sessions

Claude Code compresses its context window during long sessions — the equivalent of an intern who loses track of early decisions as the day goes on. Two patterns help:

Session notes: Keep a running .claude/session-notes.md that captures architectural decisions made during the session. Point Claude to this file at the start of any continuation session.

Worktree isolation: For complex features that require parallel work, Claude Code supports git worktrees with the --worktree flag. Each worktree gets an isolated context, which prevents debugging conversations from bleeding into architecture decisions.

# Start Claude in an isolated worktree for a specific feature
claude -w "implement the new product filter component"

What Nobody Tells You About Team Adoption

The hardest part of rolling Claude Code out to a team isn't the technical setup. It's calibrating what level of autonomy to grant in different contexts.

Our current framework for a 12-person team:

• Greenfield features with good test coverage: Auto-Accept mode is fine. Claude has a safety net.
• Shared components or library code: Plan Mode only. Review every diff.
• Legacy code without tests: Explore only — never let Claude auto-edit legacy code without a human reviewing the plan in detail.
• New repository: Always start with /init to generate CLAUDE.md, then edit before running any tasks.

As an Official Shopify Partner and DPIIT-recognised startup, we build under real client SLAs. Claude Code is a productivity multiplier when used with discipline — and a liability when treated as autocomplete on steroids.