replica-backend (backend de clone d'application)

Construit le backend d'un clone d'application : authentification, migrations et règles d'accès à la base de données, paiements avec Stripe, email, tâches en arrière-plan et intégrations tierces via les API officielles uniquement, ainsi qu'une checklist de sécurité.

Qu'est-ce que replica-backend (backend de clone d'application) ?

Ce skill d'agent est conçu pour générer le backend fonctionnel d'un clone d'application. Il lit le fichier `replica/architecture.md`, écrit les migrations et le code serveur, et tient à jour `replica/backend.md` avec une checklist de sécurité. Il prend en charge l'authentification (email, OAuth), la base de données (migrations, règles d'accès, seed), les paiements via Stripe Checkout et le portail client, les emails transactionnels via Resend ou Postmark, et les intégrations tierces via leurs API officielles (avec les propres clés de l'utilisateur). Une checklist de sécurité exhaustive est automatiquement gérée pour garantir que les secrets, la validation des entrées, l'autorisation et les taux limites sont correctement implémentés. Utilisez ce skill lorsque l'utilisateur dit "ajoute la connexion", "configure l'authentification", "relie la base de données", "ajoute les paiements", "connecte Stripe", "ajoute Google Agenda", "envoie des emails" ou "backend pour mon clone", ou lorsque `/replica-build` s'exécute sur des données fictives.

Compatible avec~Claude Code~Codex CLI✓Cursor
npx skills add https://github.com/silasroliver-hue/replica-skill-cursor/tree/HEAD/.cursor/skills/replica-backend

Installed? Explore more Productivité et collaboration skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

replica-backend

Lit replica/architecture.md. Écrit les migrations et le code serveur, et tient replica/backend.md (checklist ci-dessous) à jour.

Les règles

  • API officielles et publiques uniquement, avec les propres clés de l'utilisateur. N'appelez jamais les points de terminaison privés de l'application originale, ne réutilisez jamais son client OAuth, ne passez jamais par un proxy.
  • L'utilisateur crée les comptes et les clés. L'agent ne s'inscrit jamais à des services, ne saisit jamais de mot de passe, de carte ou de clé en production. L'utilisateur crée le projet Stripe, Supabase, Resend ou Google Cloud et place les clés dans .env.local. L'agent écrit .env.example avec chaque nom de variable et aucune valeur.
  • D'abord en mode test. Clés de test Stripe et cartes de test jusqu'au replica-deploy.

Authentification

  • Inscription par email avec vérification, réinitialisation du mot de passe, lien magique si l'original le propose. OAuth (Google, Apple) avec les propres applications développeur de l'utilisateur.
  • Sessions : cookies sécurisés http-only. Déconnexion sur tous les appareils.
  • Rôles et équipes si la carte de reconnaissance en comporte : propriétaire, administrateur, membre, avec une fonction qui répond "cet utilisateur peut-il faire cette action sur cet enregistrement".
  • Suppression de compte qui supprime réellement. Apple l'exige pour les applications avec inscription.

Base de données

  • Migrations à partir de architecture.md, versionnées, exécutées par un script.
  • Règles d'accès sur chaque table : politiques de sécurité au niveau des lignes sur Supabase, ou fonction d'autorisation appelée dans chaque requête. Testez-la : un second utilisateur ne doit rien obtenir.
  • Script de seed avec des données fictives réalistes (pas de vraies personnes).
  • Sauvegardes activées (les sauvegardes quotidiennes de l'hôte comptent, vérifiez qu'elles sont activées).

Paiements

  • Stripe Checkout pour l'inscription à un abonnement, le portail client pour les modifications et l'annulation. Ne construisez pas de formulaires de carte.
  • Webhooks : vérifiez la signature, stockez l'identifiant de l'événement, rendez chaque gestionnaire idempotent (Stripe réessaie). Gérez checkout.session.completed, customer.subscription.updated, customer.subscription.deleted, invoice.payment_failed.
  • Le statut de l'abonnement réside dans votre base de données, mis à jour par les webhooks, lu par votre application. Ne faites jamais confiance au client.
  • L'annulation se fait en un clic. La facturation difficile à annuler est l'une des principales plaintes concernant la plupart des applications, et dans de nombreux endroits, elle est illégale.

Emails et tâches

  • Email transactionnel via Resend ou Postmark depuis votre propre domaine. Modèles rédigés à neuf.
  • Tâches pour tout ce qui est basé sur le temps (rappels, digests, synchronisation, nettoyage) avec des tentatives et un journal des lettres mortes. Heures en UTC, affichées dans le fuseau de l'utilisateur.

Intégrations

Pour chaque intégration de la matrice des fonctionnalités : l'API officielle, les étendues OAuth nécessaires (le moins possible), le processus de révision du fournisseur, les limites de débit. Les étendues Google comme Agenda nécessitent la vérification OAuth de Google avant le lancement public, ce qui prend des semaines. Commencez tôt et notez-le dans backend.md.

Checklist de sécurité

  • secrets uniquement dans les variables d'environnement, .env* dans .gitignore, rien dans les bundles client
  • entrées validées sur le serveur (zod ou similaire) sur chaque route
  • autorisation vérifiée sur chaque lecture et écriture, testée avec un second utilisateur
  • limites de débit sur l'authentification, l'inscription et tout ce qui envoie un email ou un SMS
  • les webhooks vérifient les signatures
  • téléchargements : limites de taille et de type, servis depuis un domaine ou un bucket séparé
  • aucune donnée utilisateur dans les URL ou les logs
  • dépendances auditées (npm audit)
  • politique de confidentialité liste chaque sous-traitant (Stripe, Resend, hébergeur, analytics)

Résultat

Authentification fonctionnelle, base de données, paiements en mode test, email et intégrations, .env.example, replica/backend.md avec la checklist cochée, les lignes de la matrice des fonctionnalités mises à jour. Suite : /replica-test.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

silasroliver-hue/replica-skill-cursor

>- Plans the stack, database schema and API for an app clone, from the recon map replica-recon wrote. Picks boring, managed tech, turns the inferred data model into real SQL with indexes and access rules, lists every route by flow, and orders the build as a thin vertical slice first. Use when the user says "plan the clone", "what stack should I use", "design the database", "write the schema", "plan the API", "architecture for my version of X", or after /replica-recon finishes.

silasroliver-hue/replica-skill-cursor

>- Names and rebrands an app clone so it is the user's own: name candidates with the trademark, domain, store and handle checks to run, a new palette checked for contrast, a logo brief, a voice guide, and a sweep tool that finds anything of the original left in the codebase. Use when the user says "name my app", "rebrand the clone", "make it mine", "pick a name and colours", "logo brief", "brand voice", "check for leftovers", or after /replica-entrepreneur. Always runs before /replica-launch.

silasroliver-hue/replica-skill-cursor

>- Rebuilds an app screen by screen from the recon map: app shell first, then the core flow as a vertical slice, then every screen with all its states, ticking off the feature matrix as it goes. Writes every line fresh, never the original's code, assets or copy. Use when the user says "build the clone", "build screen S07", "start building", "rebuild this screen", "implement the booking page", or after /replica-design.

silasroliver-hue/replica-skill-cursor

>- Ships an app clone live on the user's own domain: a preflight gate (tests green, parity must-haves done, rebrand sweep clean, listing linted, legal pages up), production database and env vars, the host, DNS records for the domain and for email, Stripe live mode, OAuth redirects, monitoring, and mobile builds to TestFlight and Play. Use when the user says "deploy it", "ship it", "put it live", "connect my domain", "go to production", "publish the app", or after /replica-launch.

Skills associés