Best Cursor Rules for Supabase Projects
Cursor RulesDifficulty: BeginnerUpdated: 2026-05-25
Cursor rules that prevent schema drift and keep Supabase + Next.js changes safe.
Use this rule if you are building:
- Auth redirects and callback routes
- Database schema changes and migrations
- Row-level security reviews
- Storage uploads and signed URLs
This rule helps Cursor avoid:
- Modifying unrelated files
- Leaking env values
- Breaking API routes and request boundaries
- Editing database migrations without review
Copy Cursor Rules
Paste into .cursorrules at your repo root.
# Project: Best Cursor Rules for Supabase Projects
# Goal: Ship safely with minimal, reviewable diffs.
You are an AI coding assistant. Follow these rules strictly:
1) Make the smallest change that solves the task.
2) Never modify unrelated files. If you must touch more than 2 files, explain why.
3) Do not change dependencies or configs unless explicitly requested.
4) Preserve existing formatting and code style.
5) Never log secrets. Never print env values.
When asked to implement a feature:
- Ask for the exact acceptance criteria if missing.
- Propose a short plan, then implement.
- Add lightweight validation steps (lint/build/tests) when available.
Repository boundaries:
- Do not edit lockfiles unless dependencies changed.
- Do not edit generated files.
Framework notes:
- Prefer server components for data fetching; keep client components minimal.
- Use environment variables via process.env only; never inline secrets.
Output:
- Provide changes as a patch.
- Include file paths and the key lines changed.Show full rules
# Project: Best Cursor Rules for Supabase Projects
# Goal: Ship safely with minimal, reviewable diffs.
You are an AI coding assistant. Follow these rules strictly:
1) Make the smallest change that solves the task.
2) Never modify unrelated files. If you must touch more than 2 files, explain why.
3) Do not change dependencies or configs unless explicitly requested.
4) Preserve existing formatting and code style.
5) Never log secrets. Never print env values.
When asked to implement a feature:
- Ask for the exact acceptance criteria if missing.
- Propose a short plan, then implement.
- Add lightweight validation steps (lint/build/tests) when available.
Repository boundaries:
- Do not edit lockfiles unless dependencies changed.
- Do not edit generated files.
Framework notes:
- Prefer server components for data fetching; keep client components minimal.
- Use environment variables via process.env only; never inline secrets.
Output:
- Provide changes as a patch.
- Include file paths and the key lines changed.Related Build Kits
Related Launch Checklists
Related Playbooks
Related Fixes
What this Cursor rule is for
Keep edits scoped, protect critical files, and enforce safe patterns for Supabase / Auth / PostgreSQL projects.
Who should use it
- Indie developers shipping production features fast
- Teams that want predictable AI changes with minimal diff
Copy the Cursor rule
# Project: Best Cursor Rules for Supabase Projects
# Goal: Ship safely with minimal, reviewable diffs.
You are an AI coding assistant. Follow these rules strictly:
1) Make the smallest change that solves the task.
2) Never modify unrelated files. If you must touch more than 2 files, explain why.
3) Do not change dependencies or configs unless explicitly requested.
4) Preserve existing formatting and code style.
5) Never log secrets. Never print env values.
When asked to implement a feature:
- Ask for the exact acceptance criteria if missing.
- Propose a short plan, then implement.
- Add lightweight validation steps (lint/build/tests) when available.
Repository boundaries:
- Do not edit lockfiles unless dependencies changed.
- Do not edit generated files.
Framework notes:
- Prefer server components for data fetching; keep client components minimal.
- Use environment variables via process.env only; never inline secrets.
Output:
- Provide changes as a patch.
- Include file paths and the key lines changed.
Recommended project structure
- src/app
- src/components
- src/lib
- content/cursor-rules
How to use it in Cursor
- Copy the block into your repo root as
.cursorrules - Restart Cursor
- Test by asking it to change one small file
Common mistakes
- Rules exist but Cursor uses a different workspace root
- Rules are too vague and not actionable
Related workflows
- Use Cursor to Fix Vercel Build Errors
- Build SEO Landing Pages with Cursor
Related MCP servers
- Best MCP Servers for Cursor
- Best File System MCP Servers
FAQ
Should I allow the agent to edit database migrations automatically?
Prefer manual review for any schema change and run migrations locally first.