Claude Code tips from 30+ weekly builds

A one-week build cycle is a brutal habit filter. Anything that doesn't repay its friction inside seven days gets dropped, so what follows is the residue: the practices still standing after thirty-plus rounds. Claude Code ships features fast, so I've kept these at the habit level and checked the specifics against the current docs before publishing.

1. Why does plan mode come first?

Plan mode (toggle with Shift+Tab) lets Claude read and reason about the codebase but not change it, so it explores and proposes before anything touches disk. On unfamiliar code or any multi-file change, this is the single biggest reliability upgrade available, and it costs one keystroke. My rule: if I can't predict the diff, we start in plan mode. Approving a good plan takes seconds; unwinding a confident wrong build takes an afternoon.

2. What actually belongs in CLAUDE.md?

CLAUDE.md is the file Claude reads at the start of every session, and the mistake is treating it as documentation. It's standing orders: the run and test commands, the two or three architectural rules that matter, the things Claude got wrong last week. Mine stay under a page, because a long CLAUDE.md is skimmed the way you skim terms of service. The habit that compounds: when Claude makes a mistake worth preventing, the fix ends the session by becoming a line in CLAUDE.md.

3. Why is there a jotthread.md in every repo?

The habit this whole site grew from. Every build repo carries one Markdown file holding the project's decisions, open tasks, and notes, committed next to the code it refers to. Claude reads it for context at session start and writes to it as things get decided, so the project's memory travels with the project, diffs in git, and survives every context reset. I use JotThread to run mine with /jot and /thread, but the habit works freehand too; the skill just makes the format exact and the capture two characters. Why a file beats an app for this job is its own post.

4. When do checkpoints beat git?

Claude Code checkpoints your session so you can rewind Claude's edits (the /rewind command) without touching your git history. They're for the small reversals: the refactor that went sideways, the styling experiment that failed. They are not a git replacement, and they can't undo side effects like API calls or database writes, so the discipline is both: checkpoints for conversational undo, real commits at every working state. Cheap reversals change how you prompt, because trying something stops being scary.

5. Why write the spec before the prompt?

The strongest correlation across thirty builds: the quality of what ships tracks the specificity of what I asked for. Two minutes writing constraints (what exists, what must not change, what done looks like) beats twenty minutes of corrective back-and-forth. Vague prompts don't fail loudly; they succeed at the wrong thing, which is worse.

6. When should work go to a subagent?

Subagents run in their own context, so I hand them anything bulky whose full transcript I don't need back: research a library, audit the error handling, hunt a bug across the codebase. The main session stays clean and gets a summary instead of two hundred lines of exploration. The signal to delegate is noticing that a task will fill the context with reading rather than deciding.

7. What are hooks for, in one sentence?

Hooks run real commands at fixed points in Claude's tool use, which makes them enforcement where CLAUDE.md is advice. Claude can skim past a written rule; it cannot skim past a hook that blocks edits to production config or runs the formatter after every change. I keep exactly two or three per project, because each one is machinery to maintain. Rule of thumb: preferences go in CLAUDE.md, laws go in hooks.

8. Which custom commands pay for themselves?

Any prompt you've typed three times is a slash command waiting to exist: drop a Markdown file in .claude/commands/ and it becomes one. Mine are boring on purpose, a review checklist, a pre-launch audit, a changelog writer. Boring is the point; commands are how a repeated prompt stops degrading into a lazier retyped version of itself. This is also the gateway to skills, which trigger themselves instead of waiting to be typed. Where each mechanism fits is in skills vs MCP.

9. What's the end-of-session habit?

Sessions end; context dies; the project continues. So the last two minutes of every session are a capture pass: decisions and open tasks into jotthread.md, any lesson worth enforcing into CLAUDE.md, then a commit. Next session starts by reading both files and continues as if the conversation never broke. It's the least glamorous habit on this list and the one I'd keep if I could only keep one.

Common questions