My Claude Code workflow: context, planning, skills and review

Claude Code is my main coding environment and part of my full development setup. This article describes the workflow I use: give the tool project context, plan changes that span several files, reuse stable procedures, then review the diff. It is a personal workflow, not a controlled speed benchmark.

This is what changed.

The shift: from editor to conversation

The useful part is being able to point to an existing pattern: "implement the blog post page following the same pattern as the freebie page". Claude can inspect the project and propose a change that follows its types, error handling and imports. I still check whether it actually did.

That only works if Claude knows your codebase conventions. Which brings me to point one.

1. CLAUDE.md is non-negotiable

Every project gets a CLAUDE.md at the root. It's a plain markdown file Claude reads at the start of every session. Mine includes:

• Stack: framework, language, key libraries
• Conventions: import order, error handling pattern, logging style
• Rules: what we never do (e.g., no try/catch in actions, no console.log)
• Architecture: folder structure and which layer owns what

Without this, Claude has to infer more from the files it sees. A CLAUDE.md reduces that guesswork; it does not replace reviewing the proposed diff.

2. Plan Mode before every non-trivial task

For a change that crosses several files or boundaries, I ask Claude to inspect the relevant code and outline an approach first. I correct the plan before implementation when it misses a constraint. For a typo or a local edit, that process would add overhead, so I keep it simple.

3. Skills for repeated workflows

Repeated tasks become skills. I have skills for: committing with a clean message, running a pre-ship review, scanning security, and doing my morning briefing.

Each skill is a markdown file describing exactly what to do. You invoke it and it runs. No copy-pasting prompts, no context re-setup. The Claude Code Skills Starter Kit has the ones I use daily, ready to drop into your ~/.claude/ folder.

4. Hooks for the boring stuff

Claude Code hooks are shell commands that fire on events (file saved, session started, Claude stopped). I use them to:

• Auto-inject today's date into every session
• Send a push notification when a long task finishes
• Run the linter after any file write

That last hook catches some formatting issues earlier. I have not measured a weekly time saving, so I do not attach a number to it.

5. I let it explore, I review

The workflow that surprised me most: I describe a feature, Claude explores the codebase, proposes an approach in the chat, and I say yes or no. Then it implements. I review the diff.

I stopped trying to micromanage the implementation. The code quality went up when I started trusting the plan + review loop instead.

What didn't work

• Delegating without context: Claude writes generic code without your conventions. CLAUDE.md fixes this.
• Accepting first output blindly: It's fast, not perfect. Read the diff.
• Using it for everything: Tiny edits are faster by hand. Save Claude for the things that require thinking.

What this workflow does not prove

I previously compared an estimated 2.5 hours for a feature with an estimated 40 minutes using this workflow. I did not keep a dated task log or control for task difficulty, familiarity or rework, so that comparison does not establish a speed multiplier. The useful claim I can support is narrower: project instructions, planning for cross-file changes and a final diff review are part of my current workflow. Your result depends on the task and on how much verification it needs.

If you want to measure your own result, pick a few comparable tasks and record the same stages each time: understanding the change, planning, implementation, review and rework. Keep the task type and definition of “done” consistent; report the sample and dates if you share a number.

---

Want the Skills and hooks behind this workflow? The Claude Code Skills Starter Kit is a starting point; check each file against your project before enabling it.