CLAUDE.md — The Non-Negotiable
A CLAUDE.md file in your project root. Claude Code reads it at the start of every session. It's onboarding docs for your AI pair programmer.
What goes in it: your stack (specific versions, not just "Vue"), file structure, naming conventions, component patterns, error handling approach, available commands.
Without it, Claude guesses. With it, Claude follows your architecture.
Keep it under 200 lines. Move detailed docs to separate files and reference them with @filename.
If you do one thing from this post, create this file. 30 minutes of work. Hours saved per session.
Skills — Load Expertise, Not Context
Skills live in .claude/skills/. They're markdown files that give Claude specialized knowledge for specific tasks — but only when relevant.
The difference from CLAUDE.md: CLAUDE.md loads every session. Skills load on demand. You don't bloat your context with PDF generation instructions when you're writing API routes.
The real power: write skills for your own domain. I wrote one for my product's detection rule format. The exact structure, fields, validation patterns, naming conventions. Now every new rule comes out perfectly structured. No re-explaining. No drift.
Community skills and plugins exist too. The ecosystem is growing fast.
Subagents — Parallel Work
Claude Code can spawn subagents — independent processes with their own context and tools.
Building a feature but also need to refactor tests? Kick off a subagent for the tests. It works in a git worktree (isolated copy of your repo), so zero conflict risk. You keep working on the feature.
I use them for:
- Parallel code reviews
- Running test suites while developing
- Research tasks that need deep exploration
- Verification passes on generated code
Subagents access skills too. So a subagent loads domain knowledge, does its work, returns results. You're orchestrating a team, not managing a chatbot.
Plan Mode — Think Before You Generate
Start in plan mode for anything non-trivial. Describe what you need. Let Claude explore the codebase, identify touch points, produce a plan. Review the plan. Then switch to implementation.
This prevents the most expensive failure mode: generating code that solves the wrong problem. Planning costs minutes. Rewriting costs hours.
I document the plan in a separate file that Claude references during implementation. Every prompt becomes a step against a plan, not an open-ended request.
The Setup in Practice
Here's what this looks like end-to-end:
- CLAUDE.md tells Claude my stack, conventions, patterns
- Plan mode produces a reviewed implementation plan
- Skills load domain-specific knowledge for the task
- Focused prompts implement one step at a time against the plan
- Subagents handle parallel work without context switching
Each piece is useful alone. Together they compound. Claude Code goes from "generates code" to "follows my development process."
What I Shipped With This
I built Sitewatch with this exact workflow — a monitoring platform that detects when websites return 200 OK but are actually broken for users. Broken JS bundles after deploys, MIME type mismatches, stale CDN content, redirect loops. The failures uptime tools miss.
Claude Code wrote ~60-70% of the codebase. The detection logic — the brain of the product — came from me. The setup above is how I maintained quality while moving at that speed.
Free tier for 1 site if you want to try it: getsitewatch.com
TL;DR
Stop prompting harder. Start setting up better.
- Create a
CLAUDE.md— today - Write a skill for your most common task
- Make a slash command for your most repeated workflow
- Use plan mode for anything bigger than a single file
- Use subagents when tasks can run in parallel
The developers getting the most out of Claude Code aren't the best prompters. They're the ones with the best setup.
That about wraps it up!
Top comments (0)