Most people open Claude Code, type a prompt, watch it edit a file, and call it a day. That's the 10% version. It works fine, but it's the same as using a spreadsheet purely as a place to type numbers and never touching a formula.
The rest of it is genuinely worth learning, not because more features means more impressive, but because each one solves a specific kind of friction that shows up the moment you use Claude Code on a real project instead of a toy one. Here's what's actually there.
Every session starts with a blank context window. Claude doesn't remember yesterday's conversation unless you give it something to read at the start of today's.
That's what CLAUDE.md is for. It's a plain markdown file, essentially your project's front-desk brief, that Claude reads at the start of every session. Build commands, coding conventions, architectural decisions, the stuff you'd otherwise type into chat every single time. Run /init in a project and Claude will scan your codebase and generate a starting one for you, build commands, test instructions, conventions it can infer just from reading your files.
The trap here is treating it as a dumping ground for everything, including corrections that only apply to one edge case. Keep it under 200 lines. Longer files eat more context and Claude follows them less reliably, not more. If something only matters for one part of the codebase, it belongs in a path-scoped rule or a skill instead, not the main file.
Separate from CLAUDE.md, Claude Code also keeps its own running notes, called auto memory. You don't write these, Claude does, based on corrections you give it and patterns it picks up as it works. It saves four kinds of things: your working preferences, corrections you've made, ongoing project context that isn't obvious from the code itself, and pointers to things like an issue tracker or dashboard.
It skips anything it could just figure out by reading the code, so it doesn't turn into a bloated diary. Run /memory anytime to see exactly what's been saved and edit or delete it, it's just markdown sitting in a folder, nothing hidden. The practical effect is that the more you use it on one project, the less you find yourself repeating the same correction three sessions in a row.
If you've ever watched Claude confidently build the wrong thing for ten minutes before you caught it, plan mode is the fix. Hit Shift+Tab or type /plan and Claude switches into read-only mode: it explores, researches, and proposes a plan, but doesn't touch your files until you approve it.
This matters more than it sounds like it should. A wrong plan costs you thirty seconds to redirect. A wrong implementation costs you the time to build it, notice it's wrong, and unwind it. If you're new to Claude Code, defaulting to plan mode for anything non-trivial is the single highest-leverage habit you can build early.
Here's a distinction that took me a while to actually internalize: everything in your CLAUDE.md is a request. Claude reads it, weighs it against everything else in context, and usually follows it. Usually.
A hook is different. It's a shell command that runs automatically at a specific point in Claude's process, formatting a file after every edit, blocking a write to a sensitive file, sending you a notification when Claude needs input, and Claude doesn't get a vote. A PreToolUse hook can block an action outright regardless of what Claude decides to do next.
The mental model that actually stuck for me: if you'd be annoyed by something getting ignored once, it shouldn't live as a sentence in CLAUDE.md. It should be a hook. Auto-formatting on save, blocking edits to .env or package-lock.json, these aren't things you want to politely request every session, they're things you want enforced.
If you've retyped a 200-word prompt more than twice, that's a skill waiting to happen. Skills package a repeatable workflow, instructions plus whatever it needs to execute, into something that loads on demand instead of sitting in your context every session.
The pattern that works: don't try to design a skill up front. Work through something with Claude until the process is actually dialed in, then ask Claude to turn that conversation into a reusable skill. It'll name it and tell you what triggers it. The discipline worth having here is keeping the trigger word specific. A common word firing in the middle of unrelated work is worse than a skill that never fires at all.
Before spending an afternoon building your own version of something, check /plugin for the marketplace. Anthropic's official marketplace covers things like code intelligence, external integrations, and automatic security review, and the community marketplace has a wider spread beyond that.
Connectors are a similar story from a different angle. Anything you've already connected on claude.ai, Gmail, a calendar, whatever, carries straight over into Claude Code sessions without you setting it up twice. The practical use case that sold me on this: giving Claude access to your actual calendar and inbox means asking for a summary of your week gives you a real answer instead of a guess.
If you're new to this, the order that makes sense is: get a CLAUDE.md in place first, since everything else builds on Claude actually understanding your project. Use plan mode by default until you trust the rhythm. Then let hooks and skills emerge naturally, you'll know you need one the second time you find yourself typing the same correction or the same long prompt.
None of this requires understanding some elaborate system upfront. It requires noticing your own friction and building the fix once instead of repeating the workaround forever. That's really the whole idea behind all of it.