Building React Native Apps with Claude Code: The Complete Developer Playbook

Most developers using AI coding assistants hit the same wall: they spend more time re-explaining their conventions than writing code. This guide solves that problem completely — configuring Claude Code so it understands your stack, enforces your standards, and ships quality React Native components from a single slash command.

This is not a beginner tutorial. It is the setup guide you would write after building three production apps with Claude Code and learning what actually matters. By the end, you will have a project where /component UserAvatar produces a fully typed, tested, accessible, and linted component ready for device testing — with no follow-up prompts.

01 What is Claude Code?

Claude Code is an agentic coding tool from Anthropic, available as a CLI (npm install -g @anthropic-ai/claude-code) and as a VS Code extension. Unlike a chat-based assistant, Claude Code operates directly on your file system — it reads, writes, and edits files, runs shell commands, executes tests, and interacts with git. It reasons over your entire codebase, not just a pasted snippet.

The single most expensive mistake when working with Claude Code is letting it start coding before you have agreed on what to build.

— Learned after the third rewrite

02 Scaffolding the Project

The recommended starting point is Expo's managed workflow with TypeScript. It gives you a working app, a test runner, and Expo Go device testing out of the box — without the overhead of a bare React Native project.

npx create-expo-app@latest MyApp --template blank-typescript
cd MyApp
claude   # launch Claude Code from the project root

After scaffolding, you have the default Expo structure. Before writing a single line of application code, add the directory layout Claude will work within:

mkdir -p src/{components/common,components/screens,screens,navigation}
mkdir -p src/{hooks,services,store,utils,constants,types,assets}
touch src/components/common/index.ts
touch src/navigation/AppNavigator.tsx
touch src/constants/routes.ts

03 CLAUDE.md — The Foundation of Everything

CLAUDE.md is the most important file in your project. Claude reads it at the start of every session — it is your project's permanent standing brief. Get this right and you will never repeat the words "use TypeScript strict mode" or "add JSDoc" again.

Here is what the complete CLAUDE.md looks like for a production Expo TypeScript project:

# MyApp — Claude Instructions

## Stack
- Expo SDK (managed workflow), React Native, TypeScript strict
- React Navigation v6 · Zustand · TanStack Query v5
- StyleSheet API only — no Styled Components, no NativeWind
- Jest + React Native Testing Library

## Commands
- Start:      npx expo start
- Tests:      npm test -- --watchAll=false
- TypeCheck:  npx tsc --noEmit
- Lint:       npm run lint

## Code style
- Functional components, arrow syntax: const X = () => {}
- Named exports for components; default export for screens only
- All styles in StyleSheet.create() — zero inline style objects
- Only Colors.*, Spacing.*, Typography.* — no magic numbers

## Before finishing any task
1. npx tsc --noEmit    — fix all errors
2. npm run lint        — fix all errors and warnings
3. npm test -- --watchAll=false — all tests green

04 Skills — One Configurable Skill Per Workflow

The most common mistake developers make with Claude Code skills is creating one skill per component. That produces an unmaintainable pile of nearly-identical files. The correct model is one skill per workflow type, with $ARGUMENTS supplying the name at invocation time.

The four skills a React Native project needs

Every skill except /review has disable-model-invocation: true in its front matter. This critical flag means Claude can only run the skill when you invoke it — it can never trigger itself mid-task. This is especially important for /push, which touches git.

Anatomy of the /component skill

The /component skill is where all the quality enforcement lives. Rather than asking Claude to "write good code", the skill mandates every standard as an explicit numbered step:

05 Hooks — Deterministic Automation

Hooks are shell commands that fire at specific points in Claude's lifecycle. No LLM is involved — they are completely predictable. This makes them perfect for formatting, notifications, and file protection. They live in .claude/settings.json.

Three hooks cover nearly everything a React Native project needs:

1. PostToolUse → Prettier Fires after every file edit and runs prettier --write on the changed file. You never see a formatting diff in a PR again.
2. PostToolUse → TypeScript check Runs npx tsc --noEmit after editing any .ts or .tsx file. Errors surface immediately rather than at commit time.
3. Notification → Desktop alert Fires when Claude is waiting for your input. Uses osascript on macOS or notify-send on Linux. You can step away from long tasks without polling the terminal.

06 GitHub Integration and PR Workflow

Claude Code integrates with GitHub through the gh CLI. Once authenticated, the /push skill handles the entire commit-push-PR cycle. But first, the repository needs the right branch structure and protection rules.

Initial repository setup

# Create repo, set origin, push in one command
gh repo create MyApp --private --source=. --push

# Create and push the develop branch
git checkout -b develop
git push -u origin develop

# Set develop as default on GitHub
# GitHub → Settings → Branches → change default to develop

Branch protection rules to enable

Set these on both main and develop in GitHub → Settings → Branches:

Claude-assisted PR review

The /review skill reviews your current diff or a specific PR number. For PRs you receive, pipe the diff directly:

gh pr diff 42 | claude "Review for: TypeScript issues, missing tests,
accessibility failures, and performance problems"

This produces a structured report with Must Fix, Should Fix, and Suggestions categories. Claude can catch type errors and missing test cases — but it cannot judge business logic or product decisions. Human review remains mandatory before any merge.

07 The Daily Development Loop

In practice, building a complete React Native screen looks like this conversation with Claude Code:

# Create a new component
/component ProductCard

# Pipeline runs automatically: scaffold → test → TS → lint → a11y → perf → security
# Claude prints the ✅ table when all checks pass

# You test on device with Expo Go, then:
/push feature/product-card

# Claude commits, pushes, opens the PR
# Review the PR, approve, merge. Then:

/screen Products
# Repeat

08 Writing Prompts That Actually Work

Skills handle the structured, repeatable work. But you will still write free-form prompts for exploratory tasks, bug fixing, and architectural decisions. The quality of those prompts determines how much rework you do.

The four-phase approach

09 Best Practices at a Glance

1. Start with only CLAUDE.md Add everything else only when you hit a specific pain point. The urge to configure everything upfront produces infrastructure nobody uses.
2. One skill per workflow type, not per component $ARGUMENTS supplies the name. A new component never needs a new skill file.
3. Hooks for deterministic steps, skills for judgment-based steps Prettier formatting is a hook. Accessibility review is a skill. Never reverse this.
4. disable-model-invocation: true on anything that touches git Without this flag, Claude can push code mid-task. You always want to be the one who decides when to push.
5. The final report table only appears when every check passes Build this into every skill. If Claude can show you a table with a ❌, it will — and you will lose the enforcement you designed.
6. Use Plan Mode before touching more than three files A two-minute plan conversation prevents a twenty-minute revert.
7. Human review is not optional Claude reviews diffs for technical correctness. It cannot review product decisions, business logic, or UX suitability. Branch protection rules enforce this.

11 Conclusion

The developers who get the most out of Claude Code are not the ones who write the most impressive prompts. They are the ones who invest thirty minutes in a good CLAUDE.md, four configurable skills, and two hooks — and then get out of the way.

The setup described here means every component and screen your project ever ships goes through the same ten-step quality gate: tests, TypeScript, lint, accessibility, performance, and security — automatically, every time, without a single follow-up prompt.

The goal is not to use AI to write code faster. It is to use AI to enforce standards you would otherwise skip when you are tired or in a hurry.

The files — CLAUDE.md, four skills, settings.json, theme.ts, and testIds.ts — are everything you need. Start with the scaffold, configure Claude Code, build the navigation shell, and let the daily loop do the rest.