Two Engineering Guides for Supabase and Postgres

Pick a task and get started

Install both Skills and confirm they can be read, then choose a concrete task. The first includes a permissions exercise; the other two require real project files. Each prompt defines the stage it will deliver.

1. Install both Skills in the target project

   Copy install command

   Run the author’s command in the target repository, select your assistant and keep both Skills. Installation is project-scoped by default. Confirm the Skills and references are readable afterward; this does not establish a Supabase database connection.

   npx skills add supabase/agent-skills

   Read the author’s setup guide

   Confirm the Skills and inputs are readable before the first task

   Open your coding assistant in the project where you installed the Skills. Ask it to use supabase and supabase-postgres-best-practices and identify the loaded SKILL.md files and relevant references. If discovery fails, check the host’s installation convention. The first task uses the hypothetical table and policy in the prompt; it needs no new Supabase project, database password or write access.

   Read the official scope and Skill list

2. Give your AI this first task

   Copy prompt

   Prompts and output filenames are editorial conventions. They request inspectable evidence and candidate changes. No Skill installation, database connection or example SQL execution was performed for this page.

   Use supabase and supabase-postgres-best-practices. First confirm that both Skills and the relevant references are readable. Follow supabase’s process to check the current changelog and official RLS documentation, reporting only what matters for this task. State any documentation-access limitation. This is an editorial review exercise, not a live database: public.notes has id uuid primary key, owner_id uuid not null, and body text. RLS is enabled. authenticated has SELECT only; anon has no table privilege. No other policies apply. The only policy is: create policy "signed_in_read" on public.notes for select to authenticated using (true); Required behavior: a signed-in user reads only rows whose owner_id equals their user ID; signed-out visitors read none. Review these inputs only. Do not connect to a database or execute SQL. Read references/security-rls-basics.md and references/security-privileges.md inside supabase-postgres-best-practices. Explain the table privilege, the rows permitted by the policy, and why the current policy misses the requirement. Draft SQL that replaces the broad policy; do not merely add a narrow policy while retaining the old one. Check Auth helpers against current official documentation. Deliver rls-review.md, rls-proposal.sql and rls-test-matrix.md. Cover user A reading their own row, A reading B’s row, B reading their own row, and an anon request. Specify expected rows or error type, distinguishing missing privileges from an empty policy-filtered result. A successful administrator or service_role query does not demonstrate isolation for an application user. Label findings as static review and every test as not run.

3. Check what you receive

   • An explanation of access: TO authenticated selects a role, while using (true) still allows that role to read every row. The ownership requirement needs a row predicate.
   • Candidate replacement SQL and an identity/data test matrix. Check that the old broad policy is handled: default permissive policies combine with OR.
   • No database is connected or changed. Before applying this to a real project, gather all grants, applicable policies and versions, then verify actual returned rows as ordinary application users.
   Read the author’s notes for this task