Building a Real Workflow: From Install to Production

The Goal: A Workflow You Dont Have to Think About

The developers who get the most out of Claude Code are not the ones who use the most features — they are the ones who have built a consistent, repeatable workflow. The decisions are made once: which permission mode to use, when to commit, how to structure CLAUDE.md, what goes in the deny list. After that, those decisions happen automatically. They focus on the work.

This lesson puts together everything from the previous nine into one coherent system. By the end, you will have a complete workflow you can apply to any project, starting today.

Setting Up a New Project: The Complete Checklist

Every new project gets this treatment before the first real task:

Step 1: Orient Claude

cd my-project
claude

> What does this project do?
[Claude reads all key files and gives you a summary — correct it if anything is wrong]

> What is the folder structure and what does each directory do?
[Claude walks through the layout]

Step 2: Generate your CLAUDE.md

> /init

Claude generates a first draft. Review it immediately. Add anything obvious that is missing: critical patterns, things Claude tends to get wrong in this stack, exact test commands. Remove anything irrelevant. Commit it.

Step 3: Configure your settings

Create .claude/settings.json:

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run test)",
      "Bash(npm run lint)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git add *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)",
      "Bash(curl *)",
      "Bash(npm install *)",
      "Read(.env*)",
      "Read(secrets/**)"
    ]
  }
}

Adjust the allow list to match your project's actual command set. Commit this file.

Step 4: First real task

> Run the tests and tell me if any are failing. If they are, explain why.
[Claude runs tests, reads failures, gives you the picture]

This baseline check tells you what state the codebase is in before you start, and gives Claude context about your testing setup that it will use for the rest of the session.

The Daily Development Loop

This is the workflow for every feature, bug fix, and refactor:

1. Start on a branch

git checkout -b feature/user-profile-editing

Never work on main. This is the containment rule from Lesson 8. If the whole thing goes sideways, you delete the branch and start over.

2. Launch Claude in the right mode

claude --permission-mode acceptEdits

For most feature work, acceptEdits is the right mode. For anything risky — a database migration, a large refactor — use plan mode first to review the approach before Claude writes anything.

3. Give a specific, complete prompt

> Add an "Edit Profile" page to the user dashboard.
The form should let users update: display name (required, 3–100 chars), bio (optional, max 500 chars), and website URL (optional, must be a valid URL or empty).
On submit: validate all fields server-side, update the users table, return the updated user object.
On validation error: return HTTP 422 with specific field errors.
After writing the code, run npm test and confirm no existing tests are broken.

This prompt includes: what to build, field-level requirements, the validation spec, the error format, and a verification step. Claude has everything it needs without guessing.

4. Review everything before committing

git status                    # Which files did Claude touch?
git diff                      # What exactly changed?
git diff --stat               # Summary view for large changesets

Read every line of the diff. Look for unexpected changes, hardcoded values, missing edge cases, and anything that does not match your project's conventions.

5. Stage only what you approve

git add src/components/UserProfile.tsx
git add src/api/users.ts
git add tests/api/users.test.ts
# Review each file before adding it

Do not use git add . or git add -A — stage files explicitly. This forces you to touch every changed file and prevents accidentally committing a file Claude modified that you did not notice.

6. Commit with a meaningful message

git commit -m "feat: add edit profile form with server-side validation"

The commit message describes what and why — not what files changed. "Add edit profile" is the what. Future-you will thank present-you for a clean git log.

7. Continue, or /clear for a new task

If the next task is related, continue the session. If it is a completely different concern, run /clear to give Claude a fresh slate (CLAUDE.md is still loaded). For a very long session, use /compact first to free up context.

The Git Worktree Pattern for Risky Changes

For migrations, major refactors, or anything where a mistake would be expensive to undo, use git worktrees to fully isolate Claude's work:

# Create a separate working copy of the repo in a new directory
git worktree add ../myproject-auth-refactor main

# Do all the risky work there
cd ../myproject-auth-refactor
claude --permission-mode acceptEdits

> Refactor the entire authentication system from sessions to JWTs.
  Read the current implementation first, propose an approach, then implement it.
  Run all tests after each file change to catch regressions immediately.

# Review all changes at once from the original repo
cd ../myproject
git diff main ../myproject-auth-refactor

# Only merge when you are satisfied with everything
git merge --no-ff feature-branch-name

# Clean up the worktree
git worktree remove ../myproject-auth-refactor

The worktree is completely isolated. Your main directory is untouched throughout. If the refactor goes badly — if Claude breaks something you cannot fix, or takes an approach you realise is wrong halfway through — you delete the worktree directory and start over with zero impact on your working code.

Team Setup: The Right Project Structure

When multiple developers use Claude Code on the same project, the configuration files become shared infrastructure. Here is the structure to aim for:

project/
├── CLAUDE.md                        # Team conventions — commit this
├── .claude/
│   ├── settings.json                # Team permissions — commit this
│   ├── settings.local.json          # Personal overrides — add to .gitignore
│   ├── commands/
│   │   ├── deploy.md                # /deploy — deploy to staging
│   │   ├── new-component.md         # /new-component [name]
│   │   └── check.md                 # /check — run the full quality gate
│   ├── agents/
│   │   └── security-reviewer/       # Custom security review agent
│   └── rules/
│       ├── api.md                   # API conventions for src/api/**
│       └── security.md              # Security rules for all files
└── .mcp.json                        # MCP servers — commit this

New team members: clone the repo, run claude, everything is pre-configured. CLAUDE.md tells Claude about the project. settings.json enforces the permission rules. The commands directory documents the team's workflow. The MCP config connects to the team's shared services.

Recognising When the Workflow Is Working

After a few weeks with a well-configured Claude Code setup, you will notice these signs:

• Claude rarely makes the same mistake twice — it is in CLAUDE.md
• You spend more time reviewing than explaining
• Your git history is clean and atomic — one feature per branch, one concern per commit
• Tests pass before you look at the diff, because you asked Claude to run them
• You are comfortable giving Claude complex, multi-file tasks without anxiety about what it will do

Recognising When Something Is Wrong

These patterns indicate something needs adjustment:

The One Rule That Changes Everything

If you take one thing from this entire course, make it this:

Never approve what you do not understand.

Not because Claude is untrustworthy. Not because it makes frequent mistakes. But because you are the engineer. The code in your repository is your responsibility. The bugs that reach production are your bugs. The security vulnerabilities are yours to own.

Claude Code is a tool that makes you faster, more thorough, and capable of working at a scale that would be impossible alone. It is an extraordinary tool. But the judgment — which approach is right, which tradeoff is acceptable, which code is safe to ship — that is yours.

When you understand every change you approve, you are working with Claude Code. When you do not, you are being managed by it. The developers who use it most effectively are firmly in the first category.

You now have everything you need to be one of them.