Créer et mettre à jour des plugins Figma génératifs

Chargez cette skill avant chaque appel create_generative_plugin ou update_generative_plugin. En langage utilisateur, appelez le résultat un « plugin ». Le qualificatif « générative » distingue uniquement cet outil de la bibliothèque de compte des autres systèmes de plugins.

Vérification préalable

Avant de rédiger, confirmez que la demande correspond à cette surface :

• Les plugins s'exécutent dans l'éditeur Figma Design.
• Chaque plugin doit fournir une interface utilisateur fonctionnelle pour son flux de travail principal. Un plugin sans entrées configurables nécessite toujours une action primaire claire et une rétroaction utile de statut ou de validation.
• Ne jamais intégrer de clés API, tokens OAuth, URLs signées ou autres secrets. Le code source du plugin est lisible par les personnes qui y ont accès. Pour les intégrations authentifiées, arrêtez-vous et proposez un dataset statique, un endpoint public sans authentification, ou une architecture différente.

Flux de création

1. Résolvez le flux de travail demandé et ses contrôles utiles. Posez une question concise uniquement si les entrées requises ou le comportement sont véritablement ambigus.
2. Résolvez planKey. Réutilisez-en une fournie par l'utilisateur ; sinon appelez whoami. Utilisez automatiquement le seul plan admissible, ou demandez à l'utilisateur de choisir quand plusieurs plans matériellement différents sont disponibles.
3. Appelez create_generative_plugin une seule fois avec un nom concis, une description, et planKey. Cela crée un scaffold de dessin de carré exécutable, pas le plugin final demandé.
4. Appelez get_generative_plugin avec l'id retourné, puis lisez chaque URI source. Cela établit le manifest du scaffold, le contrat de message UI, et le point d'entrée TypeScript actuel.
5. Remplacez le scaffold par des fichiers créés complets pour le comportement et l'interface utilisateur demandés.
6. Appelez update_generative_plugin avec l'id retourné, un array files contenant les remplaçants complets pour code.ts et, quand l'UI change, ui.html, plus un commitMessage spécifique. Utilisez metadata pour changer le nom ou la description.

Ne vous arrêtez jamais après create_generative_plugin : le starter doit être remplacé par l'expérience demandée.

Flux de mise à jour

1. Identifiez le plugin. Si nécessaire, appelez list_generative_plugins, puis get_generative_plugin.
2. Lisez chaque URI source retourné par l'outil get avant de modifier. Traitez ces fichiers comme la source de vérité actuelle.
3. Préservez l'interface utilisateur existante, les contrôles, le comportement de relancement, la validation, et les affordances visibles à l'utilisateur sauf si l'utilisateur demande de les changer.
4. Appelez update_generative_plugin avec le contenu de remplacement complet pour chaque fichier existant modifié. Utilisez { path: "code.ts", content: "..." } pour le point d'entrée et { path: "ui.html", content: "..." } pour l'interface. Les fichiers non spécifiés sont préservés.

Règles de rédaction

• Avant d'écrire les fichiers de remplacement, lisez Plugin source authoring. Cela couvre le contrat de remplacement de fichier, le cycle de vie UI/message, les contrôles PropsKit, la compatibilité des pages dynamiques, les fonts, le comportement de relancement, le travail borné, la géométrie, et les pièges de Plugin API.
• Rendez l'action primaire du plugin évidente et clarifiez les états de sélection invalides ou d'entrée.
• update_generative_plugin peut remplacer les fichiers code.ts et ui.html existants, mais ne peut pas remplacer manifest.json ni créer de nouveaux fichiers. Conservez figma.showUI(__html__, ...) dans code.ts et remplacez ui.html quand le flux de travail demandé nécessite des contrôles différents.
• Évitez les modifications destructrices du canvas sauf si c'est le but explicite du plugin et que l'interface le rend clair.
• Ne fermez pas avant que le travail asynchrone et les messages UI aient été complétés.
• Traitez un résultat update_generative_plugin sans erreur comme un succès. Enregistrez la version retournée si elle est présente ; une réponse réussie peut l'omettre.
• En cas d'erreur de compilation, utilisez la sortie du compilateur retournée pour faire la correction source la plus petite et réessayez une fois. Si elle échoue toujours, surfacez l'erreur au lieu de réécrire à plusieurs reprises le plugin.

Achèvement

Signalez le nom et l'id du plugin, plus la version retournée si elle est présente et une brève description de son interface et de son action primaire.