Stop your AI coding agent wrecking your app: the rules file setup

The agent fixed your button. It also rewrote your sign-up page, renamed a database column and “tidied up” your pricing. Nobody asked it to.

That happens because the agent starts every session knowing nothing about your app. It sees code. It doesn’t see that the pricing page is finished, that real people’s data sits in that table, or that you wanted one small change.

A rules file fixes the first half of that problem. It’s a short note the agent reads before every task: what the app is, who it’s for, and what it must never touch.

I’ve built more than 20 web and mobile apps with AI, and the writing system behind this guide runs on a rules file I built with Claude Code. Mine says things like “never write into the website folder”, “never invent prices” and “no em dashes anywhere”. The agent reads it every time, so I don’t repeat myself. If you want help setting up your first build properly, this is where I teach it.

What is a rules file, and why does your agent need one?

A rules file is a plain-English text file that sits in your project and gets read by the AI agent before it works. It carries what the agent can’t guess from the code.

Your prompt covers one task. The rules file covers every task. So you write “don’t touch the payments code” once, not in every message.

This is the same idea as my take on prompting: stop adding roles to your AI prompts and give the AI audience, goal, format, constraints and context instead. A rules file is that context, saved. It shouldn’t open with “You are a senior engineer”. It should open with what your app does and who uses it.

Where does the rules file go in each tool?

Every tool has its own file name and place. Here’s where each one lives. File names and settings checked on each tool’s own docs on 9 November 2026.

1. Claude Code: CLAUDE.md

Put CLAUDE.md in your project’s top folder, or in a .claude folder inside it. Rules you want in every project go in ~/.claude/CLAUDE.md on your computer (Claude Code memory docs).

You don’t have to start from scratch. Type /init and Claude Code writes a first draft from your code. If a CLAUDE.md already exists, it suggests improvements instead of overwriting it.

Anthropic recommends keeping each CLAUDE.md under 200 lines. Longer files use more context and get followed less well.

2. AGENTS.md: one file for many tools

AGENTS.md is a plain Markdown file in your project’s top folder, with no required format (agents.md). Cursor, Codex, GitHub Copilot’s coding agent, Gemini CLI, Windsurf and others read it.

Lovable reads it too. Claude Code reads AGENTS.md when there is no CLAUDE.md, from version 2.1.277 onwards. If you switch between tools, this is the file I’d write first.

3. Cursor: project rules or AGENTS.md

Cursor keeps project rules as .mdc files in a .cursor/rules folder. A plain .md file in that folder gets ignored, which trips people up (Cursor rules docs).

Each rule has a mode: Always Apply, Apply Intelligently, Apply to Specific Files or Apply Manually. For your never-touch list, pick Always Apply.

Rules for every project go in Customize > Rules. Cursor also reads AGENTS.md, so you can skip the .mdc files entirely.

4. Lovable: Instructions

Lovable renamed Knowledge to Instructions. Older guides still say Knowledge (Lovable docs).

Open Project settings > Instructions for one app, or Workspace settings > Instructions for all of them. Each holds up to 10,000 characters. When the two disagree, the project instructions win.

Lovable also reads an AGENTS.md or CLAUDE.md in your project with every message. On paid plans it rewrites or removes outdated AGENTS.md rules unless you asked for the rule.

5. Replit: replit.md

Replit’s Agent reads replit.md from your project’s top folder only, not from subfolders (Replit docs). Agent creates the file for new projects, and both you and Agent edit it as the app grows.

Replit’s docs say very large files may not be fully processed, so keep it short. Replit’s docs only mention replit.md, so put your rules there even if you also keep an AGENTS.md.

What should a non-coder put in a rules file?

Five sections cover most first apps. Write each in the words you’d use with a freelancer on day one.

1. About this app. What it does and who uses it. “A booking app for my yoga classes. Users are my students, most of them on phones.”
2. Never do. The things a mistake would cost you. Deleting or renaming database tables. Changing payment or login code. Changing pages you’ve marked as finished.
3. Ask me first. New packages, new pages, design changes, anything touching user data.
4. How to check your work. “Open the page and test the change before saying it’s done.”
5. How to report back. “Plain English. List every file you changed.”

Keep secrets out. No passwords, no API keys. The file sits with your code.

The “Write my rules file” prompt below builds all five sections from your answers. The prompts in this guide are starting points, not tested recipes, so read what they give you.

Does a rules file stop the agent breaking things?

No, not on its own. Anthropic says Claude treats CLAUDE.md as context, not as enforced settings (Claude Code memory docs). The agent reads your rules and usually follows them. Usually isn’t always.

So pair the rules with brakes that work when the rules get ignored:

• Plan mode. Claude Code, Lovable and Replit all have a plan mode where the agent proposes changes and edits nothing until you approve (Claude Code permission modes, Lovable plan mode, Replit plan mode). In Lovable, each plan mode message costs one credit.
• Permission settings. Claude Code’s default mode asks before every edit and command. Auto mode asks less, and Anthropic says it doesn’t guarantee safety. For a hard block on an action, Claude Code uses permission deny settings or hooks.
• The “Start an autopilot session safely” prompt. It makes the agent list the files it will change and stop before anything on your never-touch list.

How do you undo it when the agent breaks something anyway?

Every tool here keeps earlier versions. Know where the undo button is before you need it.

• Claude Code: it saves a checkpoint before each prompt. Type /rewind or press Esc twice to restore code, the conversation or both (Claude Code checkpointing). Changes made by terminal commands aren’t tracked, and Anthropic says checkpoints don’t replace Git.
• Lovable: open History from the top bar to revert the code. It doesn’t roll back data in your database (Lovable History).
• Replit: click “Rollback to here” in the Agent tab. Your development database only comes back if you tick Database under the extra rollback options, and production databases don’t come back this way (Replit checkpoints).

Notice the pattern. Code comes back easily. Data often doesn’t. That’s why database changes belong on your “Never do” list.

After every rollback, add one rule. The “Turn a mistake into a new rule” prompt below writes it for you.

Which tool should you start with?

If you’ve never built anything, start in Lovable. Security and the database come built in, so your rules file mostly covers design and scope. My comparison of the best vibe coding tools goes through the rest.

If you want help choosing what to build first, start with how to start vibe coding, then read how to ship your first app as a beginner. Write the rules file before your first real feature. And if the problem is ChatGPT or Claude sounding like a bot when you write, that’s a different rules file: stop ChatGPT and Claude sounding like AI.

Help me write a rules file for the AI agent that builds my app.

My app: [what it does, in one or two sentences]
Who uses it: [who, and what they need from it]
The tool I build with: [Claude Code / Cursor / Lovable / Replit]
What scares me: [for example: losing user data, breaking payments, the agent redesigning pages I like]

Write a rules file under 60 lines in plain English with these sections:
1. About this app (what it is, who it's for)
2. Never do (things the agent must never change or delete)
3. Ask me first (changes that need my yes)
4. How to check your work (what to test before saying it's done)
5. How to report back (short, plain English, list the files you changed)

Every rule must be specific enough to follow and check. No vague rules like "write good code". Don't invent features my app doesn't have. If you need to know something, ask me before writing.

Read my rules file below. It's for an AI coding agent that works on my app while I'm not watching every step.

Find:
- rules that are vague or impossible to check
- rules that contradict each other
- risky areas I haven't protected (data, payments, logins, live users)
- anything longer than it needs to be

List the problems first, one line each. Then give me a tightened version under 60 lines. Keep my wording where it works. Don't add rules about things my app doesn't have.

My rules file:
[paste it here]

Before you change anything, read the rules file in this project.

Then:
1. Tell me in 3 lines what you understand the task to be.
2. Write a short plan and list every file you expect to change.
3. If the plan touches anything on the "Never do" or "Ask me first" lists, stop and ask me.
4. Only start once I reply "go".

When you finish, tell me what you changed, what you tested and anything you weren't sure about.

The task: [describe it]

My AI coding agent made a mistake. Help me write one new rule for my rules file so it doesn't happen again.

What I asked for: [your request]
What it did instead: [what went wrong]
What it should have done: [the right behaviour]

Write one rule, one or two sentences, phrased as a direct instruction the agent can follow. Make it specific to this situation. Then tell me which section of my rules file it belongs in.