Design Postgres changes
Create tables, constraints, indexes, functions, triggers, views, extensions, migrations, seeds, and generated application types.
Supabase Codex Skills help Codex build with Postgres, Auth, Storage, Realtime, Edge Functions, and the Supabase CLI. Download the skills for schema design, migrations, row-level security, generated types, local stacks, seed data, function testing, environment management, and controlled deployment.
task: complete supabase application development task
inspect:
- requirements and context
- existing standards
- failure and edge cases
verify: outputs + checks + handoffA dependable Supabase workflow keeps schema changes in migrations, tests them locally, generates matching types, and treats authorization policies as part of the data model.
These skills help Codex distinguish local and linked commands, preserve secrets, and verify database, Auth, Storage, Realtime, and function behavior together.
Create tables, constraints, indexes, functions, triggers, views, extensions, migrations, seeds, and generated application types.
Write and test row-level security policies, Auth flows, role behavior, service operations, storage policies, and tenant boundaries.
Develop and test Edge Functions, webhooks, scheduled work, Realtime behavior, file operations, and typed client integrations.
Start the local stack, diff and reset migrations, pull deliberate remote history, check status, push approved changes, and deploy functions.
The steps keep context, implementation, and verification visible so the result can be reviewed and repeated.
Read config, migrations, schemas, seed data, generated types, clients, policies, functions, environments, and CLI version.
State who can read or change each row or object, required constraints, API behavior, failure modes, and migration compatibility.
Create migrations and policies, reset the local database, seed representative users and data, run functions, and verify typed clients.
Compare migration histories, inspect diffs and destructive operations, regenerate types, then prepare a controlled database and function deployment.
The workflow adjusts to the project, audience, tools, and risk while preserving the same quality standard.
Model relational data, queries, indexes, constraints, functions, migrations, and generated types.
Implement providers, sessions, claims, row-level security, roles, account flows, and tenant isolation.
Develop Edge Functions, webhooks, external APIs, background jobs, email, payments, and server-only logic.
Manage buckets, object policies, uploads, signed access, database changes, subscriptions, and presence.
Start with one defined outcome and provide the source material, constraints, and checks that matter.
These skills are designed for people who need dependable supabase application development work with a visible process.
Build database-backed products with typed clients and explicit authorization.
Move quickly while keeping migrations, secrets, policies, and production changes reviewable.
Design Postgres behavior, functions, integrations, performance, and operational checks.
Test tenant isolation, roles, storage access, service keys, and policy coverage.
The skills do not reveal project secrets, weaken row-level security for convenience, or run destructive linked-database commands without explicit environment confirmation and approval.
Install the complete skill folder and add the project-specific context before beginning.
Keep database, Auth, RLS, Storage, Realtime, function, and deployment guidance together.
Project scope lets the workflow read Supabase config, migrations, clients, types, and test commands.
Record CLI version, project layout, approved linked targets, secrets handling, Auth providers, and deployment controls.
List reset, migration, lint, type generation, policy tests, function tests, application tests, and deployment review steps.
Practical answers about capabilities, limits, setup, and review.
Yes. They create reviewable SQL migrations and test them through the project’s local workflow.
Yes. Policies are designed from explicit user, role, tenant, and operation requirements and tested with representative identities.
Yes, including local serving, environment access, validation, external APIs, tests, and deployment preparation.
No. Privileged keys belong only in approved server-side secret storage.
Only after the target, migration history, diff, destructive effects, tests, and authorization are confirmed.
Clear context. Purposeful work. Relevant checks. A result others can understand.