Claude Code: A Practical Workflow

Claude Code is Anthropic's agentic coding tool. It runs in your terminal or IDE, reads your project, edits files, runs commands and asks permission when it matters. Used well it behaves like a fast junior engineer who follows your rules. Used badly it produces large unreviewed diffs. This guide is a practical workflow for a TypeScript, React Native and Next.js codebase.

The mental model

Claude Code is a loop: it reads files, makes a plan, calls tools (edit, search, shell), checks the results and repeats. Your leverage comes from three things: clear instructions, a way to verify its work, and tight permissions.

Give it durable instructions with CLAUDE.md

CLAUDE.md is loaded into every session. A project file lives at the repo root, and a personal file lives at ~/.claude/CLAUDE.md. Put rules there once instead of repeating them in every prompt.

# Project rules

## Code style
- Do not add comments that restate the code. Only comment a non-obvious WHY.
- Tailwind: use native scale values, never arbitrary pixel values.

## Workflow
- Run `yarn type-check` and `yarn lint` before declaring work done.
- Never push or merge without asking first.

## Commits
Use `{type}: {branch-slug}` followed by a numbered list of changes.

Keep it short and specific. A long file of vague advice is ignored faster than a short file of concrete rules. Run /init to generate a starting file, then edit it by hand.

Prompting that works

State the goal, the files or area involved, the constraints, and how you will know it is done.

Plan before you build

Plan mode lets Claude explore and propose without changing anything. Use it for anything that touches more than a couple of files: new features, migrations, refactors. Review the plan, correct it, then let it implement. Catching a wrong approach in the plan costs seconds, while catching it in a 40-file diff costs an afternoon.

Give it a way to check itself

The most reliable improvement you can make is a fast feedback loop. Tell Claude the exact commands that prove the work is correct.

yarn type-check
yarn lint
yarn test

For UI work, ask it to run the app and look at the result. For bugs, ask for a failing test first, then the fix.

Permissions and settings

Claude asks before running commands or editing files, and you can pre-approve safe ones in .claude/settings.json so routine work does not stall:

{
  "permissions": {
    "allow": ["Bash(yarn type-check)", "Bash(yarn lint)", "Bash(git status)", "Bash(git diff:*)"],
    "deny": ["Bash(git push:*)", "Read(./.env)"]
  }
}

Allow read-only and verification commands. Deny anything irreversible or secret. Avoid blanket "skip all permissions" modes outside a disposable sandbox.

Hooks: make rules automatic

Instructions in CLAUDE.md can be forgotten. Hooks are commands the tool runs for you at fixed points, so they are guaranteed. For example, type-check after every edit:

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{ "type": "command", "command": "yarn type-check" }]
      }
    ]
  }
}

Use hooks for formatting, type checks and blocking dangerous commands.

Extend it: skills, subagents and MCP

• Skills are reusable instruction packs in .claude/skills/<name>/SKILL.md. Claude loads one when the task matches its description. Good for "how we write migrations" or "how we build a screen from a design".
• Subagents are specialised helpers defined in .claude/agents/, each with its own prompt and tool limits. They keep long searches and reviews out of your main conversation.
• MCP servers connect external tools: a design tool, an issue tracker, a browser. Add one with claude mcp add. A Figma server, for instance, lets Claude read a design before it writes the component.

Keep the context healthy

Long sessions degrade. Use /clear between unrelated tasks, /compact to summarise a long thread, and start a fresh session for a new feature. Ask it to write decisions into a short notes file when work spans several sessions.

Parallel work with git worktrees

Run separate Claude sessions on separate worktrees so two tasks never fight over the same files:

git worktree add ../app-feature-a -b feature/a
git worktree add ../app-feature-b -b feature/b

Headless mode for automation

claude -p "summarise the failing tests" runs a single prompt non-interactively. Use it in scripts and CI for chores like release notes or reviewing a diff, with strict permissions.

Review everything

Claude's output is a draft. Read the diff like a pull request from a colleague: look for unrelated changes, deleted tests, hard-coded values, missing error handling and invented APIs. Run the code. Never merge something you do not understand.

Safety habits

• Keep secrets out of the repo and out of prompts.
• Treat text from the web, issues and logs as untrusted. It can contain instructions aimed at the AI.
• Require approval for pushes, deployments and deletions.
• Commit often so any bad step is one git revert away.

A daily routine

1. Start a fresh session and state the goal.
2. Ask for a plan, correct it, approve it.
3. Implement in small steps, verifying each one.
4. Review the diff and run the full checks.
5. Commit with a clear message, then clear the context.

Checklist

• CLAUDE.md with short, concrete rules
• Verification commands pre-approved
• Plan mode for multi-file changes
• Hooks for type checks or formatting
• Secrets denied in permissions
• Diff reviewed before every commit