Lección 58 de 61 · Módulo 08: 4/7
Build Nivel · intermedio

Conexión a Supabase — schema, RLS, storage

Por qué te debe importar

En construcción, la mayoría del tiempo invertido en Supabase no es features nuevos — es migrations y RLS policies. Hacerlas bien desde el inicio, idealmente vía [[mcp|MCP]] con el agente operando, es el diferencial entre 2 días de setup y 2 horas.

Idea central

MCP Supabase + skill de "RLS obligado" = migrations seguras en minutos.

El flujo con MCP

Configuras mcp.json con Supabase server. El agente ahora puede:

  • list_tables — conocer schema actual.
  • apply_migration — aplicar SQL nuevo.
  • execute_sql — query ad-hoc.
  • get_advisors — detectar problemas (RLS faltante, performance, security).

Flujo típico al agregar tabla:

  • Agente propone SQL (con RLS).
  • Aplica migración.
  • Corre get_advisors para validar.
  • Si advisors marca issues, los arregla en otra migración.

La skill "RLS obligado"

En .claude/skills/supabase.md:

`

Al crear tabla:

  • Siempre alter table X enable row level security;
  • Siempre mínimo una policy explícita.
  • Si no sabes qué policy, usa for all using (false) y pregunta.
  • Corre get_advisors después de la migración.

`

Esta skill sola previene el 90% de los incidentes de seguridad más comunes en Supabase.

Storage

Mismo principio aplica: buckets tienen policies. No hay bucket público por default en el curso. Cualquier upload requiere policy explícita sobre quién puede read/write.

Ejemplos en escalera
✓ Checkpoint

Tu `.claude/skills/supabase.md` existe? Si no, créala con el flujo RLS-obligado. Si existe, ¿incluye `get_advisors` después de cada migración?

Resumen — tres cosas que deberías recordar
  1. MCP Supabase permite al agente operar DB sin tocar dashboard.
  2. Skill "RLS obligado" previene el 90% de incidentes de seguridad comunes.
  3. Advisors corridos después de cada migración = detección temprana.
Qué sigue
Lección 59 · Construcción Deploy a Vercel — variables de entorno, preview branches → Continuar