Most people let Claude read multiple files directly in the main session. This quickly bloats the context window and reduces reasoning quality. Advanced users delegate research to subagents, but they don't do it with a text rule anymore. They define the subagent as a real, reusable agent.
Why it works: Subagents run in their own isolated context window with their own system prompt, tool permissions, and model. The main session only ever sees the final summary, never the intermediate file reads. Your primary context stays focused on decision-making while the research happens off to the side.
How to implement it: Run /agents inside Claude Code and create a project-scoped agent. It lives as a Markdown file in .claude/agents/ (or ~/.claude/agents/ for all projects), so it's version-controlled and shareable with your team:
---
name: researcher
description: Explores the codebase and returns structured summaries.
Use proactively for any task that requires reading multiple files.
tools: Read, Glob, Grep
model: haiku
---
You are a research agent. Explore the files relevant to the task,
then return ONLY a structured summary: key findings, relevant file
paths, and open questions. Never return full file contents.Restrict the tool list to read-only tools so the agent can analyze but never modify anything, and run it on a cheaper model since research doesn't need your strongest one.
Most people stuff every rule into CLAUDE.md: project rules, context rules, workflow rules, all of it. The higher-leverage approach is treating CLAUDE.md as one of four surfaces and routing each rule to the one that actually enforces it.
Why it works: CLAUDE.md is guidance, not enforcement. Claude can drift from it in long sessions. When a rule lives on the surface designed for it, it either can't be broken or gets loaded exactly when needed instead of sitting in context all session.
How to implement it: Use this routing map:
| The rule is... | Put it in... |
|---|---|
| Must be enforced, no exceptions | Hooks or permissions |
| Contextual knowledge, used sometimes | Skills |
| A delegation boundary | Subagent definitions |
| Always-on project guidance | CLAUDE.md (keep it SHORT) |
Your old "never load more than 3 files into the main session" rule becomes a delegation boundary baked into the researcher subagent from Technique 1. What stays in CLAUDE.md: architecture notes, conventions, and compact instructions so auto-compression preserves what matters:
## Compact Instructions
When summarizing this conversation:
- Preserve all API changes and their rationale
- Keep error messages and their solutions
- Maintain the list of modified filesThen audit what's left. A shorter CLAUDE.md is loaded every session, so every trimmed line is tokens saved on every single run.
Instead of asking Claude to critique its own work inside the same conversation, advanced users build verification into the system so output gets checked before it ever reaches them.
Why it works: Self-critique in the same session has a flaw: Claude is grading its own homework, inside the same context that produced the mistakes. A separate verification step runs with fresh eyes and its own system prompt, isolated from the main conversation's bias. And when verification is gated rather than prompted, it can't be skipped.
How to implement it: Three levels, in order of power:
1. Objective targets. Give Claude tests or expected output to verify against, so success is measurable instead of a matter of opinion.
2. A verifier subagent. Define a second agent (like the researcher in Technique 1) whose only job is reviewing work against your criteria:
---
name: verifier
description: Reviews completed work before it is presented.
Use after any implementation task.
tools: Read, Glob, Grep, Bash
---
Check the work against: 1) Does it fully meet the original request?
2) Are there gaps or unstated assumptions? 3) Do the tests pass?
Return a verdict: APPROVED or a specific list of fixes.3. Gate it with a hook. A SubagentStop hook fires when a subagent finishes, so you can programmatically check its output and send it back for revision until it meets your rubric. At this point, quality control isn't a request you make. It's a property of the system.
The pattern across all three: what used to be prompt tricks is now architecture. You don't ask Claude to behave a certain way, you build a system where that behavior is the default.