Claude Skills Guide

Claude Code Consultant Codebase Context Switching Workflow

As a freelance consultant or agency developer, you’ll often juggle multiple client projects, each with distinct tech stacks, coding conventions, and architectural patterns. Claude Code excels at helping you switch contexts efficiently, but without a structured workflow, you risk contamination between projects or wasted time re-establishing context. This guide walks you through a battle-tested codebase context switching workflow that maximizes productivity across client engagements.

Understanding the Context Switching Challenge

Every project carries implicit context: folder structure conventions, testing frameworks, deployment pipelines, and team-specific preferences. When switching between projects, Claude Code needs explicit guidance to avoid applying patterns from one project to another. The key is establishing clear boundaries and transition protocols.

The challenge becomes apparent when you realize Claude Code operates within a single working directory at a time. While it can reference multiple files, it doesn’t automatically understand that “the React project” differs from “the Python API” unless you tell it explicitly.

Establishing Project-Specific Claude.md Files

The foundation of clean context switching lies in creating project-specific CLAUDE.md files at each project’s root. This file serves as the anchor that defines project identity, technical constraints, and operational boundaries.

# Project Context: Acme E-commerce API

## Tech Stack
- Python FastAPI backend
- PostgreSQL database with asyncpg
- Redis for caching and session management
- Docker containers orchestrated with docker-compose

## Code Conventions
- Use async/await for all database operations
- Pydantic v2 for schema validation
-pytest for testing with pytest-asyncio
- Type hints required on all function signatures

## Project Structure

src/ ├── api/ # Route handlers ├── models/ # Database models ├── schemas/ # Pydantic schemas ├── services/ # Business logic └── core/ # Configuration and shared utilities


## Testing Requirements
- Minimum 80% code coverage
- Integration tests in tests/integration/
- Mock external APIs with respx

## Deployment
- CI/CD via GitHub Actions
- Deploys to AWS ECS on merge to main

When you enter this project directory, Claude Code reads this file automatically, establishing the correct mental model before you issue any commands.

The Handoff Protocol for Client Transitions

Before leaving a project, establish a clear handoff protocol. This ensures you can resume work later without relearning the project’s state.

Exit Checklist

  1. Commit or stash all changes — Never leave uncommitted work that might confuse future Claude Code sessions
  2. Update the project status — Note incomplete tasks in CLAUDE.md or a dedicated TODO file
  3. Document current blockers — If you’re stuck on something, leave a clear note for your future self
  4. Close resource connections — Ensure any database connections or API sessions are properly terminated

Entry Protocol

When starting work on a project you haven’t touched recently:

# Navigate to project directory
cd /path/to/project

# Read the CLAUDE.md first
cat CLAUDE.md

# Check for recent changes since your last session
git log --oneline -10
git status

# Review any TODO or NOTES files
ls -la *.md

This entry ritual takes under a minute but prevents hours of confusion from working on stale context.

Using Skills for Context Preservation

Claude Code skills provide powerful mechanisms for encapsulating project-specific workflows. Create skills for each major technology stack you work with, then customize them per project.

Example: FastAPI Project Skill

Create a skill file skills/fastapi-project.md:

# FastAPI Project Skill

This skill provides commands and conventions for FastAPI projects.

## Available Commands

### `test` 
Run the test suite with coverage report:
```bash
pytest --cov=src --cov-report=term-missing -v

migrate

Create a new database migration:

alembic revision --autogenerate -m "$1"
alembic upgrade head

run

Start the development server with hot reload:

uvicorn src.main:app --reload --host 0.0.0.0 --port 8000

Code Generation Patterns

When generating new endpoints:

  1. Define the Pydantic schema first in src/schemas/
  2. Create the route handler in src/api/
  3. Add business logic to src/services/
  4. Write tests in tests/api/

Common Pitfalls

Load this skill when working on any FastAPI project, then augment it with project-specific details from CLAUDE.md.

Context Switching with Git Worktree

For consultants maintaining multiple branches or client variants simultaneously, git worktree provides filesystem-level isolation that pairs perfectly with Claude Code’s directory-based context:

# Create a separate working tree for feature development
git worktree add ../client-project-feature feature-payment-integration

# Switch to the feature branch
cd ../client-project-feature

# Claude Code now operates in the feature branch context
# The main project remains untouched

This approach allows you to keep multiple projects or branches “open” and switch between them by changing directories, with each worktree maintaining its own CLAUDE.md and skill configuration.

Leveraging Environment-Specific Contexts

Many consultants work across development, staging, and production environments. Create environment-specific notes that Claude Code can reference:

# Environment: Staging

## API Endpoint
https://staging-api.acme.com

## Database
- Host: staging-db.acme.com
- Credentials: See 1Password vault "Acme Staging"

## Debugging Tips
- Enable verbose logging with LOG_LEVEL=DEBUG
- Check CloudWatch logs for API errors
- Use ngrok for local testing against staging webhooks

Store these as CLAUDE.md, CLAUDE.staging.md, and CLAUDE.production.md to maintain clean separation.

The Resume Flag for Long-Running Tasks

When context switching mid-task, Claude Code’s --resume flag becomes invaluable:

# Start a long migration task
claude --resume /tmp/task-state.json

# Claude Code loads previous context and continues

This works alongside proper task documentation to ensure nothing falls through the cracks during client transitions.

Practical Example: Full Day Across Three Clients

Imagine you’re a consultant with three client projects: a React dashboard, a Python ML service, and a Ruby on Rails legacy app. Here’s how your day might flow:

Morning — React Dashboard (Client A)

cd ~/clients/acme-dashboard
# CLAUDE.md establishes React 18, TypeScript, Tailwind context
# Build components, run tests
# Exit: git commit, update TODO.md with "Need API spec from client"

Midday — Python ML Service (Client B)

cd ~/clients/neuralnet-api
# Different CLAUDE.md: FastAPI, PyTorch, Kubernetes deployment
# Debug model inference issue
# Exit: Note blocker about GPU availability in CLAUDE.md

Afternoon — Rails App (Client C)

cd ~/clients/legacy-rails
# Separate context: Rails 6.1, PostgreSQL, Sidekiq
# Implement new feature
# Exit: Complete git workflow, PR ready for review

Each transition takes seconds because the context is explicitly defined in each project’s CLAUDE.md, and skills provide the appropriate commands for each tech stack.

Key Takeaways

Effective codebase context switching as a Claude Code consultant relies on three pillars:

  1. Explicit project identity through CLAUDE.md files that define tech stack, conventions, and structure
  2. Skill encapsulation that provides stack-specific commands without cross-contamination
  3. Ritualized transitions with entry and exit protocols that preserve context between sessions

Implement this workflow, and you’ll find client transitions become seamless—letting you maintain multiple engagements without the mental overhead of constantly recalibrating your approach. Claude Code becomes not just a coding assistant but a context-aware partner that understands exactly which project you’re working on and how that project expects to be handled.

Built by theluckystrike — More at zovo.one