Keep the instructions that describe your project and test whether the rest still help. Austin Marchese’s response to Boris Cherny’s advice to delete old customizations adds a useful limit: preserve intentional boundaries. Back up the setup, change one part, and compare the results before keeping the edit.
01Keep the fixed requirements
Anthropic reported removing more than 80 percent of Claude Code’s system prompt for Claude 5 models without measurable loss on its coding evaluations. That result concerns Anthropic’s tasks. Your approval rules and client requirements need their own assessment.
Duncan Rogoff’s walkthrough introduced this guide’s pruning method. Marchese’s later video supplies the distinction to apply before removing a line:
| Instruction describes | What to do |
|---|---|
| A fixed requirement, such as approval before sending a report | Keep it; preserve the permission controls that enforce it |
| A project fact the model cannot infer, such as why a dependency stays pinned | Keep it near the work that needs it |
| A style preference expressed as an absolute, such as never using lists | State the reader’s need and when the preference applies |
| A workaround for an old model error | Test the task without that workaround |
| Two conflicting directions | Resolve which applies, then remove or narrow the other |
“Do not delete intentional boundaries.”
Austin Marchese, “The REAL Reason The Creator of Claude Code Told You To Delete Everything” · 10:44Stop shouting at the model covers overly forceful wording. Keep instructions backed by recurring failures, as described in Turn repeated fixes into rules. For actions with consequences, Assume your agent uses every tool it has explains why written limits need tool restrictions too.
02Keep examples with a purpose
At 7:09, Marchese suggests replacing rigid examples with a description of the result needed. He also keeps examples for work that must follow an established format. A monthly report may need the same columns because another system imports them.
For an open-ended report, state the decision it should support, the source data, and how claims should be checked. For a fixed report, include its approved template. Label which parts of an example are required and which the model may change.
The following is an original prompt for reviewing instructions, not a prompt transcribed from the video:
Review this report-writing skill without editing it. Separate fixed requirements, project facts, preferences, repeated instructions, and possible outdated workarounds. Cite the file and line for each finding. Preserve required fields and approval boundaries. For each proposed change, name a task and a check that would reveal whether the change made the result worse. Return a proposed diff for review.
Use Brief the model like a brilliant new hire when the missing information is the task itself. Instruction cleanup cannot supply a goal nobody has stated.
03Load detail when work needs it
Keep frequently needed project facts in CLAUDE.md. Put occasional procedures in a skill or a separate reference file with a clear condition for reading it. Expertise you can install covers how those procedures are packaged.
For example, the standing file can say: “Before writing customer-facing copy, read docs/writing-style.md.” Test a writing request afterward to confirm the agent opens the file.
An @path import behaves differently: Claude Code expands imports at startup. Splitting one large instruction file into several imported files organizes the text but still loads it. Stop hitting your token limit covers budgeting that context.
Auto memory is another source of context. Use /memory to inspect its settings and saved notes. Keep deliberate project instructions under review even when automatic note-taking is enabled; Audit what your agent saved to memory covers duplicate and stale notes.
04Name the check that proves done
At 9:45, Marchese argues that a generic instruction to verify may repeat behavior the model already attempts. His practical recommendation is to specify how this particular output should be verified.
For a report, name the source totals that must match. For code, name the relevant test command and expected result. Anthropic’s best practices still recommend giving Claude runnable checks and asking for evidence. An agent saying it verified something leaves the result unproven until you can inspect that evidence.
Keep a check that catches an observed failure. Remove repeated checking only after establishing that both checks cover the same requirement. Make skills improve after each run covers testing those edits against earlier failures.
05Compare before keeping the edit
Marchese proposes comparing an old setup, a revised setup, and a run without customizations. He later says he usually skips measurement. Our recommendation is to keep a small comparison: a shorter file alone cannot show that the work improved.
Use fresh sessions, the same model, identical input files, and the same completion checks. Record correctness, manual repairs, elapsed time, and cost when available. Repeat a close or inconsistent result before drawing a conclusion. Compare AI agents on your own work develops this method.
The documented terminal command is:
claude --safe-mode
Safe mode disables customizations, including instruction files, skills, hooks, MCP servers, and auto memory. Normal permissions still apply. Because custom hooks and tools disappear too, use a disposable copy and a task that needs no external actions. Treat this run as a configuration diagnostic; it changes more than the instructions.
For the old-versus-revised comparison, keep tools and permission controls unchanged. Anthropic also recommends /doctor for instruction and skill cleanup. Read its findings as candidates to test; the report cannot decide which client requirements still apply.