Issues with Cursor not consistently following conventions defined in .cursorrules

Thanks for reporting a bug you have found in Cursor!
Please add the following info to help us diagnose your issue:
Hi community,

I’m facing difficulties using Cursor to maintain the conventions clearly defined in the .cursorrules file. The current setup is as follows:

  • In the Database (Supabase/PostgreSQL):
    • Tables: snake_case and plural (e.g., user_profiles )
    • Columns: snake_case (e.g., first_name )
    • Relationships: snake_case with _id suffix (e.g., user_id )
  • In Prisma Schema:
    • Models: PascalCase (e.g., UserProfile )
    • Fields: camelCase
    • Use of @map and @@map to map names to snake_case

When developing @cursor/rules , @templates , and trying to ensure Cursor consistently follows these rules, I frequently find it ignores or incorrectly applies the established conventions. This happens even after repeatedly clarifying and confirming that the rules have been read by Cursor.

For example, Cursor recently generated this Prisma model:

model Booking {
  id                String             @id @default(uuid()) @db.Uuid
  booking_ref       String             @unique @map("booking_ref")
  departure_id      String             @db.Uuid @map("departure_id")
  departure_date_id String             @db.Uuid @map("departure_date_id")
  notes             String?            @db.Text @map("notes")
  paid_amount       Decimal?           @db.Decimal(12, 2) @map("paid_amount")
  payment_status    PaymentStatus      @default(UNPAID) @map("payment_status")
  status            BookingStatus      @default(PENDING)
  total_price       Decimal            @db.Decimal(12, 2) @map("total_price")
  user_id           String?            @db.Uuid @map("user_id")
  created_at        DateTime           @default(now()) @map("created_at") @db.Timestamptz(6)
  updated_at        DateTime           @updatedAt @map("updated_at") @db.Timestamptz(6)
  booking_passengers BookingPassenger[]
  departure         Departure          @relation(fields: [departure_id], references: [id])
  departure_date    DepartureDate      @relation(fields: [departure_date_id], references: [id])
  user              User?              @relation(fields: [user_id], references: [id])

  @@index([departure_id])
  @@index([departure_date_id])
  @@index([user_id])
  @@index([status])
  @@map("bookings")
}

The typical response after pointing out the issue:

“You’re absolutely right! I apologize for the confusion and for not correctly following the rules YOU established.”

I’m not suggesting Cursor doesn’t work well, but constantly reminding it of the rules is incredibly exhausting.

This makes the workflow quite frustrating, as I waste a lot of time manually correcting each instance.

Has anyone else experienced something similar? Any advice or solutions you’ve found to improve this situation?

Thanks in advance for any help!

Best regards!

:white_check_mark: Check the forum to ensure the issue hasn’t been reported already
:lady_beetle: Provide a clear description of the bug
:counterclockwise_arrows_button: Explain how to reproduce the bug (if known)
:camera: Attach screenshots or recordings (e.g., .jpg, .png, .mp4).
:laptop: Tell us your operating system and your Cursor version (e.g., Windows, 0.x.x).
:prohibited: Tell us if the issue stops you from using Cursor.

Just because Cursor has read the rule doesn’t mean it has to apply it, the one has nothing to do with the other.
When Cursor applies a rule is determined by FrontMatter Rules and content. If it contains nonsense, Cursor will not do anything with it.
Ask him carefully and emphatically what is wrong with the rule.
The first answer will be that everything is right with the rules, it’s up to him.
Then you ask again and say that we have to find the error and he should be honest, then you will usually get an answer as to what the problem is.

Also its not necessarily Cursor who doesnt apply the rule, but the LLM. Its a common practice to state at begin of rule file to always output specific marker text

Example:
You will output following at begin of each response: #Rules: Supabase/Prisma

It depends also on the amount of content in your context. Too much context will confuse AI as it wouldnt know how to handle contradictions,…

Also if you have all this in .cursorrules file it might be too much there.
Unless you only work with database code it would be better to use separate Project Rules for Supabase and or Prism, independent of any other rules you need.