Supabase 与 Postgres 的两项工程指南

选一个任务，开始使用

先安装两项 Skill 并检查能否读取，再选一个明确任务。第一项自带权限练习；后两项需要你提供实际项目文件。所有提示词都说明本轮交付到哪个阶段。

1. 在目标项目安装两项 Skill

   复制安装命令

   在目标项目根目录运行作者命令，按提示选择使用的助手并保留两项 Skill。默认安装在项目范围；完成后先核对 Skill 与 references 可读。此命令不等于已连接 Supabase 数据库。

   npx skills add supabase/agent-skills

   查看作者安装说明

   先确认 Skill 与材料可读，再做第一项任务

   在安装所在项目打开代码助手，明确说“使用 supabase 和 supabase-postgres-best-practices，先列出已加载的 SKILL.md 及本题所需 references”。若识别不到，先按宿主规范检查安装位置。第一项直接使用提示词里的假设表和策略，不需要创建 Supabase 项目、填写数据库密码或配置写权限。

   查看官方安装范围与两项 Skill

2. 把这段话发给 AI

   复制提示词

   提示词和输出文件名为本站编辑约定。它们要求可检查的材料与候选方案；本页未安装技能、连接数据库或执行示例 SQL。

   请使用 supabase 和 supabase-postgres-best-practices。先确认能读到这两项 Skill 及相关 references；按 supabase 的方法检查当前 changelog 和官方 RLS 文档，只报告与本题有关的内容。若文档暂时不可访问，说明这个限制。 下面是本站编写的权限审查练习，不是真实数据库： public.notes 的列为 id uuid primary key、owner_id uuid not null、body text。RLS 已启用。authenticated 只有 SELECT 权限，anon 没有表权限。没有其他适用策略，唯一策略为： create policy "signed_in_read" on public.notes for select to authenticated using (true); 目标：登录用户只能读 owner_id 等于自己用户 ID 的行；未登录访客不能读。 仅审查这些输入，不连接数据库，不执行 SQL。读取 supabase-postgres-best-practices 的 references/security-rls-basics.md 与 references/security-privileges.md；逐层说明角色是否有表权限、策略允许哪些行、现有策略为何不符合目标。给出替换现有宽松策略的 SQL 草案；不要只追加一条窄策略而留下旧策略。所有用到的 auth 辅助函数按当前官方文档核对。 交付 rls-review.md、rls-proposal.sql 和 rls-test-matrix.md。验证矩阵至少覆盖用户 A 读自己的行、A 读 B 的行、B 读自己的行、anon 请求；写清预期数据或错误类型，区分无表权限与策略过滤为空。不要借用管理员或 service_role 的成功查询证明普通用户隔离有效。全部结论标明来自静态审查，测试状态写“未运行”。

3. 检查你拿到的结果

   • 一份可解释的权限分析：TO authenticated 只限制角色，using (true) 仍允许该角色读取所有行；需按业务要求约束 owner_id。
   • 一份替换策略的候选 SQL 和角色/数据验证矩阵。检查是否处理旧宽松策略，避免多个默认 permissive 策略按 OR 合并后继续放宽访问。
   • 尚未连接或改动数据库。将草案用于真实项目时，要补齐所有 grants、适用策略及版本，并用普通应用身份验证实际返回行。
   查看这项任务的作者说明