用途：处理任何涉及 Supabase 的任务，包括 Database、Auth、Edge Functions、Realtime、Storage、Vectors、Cron、Queues 等产品及客户端相关开发。
主要原则与能力：
- Supabase 变更频繁，实施前应抓取 https://supabase.com/changelog.md 扫描破坏性变更标签，再查当前文档，不依赖训练数据中的函数签名与 config.toml 设置。
- 实施后必须运行测试查询验证，未验证的修复视为不完整。
- 同一方法失败 2-3 次后应停止重试，改用其他方法、查文档、细读报错并检查日志。
- 新建表可能不会自动暴露给 Data (REST) API，需检查 Data API 设置并用显式 GRANT 授权 anon/authenticated；这与 RLS 是两回事，前者控制表能否访问，后者控制可见行。授权公开访问时同时启用 RLS。
- 暴露 schema（默认含 public）中每张表都要启用 RLS，策略应匹配真实访问模型，而非所有表套用同一 auth.uid() 模式。
安全清单要点（涉及 auth、RLS、视图、存储、用户数据时适用）：
- 授权判断不要用 user_metadata（raw_user_meta_data 用户可编辑且可能出现在 auth.jwt()），应存放在 raw_app_meta_data / app_metadata。
- 删除用户不会使现有访问令牌失效，应先登出或撤销会话；敏感应用保持短 JWT 有效期。
- 不得在公开客户端暴露 service_role 或 secret key；前端优先用 publishable keys；Next.js 中 NEXT_PUBLIC_ 变量会发送到浏览器。
- 视图默认绕过 RLS，Postgres 15+ 用 CREATE VIEW ... WITH (security_invoker = true)，旧版本撤销 anon/authenticated 访问或放入非暴露 schema。
- UPDATE 需要 SELECT 策略，否则静默返回 0 行；UPDATE 策略需同时有 USING 和 WITH CHECK。
- auth.role() 已弃用，改用 TO 子句；TO authenticated 仅验证身份不含授权，须搭配 USING 中的归属判断。
- SECURITY DEFINER 绕过 RLS，不要用它解决权限错误；public 中的此类函数默认所有角色可执行，若必须使用应放在非暴露 schema 并加 auth.uid() 检查，随后运行 supabase db advisors。
- Storage upsert 需要 INSERT + SELECT + UPDATE 三项权限。
- 安装 supabase-js、@supabase/ssr、supabase-py 等包时应固定版本并提交 lockfile。
CLI 与 MCP：CLI 结构随版本变化，始终用 --help 发现命令（supabase --help、supabase <group> --help、supabase <group> <command> --help）。已知限制：supabase db query 需 CLI v2.79.0+，supabase db advisors 需 v2.81.3+。新建迁移文件先用 supabase migration new <name>。MCP 连接排查：用 curl 检查 https://mcp.supabase.com/mcp 可达性（401 表示正常），检查项目根的 .mcp.json，必要时触发 OAuth 2.1 认证。文档获取优先用 MCP search_docs，其次在文档 URL 后加 .md，再考虑网页搜索。
Schema 变更：用 execute_sql（MCP）或 supabase db query（CLI）直接执行 SQL 迭代，不要用 apply_migration 改本地 schema。提交迁移时先跑 advisors 修复问题，再执行 supabase db pull <descriptive-name> --local --yes，最后 supabase migration list --local 验证。
限制与未提供信息：资料未提供具体收费、价格、平台支持范围、性能效果与完整操作步骤；部分内容指向外部安全索引与技能反馈文档，需另行查阅。