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

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

Vérification préalable

Avant la création, confirmez que la demande convient à cette surface :

• Les plugins s'exécutent dans l'éditeur Figma Design.
• Chaque plugin doit fournir une interface fonctionnelle pour son workflow principal. Un plugin sans entrées configurables doit toujours avoir une action primaire claire et un retour d'état ou de validation utile.
• Ne jamais intégrer de clés API, tokens OAuth, URLs signées ou autres secrets. La 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.

Workflow de création

1. Résolvez le workflow demandé et ses contrôles utiles. Posez une question concise uniquement si les entrées requises ou le comportement sont vraiment ambigus.
2. Résolvez planKey. Réutilisez celui fourni par l'utilisateur ; sinon appelez whoami. Utilisez automatiquement le seul plan éligible, ou demandez à l'utilisateur de choisir si 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 source URI. Cela établit le manifest du scaffold, le contrat de message de l'interface, et le point d'entrée TypeScript actuel.
5. Remplacez le scaffold par des fichiers complètement créés pour le comportement et l'interface demandés.
6. Appelez update_generative_plugin avec l'id retourné, un tableau files contenant les remplacements complets pour code.ts et, quand l'interface change, ui.html, ainsi qu'un commitMessage spécifique. Utilisez metadata quand vous changez le nom ou la description.

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

Workflow de mise à jour

1. Identifiez le plugin. Si nécessaire, appelez list_generative_plugins, puis get_generative_plugin.
2. Lisez chaque source URI retourné par l'outil get avant d'éditer. Traitez ces fichiers comme la source de vérité actuelle.
3. Préservez l'interface existante, les contrôles, le comportement de relancement, la validation et les affordances visibles par 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 création

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

Complétion

Rapportez le nom et l'id du plugin, plus la version retournée quand elle est présente et une brève description de son interface et de son action primaire. Construisez et incluez une URL cliquable qui ouvre un nouveau fichier Design avec le plugin non publié prêt à essayer, en utilisant l'id exact du plugin comme try-tool-resource-content-id :

https://www.figma.com/file/new?try-tool-resource-content-id=<id>&try-tool-resource-type=gen_tool&type=design&mode=design

Après avoir présenté le lien du nouveau fichier, demandez si l'utilisateur veut ouvrir le plugin dans un fichier Figma Design existant à la place. Si oui, réutilisez une URL de fichier déjà fournie ou demandez-en une, puis ajoutez les mêmes paramètres de requête try-tool-resource-content-id et try-tool-resource-type à cette URL. Ne devinez jamais l'URL du fichier.