silasroliver-hue/replica-skill-cursor

Construye el backend de un clon de aplicación: autenticación, migraciones de base de datos y reglas de acceso, pagos con Stripe, email, trabajos en segundo plano e integraciones de terceros a través de APIs oficiales, más una lista de verificación de seguridad.

¿Qué es replica-skill-cursor?

Esta skill está diseñada para construir el backend completo de un clon de aplicación, manejando autenticación, base de datos, pagos, correo electrónico, trabajos en segundo plano e integraciones de terceros usando exclusivamente APIs oficiales con las propias claves del usuario. Es parte del flujo de trabajo `/replica-build` y se activa cuando el usuario menciona acciones como 'añadir login', 'configurar autenticación', 'conectar base de datos', 'añadir pagos', 'conectar Stripe', 'añadir Google Calendar', 'enviar emails' o 'backend para mi clon'. La skill escribe migraciones de base de datos, código de servidor y mantiene actualizado el archivo `replica/backend.md` con una checklist de seguridad. Sigue reglas estrictas: solo APIs oficiales y públicas, el usuario crea sus propias cuentas y claves, y todo se prueba primero en modo de prueba (test mode). Soporta plataformas como Supabase, Stripe, Resend, Postmark y Google Cloud, y genera código funcional para autenticación (email, OAuth, roles), pagos (Stripe Checkout, webhooks, estados de suscripción), base de datos (migraciones, reglas de acceso, semillas) y más. La checklist de seguridad incluye nueve puntos críticos como validación de entrada, autorización, límites de tasa y verificación de webhooks.

Compatible con~Claude Code~Codex CLI✓Cursor

npx skills add https://github.com/silasroliver-hue/replica-skill-cursor/tree/HEAD/.cursor/skills/replica-backend

Documentación

replica-backend

Lee replica/architecture.md. Escribe migraciones y código de servidor, y mantiene actualizado replica/backend.md (lista de verificación abajo).

Las reglas

Solo APIs oficiales y públicas, con las claves propias del usuario. Nunca llames a los endpoints privados de la aplicación original, nunca reutilices su cliente OAuth, nunca hagas proxy a través de ella.
El usuario crea cuentas y claves. El agente nunca se registra en servicios, nunca escribe una contraseña, tarjeta o clave en producción. El usuario crea el proyecto de Stripe, Supabase, Resend o Google Cloud y coloca las claves en .env.local. El agente escribe .env.example con cada nombre de variable y sin valores.
Primero en modo de prueba. Claves de prueba de Stripe y tarjetas de prueba hasta replica-deploy.

Autenticación

Registro con email y verificación, restablecimiento de contraseña, enlace mágico si el original lo tiene. OAuth (Google, Apple) con las aplicaciones de desarrollador propias del usuario.
Sesiones: cookies seguras http-only. Cerrar sesión en todos lados.
Roles y equipos si el mapa de reconocimiento los tiene: propietario, administrador, miembro, con una función que responde "¿puede este usuario hacer esto a este registro?".
Eliminación de cuenta que realmente elimine. Apple lo requiere para aplicaciones con registro.

Base de datos

Migraciones desde architecture.md, registradas en el sistema de control de versiones, ejecutadas por un script.
Reglas de acceso en cada tabla: políticas de seguridad a nivel de fila en Supabase, o la función de autorización llamada en cada consulta. Pruébalo: un segundo usuario no debe obtener nada.
Script de semilla con datos falsos realistas (sin personas reales).
Copias de seguridad activadas (las copias diarias del alojamiento cuentan, verifica que estén habilitadas).

Pagos

Stripe Checkout para registrarse en un plan, el Portal del Cliente para cambios y cancelaciones. No construyas formularios de tarjeta.
Webhooks: verifica la firma, almacena el ID del evento, haz que cada manejador sea idempotente (Stripe reintenta). Maneja checkout.session.completed, customer.subscription.updated, customer.subscription.deleted, invoice.payment_failed.
El estado de la suscripción vive en tu base de datos, actualizado por los webhooks, leído por tu aplicación. Nunca confíes en el cliente.
Cancelar es un solo clic. La facturación difícil de cancelar es una queja principal sobre la mayoría de las aplicaciones, y en muchos lugares es ilegal.

Correo electrónico y trabajos

Correo transaccional a través de Resend o Postmark desde tu propio dominio. Plantillas escritas desde cero.
Trabajos para cualquier cosa basada en tiempo (recordatorios, resúmenes, sincronización, limpieza) con reintentos y un registro de mensajes fallidos. Horas en UTC, mostradas en la zona horaria del usuario.

Integraciones

Para cada integración en la matriz de características: la API oficial, los alcances OAuth necesarios (los menos posibles), el proceso de revisión del proveedor, los límites de velocidad. Alcances de Google como Calendar necesitan la verificación OAuth de Google antes del lanzamiento público, lo que lleva semanas. Empieza temprano y escríbelo en backend.md.

Lista de verificación de seguridad

secretos solo en variables de entorno, .env* en .gitignore, nada en los bundles del cliente
entrada validada en el servidor (zod o similar) en cada ruta
autorización verificada en cada lectura y escritura, probada con un segundo usuario
límites de velocidad en autenticación, registro y cualquier cosa que envíe correo electrónico o SMS
webhooks verifican firmas
subidas: límites de tamaño y tipo, servidas desde un dominio o bucket separado
sin datos de usuario en URLs o registros
dependencias auditadas (npm audit)
política de privacidad lista cada procesador (Stripe, Resend, alojamiento, análisis)

Salida

Autenticación funcional, base de datos, pagos en modo de prueba, correo electrónico e integraciones, .env.example, replica/backend.md con la lista de verificación marcada, filas de la matriz de características actualizadas. Siguiente: /replica-test.