AI chatbot app rules: AGENTS.md, CLAUDE.md & Cursor rules
AI chat apps leak API keys and run up bills when the model call happens in the browser. These rules put the key on the server and a ceiling on spending.
Stack these rules assume: Web front end + a small server route that calls an LLM API. Different stack? Customize it in the generator.
Quick start
- Copy the
AGENTS.mdbelow into your project's root folder. - Fill in the three
[bracketed]lines under "Project". Delete any rule that doesn't fit. - Start your first chat with: "Read AGENTS.md and follow it for this whole session."
AGENTS.md (works across tools)
Read by OpenAI Codex, Cursor, GitHub Copilot, Claude Code (when there's no CLAUDE.md) and many other agents.
# AGENTS.md: AI chatbot app
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Web front end + a small server route that calls an LLM API
- Version 1 only needs to: [the ONE thing it must do]
## Commands
- Run locally (or your framework's dev command): `npm run dev`
## Project rules
- Call the LLM API only from server code. The API key never reaches the browser.
- Keep the model name and settings in one config place. Use the exact model ID I give you. Don't invent model names.
- Set a max output tokens value, and limit message length and requests per user.
- Show a clear error message when the API fails or rate-limits. Never show raw error objects to users.
- Don't log full conversations with personal data unless I ask. If we log, say where and for how long.
- Keep the system prompt in its own file so I can edit it without touching code.
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
Want a step-by-step kit?
Our paid templates ($6 to $9) add a full prompt sequence and a worked example on top of rules like these, for games, Discord bots, email triage, MVPs and fixing messy code.
Why each rule exists
- AI chatbot app ruleCall the LLM API only from server code. The API key never reaches the browser.Why: A key in front-end code can be copied by anyone and used on your bill.
- AI chatbot app ruleKeep the model name and settings in one config place. Use the exact model ID I give you. Don't invent model names.Why: Model names change often, and AI tools happily make up ones that don't exist.
- AI chatbot app ruleSet a max output tokens value, and limit message length and requests per user.Why: Without limits, one user (or bot) can spend your monthly budget in an afternoon.
- AI chatbot app ruleShow a clear error message when the API fails or rate-limits. Never show raw error objects to users.Why: Raw errors can leak internals and confuse users.
- AI chatbot app ruleDon't log full conversations with personal data unless I ask. If we log, say where and for how long.Why: Chat logs are sensitive. Collect only what you need.
- AI chatbot app ruleKeep the system prompt in its own file so I can edit it without touching code.Why: You'll tune the prompt far more often than the code.
- How to workDo one task per request. If my request is really several tasks, list them and do only the first.Why: Big multi-part requests are where AI tools change 12 files and you can't tell which change broke things.
- How to workBefore writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.Why: A plan you can read in 10 seconds catches the wrong approach before it costs you an hour or a pile of credits.
- How to workMake the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.Why: Drive-by "cleanups" are the #1 cause of "it was working yesterday".
- How to workAsk before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.Why: These are the changes that are hard to undo. One quick question is cheaper than a rollback.
- How to workIf you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.Why: AI tools confidently invent functions and config options. Making it check is the cure.
- How to workNever say something works unless you ran it or I confirmed it. Report errors exactly.Why: "Should work now" isn't a test result. You want facts, not optimism.
- How to workSecrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.Why: Leaked keys get found by bots within minutes of a public push. This rule is the cheapest insurance you'll ever buy.
- How to workNever run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.Why: One bad command can delete the only copy of your work.
- Finish every task withWhat changed, how to test it, and a commit message.Why: This turns every task into a checkpoint: you test it, you commit it, and you always have a last good version to go back to.
Use it as CLAUDE.md (Claude Code)
Pick one:
- Do nothing. Current Claude Code versions read
AGENTS.mdwhen the project has noCLAUDE.md. Run/memoryin a session to check it loaded. - Import it (best if you want Claude-only extras, or you're on an older Claude Code). Create
CLAUDE.mdnext toAGENTS.md:
@AGENTS.md
## Claude Code
- Use plan mode before any change that touches more than 3 files.
- Claude only? Save the same AGENTS.md text as
CLAUDE.mdinstead. Don't keep two separate copies; they drift apart.
Heads-up: if a project has both files and CLAUDE.md doesn't import AGENTS.md, Claude Code reads only CLAUDE.md by default. More in AGENTS.md vs CLAUDE.md.
Use it as Cursor rules (.cursor/rules/*.mdc)
Cursor reads AGENTS.md too, so the file above already works. If you prefer Cursor's own Project Rules, split it into two .mdc files. The .mdc extension and frontmatter are required; Cursor ignores plain .md files in .cursor/rules.
---
description: Project overview and working rules for AI chatbot app
alwaysApply: true
---
# AI chatbot app
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Web front end + a small server route that calls an LLM API
- Version 1 only needs to: [the ONE thing it must do]
## Commands
- Run locally (or your framework's dev command): `npm run dev`
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
The project rules only attach when a matching file is in the chat (globs with alwaysApply: false). Want them on all the time? Change it to alwaysApply: true.
---
globs: **/*.ts, **/*.tsx, **/*.js, **/*.py
alwaysApply: false
---
# Project rules: AI chatbot app
- Call the LLM API only from server code. The API key never reaches the browser.
- Keep the model name and settings in one config place. Use the exact model ID I give you. Don't invent model names.
- Set a max output tokens value, and limit message length and requests per user.
- Show a clear error message when the API fails or rate-limits. Never show raw error objects to users.
- Don't log full conversations with personal data unless I ask. If we log, say where and for how long.
- Keep the system prompt in its own file so I can edit it without touching code.
Use either AGENTS.md or these .mdc files, not both, so you don't send the same rules twice. See Cursor rules vs AGENTS.md.
Use it in Lovable or Bolt
Browser builders don't read files from your computer, so paste the rules into the project's persistent instructions:
- Lovable: Project settings → Knowledge (up to 10,000 characters). This version is 2,017 characters. If your Lovable project is connected to GitHub, Lovable's docs say it also reads a root-level
AGENTS.md. - Bolt: Project settings → Knowledge.
This version drops the Commands section, since the builder runs the project for you.
# Project rules: AI chatbot app
Instructions for AI coding agents working on this project. Replace anything in [brackets].
## Project
- What it is: [one sentence: what you are building and who it is for]
- Stack: Web front end + a small server route that calls an LLM API
- Version 1 only needs to: [the ONE thing it must do]
## Project rules
- Call the LLM API only from server code. The API key never reaches the browser.
- Keep the model name and settings in one config place. Use the exact model ID I give you. Don't invent model names.
- Set a max output tokens value, and limit message length and requests per user.
- Show a clear error message when the API fails or rate-limits. Never show raw error objects to users.
- Don't log full conversations with personal data unless I ask. If we log, say where and for how long.
- Keep the system prompt in its own file so I can edit it without touching code.
## How to work
- Do one task per request. If my request is really several tasks, list them and do only the first.
- Before writing code, give a 3-line plan: what you'll change, which files, and how I'll test it.
- Make the smallest change that works. Don't refactor, rename, or reformat code I didn't ask about.
- Ask before adding a dependency, deleting or moving files, changing the data/database structure, or touching more than 3 files.
- If you're not sure a library, API, or setting exists in the version we use, say so and check the installed package or the docs instead of guessing.
- Never say something works unless you ran it or I confirmed it. Report errors exactly.
- Secrets (API keys, tokens, passwords) live only in environment variables or a .env file listed in .gitignore. Never print, hardcode, or commit them.
- Never run destructive commands (rm -rf, git reset --hard, force-push, dropping tables) without asking first.
## Finish every task with
1. What changed (list the files).
2. How to run or test it in under a minute, and what I should see.
3. A suggested git commit message.
Building this in a browser app builder? These rules work as Project Knowledge in both. Try Lovable · Try Bolt
Disclosure: the Bolt link is an affiliate (referral) link. If you sign up or buy through it, VibeKits may earn a commission at no extra cost to you. The Lovable link is a plain link. It never changes our pick.
Related
- Lovable vs Bolt vs Replit for beginners (honest picks, real prices)
- AGENTS.md, CLAUDE.md and Cursor rules formats explained