My Claude Code Workflow

Why Workflow Matters

Those who know me would know I swear by Claude Max 20x. But there are caveats, owning it is one thing but using it effectively is another. After months of daily usage across multiple projects, I've developed a workflow that is considered the most suitable for me what I believe is the best.

Project Structure: The Foundation

The first thing I do with any project is set up a proper directory and workflow structure for Claude Code. This isn't just showing a pretty directory but how Claude will navigate around it when developing, which makes every iteration more impactful.

The Directory Structure

my-project/
├── CLAUDE.md              # Project instructions and context
├── claude/
│   ├── agents/            # Specialized agent definitions
│   ├── docs/              # Project documentation
│   ├── skills/            # Claude Skills, these are technically in .claude global settings, but I have them
│   └── tickets/           # Task tickets and tracking
└── [your actual code]

CLAUDE.md: Your Project's Brain

This file is the entrypoint. It's the first thing Claude reads when starting a session. A good CLAUDE.md includes:

Project overview: What the project does in 2-3 sentences
Tech stack: Languages, frameworks, key dependencies
Project structure: Where things live
Common commands: How to build, test, run, basically what you write in your README.md
SDLC: What is the software development lifecycle that you iterate by
Important context: Anything Claude needs to know

The more specific your CLAUDE.md, the less time you spend repeating yourself every session. I'd like to keep it less verbose but also include as many important summary regarding the project as possible.

Agents: Specialized Modes

Agents are predefined prompts that put Claude into specific modes. I typically have:

coder: For implementation work
planner: For breaking down complex tasks
checker: For code review and testing
researcher: For exploring codebases and documentation

Each agent has its own markdown file with specific instructions. When Claude needs to do a particular type of task, it can invoke these agents which will reference their specifications for context. Think of it as a dependency graph that triggers on specific conditions, except they are not 100% deterministic because LLM.

Tickets: Structured Task Management

Instead of vague requests, I create tickets. A ticket includes:

Clear description of what needs to be done
Acceptance criteria (how do we know it's done?)
Relevant files and context
Priority level

This forces me to think through what I actually want before prompting Claude, because if you don't even know what you want specifically, then how is Claude going to do it for you?

Also, this is some product manager stuff iykyk

Daily Workflow: Plan Mode by Default

One thing that I always do is to always start in plan mode.

The Plan Mode Workflow

Describe what you want - Be specific about the outcome
Let Claude explore - It reads relevant files, understands context
Review the plan - Claude presents its approach
Approve or adjust - Iterate until the plan makes sense, a contract that both you and Claude agrees on
Defining deliverables and requirements - Claude creates the ticket for the approved plan
Execute - Then we execute the plan based on the ticket

Why does this work? Because it prevents Claude from charging ahead with a wrong approach. The cost of planning is low and the cost of reverting bad implementation is high.

Skills: Repeatable Actions

Skills are like macros - predefined actions you can invoke with a slash command. But I don't really invoke them specifically, I just say something like "Create a commit and push using the commit skills" or "Create a PR with the PR skills" or even "Create a commit and push using the commit skills, then create a PR using the PR skills"

/commit

Claude analyzes the changes, writes a conventional commit message, and handles the git operations.

/create-pr

When it's time to open a pull request:

/create-pr

Claude looks at all commits on the branch, summarizes the changes, and creates a properly formatted PR with description and change list.

/create-ticket

Need to track a new task:

/create-ticket

Claude creates a properly formatted ticket file, assigns the next ticket number, and updates the ticket list.

Custom Skills

You can create your own skills for repetitive workflows. If you find yourself giving Claude the same instructions repeatedly, that's a skill waiting to be created.

MCP

Model Context Protocol (MCP) lets you connect external tools to Claude, basically it is the API for LLMs, but frankly speaking, it is context bloat to me and I'm not a fan of it at all.

The promise is that you can connect databases, APIs, and external services directly to Claude. The reality is:

Setup friction: Getting MCP servers running reliably is VERY painful
Inconsistent behavior: Sometimes it works, sometimes it doesn't
Development phase: It is still in development phase and unstable.

Maybe MCP will mature and become essential, I'll stand correcter by then but right now, I skip it and use simpler approaches. If I need to query a database, I write a script. If I need to call an API, I use curl.

A few more general tips

One Task at a Time

Don't dump five unrelated tasks in one prompt. Claude handles focused, single-purpose requests much better than sprawling multi-part ones, clear after you're done to free up context and keep things bite-sized.

Use the Todo List

Claude has a built-in todo system. They are basically deliverables, use it to keep track and provides visible progress.

Let Claude Read First

This is kinda common sense, but before asking Claude to modify code, let it read the relevant files. Understanding before action prevents a lot of mistakes.

Trust but Verify

Claude is good, but it's not perfect. Always review the changes, run the tests, check that things actually work! Don't just leave it unsupervised, that's how you get slop.