Commandes par exemple

Vous ne tapez pas de noms de commandes sur fastsite. Vous dites ce que vous voulez et l'agent choisit l'outil. Les noms sont tout de même indiqués ici, pour deux raisons : pour que vous puissiez reconnaître ce que votre agent vient de faire à votre site, et pour que vous puissiez être précis dans les cas où cela compte. Si aucun client n'est encore connecté, commencez par connecter votre agent puis revenez ici.

Les deux commandes d'ouverture

Deux commandes méritent d'être connues par leur nom, car chaque session commence par elles.

Lister mes sites.	list_sites — retourne les identifiants. Un identifiant de site est le premier argument de presque toutes les autres commandes, c'est ainsi qu'une session prend ses repères.
Lire le guide de création pour le site blog, puis rédiger la page.	get_authoring_guide — les règles que l'audit de build applique réellement, intégrées avec les paramètres régionaux et la syntaxe d'intégration du site. Un agent qui le lit produit un balisage qui se publie. Celui qui devine produit un balisage qui est rejeté.

Vos dix premières minutes

Du moteur vide à la page publiée. Dites ces étapes une à une et lisez ce qui revient avant de continuer.

1. Créer un site appelé Notes sur notes.example.com. create_site vous donne un identifiant pour tout adresser ensuite.
2. Lire le guide de création pour ce site. get_authoring_guide. Faites-le avant toute rédaction ou conception, pas après le premier rejet.
3. Afficher les fichiers du shell. shell_list_files — les templates Twig et les jetons CSS qui encadrent chaque page.
4. Prendre un instantané du shell, puis assombrir l'en-tête. shell_snapshot, puis shell_put_file. Les instantanés sont peu coûteux et en restaurer un ne prend qu'une seule commande.
5. Rédiger une courte page À propos. create_page. Elle arrive en tant que brouillon.
6. Prévisualiser le site. preview_site effectue le build sans déployer et renvoie une URL. L'audit de build s'exécute ici, c'est donc là que le mauvais balisage apparaît.
7. Publier. publish_site. Un seul commit git, en ligne derrière le CDN.

Contenu

Qu'est-ce que j'ai sur le blog ?	list_posts
Montrer le post 14.	get_post — inclut le corps HTML, ce dont vous avez besoin avant de demander une modification.
Écrire un post sur la sortie, le publier.	create_post
Ajouter une page de tarifs.	create_page — la même chose sans date. Les slugs peuvent être imbriqués, donc help/getting-started fonctionne si vous conservez une ancienne structure d'URL.
Resserrer la seconde moitié de ce post et corriger le titre.	update_post — seuls les champs qu'il envoie sont modifiés.
Supprimer l'ancienne page de lancement.	delete_content — corbeille, pas supprimé définitivement. Le prochain build retire la page.

Recherche et vérification

Les deux font appel à un modèle ancré sur le web, donc ils prennent un moment et en valent la peine pour tout ce qui contient un chiffre.

Rechercher ce qui a changé dans les règles d'accessibilité de l'UE cette année avant de rédiger.	research — un dossier structuré avec chiffres et sources, à partir duquel rédiger. Les sources d'abord, le brouillon ensuite.
Vérifier les faits de ce post.	fact_check — verdicts par affirmation avec sources, conservés sur la ligne de contenu. Conçu pour les prix et les statistiques. À activer par site.

Médias

Importer cette image et l'utiliser comme image mise en avant.	upload_media_from_url. Le texte alternatif est requis lors de l'importation, et les images sont intégrées par identifiant média — une URL d'image externe dans un corps fait échouer le build.
Qu'y a-t-il dans la médiathèque ?	list_media
Supprimer l'ancienne capture d'écran.	delete_media, réversible avec restore_media. purge_media est celui qui supprime les fichiers définitivement.

Design

Le shell est le cadre autour de chaque page : templates Twig, jetons CSS, chaînes de traduction. Le contenu ne porte jamais son propre style, c'est donc ici qu'une refonte se produit.

Qu'y a-t-il dans le shell ?	shell_list_files
Afficher le template de base.	shell_get_file
Rendre la couleur d'accent plus chaude sur tout le site.	shell_put_file sur le fichier de jetons — généralement une modification d'une seule ligne qui recolore tout. Validé à l'écriture, déclenche un rebuild.
Prendre un instantané du shell d'abord.	shell_snapshot
Remettre comme c'était avant.	shell_restore — et une restauration prend elle-même un instantané au préalable, donc annuler une annulation fonctionne.

Composants

Construire un composant tableau de tarifs.	upsert_component — HTML ou React. Le build le convertit en balisage statique, donc rien n'est livré en JavaScript.
Quels composants ce site possède-t-il ?	list_components, et delete_component pour en supprimer un.

Langues

Ajouter l'allemand et tout traduire.	add_language — ajoute la locale et met en file d'attente la traduction.
Rafraîchir les traductions, j'ai modifié trois pages.	translate_site, qui publie une fois terminé.
Mettre un sélecteur de langue dans l'en-tête.	get_language_switcher retourne le marqueur et le balisage. Le placement vous appartient — rien n'est inséré automatiquement.
Supprimer le suédois.	remove_language — supprime les traductions et les pages de la locale, puis reconstruit.

Publication

Prévisualiser.	preview_site — effectue le build, exécute l'audit, ne déploie rien.
Publier.	publish_site — retourne un job à surveiller.
C'est terminé ?	get_build_status
Qu'est-ce qui a été construit récemment ?	list_jobs — builds, publications et traductions, les plus récents en premier.

Routage et scripts du site

Rediriger l'ancienne URL de tarifs vers la nouvelle.	upsert_redirect. list_redirects affiche également les erreurs 404 capturées, ce qui est le meilleur point de départ.
Supprimer cette redirection.	delete_redirect
Ajouter le snippet d'analytics.	upsert_script — en-tête ou corps, défini au niveau du site plutôt que collé dans un corps. list_scripts et delete_script pour le reste.

Annuler des actions

Trois filets de sécurité distincts, à trois niveaux différents.

Qu'y a-t-il dans la corbeille ?	list_trash, puis restore_content. purge_content est celui qui est permanent.
Restaurer le shell à la révision d'hier.	shell_restore — design uniquement, aucun contenu touché.
Sauvegarder le site.	backup_site, list_backups, restore_backup — le site entier, base de données incluse. Une restauration reconstruit et publie.

Sites, équipes et identifiants

Créer un site pour le nouveau client.	create_site
Changer l'URL de base et la branche git.	update_site — c'est également là que se trouvent le mode de service, l'hôte canonique et l'option de vérification des faits.
Ajouter mon token GitHub pour que cela puisse publier.	add_github_credential, avec list_github_credentials et delete_github_credential. Les tokens sont stockés chiffrés et ne sont jamais retournés.
Inviter mon designer.	create_team, invite_member, accept_invite, list_teams.

Webhooks

Qu'est-ce qui peut poster dans ce site ?	list_webhooks — liste également les mappeurs intégrés, qui sont ce qui transforme un payload entrant en post ou en page.
Me donner un endpoint vers lequel mon automatisation peut poster des brouillons.	create_webhook
Est-ce que ça a été déclenché ?	webhook_deliveries

Le fonctionnement complet se trouve sur la page webhooks.

Quand une commande retourne une erreur

Les échecs reviennent sous forme de messages lisibles plutôt que d'erreurs de transport, ce qui signifie que votre agent peut généralement lire le message et se corriger. Demandez-lui de le faire. Les trois que vous rencontrerez en premier :

• Le corps a été rejeté. Le contenu est du corps HTML uniquement — pas de <script>, pas de styles inline, pas d'images externes. Dites à l'agent de lire le guide de création et de réécrire.
• Une image a fait échouer le build. Les images doivent d'abord être importées et référencées par identifiant média, avec un texte alternatif. Une URL en hotlink ne passe jamais.
• Rien n'a changé sur le site en ligne. Rédiger n'est pas publier. Demandez publish_site, ou vérifiez get_build_status si vous l'avez déjà fait.

Le protocole sous-jacent — découverte, portées, durées de vie des tokens, le catalogue d'outils faisant autorité pour votre version — se trouve sur la référence MCP. Vous préférez le HTTP simple ? L'API REST couvre le même terrain avec une clé API.