How I Use Claude Code Every Day

I talk about Claude Code a lot, so here's the full rundown of how I actually use it day to day. Not the demo version, the real one. How I set it up, how I prompt it, and the few features that turned it from a neat toy into the thing I open first every morning.

If you write code, or you're a curious everyday user who wants a real assistant in the terminal, this is for you.

What Claude Code is

Claude Code is an agentic coding tool that runs in your terminal. That word agentic is doing a lot of work, so here's what it means in practice. It doesn't just answer questions. It reads your project, makes a plan, edits files across your codebase, runs commands, checks the output, and fixes its own mistakes. You stay in the loop and approve the big moves.

Think of it less like autocomplete and more like a teammate who already read the whole repo before you finished your coffee.

Getting it running

Setup takes about two minutes. Install it once, globally.

npm install -g @anthropic-ai/claude-code

Then go into any project folder and start it.

cd my-project
claude

The first run walks you through signing in with your Anthropic account. After that you just type what you want in plain English. My very first command in a new project is always the same.

/init

That scans the project and writes a CLAUDE.md file, which is the memory Claude reads every time it starts. More on that below.

Why folder structure matters more than you think

Here's the thing nobody tells you. Claude is only as good as what it can find. A messy repo makes it guess. A clean one makes it fast and almost spookily accurate, because it navigates your project the same way you do, by reading folder and file names.

So good structure isn't just tidy for you, it's fuel for the model. The habits that help me also help Claude.

• Many small files beat a few giant ones. A 200 line file is easy to read and safe to change. An 800 line file is where bugs hide.
• Name things for what they are. PostCard.tsx tells Claude exactly what it is. utils2.ts tells it nothing.
• Group by feature, not by type. Keep the things that change together close together.

A layout like this lets Claude jump straight to the right file instead of reading half the repo to orient itself.

app/
  blog/[slug]/page.tsx
  page.tsx
components/
  Header.tsx
  PostCard.tsx
lib/
  posts.ts
  site.ts
content/
  posts/
    my-first-post.mdx
CLAUDE.md

When the names and folders are clear, you can say "fix the post card hover" and Claude knows where to go without a single hint from you.

How to prompt it well

This is where most people leave value on the table. The quality of what you get back tracks almost perfectly with how clearly you ask. A few habits that made the biggest difference for me.

Be specific about the goal, not the keystrokes. I tell it what I want to be true, and let it figure out the steps.

Add a dark mode toggle to the navbar that saves the choice and respects the system setting.

That works far better than feeding it one tiny instruction at a time. Point it at the right files when you know them, so it doesn't have to guess. And when a task is big, ask for a plan before any code gets written. Reading the plan first catches wrong turns early, while they're cheap to fix.

Agentic workflows

The real shift is letting Claude run the loop instead of babysitting every line. A normal task for me looks like this. I describe the feature, it reads the relevant files, proposes a plan, makes the edits across however many files it needs, runs the build or the tests, sees what failed, and fixes it. I review the result at the end like a pull request.

For bigger jobs it can hand work to subagents, smaller focused helpers that go off and do one thing, like searching the codebase or reviewing a diff, then report back. That keeps the main thread fast and the context clean.

My rule is simple. Give it clear direction, let it work, then review like you would a teammate's PR. Trust it with the boring parts, check it on the important ones.

Skills

Skills are how you teach Claude Code to do a task your way, every time. A skill is just a folder with a SKILL.md file that holds instructions, and Claude pulls it in automatically when the work matches.

I use them for the repetitive stuff. A writing style guide so every blog post sounds like me. A review checklist so it catches the same issues I would. A deploy routine so it runs the same steps in the same order. Write the instructions once, and you stop repeating yourself.

Here's the bigger idea. Plain markdown files are the cheapest way to make Claude smarter, and you don't need to train anything. Every .md file you write is context you can hand it. A SKILL.md for a specific job, a CLAUDE.md for how the whole project works, a voice.md so it writes like you. The model already knows how to code. What it doesn't know is your project, your taste, and your rules. Markdown is how you teach it all three.

The pattern I keep coming back to is simple. Anytime I explain the same thing twice, I write it down in a markdown file instead. Next time, Claude reads it and just does it right.

# SKILL.md

When deploying this site:

1. Run the build and confirm it passes.
2. Check the sitemap and robots output.
3. Commit with a clear message, then push to main.

MCP

MCP is what connects Claude Code to the outside world. It stands for Model Context Protocol, and the short version is that it lets Claude talk to other tools and services through small servers. GitHub, your database, a browser, your docs, whatever you wire up.

You add a server in a .mcp.json file in your project.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

Once that's connected, I can ask Claude to open a pull request, read an issue, or pull data straight from my database without leaving the terminal. This is the piece that takes it from a coding tool to a control center for your whole stack.

A quick word on LLMs, RAG, and local models

If you're newer to the AI side, a few terms are worth knowing because they explain why all of the above works so well.

An LLM is the model itself, the thing that reads your words and writes a response. Claude is an LLM. On its own it only knows what it learned during training, which means it knows nothing about your project.

That's where RAG comes in. It stands for retrieval augmented generation, and the plain version is this. Instead of hoping the model already knows something, you hand it the right documents at the right moment so it answers from your stuff, not from memory. When you think about it, that's exactly what CLAUDE.md, your skills, and MCP are doing. They feed Claude the right context for the task. It's a practical, everyday version of the same idea.

Then there's running models on your own machine. Tools like Ollama let you download an open model and run it locally, fully offline and free, with nothing leaving your laptop.

ollama run llama3

I reach for a local model when privacy or cost matters, or when I just want to tinker without an internet connection. For real day to day work I still want the smartest model I can get, which is where a hosted tool like Claude Code earns its place. The nice mental model is this. Local models are great for private and cheap, hosted models are great for smart. Pick the one the job actually needs.

A few everyday habits

A handful of small things I do that pay off constantly.

• Keep CLAUDE.md updated with how the project works and any rules I care about. It's the difference between Claude guessing and Claude knowing.
• Start a fresh chat for a fresh task. A clean context gives sharper answers.
• Ask for a plan on anything non trivial before it touches code.
• Let it run the tests and read the errors itself instead of copying output back and forth.

The takeaway

You don't need to use every feature on day one. Install it, run /init, and start giving it real tasks in plain English. Add a CLAUDE.md so it remembers how your project works. Reach for skills when you're repeating yourself, and MCP when you want it talking to your other tools.

That's the whole loop. Describe what you want, let it work, review the result. It's the closest thing I've found to having a second developer who never gets tired.