You've described your app, the AI built a first version, and it's mostly right. Then you ask for a second feature and it quietly switches state libraries. A third, and it reformats half the files you'd already settled. None of this is in your prompt. It's just the model filling gaps with its defaults instead of yours.
A prompt is a one-time instruction. What you actually want is a standing one — something the tool re-reads every time it touches your code. That's what AGENTS.md and .cursorrules are for. They're the small files that sit in your repo and tell the AI the rules of your project before it writes a single line.
The difference between a prompt, a rules file, and a spec
These three get muddled constantly, so it's worth separating them, because they do different jobs and you want all three.
A prompt is the thing you type right now: "add a settings page." It's specific and disposable.
A rules file (AGENTS.md or .cursorrules) is the standing context the tool loads automatically on every prompt: "this project uses TypeScript, Tailwind, and Supabase; never add a new state library; tests live next to the file they test." You write it once and it shapes every prompt after.
A spec is what the app is: the one-paragraph description, the ranked feature list, the data model, what you're explicitly not building. If you're fuzzy on the difference between these documents, the PRD-vs-spec-vs-brief breakdown is the short version.
The rules file answers "how should you build?" The spec answers "what are we building?" The prompt answers "what next?" Skip the rules file and the AI re-invents your conventions every session. Skip the spec and it re-invents the product.
What is .cursorrules
.cursorrules is Cursor's project-rules mechanism — a file (or, in newer Cursor versions, a set of files under .cursor/rules/) that the editor injects into the model's context on every request inside that project. You don't paste it each time; Cursor reads it for you.
The point is durable, repo-specific instruction. Good things to put in it:
- Stack and versions. "React 18, TypeScript strict, Vite, Tailwind. No Next.js — ignore any 'use client' suggestions." Models love to assume Next.js; one line stops a category of wrong output.
- Conventions the AI keeps breaking. Import ordering, where shared code lives, naming patterns, "use the
toastfrom sonner, not a custom one." - Hard "never" rules. "Never edit generated type files." "Never commit secrets." "Never add a dependency without asking."
- How to verify. "After changing a
.tsfile, runnpm run lint." Telling the agent how to check its own work is one of the highest-leverage lines you can write.
Keep it short and imperative. A rules file that runs to three screens gets diluted; the model weights a tight, declarative list far more reliably than a wall of prose.
What is AGENTS.md
AGENTS.md is the tool-agnostic version of the same idea: a plain-markdown file at the root of your repo that gives any AI coding agent its standing instructions. The pitch is simple — instead of one proprietary rules format per tool, you keep a single AGENTS.md that travels with the codebase, and whichever agent you point at the repo reads it.
In practice it tends to hold the same material as a Cursor rules file, plus the things a fresh agent needs to be productive in a repo it's never seen:
- a one-line description of what the project is
- how to install, run, build, and test it (the exact commands)
- the stack and the architectural conventions
- the "don't touch" list — generated files, migrations, anything load-bearing
- where to look first for shared utilities and patterns
Think of it as the README you'd write for a competent new contributor who happens to read fast and take everything literally. That last part matters: an agent does exactly what the file says, so vague lines ("write clean code") do nothing, while concrete ones ("functions over classes; colocate tests; never throw raw strings") change behaviour immediately.
Because AGENTS.md is just markdown at a known path, it's low-commitment. If a tool doesn't read it natively, nothing breaks — it's still a useful doc for you. If it does, you've got one file doing the job across every agent you use.
Should you keep both?
If you only use Cursor, a Cursor rules file is enough on its own. If you move between tools — and most people end up bouncing between at least two, which is the whole premise of a two-tool Cursor-and-Lovable workflow — then AGENTS.md is the one that travels.
The pragmatic setup for a multi-tool workflow: put the real content in AGENTS.md, and keep a thin Cursor rules file that effectively says "follow AGENTS.md" plus any Cursor-only specifics. One source of truth, no drift between two files that are supposed to agree. Two files that disagree is worse than one file, because now the agent has to guess which one wins.
Where the rules file ends and the spec begins
Here's the trap. A rules file is tempting to overload, because it's the file the AI definitely reads. So people start dumping feature decisions into it: "the dashboard should show recent projects," "billing has four tiers." Now your conventions file is also a half-spec, and a bad one — unranked, no data model, no "not building" list.
Keep the lanes clean. The rules file is for how you build and stays stable for months. The spec is for what you're building and changes as the product does. When the AI needs to know that features have a priority order, that the data model has a projects table with these columns, that v1 explicitly excludes multi-user — that's spec territory, and trying to cram it into .cursorrules produces the same vague output you were trying to escape.
This is the gap Draftlytic is built to close: you answer a few questions about your idea and come out with the structured spec — description, ranked features, data model, the "not this" list — in a form you can paste straight into your tool or commit alongside AGENTS.md. The rules file says "use Supabase and write tests"; the spec says "here is the actual app." Together they're most of why one person's AI output stays coherent across a weekend and another's drifts at prompt four.
A starter AGENTS.md
If you've never written one, start small and grow it. Every time the AI does something you have to correct twice, that correction becomes a line in the file:
# AGENTS.md
## Project
A personal weekend-hike planner. Single user, mobile-first web app.
## Commands
- install: npm install
- dev: npm run dev
- test: npm run test
- lint: npm run lint (run after any .ts/.tsx change)
## Stack
React 18 + TypeScript (strict) + Vite + Tailwind. Supabase for data/auth.
Not Next.js — ignore any "use client" suggestions.
## Conventions
- Shared code lives in src/lib. Components in src/components.
- Functions over classes. Colocate tests next to the file they test.
- Toasts: import from sonner.
## Never
- Edit generated type files.
- Add a dependency without asking first.
- Commit secrets or .env files.
That's the whole shape — under a screen, all imperative, every line earning its place. It won't be complete on day one, and it shouldn't be. The good version of this file is the one you've corrected into existence over a couple of weeks of real building.
The takeaway
AGENTS.md and .cursorrules are the same move from two angles: give the AI standing instructions so you stop re-typing your conventions and it stops re-inventing them. Use the rules file for how you build, keep it tight and imperative, and let AGENTS.md be the portable one if you work across tools. Then keep the what — the features, the data model, the boundaries — in a real spec, because a rules file was never meant to carry the product. Get both in place and the difference shows up fast: fewer corrections, less drift, and an AI that builds your project instead of a generic one. If you want the bigger picture on why the pre-prompt work matters at all, vibe coding still needs ten minutes of planning — the rules file and the spec are where that ten minutes lives.