用途：当任务涉及 Supabase 时使用，包括其数据库、Auth、Edge Functions、Realtime、Storage、Vectors、Cron、Queues 等产品，以及 supabase-js、@supabase/ssr 在 Next.js、React、SvelteKit、Astro、Remix 中的集成和登录登出等认证问题。
主要能力与原则：Supabase 变化频繁，实现前应核对变更日志与当前文档，不要依赖训练数据；先获取 https://supabase.com/changelog.md 扫描破坏性变更，再查相关文档。改动后要跑测试查询验证。同一方法失败 2-3 次应停下换思路并查日志。新建表可能未自动暴露给 Data API，需显式 GRANT 给 anon/authenticated，且这与 RLS 是两回事；暴露 schema 中的每张表都应启用 RLS，并按真实访问模型编写策略。
安全要点：不要在 JWT 授权决策中使用 user_metadata，应使用 raw_app_meta_data/app_metadata；删除用户不会使已有令牌失效；不要在前端暴露 service_role 或 secret key；视图默认绕过 RLS，Postgres 15+ 用 CREATE VIEW ... WITH (security_invoker = true)；UPDATE 需要 SELECT 策略；auth.role() 已弃用，改用 TO 子句，且 TO authenticated 需配合 USING 中的归属判断；UPDATE 策略需同时有 USING 和 WITH CHECK；SECURITY DEFINER 会绕过 RLS，应优先 SECURITY INVOKER，必要时放在非暴露 schema 并加 auth.uid() 检查；Storage upsert 需要 INSERT+SELECT+UPDATE；安装 Supabase 包应固定版本并提交 lockfile。
用法：CLI 命令通过 --help 发现，不要猜测。supabase db query 需 CLI v2.79.0+，supabase db advisors 需 v2.81.3+。新建迁移文件先用 supabase migration new <name>。改 schema 用 execute_sql 或 supabase db query，不要用 apply_migration 改本地库。提交迁移流程：跑 advisors、检查安全清单、supabase db pull <descriptive-name> --local --yes、supabase migration list --local 验证。MCP 连接问题按顺序排查：curl -so /dev/null -w "%{http_code}" https://mcp.supabase.com/mcp（401 表示服务正常）、检查 .mcp.json、完成 OAuth 2.1 认证。文档优先用 MCP search_docs，或给文档 URL 加 .md 获取。
限制：仅在任务明确匹配其上游产品或 API 范围时使用；命令、API 行为、价格、配额、凭据和部署影响需以当前官方文档为准；示例不能替代环境测试、安全审查或对破坏性/高成本操作的用户批准。