Concevoir un site web marketing de produit
Créez un site dont le contenu, les choix visuels et les interactions expliquent ce produit particulier. Prend en charge les SaaS, micro-SaaS, services, outils et autres produits sans imposer un framework, un nombre de pages fixe ou un modèle visuel SaaS.
Établir la tâche réelle
Lisez la demande de l'utilisateur, les instructions du dépôt, la définition produit approuvée (telle que project.md) et le site marketing existant avant de modifier quoi que ce soit. S'il n'existe pas de définition produit, établissez l'audience, l'offre, les capacités disponibles et l'objectif du site à partir de sources autorisées ; demandez uniquement les décisions manquantes. Déterminez si la tâche est un brief, une implémentation par agent de codage, un transfert vers un constructeur externe, ou une mise à jour ciblée. Préservez les décisions produit existantes, l'architecture et le périmètre autorisé. Ne recommencez pas la découverte pour une simple modification de site web.
La définition produit approuvée possède les faits produit, le périmètre, les décisions commerciales et l'état de préparation ; préservez son nom et son emplacement. Un marketing-site-brief.md séparé possède l'architecture de l'information, les exigences de contenu/conception, les interactions et le plan de découvrabilité ; référencez-le dans la définition produit (par exemple, project.md). Ne dupliquez pas l'intégralité de la définition produit et ne créez pas de source concurrente de vérité produit. Les spécifications existantes conservent leur responsabilité pour le travail d'implémentation.
Inspectez le framework réel, les routes, le rendu, les composants, les dépendances et les contraintes d'hébergement. Pour un nouveau site, recommandez une approche compatible basée sur le contenu, les besoins de rendu/indexation, les intégrations, la maintenabilité et les contraintes de l'équipe. Expliquez les compromis importants plutôt que de choisir automatiquement le framework le plus récent. Un skill de conception est un guide de travail, pas un framework ou une dépendance d'exécution ; SaaS est un modèle de produit, tandis que Sass est un outil de style.
Produire un brief de conception transférable
Utilisez le modèle de brief en anglais ou le modèle en arabe lors de la création du brief ; adaptez les sections au projet plutôt que de les remplir avec des faits inventés. Identifiez les inconnues qui bloquent un travail utile, et procédez avec des hypothèses déclarées pour les détails non bloquants.
Donnez à chaque page proposée une question de visiteur distincte, un contenu utile et une action suivante. Fusionnez les pages minces ou répétitives. Incluez le texte de la page, l'état de préparation des fonctionnalités publiques, les limites des preuves, la navigation, les liens internes, les étiquettes de prévisualisation, le comportement des formulaires, les exigences responsive/RTL, l'accessibilité, les métadonnées, l'applicabilité JSON-LD, la performance et les vérifications d'acceptation. Un site multipage doit avoir des routes et un contenu significatifs, pas une seule page avec des ancres renommées ou de nombreuses pages de mots-clés quasi identiques.
Définissez une direction visuelle reconnaissable : audience et personnalité, principes de référence, typographie, jetons de couleur/d'espacement, composition, assets, mouvement et contraintes intentionnelles. Évitez d'appliquer la même formule hero/cartes/gradient/tableau de bord à chaque produit. Ne copiez pas la marque d'un autre produit et ne fabriquez pas de preuves clients. Incluez le raisonnement pour qu'un autre outil puisse exécuter la conception de manière cohérente.
Lisez la sélection d'outils de conception lors du choix d'un framework, de skills de conception optionnels ou d'un constructeur. Inspectez les skills de conception disponibles avant de les invoquer. Sélectionnez la combinaison la plus petite et utile pour la tâche, expliquez les chevauchements et préservez leur compatibilité réelle avec l'hôte. Ne prétendez pas qu'un skill nommé est installé. Des skills externes optionnels peuvent améliorer la direction artistique ou les revues, mais ce workflow fonctionne toujours sans eux. Ne téléchargez, n'installez et n'exécutez pas de paquets tiers simplement parce que leurs noms apparaissent dans le brief. Si un skill optionnel crée des fichiers comme PRODUCT.md ou DESIGN.md, mappez-les explicitement comme des sorties d'outils dérivées ou des notes de conception de travail sous les références approuvées ; n'introduisez pas silencieusement des autorités produit/marketing concurrentes. Inspectez les points d'entrée et la compatibilité actuels avant d'exécuter des lanceurs, des initialiseurs, des hooks ou des helpers réseau ; ne supposez pas qu'un skill de conception est uniquement en Markdown.
Construire directement ou transférer le même brief
- Voie agent de codage : implémentez le brief de site web approuvé dans les conventions de projet existantes. Construisez les fondations partagées, les pages représentatives et la navigation fonctionnelle, puis complétez les autres pages et états. Utilisez le système de design existant lorsqu'il fait partie de l'identité du produit ; ne le remplacez pas sans une raison basée sur la tâche.
- Voie constructeur externe, comme Lovable : fournissez le même brief nettoyé et les assets nécessaires en utilisant les entrées réellement supportées par l'outil. Donnez une instruction à périmètre limité qui préserve les faits produit et distingue les interactions fonctionnelles des prévisualisations. Un outil ne peut pas lire les fichiers locaux simplement parce que leurs noms sont mentionnés. Vérifiez la documentation actuelle avant de promettre un comportement spécifique d'import/export, de framework ou de synchronisation. Inspectez le code reçu et les exigences d'intégration avant de fusionner ; n'écrasez pas l'application et ne déplacez pas son backend par hypothèse.
Pour l'une ou l'autre voie, examinez les résultats générés réels et corrigez les problèmes observés par passes limitées. Ne pré-écrivez pas la réponse de l'outil et ne revendiquez pas le succès à partir de son message d'achèvement. Approuver un brief n'implique pas la publication, les dépenses, le provisionnement de services ou l'installation de dépendances en dehors du workflow choisi. Les modifications réversibles de routine déjà autorisées par la tâche ne nécessitent pas d'approbation répétée.
Vérifier le comportement et la découvrabilité
Utilisez le guide d'acceptation pour l'implémentation et la revue finale. Testez les routes réelles et les actions critiques, la direction arabe/latine le cas échéant, les dispositions mobile/desktop, l'utilisation du clavier, les états de chargement/erreur/succès significatifs et les métadonnées destinées à la production. Distinguez une démo front-end d'une soumission réellement sauvegardée. Vérifiez un enregistrement réel avant de revendiquer une inscription réelle, et protégez les données privées séparément des contrôles d'indexation.
Sélectionnez les données structurées appropriées à la page visible et à l'éligibilité actuelle à la recherche. N'inventez pas d'avis, de prix, d'organisations, de disponibilité ou d'évaluations pour remplir un schéma. Validez la syntaxe et les exigences de recherche applicables ; un JSON-LD valide ne garantit pas un résultat enrichi ou un classement. Ne traitez pas llms.txt, un choix de framework ou un score SEO automatisé comme une garantie de visibilité.
Rapportez les vérifications réellement effectuées, l'environnement/la version, les échecs observés et les zones non testées. Une capture d'écran prouve l'apparence à cette fenêtre, pas le stockage fonctionnel, l'indexation en production ou la performance sur le terrain.
Revue finale obligatoire
Avant de déclarer le brief, le transfert ou le site web terminé, effectuez la revue finale pour le mode demandé. Comparez l'expérience réelle du visiteur ou le brief transférable avec le périmètre accepté et la direction de référence. Corrigez les constats et revérifiez les sorties affectées, enregistrez des preuves concises et divulguez les vérifications manquantes. La présence de fichiers, les captures d'écran générées et les builds verts n'établissent pas à eux seuls un site web utile.
Maintenir l'alignement produit et site web
Lorsque la tâche inclut une maintenance continue, adaptez l'extrait AGENTS en anglais ou l'extrait en arabe aux chemins réels du projet. Pour les modifications produit approuvées, inspectez la carte d'impact et mettez à jour le contenu, la navigation, les métadonnées, les données structurées et les tests du site web dans le périmètre autorisé du dépôt. Marquez précisément les capacités planifiées et livrées ; une fonctionnalité implémentée n'est pas automatiquement publiée pour chaque visiteur.
Si les faits produit, les conditions commerciales ou les dépendances externes ne sont pas résolus, signalez la décision plutôt que de l'inventer silencieusement. Si le site web vit ailleurs, identifiez le suivi exact requis au lieu de prétendre qu'il a changé. Gardez les modifications du dépôt distinctes du déploiement et de la publication publique.