braindcode-build

Utiliser quand l'équipe IA du projet Build se déclare — « ajoute les agents du projet », « reprends l'équipe officielle de l'idée », « vérifie les agents déclarés ». Photos officielles uniquement, un add par agent, vérification finale.

Utiliser quand l'extension Build a besoin de sa base — « active la base du projet », « vérifie les données en SQL », « ajoute une table ». get_database_status d'abord, activation sur accord, SELECT libre, toute écriture SQL montrée et confirmée.

Utiliser quand l'app Lovable doit parler au MCP produit — « branche FoodEatUp dans l'app », « connecte le MCP RapidoCRM côté serveur », « mets l'auth du connecteur ». Modèle « Connexion MCP + auth », lien profond du tableau de bord, audit du code - rien au navigateur.

Utiliser quand l'utilisateur rédige le cahier des charges d'une extension Build — « écris le CDC », « quels outils MCP le produit expose vraiment ? », « enregistre la spec ». get_spec_prompt, découverte réelle par tools/list, rédaction complète, save_project_spec.

Utiliser quand le catalogue de connecteurs Build se consulte ou s'enrichit — « quels connecteurs existent sur Build ? », « détaille le connecteur RapidoCRM », « propose un connecteur manquant ». Familles lues/écrites et actions sensibles restituées, proposition après aperçu.

Utiliser quand l'utilisateur cherche quoi construire sur Build — « propose-moi une idée d'extension », « quelles idées FoodEatUp en difficulté facile ? », « critique mon idée d'extension ». Cinq idées adaptées au profil, critique honnête, réservation sur accord.

Utiliser quand les vitrines publiées se rattrapent une à une — « complète les tutoriels manquants des 20 vitrines », « rattrape la vitrine RapidoRH Ascend », « finis Daily Brief ». Projet par projet - retrouver le code Lovable, rédiger depuis le réel, republier sur accord.

Utiliser quand l'utilisateur crée l'app Lovable d'une extension Build — « crée le projet Lovable », « pars d'un remix de cette réalisation », « importe la maquette Claude Design ». Création sur accord (crédits), message initial conforme, knowledge, workspace cible.

Utiliser quand le MCP de l'extension entre dans l'orchestrateur — « déclare mon MCP dans Plan'It », « teste le connecteur Plan'It », « référence le serveur sur la marketplace ». add_mcp_server + auth dans l'app, test, outils relevés, déclaration marketplace.

Utiliser quand l'idée est choisie et qu'on lance le chantier Build — « démarre le projet », « déclare-toi développeur IA de cette idée », « initialise le journal d'exécution ». register_ai_developer d'abord, contexte, initialisation, espace Lovable visé.

Utiliser quand l'utilisateur déroule le chantier Build — « exécute le plan », « prochaine étape du projet », « reprends à l'étape 4 ». Le cœur du plugin - une carte à la fois, validations humaines bloquantes, diffs relus, progression enregistrée.

Utiliser quand l'extension expose son propre serveur MCP — « expose le MCP de mon extension », « fais valider mon MCP par une tâche complète », « enregistre la trace de validation ». Edge function par étapes, tâche accomplie sans aide, trace jointe, progression enregistrée.

Utiliser quand l'utilisateur parle hackathon ou demoday Build — « inscris le projet au hackathon », « où en est le demoday ? », « prépare mon pitch », « montre l'arène ». Dates vérifiées avant toute inscription, pitch répété avec l'Academy, arène en lecture.

Utiliser quand l'utilisateur veut les maquettes d'une extension Build — « écris les prompts Figma », « maquette les écrans avec la charte », « prépare le fichier Figma ». Charte par get_brand_guidelines, prompts kind figma, Figma en serveur de session, adresses gardées pour la vitrine.

Utiliser quand la démo publiée se mesure — « combien de visiteurs sur ma démo ? », « les stats de la vitrine », « donne la mesure de la boucle du projet ». Analytics Lovable réels, présentés comme KPI de vitrine et proposés comme source de la boucle.

Utiliser quand l'extension publie son plugin Claude Code — « génère le plugin du projet », « mets le scaffold aux normes du dépôt », « ouvre la PR du plugin ». generate_plugin_scaffold, normes marketplace, validateurs, PR, enregistrement Build.

Utiliser quand la vitrine Build d'un projet se publie — « publie la vitrine », « qu'est-ce qui manque au readiness ? », « mets la démo en ligne ». Readiness d'abord, chaque manque comblé par une source réelle, deploy après validation humaine, publication sur accord.

Utiliser quand l'extension devient une routine mesurée — « écris la routine de mon extension », « audite le prompt de routine », « rattache la boucle KPI du projet ». Plan de routine Build, audit six blocs, coût Plan'It annoncé, rattachement, proposition sans acceptation d'office.

Utiliser quand les consignes d'espace Lovable se gèrent — « pousse la charte en skill d'espace », « quelles consignes partagées existent ? », « mets à jour la skill sécurité MCP ». Lecture avant toute modification, écritures sur accord, consignes utiles à tous les projets.

Utiliser quand le tableau Build se consulte ou se tient — « montre le kanban du projet », « ajoute une carte », « passe la carte en bloquée ». get_board, cartes ajoutées et mises à jour, validations et blocages visibles.

Utiliser quand l'utilisateur demande « où en sont mes projets Build ? », « fais le point BraindCode Build », « qu'est-ce qui manque pour publier ? ». Un écran - projets, readiness, validations en attente, kanban du projet actif, idées proposées.

Utiliser quand l'extension se teste — « fais la recette de l'app », « écris le rapport de test », « teste les cas d'erreur MCP ». Parcours manuel décrit, scénarios automatisés (jeton expiré, outil absent, entrée invalide, quota), rapport obligatoire.