35 Practical Claude Code Tips with Ready‑to‑Use Commands

1. Project Startup in Four Steps

When starting a new project, follow these actions to halve setup time.

/init /init Scans the whole codebase, automatically creates CLAUDE.md that records project structure, tech stack, coding conventions. Subsequent sessions read it automatically, avoiding repeated background description.

/memory – Write Persistent Rules /memory Opens the memory editor where you can add cross‑session persistent rules, e.g.

Always use TypeScript strict mode.

All public functions must have JSDoc comments.

After modifying any file under /src/core , run tests.

These rules are applied automatically in every session.

Plan Mode (Shift+Tab) – Plan Before Coding

Switch to Plan mode (Shift+Tab); Claude Code only analyses and proposes an architecture. After confirming, switch back to implementation mode. This habit prevents many bugs.

Mode Constraints – Lock Style in CLAUDE.md

Add a section to CLAUDE.md that defines file‑creation patterns, for example:

New file patterns:

- API route: see src/api/example-route.ts

- Database query: follow the repository pattern in src/repositories/example-repo.ts

- React component: see src/components/ExampleComponent.tsx

Claude Code will align new files with these conventions.

2. Session Management – Context Is a Scarce Resource

/compact – Compress Context /compact After a 30–45 minute conversation, run this command to compress the whole dialogue into a concise summary that keeps key decisions and current state. Without this step, output quality degrades.

/clear – Start a Fresh Task /clear Clears the context before a new task. Carrying database‑refactoring context into front‑end work produces tangled code. Principle: one feature per conversation.

/cost – Check Token Usage /cost Shows the token consumption of the current session. Check hourly and set a mental budget.

Model Switching

Use Opus for planning and architecture decisions, Sonnet for concrete implementation. Switch in Claude Code settings or specify at conversation start. Opus is thoughtful but expensive; Sonnet is fast and cheap.

! Prefix – Direct Terminal Output

!git status
!npm test
!ls src/

Prefix a message with ! to run the command inside the chat window, avoiding a separate terminal.

Parallel Sessions

Open two terminal windows: one for back‑end implementation, one for front‑end. Each keeps a clean context, then combine the results. This is more stable than switching back and forth in a single session.

3. Code Quality – Stable and Useful Output

Reference‑File Method

Instead of describing style in words, point to a concrete file:

Look at src/auth/login.ts for the authentication implementation and replicate the same pattern for password‑reset.

This is ten times more precise for maintaining consistent style.

Screenshot Debugging

Paste a screenshot of the UI issue and say:

Button and input are misaligned; card spacing is inconsistent. Fix both.

Faster and clearer than a textual description.

Test‑First Implementation

Write test cases for a discount‑price function covering normal discount, zero discount, 100 % discount, negative price, and string input. Then implement the function so all tests pass.

Defining behavior first ensures correct implementation.

Incremental Build

Break a large feature into steps, testing each:

Step 1: Build only the database schema, nothing else.

Verify OK, then:

Step 2: Build the API endpoints that use the schema.

Five small steps with tests yield higher quality than a single large prompt.

Diff Review

After changes, ask Claude Code to show the diff of all modified files and explain each change in one sentence.

This catches unintended modifications.

4. Exploring Unknown Codebases

Codebase Query

Read the src/services/ directory and explain the full data flow from API route to database, the patterns used, and what I need to know before modifying this code.

Understanding architecture first avoids conflicting changes.

5. Architecture and Refactoring

Architecture Audit

Analyze my project requirements (list them). Propose two different architecture options, each with component diagram, pros, cons, complexity estimate, potential issues, and finally recommend one with justification.

Refactor Planning

Read src/services/user-service.ts . It has grown to 800 lines with too many responsibilities. Propose a split‑refactor plan: new file structure, which code moves where, and ensure external references remain intact. Do not start refactoring yet; only give the plan.

The “do not start refactoring” constraint prevents premature changes.

Database Migration Generation

I need to modify the user table schema: add a role enum field (admin, editor, viewer, default viewer) and rename name to display_name . Generate migration files, update the repository layer, all API routes that reference the old schema, and TypeScript type definitions. Before making changes, list all files that need to be updated.

Multi‑layer coordinated changes showcase Claude Code’s strength.

6. API Design and Security

API Design Review

Review my API design (paste route definitions). Check naming consistency, missing error responses, which endpoints need pagination, which lack authentication, and any REST violations. Provide concrete improvement suggestions.

Security Scan

Scan the codebase for security issues: SQL injection, XSS, exposed secrets, missing input validation, insecure direct object references, lack of rate limiting. For each issue, give severity, exact location, why it’s dangerous, and how to fix it.

Performance Analysis

Analyze performance problems in the codebase: N+1 queries, missing indexes, unnecessary React re‑renders, large bundles that could be lazy‑loaded, APIs that should be cached. Prioritize by impact.

7. Engineering Automation

Git Hook

Create a pre‑commit hook that runs lint, type checking, detects console.log in production code, and blocks the commit if any check fails. Install it at .husky/pre-commit .

CI Pipeline

Create a GitHub Actions workflow that triggers on every PR, installs dependencies, runs the full test suite, runs lint, builds the project, comments the results on the PR, and caches node_modules .

Environment Setup Script

Write a script that a new developer can run once to set up the whole development environment: install dependencies, create .env from .env.example , spin up a local database, run migrations, seed test data, and run the test suite to verify everything works.

Release Notes Generation

Read the git log since the last tag and generate release notes categorized as new features, bug fixes, performance improvements, and breaking changes. Write each entry in user‑friendly language, format as markdown.

8. Documentation and Test Data

Feature Documentation Generation

After completing a feature, read every file created or modified and generate full documentation: purpose of each function, how they connect, expected inputs/outputs, and any non‑obvious design decisions.

Generating documentation immediately yields higher accuracy than doing it days later from memory.

Test Data Construction

Create a comprehensive test data file for the development database: 5 users (1 admin, 2 editors, 2 viewers), 20 realistic example projects, entity relationships, edge cases (archived projects, deleted users, projects without members). Avoid placeholder values like “test123”.

9. Dependency Management

Pre‑Add Dependency Check

I want to add [package] for [specific scenario]. Check whether the package is still maintained, has known security issues, its impact on bundle size, and whether a lighter alternative exists that satisfies the requirement.

Dependency Conflict Resolution

I encountered this dependency conflict: [paste error]. Analyze the cause, identify which packages require conflicting versions, and suggest the minimal‑change solution with trade‑offs explained.

10. Debugging and Issue Investigation

Full Error Paste

I encountered this error: [paste full error message and stack trace]. Before giving a fix, walk through the root cause step by step.

The “step‑by‑step analysis” constraint prevents jumping to a premature conclusion.

Git Checkpoint

git add . && git commit -m "checkpoint: backup before changes"

Allows instant rollback if something goes wrong.

Bug Reproduction Flow

User reported a bug: [paste bug report]. Create minimal reproduction steps (exact actions, expected behavior, actual behavior), write a failing test that captures the bug, then fix the code so the test passes.

From reproduction to fix in a single line.

Blame Investigation

This function started failing yesterday. Read the git log of this file for the past week, identify the commit that likely introduced the issue, explain what changed, and suggest a fix.

11. Recovery Mode

Recovery Mode

Stop. Read the original usable version of the file from git: [paste git show output]. Restate the goal we are trying to achieve: [brief goal]. Switch to a new approach. The previous attempts clearly failed.

Sometimes starting from a clean state is faster than patching many errors; knowing when to stop is a key skill when using AI‑assisted development.

These 35 tips each include a concrete command or copy‑paste‑ready prompt. Key takeaways: /init + CLAUDE.md as a foundation, Plan Mode for design first, /compact to keep context clean, incremental builds with tests for quality, Git Checkpoint as safety net, and Recovery Mode for graceful bail‑out.