[Blog] get started with claude coding
a practical, no-jargon guide from someone (almost beginner) who's been through copilot, cursor, and everything in between.
also live on medium (please leave a like man).
what's claude code?
Claude Code is Anthropic's command-line coding agent. You run it in your terminal, point it to any codebase, and have a conversation with an AI that can read, write, and edit your files directly. Simple!
step 0: the basics, just start talking
If you've never used Claude Code before, here's what you should do: install it, navigate to your project folder in the terminal, and type claude. That's it. You're now in a conversation with an AI agent that can see your codebase.
You can ask it things like:
- "What does the handle function in app.js do?"
- "Add a loading spinner to the checkout page."
- "Fix the bug where the date picker breaks on mobile."
Claude reads your files, proposes changes, and asks you to approve them. Idea is to treat Claude as your intern, just a really smart one. It's like pair programming, except your intern has read the entire codebase in seconds and knows everything about software development that is available on the internet.
Just talking to Claude code alone is useful. But if you stop here, you're leaving a lot on the table.
step 1: create a CLAUDE.md file, give claude a brain
This is the single most important upgrade you can make in my opinion.
Think of CLAUDE.md as the system prompt for your coding agent. It's a markdown file in the root of your project, and Claude reads it at the start of every conversation. It tells Claude who it's working with, what the project is, and how things should be done.
how to create one
Just run: /init
Claude will generate a basic starting CLAUDE.md for you. But that's just the seed, this file should continuously evolve.
what to put in it
Anything you find yourself repeating to Claude, put it in CLAUDE.md instead. Think of it this way: if a brand-new developer joined your team tomorrow, what would they need to know? That's what goes here.
Some examples:
- Project overview: "This is a Next.js e-commerce app using Prisma and PostgreSQL."
- Code conventions: "We use camelCase for variables, snake_case for payloads. All API routes go in /src/api."
- Common commands: "Run tests with npm run test. Deploy with npm run deploy:staging."
- Things to avoid: "Never modify the legacy/ folder directly. Don't use any types in TypeScript."
- Architecture decisions: "We use the repository pattern for database access. All business logic lives in the /services directory."
different levels of CLAUDE.md
You can actually have multiple CLAUDE.md files that serve different purposes:
Project-level: Shared knowledge for the whole team. Check this into Git. Has to be collaboratively kept upto date. This must become a living document everyone contributes to. When someone figures out Claude keeps making the same mistake? Add a note. Found a prompt that works well? Put it in. It's supposed to be an ever-evolving file.
User-level: Your personal coding preferences (formatting style, preferred patterns, etc.). Not checked into Git.
Folder-level: Context specific to that part of the codebase (e.g., a CLAUDE.md inside /frontend with React-specific rules).
step 2: use plan mode, think before you build
A mistake I made early on is I'd ask Claude to make a big feature and let it rip. It would start writing code immediately, and sometimes it would go down the wrong dark buggy path and by the time I noticed, it had changed 15 files and my simple checkout page had somehow become a distributed microservices architecture with its own event bus.
Don't make the same mistake. Plan Mode solves this.
what is plan mode?
Plan Mode is a setting (toggled with Shift + Tab) that tells Claude: "Don't write any code. Just think and talk to me."
This is important because, without it, Claude's natural instinct is to start making changes. Plan Mode forces it to slow down and have a conversation first.
how i use it:
Whenever I start a new feature or bug fix, I follow this flow:
- First enter Plan Mode and describe what I want to build.
- Ask Claude to ask ME questions. This is the key move. I say something like: "Before we start, ask me any clarifying questions and flag any concerns." Claude will often ask about edge cases and architectural decisions I hadn't considered because I'm obviously dumb.
- Go back and forth until Claude and I have a solid plan for what we're gonna do and what we're not going to do (which is arguably more important when it comes to AI coding lol). The scoping is just as important as the plan itself. And plan mode kind of forces you to scope.
- Once happy with the plan, switch out of Plan Mode (Shift + Tab again), clear the context with
/clear, and tell Claude to implement the plan you just made.
step 3: skills and workflows, teach claude specialisations
Once you're comfortable with CLAUDE.md and Plan Mode, it's pretty much time to unlock two powerful features: Skills and Workflows. They are kinda similar, but they serve very different purposes.
skills (skills.md)
A skill is a reusable prompt or set of instructions stored as a markdown file. Claude automatically detects when a skill is relevant and applies it, you don't need to invoke it manually.
I treat skills as specialisations that I'm giving Claude. Here are examples of the ones I use:
- Frontend development: Best practices for React components, state management patterns, accessibility rules.
- API design: How I want REST endpoints structured, error handling conventions, response formats.
- Unit testing: Exactly how I want test cases written: naming conventions, what to mock, coverage expectations.
- Log lookup: A skill that knows how to query my CloudWatch logs to investigate deployment issues.
I like skills because of the automatic activation. If you start talking about writing tests, Claude pulls in your testing skill without you asking. If you're working on a React component, it applies your frontend skill.
To create skills, you create .md files in a .claude/skills/ directory and Claude picks them up. Refer to skills.sh for some pretty cool skills.
workflows (slash commands)
Workflows are on-demand, multi-step processes that you invoke explicitly using a slash command. They're for bigger, more structured tasks that you want to trigger deliberately.
My favourite workflow: PR Review.
Before I raise a pull request, I open a new terminal and run: /pr-review
This kicks off a structured review process where Claude:
- Reads through all the changes in the PR.
- Rates the PR on metrics I've defined: code quality, test coverage, naming consistency, potential bugs, etc.
- Gives me a summary with specific line-level feedback by creating an MD file for the PR review with all the suggested changes.
- Then I treat the MD file as my implementation plan and one by one fix all the issues raised by asking a new Claude chat and keep track of the progress using the MD file. I only raise a PR after all these Claude flagged (relevant) issues are solved.
step 4: context management: the skill most people learn too late
This is the thing I wish someone had told me on day one.
Like all LLMs Claude has a context window; a limit on how many tokens it can hold in its "working memory" during a conversation. Every message you send, every file it reads, every response it gives, it all fills up this window. And progressively degrades the performance.
As the context window fills up, two things happen:
- Claude's quality degrades. It's like trying to think clearly when you're sleepy, the more crammed up the context is, the less sharp the responses become. Claude Code is at its best when it's fresh.
- Auto-compaction can lose important details. When the context gets too full, Claude automatically "compacts" (summarises) the conversation to free up space. The problem is that the summarisation sometimes drops important steps in a chain of thought, leading to mistakes or hallucinations after the summarisation.
how to manage it?
Use the /context command regularly. This shows you:
- How much context you've used vs. how much remains.
- A breakdown of where your context is going (which files, which MCP servers, etc.).
My rule of thumb: compact at 60–70% usage. Don't wait until you're at 95% and Claude auto-compacts at the worst possible moment. Set mental checkpoints for yourself; after each major task / milestone, check your context usage.
When you're ready to compact, use the /compact command with a summary of what matters. This lets you decide what's important to remember, rather than leaving it up to an automatic process.
putting it all together: my daily workflow
Here's what a typical development session looks like for me now:
- Wake up
- Start multiple claude code sessions
- Coffee
- Stop multiple claude sessions from getting derailed and avoid being ragebaited by an AI.
- Claude code hits limit
- Lunch
- Gym
- Another round of claude coding until limit hits again
- Sleep
- Next morning: repeat