Claude Code Power-User Setup: Beyond the Basics
Why the basics stop working at scale
You have been using Claude Code for a few months. It is fast, it knows your codebase reasonably well, and it handles routine changes without much hand-holding. Then you hit the ceiling.
The session starts strong but drifts. You spend five minutes re-explaining context that was obvious last session. You catch a regression because Claude did not run tests automatically. A refactor touches a dozen files and two of them are wrong because the scope was ambiguous. You fire up a second task and have to choose between abandoning the first or holding both in your head simultaneously.
These are not bugs in Claude Code. They are the natural consequences of using it as a smart terminal assistant rather than as an operating system. The power-user setup treats Claude Code as the latter. It has five layers: rules (CLAUDE.md), procedures (Skills), enforcement (Hooks), isolation (Subagents), and multi-window execution. This guide covers all five and shows how they combine.
Layer 1: A CLAUDE.md that actually scales
Most developers write a CLAUDE.md once and forget it. The file that gets written in week one tends to be either a list of project facts (stack, conventions, file locations) or a dump of every instruction ever given in conversation. Neither scales.
A CLAUDE.md that works at power-user scale answers exactly three questions at the top: what is the stack, what are the hard rules, and where are the files that have more detail. Everything else is either a skill (reusable procedure) or a hook (deterministic enforcement). If it is in CLAUDE.md, it needs to be there because Claude has to read it every session. Rules that are session-independent do not belong in the main file.
The structure that works:
# Project rules
## Stack
- Next.js 15 (App Router), TypeScript strict, Drizzle ORM, Turso
- Tests: Vitest + Playwright (e2e in tests/e2e/)
- Deploy: Vercel (preview on PR, production on main)
## Hard rules
- Never run `drizzle-kit push` against production (migrations only)
- All third-party SDK calls go through lib/clients/ (never inline)
- Run `pnpm test` before marking any task complete
- Read .claude/memory.md before starting any task
## Where to look
- Skills: .claude/skills/ (procedures for recurring workflows)
- Memory: .claude/memory.md (current session context)
- Agents: .claude/agents/ (specialist subagents)
Notice what is absent: no tool versions, no environment paths, no workflow explanations. Those belong in skills. The CLAUDE.md is the index, not the encyclopedia.
One rule that pays for itself immediately: "Read .claude/memory.md before starting any task." Without it, every session is cold. With it, Claude picks up where the last session left off. For more on the CLAUDE.md architecture, see our CLAUDE.md explained guide.
Layer 2: Skills as reusable procedures
A skill is a Markdown file that documents a recurring workflow. It is not a prompt template. It is a detailed procedure Claude reads before doing that category of work. The difference matters: a template tells Claude what to write, a skill tells Claude how to think through a problem.
Skills live in .claude/skills/. Claude reads them when the task calls for it, either via explicit reference in CLAUDE.md or by being called by a subagent.
Three skills that earn their place in almost every project:
The deploy skill. Covers pre-deploy checks, the exact command sequence, how to verify success, and the rollback procedure. Once written, you never have to explain "before pushing, run build and check for TypeScript errors" again.
The refactoring skill. Documents the planning-first pattern: enumerate every file that uses the target symbol, review the scope, get approval, execute, verify. Prevents the "Claude edited 8 files and missed 2" failure mode.
The debugging skill. Covers the process for reproducing bugs, reading tracebacks, isolating variables, and confirming the fix. Structures Claude's debugging loop rather than letting it guess.
Skills compound. Each one you write is a piece of context that never has to be typed again. A project with 10 well-written skills behaves qualitatively differently from a project with zero. For a deeper look at skills architecture and examples, read Claude Code skills explained.
Layer 3: Hooks for deterministic enforcement
Skills and CLAUDE.md are advisory. Claude reads them and follows them, but there is a model in the loop. Hooks are different. They execute shell commands at lifecycle events with no model involved. They cannot be confused and they cannot hallucinate.
Hooks live in .claude/settings.json. Each hook specifies a lifecycle event and a command to run.
The four lifecycle events that matter most for power users:
PreToolUse runs before Claude uses a tool. This is where you block dangerous commands. If the tool is Bash and the command matches drizzle-kit push or DROP TABLE, the hook rejects it before it runs.
PostToolUse runs after every tool use. This is where you log activity, run linters automatically, or track session quality. A PostToolUse hook that runs eslint after every file write catches formatting violations before Claude moves on.
Stop runs at the end of every turn. This is where you enforce context health checks, verify that tests were run, or surface alerts.
UserPromptSubmit runs when the user submits a message. This is where you inject context automatically, like reading a memory file or loading relevant configuration based on keywords in the message.
A minimal power-user hook setup:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [{
"type": "command",
"command": "bash .claude/hooks/safety-check.sh"
}]
}
],
"PostToolUse": [
{
"matcher": "Write|Edit",
"hooks": [{
"type": "command",
"command": "bash .claude/hooks/post-write.sh"
}]
}
]
}
}
The safety-check.sh script reads the tool input, checks for blocked commands, and exits non-zero to block the action. The post-write.sh script runs linting and logs the file path. Both are under 20 lines of bash.
The key insight: hooks handle the rules you cannot afford to rely on Claude's interpretation for. For a complete reference on all twelve lifecycle events and configuration patterns, see our Claude Code hooks guide.
Layer 4: Subagents for context isolation
A subagent is a Claude Code instance with a scoped system prompt, restricted tool access, and its own memory. You use subagents when a task is either too large for one context window or too specialised to risk cross-contaminating with the main session.
The use cases that push developers toward subagents:
Long-running background tasks. While you work on feature A, a subagent reviews test coverage on the entire codebase, produces a report, and writes it to a file. You read the report when you are ready. No waiting, no context sharing.
Quality gates. An auditor subagent has access to your style guide, your voice rules, and your test suite. It reviews every PR description and returns a verdict. Because it reads only what it needs, its verdicts are consistent.
Parallel investigation. You are debugging a performance issue. One subagent investigates the database query layer, another investigates the rendering layer. Both write their findings to separate files. You synthesise.
Subagent definitions live in .claude/agents/ as Markdown files with YAML frontmatter:
---
name: auditor
description: Reviews code and PR descriptions for quality, style, and test coverage
tools: [Read, Bash]
---
You are a code quality auditor. You review code changes against the rules
in .claude/knowledge-base.md. You have read-only access. You never modify files.
When your review is complete, write the verdict to .claude/logs/audit-{date}.md.
The tools restriction is load-bearing. An auditor that cannot write files cannot accidentally change your code. Tool restriction is how you make subagents safe to run without supervision. For more on the subagent architecture, see our Claude Code subagents guide.
Layer 5: Multi-window and worktree workflows
The most productive power users run two to three Claude Code windows simultaneously. This is not multitasking at the human level. The windows are isolated and each handles a discrete task. You review output from one, provide direction to another, and let the third run unattended.
Git worktrees make this safe. A worktree is a separate working directory linked to the same git repository. Each Claude Code window works in its own worktree, so changes in one window do not affect the working tree of another.
The setup:
# Create worktrees for parallel work
git worktree add ../project-feature-a feature-a
git worktree add ../project-bugfix bugfix/login-issue
# Open Claude Code in each
cd ../project-feature-a && claude
cd ../project-bugfix && claude
Each Claude Code instance reads its own CLAUDE.md (same file via the repo) but maintains its own session state. They do not interfere with each other.
The workflow pattern that works well: one window for active feature work where you are in the loop, one window for a long-running background task (test generation, documentation, research) that you check periodically. The background window runs with fewer interruptions and you context-switch at natural boundaries rather than being pulled away mid-thought.
Worktrees pair well with the subagent pattern: the background window itself can spawn subagents for parallelism within its own task. For the mechanics of this workflow, see our Claude Code worktrees guide.
Persistent memory across sessions
The single most underused feature in Claude Code is persistent memory. Without it, every session starts cold. You re-explain the codebase structure. Claude re-discovers the patterns it identified last week. The tenth session is as slow as the first.
With persistent memory, sessions compound. A .claude/memory.md file written at the end of each session becomes the cold-start context for the next one. An agent memory directory (/.claude/agent-memory/) persists per-agent learnings across all sessions that agent participates in.
The memory protocol that works at power-user level:
At the end of every significant session, write a brief summary to .claude/memory.md: what was worked on, what decisions were made, what patterns were discovered, what is incomplete. Cap the file at 100 lines. Prune stale entries ruthlessly. A 100-line memory.md read at the start of every session is worth more than a 400-line one that Claude skims.
Agent memory is different. Where memory.md is session context (what happened recently), agent memory is calibration (what the agent has learned about this project over time). An auditor agent that remembers which rules are frequently violated produces more targeted reviews than one starting fresh.
The rule that unlocks compounding: "Read .claude/memory.md before starting any task" in your CLAUDE.md. Without that instruction, memory exists but never gets read. With it, the file becomes the handoff document between every session. For a full guide to building a persistent memory system, read Claude Code memory systems.
Automation pipelines that run without you
The end state of the power-user setup is workflows that run autonomously: triggered by a hook, executed by a subagent, verified by another hook, with output written to a file you read when convenient.
Three pipelines worth building:
Post-commit review. A PostToolUse hook on Bash detects git commit commands and triggers an auditor subagent that reviews the diff. The auditor writes a verdict to .claude/logs/. You see it when you open Claude Code next.
Daily test run. A scheduled task (cron or your CI provider) triggers Claude Code with a testing skill. It runs the full suite, identifies new failures, investigates the most likely causes, and writes a brief report. You start the day with context on what broke overnight.
Documentation sync. After merges to main, a hook triggers a subagent that reads the changed files and updates the relevant sections of your project documentation. Not a full rewrite: a targeted update. Documentation that cannot be kept current manually stays current automatically.
Building these pipelines requires the earlier layers to be solid. Hooks need to be reliable. Subagents need scoped, consistent prompts. Memory needs to be current. The automation layer is not a shortcut past the foundational work. It is the reward for doing the foundational work well.
The compounding return
Every layer in this setup has a multiplier effect on the others. Skills make subagents more capable. Hooks make skills more reliable. Multi-window workflows let you run more subagents in parallel. Memory makes all of it faster to resume.
The developers who get the most out of Claude Code are not the ones who issue the most impressive single prompts. They are the ones who have invested in the configuration layer so that Claude's defaults match their project's reality. The setup takes time upfront. The payback is measured in hours per week, compounding across every session.
Start with the CLAUDE.md restructure. Add one skill. Wire one hook. Then build from there.
Sources:
More like this
Ready to upgrade your Claude Code setup?
Get Claudify