Symptom: Claude Code changes files you did not ask it to touch.
Fastest fix: use CLAUDE.md to define scope, require a plan, request the smallest necessary diff, and demand an honest verification report.
This approach suits developers using Claude Code who need tighter change boundaries, technical leads writing project guidance, and engineers adapting ideas associated with Andrej Karpathy Skills. It reduces the chance of unwanted edits; it does not guarantee compliance or isolate permissions.
Start with the limits of CLAUDE.md
CLAUDE.md is a place to give Claude Code project instructions. Claude Code can use those instructions to understand conventions and expectations while working in your repository. Anthropic’s memory documentation explains project memory files and how Claude Code uses them.
That makes CLAUDE.md useful for directing behavior, not for enforcing a hard boundary. A sentence such as “Do not edit files outside this directory” asks Claude Code to follow a rule. It does not make those files inaccessible. If the task calls for a technical block, review Claude Code’s permission controls and configure controls appropriate to your workflow.
Keep these distinctions clear:
| Mechanism | What it is useful for | What it does not guarantee |
|---|---|---|
| CLAUDE.md | Project-specific guidance about scope, conventions, and expected workflow | That every instruction will be followed or that restricted files cannot be touched |
| Skills | Reusable instructions or workflows that can be made available for relevant tasks | Permission enforcement or automatic correctness |
| Permissions | Configured controls over tool actions | That the task instructions are clear or the resulting code is correct |
| Hooks | Actions tied to supported lifecycle events | A replacement for reviewing the change and its test results |
The official Skills documentation describes Skills as a separate feature from project memory. Treat them as distinct layers: CLAUDE.md can state the project’s standing rules; a Skill can provide a reusable workflow; permissions govern whether particular actions are allowed. Neither a well-written instruction file nor a reusable workflow is a substitute for configured access controls.
Treat instructions as guidance and permissions as controls. If an edit must be impossible without approval, do not rely on wording in CLAUDE.md alone.
Separate the Karpathy reference from your project rules
The title’s Andrej Karpathy Skills reference should not lead you to present this article’s four rules as his exact wording or as an official Claude Code standard. Karpathy’s original post is the primary source for what he said. The repository associated with the Skills discussion is a separate project, not Anthropic documentation. Verify any quotation or attribution against the original source before repeating it.
For your project, the useful step is not to copy a name or presume a particular set of rules is universal. Write instructions for the codebase and work your team actually performs. Keep the file specific enough to guide a task, but do not make it a pile of generic demands that compete with repository conventions.
Anthropic’s Claude Code best practices also provide context for working effectively with the tool. The rules below are practical project guidance. They are not a claim that the official documentation guarantees a particular result.
Apply the four rules in a controlled sequence
Rule one: define the allowed change
Say what outcome you want, which files or directories are in scope, and what Claude Code should leave alone. Make the boundary operational. “Keep the change focused” is less useful than naming the relevant area and requiring a pause before expanding it.
For example, adapt this instruction to the repository:
For this task, edit only the files needed to implement the requested behavior in the relevant feature area. Do not perform unrelated refactoring, dependency updates, formatting changes, or configuration edits. If you believe an out-of-scope change is necessary, explain why and ask before making it.
This wording helps Claude Code distinguish the requested work from adjacent opportunities. It cannot identify every possible boundary for you. If you do not know which files should change, ask it to inspect the repository and propose likely files first. Confirm the scope before implementation when that inspection reveals a broader change than you intended.
This rule directly addresses the search intent of limiting edits to specified files. You can name exact files for a narrow task, or describe an area when the implementation path is not yet known. If you name a directory, clarify whether changes to tests, documentation, or related configuration are allowed.
Rule two: require a plan before edits
Ask Claude Code to summarize its understanding, list the intended changes, and describe how it will check the result. A plan gives you a chance to catch a misunderstanding before code changes begin. It does not prove that the plan is sound or that execution will match it.
A practical instruction is:
Before editing, summarize the requested outcome, identify the files you expect to change, and describe the repository-supported checks you will use. Pause for confirmation if the scope is unclear or your plan requires files outside the agreed boundary.
For a small bug fix, the exchange should proceed in order: Claude Code explains the behavior it believes is wrong, identifies the likely implementation and test locations, and proposes an applicable check. You review that proposal. If it is within scope, ask it to proceed; if it includes a wider refactor, reject or narrow the plan first.
Plans are most valuable where task scope is uncertain or the consequences of an unintended edit are high. For a tiny, well-defined change, a brief plan may be enough. Avoid turning planning into a ritual that adds no useful information: the goal is to expose assumptions, not to create lengthy reports.
Rule three: keep the diff as small as the task allows
Ask for the minimum change that solves the request, using the project’s existing patterns. Make clear that “clean up while you are there” is not permission to restructure unrelated code, replace dependencies, or reformat entire files.
After implementation, inspect the file list and diff. Check whether each changed file supports the requested outcome. Look for unrelated formatting, renamed symbols, changed configuration, or extra abstractions that were not part of the agreed plan. A compact diff is easier to reason about, but small is not automatically correct: include necessary tests or supporting changes when the task genuinely requires them.
| Review question | Acceptable signal | Pause and investigate |
|---|---|---|
| Do changed files match the agreed scope? | Each file has a clear connection to the task | An unrelated module or configuration file appears |
| Does the diff implement the requested outcome? | The edits are focused and follow local patterns | The change introduces an unrequested redesign |
| Are necessary supporting changes included? | Relevant tests or documentation are updated when needed | The implementation appears incomplete to keep the diff short |
| Does the final report match the diff? | The summary describes actual edits | The report claims work that the diff does not show |
Compare the plan with the final diff, not just the assistant’s summary. If the file list expanded, ask what requirement caused the expansion. If there is no clear reason, revert or separate the unrelated change before review.
Rule four: require honest verification
Tell Claude Code to use checks that already belong to the project and to report what it actually ran. Do not invent a test command or assume a project uses a particular framework. Ask it to inspect the repository’s documentation, scripts, or CI configuration when the right check is unclear.
A useful instruction is:
Run the applicable checks already documented or configured for this repository. Report each check you ran and its actual result. List checks you did not run and explain why. Do not claim that code is verified when no relevant check was executed.
A useful report distinguishes among a check that passed, one that failed, and one that was not run. It should also identify limitations: for example, whether the project’s documented check could not be run in the current environment. “Looks good” is not a test result. Nor should an instruction file force Claude Code to report success when it has not confirmed the outcome.
If your workflow needs automatic actions at specific tool events, assess whether Claude Code hooks fit that requirement. Hooks are a separate mechanism from CLAUDE.md instructions. Do not describe them as a general permission system; choose and configure controls according to the behavior you need to enforce.
Check whether the rules reduce unwanted edits
Test the file against a small task with a clear outcome and a reviewable boundary. Before starting, record the allowed area and the checks the repository supports. Ask Claude Code to plan, make the requested change, and report verification. Then compare the actual work against those expectations.
Review four things:
- Files: Did Claude Code change only the agreed files, or explain and seek approval before expanding scope?
- Diff: Does each edit contribute to the task, without unrelated refactoring or formatting?
- Plan: Did implementation follow the proposed approach? If not, is the deviation explained and justified?
- Verification: Does the report say what ran, what happened, and what was skipped?
If the behavior is unclear, revise the instruction rather than adding more vague prohibitions. Replace “avoid unnecessary edits” with an explicit boundary and a pause condition. If two instructions conflict—for example, “change only this file” and “update the relevant tests”—decide which rule takes precedence. Repeat the review after the edit to see whether the revised wording made the expected behavior easier to assess.
Use this application checklist before sharing CLAUDE.md with a team:
- The task boundary says what may change and what should remain untouched.
- Scope uncertainty or a need for out-of-scope work triggers a request for confirmation.
- A short plan identifies expected files and applicable checks.
- The minimal-diff rule allows changes necessary to complete the task.
- Verification instructions require actual results and disclose skipped checks.
- No instruction implies that CLAUDE.md itself blocks access or guarantees compliance.
A good CLAUDE.md makes expectations easier to repeat and violations easier to spot. It does not replace code review, version control, or permissions configured for actions that require enforcement.
If you want to evaluate the rules on a temporary macOS development setup, decide first whether remote hardware is actually needed. A local environment avoids remote access and connectivity overhead; rented hardware can avoid buying a Mac for a short-lived test, but adds setup and remote-workflow considerations and does not improve CLAUDE.md compliance. You can review Kvmkit’s Mac options or a Mac mini rental option if that environment fits your project. For the instruction test itself, start with the smallest task you can review and use the checklist to decide whether your existing rules are precise enough.
FAQ
How can I keep Claude Code from editing files outside my task?
State the task outcome and the files or directories Claude Code may change in CLAUDE.md, and tell it to stop and ask if it discovers a required change outside that scope. Then inspect the actual diff. This is a behavioral instruction, not a file-system barrier; use permission settings or other controls when you need technical enforcement.
What should a project CLAUDE.md say to prevent unrelated code changes?
Give it actionable rules: define the task boundary, require a short plan before edits, ask for the smallest change that solves the request, and require a truthful report of relevant checks. Add project-specific conventions only when they are supported by the repository. Avoid vague commands such as “make the code better,” which invite broad interpretation.
Can CLAUDE.md stop Claude Code from making changes without approval?
No. CLAUDE.md supplies project instructions, but you should not treat it as an approval gate or a permission boundary. Tell Claude Code to pause when scope is uncertain, then configure tool permissions or other appropriate controls for enforcement. Review the proposed action and the resulting diff before accepting changes that matter.
How do I require Claude Code to verify its code changes?
Tell it to identify and run the checks that the repository already documents or uses, then report exactly what it ran and what happened. Require it to explain checks it skipped and why. Do not put an invented test command in the instruction file; first inspect the project’s existing scripts, contribution guidance, and CI configuration.