🚫 Never mass-delete without review
Commands that delete several folders or files at once always call for plan mode (module 0.5) and careful review before approval. This is the most costly and hardest-to-undo category of mistake in the entire course.
New here? This module closes Track 0 by discussing permission — the permission you grant (or deny) before the agent runs something. So far, you’ve learned to install the terminal (the text window where you type commands — short instructions the computer runs right away), setting up the project folder, and writing CLAUDE.md; now you’re learning to say “no” at the right time. Think of it as giving someone you trust the key to your house: you hand it over gradually, starting with the rooms that pose no risk.
⚠️ Attention
If the plan includes the word “delete,” “erase,” or “remove” for more than one file, stop and read carefully before approving—no exceptions.
🩹 Common error
Approving a plan “out of fatigue,” just to move faster, without actually reading the lines that mention deleting things. If you feel that rush, close the terminal (the command window), take a breath, and come back later—the agent can wait; it has no deadline.
Let’s reinforce why this category differs from the other two ("production" and "publishing"): deleting files is an action that happens only on your computer, without going through any external server — so it’s easy to think it’s "less serious." In practice, the opposite is true: if you don’t have a backup (a copy stored somewhere else), a file deleted by mistake may be gone for good. Carefully reviewing the plan here is the cheapest habit in the entire course compared with the damage it can prevent.
🏭 Never change production without a review
New here? Production is the "live" environment, used by real people — unlike a test environment, which is isolated and has no real consequences. This topic is covered in more depth in Track 4, but the golden rule starts here: never change production without reviewing it first.
🔍 Inside
Production × testing is the same logic as “draft × final version” — making a mistake in the draft costs nothing; making one in the final version does.
💡 Practical Tip
If you still can't tell test from production in your own project, treat everything as production until Track 4 explains the separation—that's the safest option.
New here? One file is any document saved on the computer (text, image, a snippet of code); a folder is the "envelope" that organizes several files together. When the agent "works in production," it's changing files that are already live — not a test copy stored only on your computer.
🔧 Common error
Ask to "update the site" without saying which environment, and the agent assumes you mean the live site. Simple fix: always name the target — "update the test version, not the published one" — and check this rule in your CLAUDE.md.
A practical way to never get this wrong: before asking for any change, ask the agent itself, "will what I'm asking change something that's already published, or will it stay in testing?" Having the agent answer that question out loud (in writing, in the conversation) forces it to check the context before acting—and forces you to read the answer before approving.
📢 Never publish without explicit approval
Make it clear in your CLAUDE.md that nothing goes live — site, post, email — without your explicit approval. A rule written in the file is read every session (module 0.4) and prevents accidental publication.
Objective: prevent accidental publishing. How to verify: ask for a task that would "publish" something and confirm that the agent stops and asks before acting.
"Publish" here means any action that leaves your computer and becomes visible to other people: putting a page online, sending an email, posting on social media. The rule applies even when the agent has the technical access to do this on its own — having access isn't the same as having authorization.
This precaution becomes even more important when Tracks 4 and 6 teach you to have the agent work on its own, on a schedule, with no one watching at the time. An automation that runs overnight and publishes something wrong is much harder to fix than an error caught right away — so the rule written in CLAUDE.md still applies even when no one is monitoring it live.
✓ Expected behavior
- ✓Agent puts together the draft and shows it before sending
- ✓Agent asks "can I publish this?" and waits for a response
✗ Warning sign
- ✗Agent says "I've published it" without asking first
- ✗You don’t remember approving that submission
✅ Visual summary: authorize upfront × always review
Use this table as a quick reference when a question comes up in the middle of a task.
✓ Authorize upfront
- ✓Read files, list folders
- ✓Create a new file, isolated
- ✓Run a test command locally
✗ Always review first
- ✗Delete more than one file or folder
- ✗Modifying production
- ✗Publish, send, or post anything
💡 Practical Tip
Trust is gradual: start by reviewing everything, then grant more freedom as the agent proves it follows the rules in your CLAUDE.md.
How trust evolves throughout the course
🏁 Track final exercise: create, write, verify
Wrap up Track 0 by putting it all together: create the project, write the CLAUDE.md, and ask the agent to summarize the project itself—the final proof that the environment is ready.
Objective: confirm that the project, CLAUDE.md, and automatic reading are all working together. How to verify: the agent’s answer should cite the objective and rules that match what was written in the file — if they match, Track 0 is complete.
🩹 Common errors in this exercise
- "Command not found": the terminal (the command window) couldn’t find the program
claude— go back to module 0.2 and check whether the installation finished. - Agent doesn't remember CLAUDE.md: confirm that the file is saved in the same folder as the project, not somewhere else on the computer.
- You accidentally closed the terminal in the middle of the conversation: no problem — open the folder again (
cd) and runclaudeagain; CLAUDE.md is read again automatically.
➡️ On to Track 1: the WAT framework
With the terminal installed, the project organized, CLAUDE.md streamlined, plan mode mastered, and the security rules in place, the environment is ready. Track 1 introduces the framework WAT (Workflows, Agent, Tools) — the piece that turns loose requests into real automation.
🎯 Main Concept
- •Track 0: prepare the environment.
- •Track 1: understand how the agent actually makes decisions and acts.
🔍 See inside: what goes where
So far, everything you’ve created—the project folder, CLAUDE.md, test files—lives only on your computer. None of it goes online on its own. Running commands in the terminal has no extra cost, but using the agent typically depends on a plan or credits (see module 0.2)—what changes with this module isn’t the cost, but the risk: publishing something to a paid service only happens with your explicit approval, as you saw in topic 3.
This is why you can complete all of Learning Path 0 in safe mode: you’re practicing at home before opening the door to the world.
💡 Practical Tip
Save this security checklist — the three red lines (bulk deletion, production, publishing) apply to the entire course, not just this track. Revisit this module whenever a new track unlocks a new capability for the agent.
Quick check (optional): Which of these actions should NEVER run without explicit review?