Claude Code usage tips

The most reliable Claude Code sessions are specific, scoped, and verifiable. Treat it like a coding agent with tools, not a generic text assistant.

Last verified
Applies to
Claude Code 2.1.x. CLI spellings were checked on local version 2.1.198; official docs may describe newer 2.1.x behavior.
Verification method
Best-practices and common-workflow guidance were reviewed together with current CLI help. The workflow below uses repository evidence; no model response is presented as a measured result.
Official sources
Best practicesCommon workflowsChangelog

Reproducible practice

Build an evidence packet for one small coding task

Replace 'done' claims with a baseline, bounded request, targeted proof, broad gate, and reviewed diff.

Prerequisites

  • A trusted repository and a small task with one observable outcome.
  • Known test, build, lint, or manual QA commands.
  • A clean baseline or an explicit list of pre-existing changes.

Steps

  1. Capture the baseline

    Record current changes and the failing or missing behavior before implementation.

    Step 1
    git status --short
    git diff --check
  2. State one acceptance check

    Give Claude the exact file scope, prohibited areas, and command or browser path that proves success.

  3. Verify in layers

    Run the smallest relevant check first, then the repository gate; retain command output rather than a prose assertion.

  4. Review the final evidence

    Compare status, diff, and tests, then ask an independent reviewer to challenge the result.

    Step 4
    git status --short
    git diff --check
    git diff --stat

Expected result

A reviewer can trace the requested outcome to a bounded diff and concrete verification output without trusting the implementer's summary.

Validation

  • The acceptance check fails or is absent at baseline and passes after the change.
  • No unrelated file appears in the final diff.
  • A second method checks high-risk behavior or attempts to refute the conclusion.

Failure handling

Tests pass but behavior fails

Add the missing browser, integration, or manual check instead of repeating the same unit test.

Diff expands unexpectedly

Stop, classify unrelated changes, and split the task before continuing.

Cleanup or rollback

  • Revert only the bounded task changes after reviewing the patch.
  • Keep failure evidence long enough to reproduce the original issue, then follow project retention rules.

Boundaries and when not to use it

  • More context is not always better; give the smallest relevant files, constraints, and evidence.
  • Independent review reduces correlated mistakes but does not replace domain-specific security, legal, or production approval.

Write prompts with acceptance checks

A strong request says what should change, what should stay stable, and how to verify it. This gives Claude Code an engineering target instead of a broad writing task.

Use repository memory

Put durable instructions in project memory: architecture notes, package manager rules, test commands, generated file warnings, and review expectations. Use CLAUDE.md for team facts and auto memory for learned preferences.

Prefer small verifiable changes

Break large work into steps that can be checked independently. Smaller changes produce clearer diffs and make recovery easier when the first approach is wrong.

Keep source claims fresh

Claude Code changes quickly. When publishing product guidance, check official documentation and changelog pages before treating a feature detail as stable.

Prompt patterns that work

Strong prompts combine goal, constraints, evidence, and verification. Weak prompts only describe intent.

Strong task prompt
Fix the login redirect bug in src/auth/. Keep existing session cookie behavior. Run pnpm test auth and pnpm lint before summarizing the diff and any skipped coverage.

Residual risk

Ask what was not tested, what assumptions were made, and which files were intentionally untouched.

Read guide

Daily use checklist

Related topics