用途：当项目包含 supabase/config.toml、supabase/migrations/ 迁移或 @supabase/supabase-js 客户端，且任务涉及 RLS、Auth、Storage、Realtime、Edge Functions 或本地环境（supabase start）时启用该技能。也用于审查访问策略、缺失或错误的 RLS policy、以及 service_role 的不当暴露。纯 Postgres 索引/执行计划/隔离级别调优而未涉及 Supabase 上下文时不使用，应改用 postgres 专项技能并将结果带回策略层；涉及 JWT、自定义 claims 或数据库外授权面时与应用安全技能配合。
主要能力与流程：识别所用 SDK、项目、经 API 暴露的 schema、既有迁移与环境策略；梳理身份、租户、角色（anon、authenticated、自定义角色）及各 claim 来源；先在 Postgres 建模表、函数与视图；为对象定义 GRANT 并为每种操作与角色定义 RLS policy，默认拒绝；以版本化迁移实现并用各角色代表性用户（含无会话的 anon）测试；仅在项目实际使用时验证 Auth、Storage、Realtime 或 Edge Functions；检查生成的 TypeScript 类型、连接池策略、日志与备份/回滚方案。
要点与限制：所有暴露 schema 的表应启用 RLS 并默认拒绝；service_role 绝不可出现在客户端；逐条策略分别测试 anon、authenticated 与自定义角色，USING (true) 等同无策略；SECURITY DEFINER 函数需固定 search_path 并自行校验；JWT 自定义 claim 需验证来源；schema 变更须走迁移，避免在控制台手工修改生产。验证时执行 supabase db reset/lint/migrations，核对 supabase gen types 生成类型、Storage 分桶策略及 Edge Functions 密钥。修改 RLS、Auth、暴露 schema、Storage、Realtime 或连接策略前先阅读 references/standards.md。具体要求与命令细节以项目资料为准，资料未提供者暂未说明。