Flutter + Supabase rules for AI coding agents

# AGENTS.md - this project

Instructions for AI coding agents working in this repository.

## Project

A Flutter (Dart) + Supabase project.

Stack: Flutter (Dart), Supabase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`

## Project structure

- Feature folders under `lib/features/<name>/` with widgets, state and data layers.

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

## Supabase

- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- Initialise `supabase_flutter` once in `main()` and access it via `Supabase.instance.client`.

## Reference docs

- [Flutter docs](https://docs.flutter.dev)
- [Supabase docs](https://supabase.com/docs)

# CLAUDE.md - this project

Project instructions for Claude Code.

## Project

A Flutter (Dart) + Supabase project.

Stack: Flutter (Dart), Supabase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`

## Project structure

- Feature folders under `lib/features/<name>/` with widgets, state and data layers.

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

## Supabase

- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- Initialise `supabase_flutter` once in `main()` and access it via `Supabase.instance.client`.

## Reference docs

- [Flutter docs](https://docs.flutter.dev)
- [Supabase docs](https://supabase.com/docs)

---
description: "Core rules for this project"
alwaysApply: true
---

# this project

A Flutter (Dart) + Supabase project.

Stack: Flutter (Dart), Supabase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
description: "Flutter (Dart) conventions: Cross-platform Flutter app in Dart 3."
globs: lib/**/*.dart, test/**/*.dart
alwaysApply: false
---

# Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

Docs: https://docs.flutter.dev

---
description: "Supabase conventions: Postgres, auth and storage from Supabase."
globs: supabase/**, **/supabase/**/*.ts, lib/supabase/**
alwaysApply: false
---

# Supabase

- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- Initialise `supabase_flutter` once in `main()` and access it via `Supabase.instance.client`.

Docs: https://supabase.com/docs

# Cursor rules - this project

You are an expert Flutter (Dart), Supabase engineer working on this codebase. Follow these rules.

## Project

A Flutter (Dart) + Supabase project.

Stack: Flutter (Dart), Supabase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`

## Project structure

- Feature folders under `lib/features/<name>/` with widgets, state and data layers.

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

## Supabase

- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- Initialise `supabase_flutter` once in `main()` and access it via `Supabase.instance.client`.

## Reference docs

- [Flutter docs](https://docs.flutter.dev)
- [Supabase docs](https://supabase.com/docs)

# Copilot instructions - this project

A Flutter (Dart) + Supabase project.

Stack: Flutter (Dart), Supabase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
applyTo: "lib/**/*.dart,test/**/*.dart"
---

# Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

---
applyTo: "supabase/**,**/supabase/**/*.ts,lib/supabase/**"
---

# Supabase

- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- Initialise `supabase_flutter` once in `main()` and access it via `Supabase.instance.client`.

---
trigger: always_on
---

# this project

A Flutter (Dart) + Supabase project.

Stack: Flutter (Dart), Supabase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
trigger: glob
globs: lib/**/*.dart, test/**/*.dart
---

# Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

---
trigger: glob
globs: supabase/**, **/supabase/**/*.ts, lib/supabase/**
---

# Supabase

- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- Initialise `supabase_flutter` once in `main()` and access it via `Supabase.instance.client`.

# GEMINI.md - this project

Project context for Gemini CLI.

## Project

A Flutter (Dart) + Supabase project.

Stack: Flutter (Dart), Supabase.

## Commands

- Run: `flutter run`
- Analyze: `flutter analyze`
- Tests: `flutter test`
- Format: `dart format .`
- New migration: `npx supabase migration new <name>`
- Generate TS types: `npx supabase gen types typescript --local > types/supabase.ts`

## Project structure

- Feature folders under `lib/features/<name>/` with widgets, state and data layers.

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Flutter (Dart)

- Code must pass `flutter analyze` with no warnings.
- Use `const` constructors wherever possible.
- Split large `build` methods into small widgets, not helper methods returning widgets.
- Use the state management already in the project (Riverpod, Bloc, Provider). Do not introduce a second one.
- Check `mounted` before using `BuildContext` after an `await`.
- Add packages with `flutter pub add`; prefer well-maintained packages from pub.dev.
- Never hardcode API secrets in the app bundle.

## Supabase

- Enable Row Level Security on every table and write explicit policies. No table ships without RLS.
- The anon/publishable key is public. The `service_role`/secret key bypasses RLS: use it only in trusted server code, never in the client.
- Change the schema with migration files in `supabase/migrations/`, not by clicking in the dashboard.
- On the server, verify the user with `supabase.auth.getUser()` (or `getClaims()`); do not trust `getSession()` alone for authorization.
- Initialise `supabase_flutter` once in `main()` and access it via `Supabase.instance.client`.

## Reference docs

- [Flutter docs](https://docs.flutter.dev)
- [Supabase docs](https://supabase.com/docs)