muhammad-ahmed-ghani/ai-website-builder

Constructeur d'applications web IA

Une application est de classe mondiale lorsque cinq choses sont vraies simultanément. Elle répond à ce que la personne voulait réellement. Elle ne ressemble à aucune autre et convertit pourtant. Elle ne dit que ce qui est vrai. Tout ce qu'elle contient fonctionne. Et quelqu'un l'a regardée dans un vrai navigateur avant de dire qu'elle était terminée. Cette compétence est la méthode pour obtenir les cinq, dans n'importe quelle pile technologique, seul ou avec des agents assistants.

Commencez ici : que feront les gens DANS l'application ?

Avant tout appel d'outil, décidez lequel de ces cas vous construisez. Lisez references/01-read-the-request.md si ce n'est pas évident.

La personne demande...	Construisez	Lire
Une application sur une entreprise, une personne, un lieu ou une chose qu'elle vend	Une application de lecture : histoire, preuve réelle donnée, un moyen de les contacter	01, 02, 03, 09, 04, 10
Quelque chose à UTILISER : un tableau de bord, un outil, un portail, "comme Slack mais...", une refonte d'un outil fonctionnel	Une application fonctionnelle : / est l'écran de travail, avec des données de démonstration et, si les gens se connectent, des identifiants de démonstration visibles	01, 05 en premier, puis 03, 09, 04
Une activité (apprendre une langue, s'entraîner pour un examen, planifier, suivre) avec un public et sans nom d'entreprise nommé	Une application fonctionnelle. Pour l'apprentissage : un accueil conçu avec des sections, puis des leçons, des exercices, la progression. PAS une brochure pour une école inventée	01, 05, 09
Une page qui présente un produit existant	Une application de lecture sur ce produit	01, 02, 03, 09, 04, 10

Le mot "site web" dans une demande ne décide pas ; ce sont les mots du propriétaire ("mon académie", "notre boutique") et ce que les gens y feront qui comptent. En cas de doute, construisez l'application fonctionnelle et dites-le dans votre premier message.

La boucle (détails dans references/00-operating-loop.md)

1. Lisez la demande. Écrivez .app-notes/brief.json (faits avec les propres mots de la personne, inconnues, hypothèses) et .app-notes/requirements.json (chaque chose qu'ils disent, maintenant et plus tard). Posez au maximum une question groupée, uniquement si une mauvaise supposition changerait la construction.
2. Recherche et stratégie (à côté de l'étape 3). Étudiez la catégorie réelle, écrivez les neuf réponses stratégiques et la thèse de design. references/02-research-and-strategy.md
3. Tableaux d'inspiration (à côté de l'étape 2). Six tableaux par tour ; chaque tableau est UN design montré comme quatre écrans de la même application, environ 2048 x 1280 ; la personne peut demander plus de tours jusqu'à satisfaction. Les six proviennent de six mondes candidats dans la culture du public, pas de six adjectifs (references/09-design-craft.md section 2). references/03-design-direction.md
4. Concepts, preuves, panel. Un concept par tableau, structurellement différent ; rendez chacun comme une page réelle ; notez-les ; choisissez.
5. Lie la direction. DESIGN.md, tokens.css, fonts.css, vérification du contraste, un plan par page.
6. Planifiez. Pages et sections avec des tâches d'une ligne, fonctionnalités avec des étapes d'acceptation exécutables, images avec des tâches.
7. Construisez. D'abord les fondations, puis les constructeurs de pages en parallèle, puis un intégrateur. Uniquement des tokens, un contenu réel, des images réelles, des contrôles fonctionnels. references/04-build-system.md, et 05-working-apps.md pour les applications fonctionnelles.
8. Vérifiez avec scripts/check-app.mjs sur la build de production : trois tailles, défilez comme le ferait un visiteur, des images, des faits mesurés, un scan de design (contraste, typographie, hiérarchie, texte couvert, ce que dit le générateur), des flux de fonctionnalités, une visite enregistrée. references/06-qa-and-repair.md
9. Critiquez, puis réparez. Jugez d'abord le design sans ancrage ; puis lisez le scan ; puis exécutez les passes nommées (mise en page, composition typographique, colorisation, plus audacieux, renforcement, polissage...) une par une, chacune cadrée, chacune se terminant par des preuves. Corrigez les causes ; revérifiez ; annulez ce qui a empiré. references/09-design-craft.md
10. Polissez par rapport à l'image choisie, puis faites un rapport honnête à partir des seules mesures.

Ne sautez pas les étapes 3, 4, 8 et 9 : ce sont celles où une application cesse d'être un modèle et où "fini" cesse d'être une affirmation. Exécutez les étapes indépendantes ensemble.

Incontournables

1. L'honnêteté prime sur tout. N'inventez jamais de témoignages, logos, presse, évaluations, statistiques, récompenses, membres d'équipe, adresses, e-mails, numéros de téléphone, prix, horaires, délais de réponse, politiques, garanties ou qualifications. Un fait manquant est laissé de côté (par défaut), transformé en invitation, ou marqué une fois avec un <Draft> visible pour le propriétaire. Compter ce que la personne n'a pas listé, c'est inventer. Les données d'exemple dans une application fonctionnelle sont autorisées uniquement parce que l'application indique "Données de démonstration" à l'écran.
2. Rien ne fait semblant de fonctionner. Pas de href="#", pas de formulaire qui ne mène nulle part, pas de bouton désactivé "pas encore connecté", pas de service de formulaire tiers que la personne n'a pas choisi, pas de connexion qui accepte n'importe quoi. Câblez-le pour de vrai ou laissez-le de côté et dites-le.
3. Ne prétendez jamais ce qui n'a pas été mesuré. Pas "testé", "vérifié", "accessible", "poli" ou "responsive" sans preuve pour cette affirmation exacte. "Je n'ai pas pu regarder" n'est jamais "propre". Ne dites jamais que le travail a commencé à moins d'avoir passé l'appel qui le démarre.
4. Décidez l'apparence à partir d'images, avant le code, et construisez selon l'image choisie. Pas d'apparences standard. Refusez les indices IA de premier et deuxième ordre, sauf si le monde de ce client les mérite (09 les liste comme des règles que le script QA mesure ; un résultat review est conservé uniquement avec une raison).
5. Un seul système de design. La couleur, la typographie, le rayon, l'ombre et l'assouplissement proviennent uniquement des tokens. Deux familles de polices au maximum. Un moment signature et une imperfection délibérée. L'accent utilisé avec parcimonie.
6. Les images sont généreuses, dirigées artistiquement et jamais truquées. Environ une par écran de défilement, un style partagé, via le manifeste d'images, un vrai texte alternatif ; pas d'images SVG dessinées à la main d'objets ou de personnes ; pas de lettrage dans les images ; pas d'image IA légendée comme un événement réel.
7. Bonne langue, bon script. lang et dir définis ; script réel (jamais de translittération pour le remplacer) ; propriétés CSS logiques ; les traductions que vous ne pouvez pas vérifier sont signalées au propriétaire.
8. Tout ce que la personne dit est enregistré et utilisé. Les suivis, les orientations et les réponses vont dans le registre des exigences et sont lus par chaque étape ultérieure. Un suivi continue le même projet.
9. La preuve prime sur le code. Chaque affirmation visuelle provient d'une image que vous avez regardée lors de cette exécution, à 390, 768 et 1440.
10. Corrigez les causes, le plus petit changement. Reproduisez, corrigez la cause, revérifiez. Deux correctifs échoués : réécrivez le composant. Un défaut à l'intérieur d'une image générée nécessite une nouvelle image, pas du CSS.

Le kit de démarrage et les scripts

<skill> ci-dessous est le dossier dans lequel se trouve ce SKILL.md (par exemple ~/.claude/skills/ai-website-builder). Exécutez les scripts depuis le dossier du projet.

bash <skill>/scripts/scaffold.sh ./my-app [--app]           # copie le kit de démarrage, installe, lint, build (--app ajoute src/app/ pour une application fonctionnelle)
node <skill>/scripts/contrast.mjs --tokens src/styles/tokens.css   # chaque paire de couleurs qu'un composant utilise, clair et foncé
node <skill>/scripts/optimize-images.mjs --src .app-notes/originals --alt .app-notes/alt.json   # jeu avif + webp et le manifeste
pnpm build && pnpm preview                                  # sert la build DE PRODUCTION (laissez-la tourner)
node <skill>/scripts/check-app.mjs --url http://localhost:4173 --flows .app-notes/flows.json --tour [--extremes]
                                                            # images, faits mesurés, scan de design, flux de fonctionnalités, visite enregistrée, rapport
                                                            # --extremes ajoute 320x640 et 1920x1080 ; --no-design saute le scan

Le script QA a besoin de Playwright (pnpm add -D playwright && npx playwright install chromium) ou --chrome /path/to/chrome. L'optimiseur a besoin de sharp.

assets/template/ est Vite + React 19 + TypeScript + Tailwind v4 avec pré-rendu par route, un contrat de tokens, 18 primitives UI, un kit de mouvement, un kit immersif, un kit d'application et un lint qui échoue la build sur les erreurs habituelles. Son AGENTS.md est la carte de fichiers de référence ; STANDALONE.md dit quoi faire manuellement sans plateforme d'hébergement (jetons d'auteur, créer des images, définir le point de terminaison du formulaire). Pour une application fonctionnelle, utilisez scaffold.sh --app (il écrit src/app/{accounts,db,seed}.ts ; une application à laquelle personne ne se connecte garde demoAccounts vide). Utilisez une autre pile si le projet de la personne en a déjà une : la méthode, les règles et les scripts ne dépendent pas du modèle.

Utilisation d'assistants

Avec un outil de sous-agent, répartissez selon references/08-role-briefs.md et donnez à chaque assistant un périmètre d'écriture disjoint (fondations : fichiers partagés ; constructeurs de pages : un dossier de page chacun ; intégrateur en dernier). Seul, suivez le même ordre. Tenez une liste de tâches partagée : les éléments de la personne sont les leurs à modifier ; ne rendez pas la main tant qu'un élément correspondant à votre partie est ouvert ; à la fin, chaque élément est fait, bloqué avec une note, ou non fait avec une raison.

Le rapport de clôture (à partir des seules mesures)

Ce que vous avez construit (pages, fonctionnalités) ; pour une application fonctionnelle, ce qui est réel et ce qui est simulé ; ce que la personne doit fournir ; ce qui a été vérifié (verdict) et ce qui ne l'a PAS été ; ce qui est encore ouvert en termes simples ; par exigence : construit et vérifié, construit non vérifié, ou non fait et pourquoi. Court, simple, sans ton marketing. Utilisez assets/checklists/done.md avant de l'envoyer.

Carte des références

Fichier	Lisez-le quand
references/00-operating-loop.md	planifier l'exécution, répartir le travail, tenir les registres et la liste de tâches
references/01-read-the-request.md	les dix premières minutes de chaque travail ; application de lecture ou application fonctionnelle ; langue ; affirmations ; suivis
references/02-research-and-strategy.md	rechercher la catégorie, écrire la stratégie et la thèse de design, choisir les squelettes de page
references/03-design-direction.md	tableaux, concepts, mouvements, typographie, lois du craft, indices IA, preuves, panel, fidélité
references/04-build-system.md	écrire du code : tokens, pages, contenu, formulaires, images, mouvement, SEO, accessibilité, budgets
references/05-working-apps.md	tout ce que les gens utilisent : backend de démonstration, connexion, régions, flux, applications d'apprentissage
references/06-qa-and-repair.md	vérifier, juger, réparer, critiquer, le rapport de clôture
references/07-failure-catalogue.md	avant de commencer et avant de faire un rapport : ce qui a mal tourné avant et le remède
references/08-role-briefs.md	brief des agents assistants ; mapper les noms d'outils
references/09-design-craft.md	choisir à quel point pousser (modes visiteur), construire un monde, les paliers de couleur et de typographie, les indices en tant que règles, les passes de raffinement, les deux évaluations, la notation
references/10-copy-and-voice.md	écrire ou réviser les mots sur l'application : voix à partir des faits, règles d'emplacement, les indices de prose générée
references/11-listening-to-the-audience.md	l'étape de recherche : entendre les inquiétudes et les mots du public sans emprunter leurs affirmations
references/12-diagrams.md	une image comment-ça-marche, processus, flux ou architecture ; construite en balisage à partir de tokens
references/13-reference-teardown.md	mesurer jusqu'à trois applications de référence pour le craft et la structure pendant la recherche
references/14-scripts-and-app-jobs.md	polices pour un script non latin ; ce que les visiteurs viennent faire dans chaque type d'application ; ajouts d'accessibilité
references/15-redesign-and-extension.md	une application existe déjà : enregistrez-la, choisissez polissage, restyle ou complet, prouvez que rien n'a été perdu
references/NOTICE.md	crédits et licences des projets publics dont cette compétence a appris
assets/checklists/brief.md, done.md	les formats des registres ; la dernière vérification