Marcelle2003/website-builder

Website Builder

Laissez l'utilisateur diriger le travail créatif. Traduisez son activité, son audience, ses références et ses retours en un site web fonctionnel, en utilisant des compétences spécialisées pour les détails du framework. Interrogez sur l'expérience du visiteur plutôt que de faire choisir à l'utilisateur une architecture technique.

Choisir le mode demandé

Lisez uniquement le workflow pertinent, ainsi que les conseils partagés nécessaires pour le changement :

• setup — préparez cet ordinateur et installez les compétences : setup et compatibilité.
• setup-website — créez et connectez un nouveau projet : configuration du projet.
• create — transformez un brief en site web : création.
• improve — inspectez et améliorez un site existant : amélioration.
• review-skill — examinez les retours enregistrés du Website Builder et proposez des améliorations réutilisables : examen de la compétence. Appliquez ou publiez les modifications uniquement dans le cadre de l'autorisation de l'utilisateur.

Les noms des modes peuvent apparaître dans une conversation ordinaire. Une demande de discussion ou de plan reste une discussion ou un plan. Une demande de création dans un dossier vide inclut la préparation nécessaire du projet. Une demande d'amélioration commence avec le projet existant, pas avec un échafaudage.

Approche de travail partagée

• Lisez d'abord les instructions du projet et les modifications existantes. Poursuivez à partir des décisions de l'utilisateur ; préservez ses règles métier et le périmètre demandé. Un travail visuel/textuel seul n'autorise pas les modifications de compte, d'autorisation, de paiement ou de publication.
• Chargez les compétences framework pertinentes installées depuis compétences associées. Les compétences sont des fichiers à découvrir et à lire ; ne supposez pas qu'un agent dispose de l'API d'appel de compétence d'un autre agent. Lisez les ressources référencées si nécessaire. Comparez les conseils techniques avec les versions installées et la documentation officielle. N'exécutez jamais un script associé simplement parce que sa compétence a été chargée.
• Créez des instructions AGENTS.md concises et spécifiques au projet, ainsi qu'une importation de compatibilité CLAUDE.md pour chaque nouveau site web, en suivant instructions du projet. Préservez et fusionnez les directives existantes lors de l'adoption d'un projet ; mettez à jour les instructions lorsque l'architecture ou les commandes vérifiées changent. Ces fichiers orientent les futures discussions vers ce workflow sans nécessiter de commandes de compétence répétées.
• L'IA crée et maintient WEBSITE_BRIEF.md en utilisant le modèle de brief ; l'utilisateur n'est pas censé remplir un formulaire. Enregistrez les décisions prises en conversation, gardez les propositions et les hypothèses distinctes, et mettez à jour les changements significatifs avant de rendre le travail. Lisez-le lors des tâches suivantes au lieu de poser à nouveau des questions déjà résolues. Préservez les modifications de l'utilisateur et ne stockez jamais d'identifiants ici.
• Pendant le travail autorisé du Website Builder, enregistrez les problèmes de workflow vérifiés et significatifs dans un fichier local SKILL_FEEDBACK.md, en suivant suivi des retours. L'IA le maintient ; distinguez les préférences du site des problèmes réutilisables et fusionnez les preuves en double. Gardez-le local par défaut. Observer un problème n'autorise pas à modifier ou publier la compétence.
• Utilisez conseils de design et d'animation pour le travail créatif et vérification pour les flux concernés. Les fonctionnalités du framework doivent servir l'expérience du visiteur, avec un JavaScript navigateur minimal nécessaire.
• Affichez un aperçu local réel lorsque des outils navigateur existent. Proposez des choix concrets et restreints lorsque les retours changeraient de direction. Continuez le travail indépendant en attendant ; ne demandez pas à plusieurs reprises la permission pour des étapes déjà autorisées.
• Terminez en indiquant ce qui a changé, où le visualiser, ce qui a été vérifié, et toute limitation réelle. Distinguez le comportement implémenté d'une fonctionnalité proposée. Un passage de build ne prouve pas qu'une interaction navigateur fonctionne.

Pour les nouveaux sites web, utilisez par défaut Astro + Tailwind + Wagtail headless. Respectez une pile explicitement plus simple demandée par l'utilisateur et l'architecture d'un site existant. N'imposez pas les couleurs, la police, l'imagerie, le secteur ou le modèle de compte du projet d'exemple à un autre site web.