Claude Code's Most Underused Features | Coding Capybaras

Photo by Chris Ried on Unsplash

The most underused Claude Code features for non-tech founders are plan mode, the CLAUDE.md memory system, checkpoints with /rewind, hooks, custom slash commands, subagents, auto memory, and context management with /context and /compact. Most of us learn to type a prompt, hit enter, and hope. That works, but it leaves the majority of the tool on the table. I used Claude Code for months before I found half of these, and each one fixed a specific frustration I'd assumed was just the cost of AI coding. This post walks through all eight — what each feature does, when to reach for it, and the mistakes I made before I knew it existed.

TL;DR

• Plan mode makes Claude read and propose before it touches files — the single biggest reliability upgrade for non-devs.
• A CLAUDE.md under 200 lines stops you from re-explaining your project every session.
• Checkpoints (/rewind or double-Esc) undo Claude's edits without you needing to understand git.
• Hooks enforce rules with code; CLAUDE.md only suggests them.
• Start with plan mode and CLAUDE.md this week. Add the rest as specific pain shows up.

Why does plan mode matter so much for non-developers?

Plan mode is a session state where Claude can read your code, search it, and reason about it — but it's not allowed to write to disk or run commands that change anything. You toggle it with Shift+Tab. Claude explores, then presents a plan. You approve it before anything happens.

If you only adopt one thing from this post, make it this one. Here's why it matters more for non-tech founders than for engineers: an engineer can read a diff and catch a bad change after the fact. Most of us can't, or at least can't reliably. Plan mode moves the checkpoint to before the change, where the conversation is in plain English. "I'll modify the webhook handler to verify signatures before processing, then add a test" is something I can evaluate. Four hundred lines of changed TypeScript is not.

My old workflow was: type a request, watch files change, get a bad feeling, ask "wait, why did you change that?" — after the fact, with the damage already on disk. In plan mode, the "wait, why?" conversation happens first. I push back on the plan, Claude revises it, and only then do we execute.

The habit I'd suggest: default to plan mode for anything touching payments, auth, or your database. Those are the areas where a confident wrong change costs you real money or real user trust. For cosmetic changes — copy edits, styling — normal mode is fine. I wrote more about this judgment call in when to trust your AI assistant, but the short version is that plan mode is how you buy verification time you don't have the skills to get from reading diffs.

Plan mode also changes the quality of the work itself. When Claude is forced to survey the codebase before acting, it finds the existing helper function instead of writing a duplicate. It notices the pattern your codebase already uses. Acting first and discovering context later is how you get the drift that makes AI-built codebases messy.

What is CLAUDE.md and why should you set it up first?

A CLAUDE.md file is a markdown file of persistent instructions that Claude Code reads automatically at the start of every session. It's the fix for the most annoying thing about AI coding as a non-dev: every new session starts from zero, and you find yourself re-explaining your project — where things live, what commands to run, what not to touch — over and over.

Per the official memory documentation, the guidance is to keep it under 200 lines, because longer files consume context and Claude's adherence degrades. The docs also give a rule for what belongs in it that I've found dead-on in practice: add an instruction when Claude makes the same mistake a second time, or when you catch yourself typing the same correction you typed last session.

Mine includes things like: which folders are off-limits (the boilerplate's /platform/ region), what command creates a new route, and the rule that all email goes through one central helper. Every one of those lines exists because Claude got it wrong once and I never wanted to explain it again.

Three related features most people miss:

/init writes your first draft. Run it in your project and Claude analyzes the codebase and generates a starting CLAUDE.md with build commands and conventions it discovers. You refine from there instead of staring at a blank file.

/memory shows you what's actually loaded. It lists every instruction file in your current session. When Claude ignores a rule, this is the first debugging step — half the time the file isn't where you think it is, so Claude never saw it.

.claude/rules/ scopes instructions to file paths. Rules files with a paths frontmatter field only load when Claude works on matching files. Your database conventions load when it touches schema files and stay out of the way otherwise. That's how you keep the main file under 200 lines as your project grows.

If you're brand new to the tool, my Claude Code guide for non-developers covers the setup basics; CLAUDE.md is the first thing I'd add after install.

Auto memory: the notes Claude writes for itself

CLAUDE.md is memory you write. Auto memory is memory Claude writes — and most users don't know it's happening. As it works, Claude saves notes about your project into a memory directory on your machine: build commands it figured out, debugging insights, preferences you expressed mid-session. Those notes load at the start of future sessions.

It's on by default in recent versions (v2.1.59+, per the docs). The first 200 lines of the memory index load into every session, and Claude pulls detailed topic files on demand.

Two practical things to know. First, you can just tell Claude to remember something — "remember that the API tests need a local Redis instance" — and it lands in auto memory without you editing a file. For a non-dev, that's the lowest-friction way to build persistent context: correct Claude once, out loud, and it sticks.

Second, everything is plain markdown you can read. Run /memory, open the auto memory folder, and audit what Claude has written about your project. I check mine every few weeks. Mostly it's accurate; occasionally there's a stale note from a refactor, and deleting it takes ten seconds. Treating the memory folder as something you can read and prune — rather than an invisible black box — is the difference between memory helping and memory quietly steering you wrong.

The division of labor that's emerged for me: CLAUDE.md holds the rules I'd put in a team handbook. Auto memory holds the accumulated street knowledge — the stuff you'd only know from having worked in the codebase.

Checkpoints and /rewind: the undo button nobody finds

Claude Code automatically snapshots your files before each edit it makes. Run /rewind — or press Esc twice with an empty prompt — and you get a menu of every prompt in the session. Pick one, and you can restore your code, your conversation, or both to that moment.

I went months without knowing this existed, and during those months my recovery strategy for "Claude made things worse" was asking Claude to un-make it worse. Sometimes that worked. Sometimes it compounded — the fix for the bad change introduced its own bad change, and I was three layers deep in a hole with no map. If you've lived that spiral, /rewind is the feature you were missing. One command, pick the last good point, back to safety.

The limits matter, per the checkpointing docs: checkpoints only track files Claude edited through its own tools, in the current session. Changes you made yourself in another editor aren't covered, and it's not a replacement for git — you still want real commits as your permanent history. I think of checkpoints as session-level undo and git as the save file. My actual workflow: commit before starting a chunk of work (I literally ask Claude to do it), then use /rewind freely within the session, knowing the commit is the hard floor.

There's also a subtler use: the rewind menu can restore just the conversation to an earlier point, or summarize a stretch of it, without touching files. When a session has wandered — you explored three approaches and want to get back to the decision point with your code intact — that's the move. It pairs well with the vibe coding workflow: move fast because the escape hatch exists.

Hooks, custom commands, and subagents

These three are more advanced, and I'd reach for them in this order.

Custom slash commands are prompt templates you save as markdown files in .claude/commands/. A file at .claude/commands/ship-check.md becomes /ship-check in your sessions. Anything you find yourself typing repeatedly — "review this for security issues, check the input validation, confirm no secrets are committed" — belongs in one. I keep a handful for my recurring rituals, and they've replaced a text file of prompts I used to paste from. If you've read my post on prompt engineering for non-developers, commands are where your good prompts go to become reusable.

Hooks are shell scripts that run automatically at fixed points in Claude's lifecycle — before a tool runs, after a file edit, and so on (hooks reference). The key distinction, straight from the docs: CLAUDE.md instructions are context Claude tries to follow; hooks execute regardless of what Claude decides. A PreToolUse hook can block any command touching a protected folder — not ask nicely, block. If there's a rule in your project where "Claude usually complies" isn't good enough — never touch the production env file, always run the linter after edits — that rule wants to be a hook. Writing one requires a small shell script, which sounds intimidating, but Claude will write its own hooks if you describe the rule. That still makes me smile.

Subagents are separate Claude sessions spawned to handle a task with their own context window, reporting back only the conclusion. The practical benefit for a founder: verbose work stays out of your main conversation. When Claude searches forty files to answer a question, all that file-reading noise fills up context you'd rather spend on the actual work. Delegating research to a subagent keeps the main thread clean, which meaningfully delays the moment your session degrades. You don't have to configure anything to benefit — you can just ask Claude to "use a subagent to research X."

Which feature solves which problem?

Here's the map I wish someone had handed me:

| Problem you have | Feature | Effort to adopt | | --- | --- | --- | | Claude changes things I didn't want changed | Plan mode (Shift+Tab) | None — it's a keystroke | | I re-explain my project every session | CLAUDE.md + /init | ~30 minutes once | | Claude forgot what we figured out last week | Auto memory | None — on by default | | Claude made it worse and I can't get back | /rewind / double-Esc | None — it's a command | | I type the same long prompt every week | Custom slash commands | ~10 minutes per command | | A rule keeps getting ignored | Hooks | Small script (Claude can write it) | | Long sessions get dumb and forgetful | /context, /compact, subagents | Habit, not setup |

The last row deserves a word since it's the only one I haven't covered: /context shows you what's filling Claude's context window, and /compact compresses the conversation when it gets bloated. Sessions don't fail loudly when context fills up — they just get subtly worse. Checking /context when a long session starts feeling off is the diagnostic most people never run.

If you're comparing tools rather than deepening one, my Cursor vs Claude Code vs Cowork comparison covers where each fits. But the honest takeaway from writing this post: most people don't need a different tool. They need the second half of the one they have.

Frequently asked questions

What's the difference between CLAUDE.md and auto memory?

CLAUDE.md is written by you and holds instructions and rules; auto memory is written by Claude and holds learnings it picks up from working with you. Both load at the start of every session. Instructions set the standard; memory accumulates the context.

Do checkpoints replace git?

No. Checkpoints only track files Claude edited in the current session, and they're a session-level safety net, not permanent history. Keep committing to git — or ask Claude to commit for you at sensible points — and use /rewind for the in-session mistakes between commits.

Are hooks safe for a non-developer to set up?

Reasonably, if you start with read-only or blocking hooks (ones that prevent actions rather than perform them). Describe the rule you want enforced and have Claude write the hook script, then have it explain the script back to you line by line before you enable it.

How big should a CLAUDE.md file be?

Under 200 lines, per Anthropic's own guidance — adherence drops as the file grows. If you're past that, move path-specific instructions into .claude/rules/ files that only load when relevant files are touched.

Do these features exist in Cursor or other AI tools?

Partially. Most AI coding tools have some instructions-file equivalent (Cursor has rules files), and several have plan-like modes. The specific mechanics here — auto memory, /rewind, lifecycle hooks — are Claude Code features, though the concepts transfer.

Which feature should a beginner adopt first?

Plan mode, same day you install. Then CLAUDE.md within the first week. Everything else can wait until you feel the specific pain it solves — adopting features before the pain exists just adds complexity.

Conclusion

The pattern across all eight features is the same: Claude Code ships with the guardrails non-tech founders need, but they're opt-in, and nothing forces you to find them. Plan mode gives you review before damage. CLAUDE.md and auto memory give you continuity. Checkpoints give you undo. Hooks give you enforcement. None of them require engineering skill to use — they require knowing they exist, which is the gap this post is meant to close. Start with plan mode and a CLAUDE.md this week; add the rest when the matching pain shows up. These Claude Code features tips are most of the distance between fighting the tool and working with it.

If you're shipping a SaaS with AI coding tools, Coding Capybaras is the free boilerplate I built for exactly this workflow — it ships with a CLAUDE.md already written, so the guardrails in this post are configured before your first session.