Some actions are so risky that even good QA doesn't protect you. These are the hard rules - actions you NEVER let Claude do, regardless of how much you trust the workflow . This lesson is the list + why each is on it.

The universal never-do list

1. Never approve ad platform mutations without a written plan

Before Claude pauses, creates, or changes an ad / campaign / ad set:

• Ask Claude to write the plan as a markdown file
• Review the plan yourself
• Approve the plan explicitly
• THEN let Claude execute

No "just pause this one campaign" in the middle of a session. The 2-minute plan review catches mistakes that cost hundreds or thousands in ad spend.

2. Never approve email sends without reading the full email

Never approve a Klaviyo / Mailchimp / any-email-provider send without:

• Reading the exact email content word-by-word
• Confirming the segment is correct (test vs live)
• Confirming the send time
• Confirming the sender name

Sends can't be undone. A draft with placeholder text going to 50,000 customers is a career-altering mistake. 3. Never approve public posts without reviewing the content

Slack, LinkedIn, Twitter, any public channel. Read the exact content. Check the destination. Public posts are permanent - screenshots outlive deletions.

4. Never approve commits containing credentials

Even if Claude says "this commit is safe". Double-check. API keys, passwords, tokens must not hit git history.

Before any commit that includes a .env-adjacent file

Before this commit - scan every staged file for anything that looks like an API key, token, password, or credential. Show me what was found.

5. Never approve rm -rf without confirming the path

Delete operations are asymmetric - easy to do, hard to undo. Before any rm -rf:

• Read the exact path
• Confirm it's inside your project folder (not root, not home directory)
• Confirm you have the data backed up somewhere

One wrong rm -rf can delete months of work.

6. Never approve force push to main without explicit need

Force push rewrites git history. Breaks things for anyone else working in the repo. Loses commits.

If Claude wants to force push, ask why. If the answer isn't "to remove a committed secret" or equally serious, deny.

7. Never approve dropping database tables

Dropping a table = deleting everything in it. Restore is painful if possible at all. If Claude wants to drop a table, have Claude rename it instead (prefix with archive) so you can recover later if needed.

8. Never approve charging credit cards / moving money

Obvious but worth stating. Any integration that can move money (Stripe, bank APIs, crypto) needs extreme caution. Default: deny unless it's a specific pre-approved action.

9. Never approve DNS or domain setting changes without a fallback plan

DNS propagation is slow. A wrong change can take a website offline for hours before you can fix it.

10. Never trust Claude on legal / regulatory content without a lawyer

Privacy policies, terms of service, GDPR disclosures, health claims, financial disclaimers. Claude can draft - a lawyer (or your legal team) must review.

The "am I about to regret this" check

Before any action that feels risky, pause and ask yourself

1. What happens if this goes wrong?
2. How long would it take to fix?
3. Who else is affected?
4. Is there a less risky way to achieve the same thing?

If the answers include "significant time", "many people", or "no less risky way" - treat this as a "never" action and require explicit approval + planning.

Adding never-do rules to CLAUDE.md

Add these to your global CLAUDE.md under a Safety section

Safety NEVER execute ad platform mutations without a written plan I've reviewed. NEVER trigger email sends without me explicitly confirming the segment + content. NEVER commit files containing credentials. NEVER approve rm -rf without confirming the path. NEVER force push to main unless explicitly requested with justification. NEVER drop database tables - rename with archive prefix instead. NEVER move money or charge credit cards autonomously. ALWAYS ask before any action I haven't explicitly authorised.

CAPS improves adherence. Every session loads these rules.

Per-client escalations

Some clients need extra caution. Add to their project CLAUDE.md:

[Client-specific safety]

NEVER publish anything to the client's live domain without explicit client approval first. NEVER change the client's brand assets without going through the approval pipeline. NEVER respond to client emails without me reviewing the draft.

Calibrate safety per project. Higher-stakes clients get stricter rules.

When safety feels like friction

Yes, these rules slow you down. That's the point. Speed without safety is how expensive mistakes happen. Rule of thumb: if following your safety rules takes 2 minutes per action, you save 20 minutes the first time they prevent a mistake. They pay back constantly.

Recovery: when something goes wrong

Despite best efforts, you or Claude will eventually do something you regret. When it happens:

1. Don't panic. Stop the session. /wrapup if safe.
2. Assess: what was done? What's the actual damage?
3. Document: write down exactly what happened + when
4. Fix in order of damage: revert git commits, restore from backup, apologise to clients
5. Learn: what rule would have prevented this? Add it to CLAUDE.md.
6. Move on. Everyone makes mistakes. Learning beats beating yourself up.

Action items

☐ Add the 10 never-do rules to your global CLAUDE.md under a Safety section

☐ Use CAPS for NEVER / ALWAYS keywords

☐ Add per-client escalations where appropriate

☐ When a mistake happens, document + add a rule - every mistake improves the system

☐ Never let "faster" override "safe" on the 10 universal rules

Module complete. Next: Module 15 - Resources + Fixes.

Exercises

1. Review the concepts covered in this lesson: Never let Claude do X.
2. Write down your key takeaway from this lesson.
3. Practice running any commands or prompts mentioned above inside your terminal.