Update to Vibe Code Security Reviewer

{
  "name": "supabase-rls-security",
  "description": "Perform deep Supabase Row Level Security, Data API exposure, policy, view, function, and role analysis.",
  "included_files": [],
  "skill_md_contents": "---\nname: supabase-rls-security\ndescription: Perform deep Supabase Row Level Security, Data API exposure, policy, view, function, and role analysis.\n---\n\n# Supabase RLS Security\n\nUse for any Supabase database, Auth, Data API, Storage, view, function, or user-data review.\n\n## Mandatory checks\n\n- Enable RLS on every table in exposed schemas, including `public` by default.\n- Confirm Data API exposure and explicit grants separately from row policies.\n- Check every table's `SELECT`, `INSERT`, `UPDATE`, and `DELETE` model.\n- For `UPDATE`, verify both `USING` and `WITH CHECK`; also verify the required `SELECT` policy.\n- Reject `TO authenticated` without an ownership, membership, tenant, or capability predicate.\n- Prefer `TO authenticated` or `TO anon` clauses; flag deprecated `auth.role()` checks.\n- Never use user-editable `raw_user_meta_data` for authorization; use trusted server-controlled app metadata or database membership tables.\n- Review views for `security_invoker = true` on supported Postgres versions or restricted access in an unexposed schema.\n- Review `SECURITY DEFINER` functions for schema placement, explicit authorization, fixed search path, minimal grants, and default `PUBLIC` execute privileges.\n- Check storage policies, including `SELECT`, `INSERT`, and `UPDATE` for upsert behavior.\n- Review service-role usage and ensure it never reaches public clients.\n\n## Findings format\n\nReport table/schema, exposed role, operation, policy, predicate, bypass path, impact, and a safe SQL or application-level remediation. Never invent a policy without understanding the intended access model.\n"
}