Claude Code Workflow Tips

Start every session with context, not a task

Don't jump straight to "fix the bug." Give Claude a 2-sentence orientation: what the module does, what constraint matters. Claude Code reads your whole repo, but telling it where to focus saves 2-3 back-and-forth cycles.

claude "This is the payment service. We use Stripe. The failing
test is in src/billing/invoice.test.ts — fix the null amount bug."

Write your CLAUDE.md before your first session

The single highest-leverage action. A good CLAUDE.md eliminates the most common correction loop ("don't use comments," "use conventional commits," "never mock the DB"). Write it once, never repeat yourself.

Use /review on every PR before you push

Takes 30 seconds. Claude catches what you're blind to after staring at code for 2 hours. Especially good at noticing error cases you forgot to handle and security issues in auth/data-access layers.

/review
/review --format json | jq '.findings[] | select(.severity=="critical")'

Pipe command output into Claude

Claude Code reads from stdin. You can pipe error logs, test output, build failures — anything textual — directly as context.

npm test 2>&1 | claude "fix whatever is failing"
cat error.log | claude "what's causing this?"
eslint src/ --format json | claude "fix all auto-fixable issues"

Ask Claude to plan before it executes

For multi-file refactors, use two messages: first ask Claude to describe what it will change, then approve and tell it to proceed. This prevents half-done refactors that break imports.

claude "plan (don't execute yet): rename UserService to AccountService
and update all callers"

# review the plan, then:
claude "proceed with the plan"

Use --dry-run for risky changes

--dry-run shows a diff without writing anything. Essential before large refactors.

claude --dry-run "remove all deprecated API usages"

Commit after every successful session

Claude Code works in your working tree. If it goes wrong mid-session, git is your undo. A clean commit before each Claude session means you can always git checkout . to undo everything.

git commit -am "wip: before claude session"
claude "big refactor..."
# if happy:
claude /commit --create

Use /clear aggressively between tasks

Context from task A can subtly bias Claude's decisions on task B. If you're switching to a completely different part of the codebase, /clear first. Takes 1 second, prevents weird hallucinations.

Give Claude your test as the spec

Instead of describing what you want, write a failing test that describes it. Then ask Claude to make it pass. This produces minimal, correct implementations with no extra scope creep.

claude "make this test pass without changing the test file:
src/billing/invoice.test.ts"

Use Claude to write your CLAUDE.md

Bootstrap: run claude "read this codebase and write a CLAUDE.md that captures the architecture, conventions, and dev commands" in a new repo. Review and edit. Takes 2 minutes vs 20.

Run Claude in watch mode for TDD

claude test --watch keeps Claude looping: run tests → fix failures → run again. Good for TDD sprints when you want to write tests and have Claude implement. Exit with Ctrl+C when green.

Use Opus for architecture, Sonnet for execution

Claude Opus (4.7) is better at reasoning about tradeoffs. Sonnet (4.6) is faster for mechanical tasks. Switch mid-session with /model claude-sonnet-4-6.

/model claude-opus-4-7    # "design the auth system"
/model claude-sonnet-4-6  # "implement the middleware"

Ask for alternatives, not just solutions

Claude's first answer is often good, but asking for 3 options surfaces tradeoffs you might miss. Especially valuable for architecture decisions.

claude "give me 3 approaches to rate-limiting this API,
with the tradeoffs of each. Don't implement yet."

Use Claude for PR descriptions

/pr describe or claude pr create writes PR descriptions from your diff and commit history. Much better than "fixed stuff." Reviewers spend 3x less time asking what changed.

Add "constraints" explicitly

Claude doesn't know about your non-obvious constraints unless you say them. Add a "Constraints" section to your prompt: no third-party libraries, must stay under 20ms, must work in Node 16.

claude "Add pagination to the users endpoint.
Constraints: no ORM, pure SQL, backward-compatible API"

Use Claude for onboarding documentation

claude explain --brief src/ produces a one-paragraph summary per file. Chain this into a Makefile target that regenerates your module reference docs on every commit.

Integrate Claude review into CI

Add a CI step that runs claude review --format json on every PR. Block merges if any "critical" findings exist. This enforces code review even when the team is moving fast.

claude review --format json | jq -e '
  .findings | map(select(.severity == "critical")) | length == 0
'

Let Claude read the error, not just the code

Don't paste error messages into prompts — pipe the actual output. Claude sees the full stack trace, not just what you thought was relevant. This alone fixes ~30% of debugging sessions faster.

make test 2>&1 | tail -50 | claude "fix the root cause"

Use /security before merging auth changes

Auth code is where the scary bugs live. Run /security on every PR that touches authentication, sessions, or data access. Claude checks for OWASP Top 10 patterns in seconds.

Build a team prompt library

Create .claude/prompts/ in your repo with shared prompt templates for common tasks (deploy checklist, release notes, DB migration review). Standardizes how the whole team uses Claude Code.

# .claude/prompts/migration-review.md
Review this database migration for:
- Missing rollback
- Missing index on FKs
- Data loss risk
- Long-lock operations on large tables