I’ve been using Claude Code (Anthropic’s CLI agent) on a few of my own projects — this blog and some Linux storage tooling — and a small set of customizations have made it noticeably faster to live with day-to-day. None of these are exotic; they’re things the docs mention but which are easy to skip past on first read.

CLAUDE.md is the highest-leverage file in any repo

Every project gets a CLAUDE.md at its root. Claude Code loads it automatically into every session, so anything you put there saves you having to re-explain it later. What’s worth keeping in it:

• The exact build / test / lint commands so the agent doesn’t guess
• Quirks of the codebase that aren’t obvious from any single file (theme generation, deploy pipeline, custom collections, where layouts come from)
• “Don’t do X” rules — branches it shouldn’t push, files it shouldn’t touch, commands it shouldn’t bypass

Run /init on a fresh repo to scaffold one, then prune. Anything obvious from git log or the directory tree doesn’t need to be in there — CLAUDE.md is for what can’t be inferred from the code.

Permission allowlists for the commands you trust

By default, Claude prompts before each shell command. For repeatable safe ones (git status, bundle exec jekyll build, ls) the prompts are pure friction. Add them to .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(git status)",
      "Bash(git diff:*)",
      "Bash(bundle exec jekyll build)"
    ]
  }
}

The /fewer-permission-prompts skill scans your past sessions and proposes sensible entries — useful for an initial pass. Allow-list aggressively for read-only commands, conservatively for anything that mutates state.

Hooks, for guardrails that should never be forgotten

If you’re saying the same thing every session (“after editing markdown, run mdformat”; “never commit .env”), it’s a hook, not a memory. Hooks in settings.json are shell commands the harness runs on events like PostToolUse — the agent can’t forget to run them, because it doesn’t run them, the harness does.

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Edit|Write",
      "hooks": [{ "type": "command", "command": "your-shell-command" }]
    }]
  }
}

Memory and CLAUDE.md are for context the agent should know. Hooks are for behavior the system should enforce. Different problems.

Plan mode before non-trivial changes

For anything bigger than a one-line fix, ask for a plan before any code. Either invoke Plan mode explicitly, or just say “give me a plan, don’t write code yet.” It’s the cheapest way to catch architectural mistakes — much better to throw away a paragraph than 200 lines of refactor.

Subagents for parallelizable or context-heavy work

The two I reach for most:

• Explore — read-only code search. Faster than running grep yourself when you don’t know exactly where something lives. Spawn it with a question, get a focused summary back instead of stuffing your context with raw matches.
• General-purpose with isolation: "worktree" — runs in a temporary git worktree so an experimental refactor doesn’t touch your working tree. The worktree auto-cleans if no changes were made.

Don’t spawn agents for everything. Each one starts cold and re-derives context, which costs more than just doing the lookup yourself. Default to inline; reach for a subagent when the task genuinely parallelizes, when the result would clutter the main session, or when you want isolation.

Choose the model deliberately

Three current models, three use cases:

• Opus 4.6 — hard reasoning, architecture decisions, gnarly bugs
• Sonnet 4.6 — most day-to-day coding
• Haiku 4.5 — quick lookups, simple edits, anything where latency matters

/fast toggles a faster Opus 4.6 if you’re on Opus and want quicker output without dropping to a smaller model.

Custom skills for your own repeating workflows

A skill is a markdown file at ~/.claude/skills/<name>/SKILL.md (or <repo>/.claude/skills/<name>/SKILL.md for project-scoped) with frontmatter and a prompt. Once defined, you can invoke it as /<name>. Good candidates: PR review checklists you keep re-typing, per-language style passes, wrappers around internal scripts. If you’ve explained the same thing more than twice, it’s a skill.

/loop and /schedule for things you’d rather not babysit

• /loop 5m /check-deploy — runs a prompt on a recurring interval until you stop it
• /schedule — creates a remote agent on a cron schedule. Useful for “open a cleanup PR for this feature flag in 2 weeks” or “triage the alerts queue every Monday morning”

The dynamic-pacing variant of /loop (no interval) lets the model self-pace, which is the right choice when you don’t know in advance how long the underlying task will take.

Memory for things that outlive the conversation

The memory system at ~/.claude/projects/<encoded-cwd>/memory/ stores small markdown files: who the user is, project constraints, feedback you’ve given Claude about your preferences. Don’t store working state there — that belongs in plans or todo lists. Memory is for context that should still be true next month.

The pattern across all of these: don’t fight the harness, configure it. Anything you keep repeating verbally is something the system can remember (CLAUDE.md), enforce (hooks), or skip (allowlists). Setup is minutes; the savings compound across every session afterwards.