Créer et mettre à jour des shaders Figma

Chargez cette skill avant chaque appel create_shader ou update_shader. Elle couvre l'authoring de shaders de la library de compte via le serveur Figma MCP. La lecture ou l'application d'un shader existant ne nécessite pas cette skill.

Les shaders ont deux types :

• effect échantillonne et transforme la couche rendue en dessous. Utilisez-le pour le flou, la distorsion, la lueur, l'étalonnage des couleurs, la pixellisation, la trame ou autre post-traitement.
• fill génère des pixels sans raster d'entrée. Utilisez-le pour les dégradés, les motifs, le bruit, les textures et les arrière-plans procéduraux.

Ne changez pas silencieusement de type lors d'une mise à jour. Le kind passé à update_shader doit correspondre au shader existant.

Flux de création

1. Décidez si la demande est un effect ou un fill. Posez la question uniquement si l'intention visuelle ne résout pas la distinction.
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 quand plusieurs plans matériellement différents sont disponibles.
3. Appelez create_shader une seule fois avec un nom concis, une description, le kind sélectionné et planKey. Cela crée un scaffold de démarrage, pas le shader final demandé.
4. Appelez get_shader avec l'id retourné, puis lisez chaque URI source. Si le client ne peut pas lire les ressources MCP, appelez get_shader avec includeSource: true à la place. Cela établit les imports runtime et le contrat de métadonnées fixe du scaffold.
5. Rédigez le remplacement complet main.ts pour le résultat demandé.
6. Appelez update_shader avec l'id retourné, le même kind, files: [{ path: "main.ts", content: "..." }], et un commitMessage spécifique. Utilisez metadata quand vous modifiez le nom ou la description.

N'arrêtez jamais après create_shader : le scaffold de démarrage est seulement un point de départ structurel.

Flux de mise à jour

1. Identifiez le shader avec list_shaders, puis appelez get_shader. Utilisez son type (effect ou fill) comme kind de mise à jour requis.
2. Lisez chaque URI source retourné par get_shader avant de modifier. Si le client ne peut pas lire les ressources MCP, appelez-le avec includeSource: true. Traitez ces fichiers comme la source de vérité actuelle.
3. Conservez les contrôles et le comportement existants sauf si l'utilisateur demande de les modifier.
4. Appelez update_shader avec le main.ts de remplacement complet dans le tableau files, pas un diff ou un fragment partiel. Un tableau files vide est valide uniquement pour une mise à jour de métadonnées uniquement.

Règles d'authoring

• Avant d'écrire le remplacement main.ts, lisez Shader source authoring. Il contient la forme de module requise, le cycle de vie WebGPU, les schémas de paramètres supportés, les règles alpha effect/fill, et la checklist des défaillances WGSL.
• Les shaders rédigés via ces outils MCP doivent être statiques. update_shader remplace seulement main.ts ; il ne peut pas changer le features.json du scaffold, où les capacités d'animation et de souris restent désactivées. Ne lisez pas les entrées temps ou souris et ne prétendez pas qu'elles sont supportées. Si l'utilisateur demande une animation, construisez le shader statique uniquement après avoir expliqué que ses propriétés exposées peuvent à la place être animées en keyframe en mode Motion.
• Exposez des contrôles pour les valeurs que les utilisateurs sont susceptibles d'ajuster par couche ; codez en dur les détails d'implémentation.
• Gardez les plages numériques délimitées et les valeurs par défaut visuellement utiles.
• Pour les effects, échantillonnez le raster d'entrée intentionnellement. Pour les fills, ne supposez pas qu'un raster d'entrée existe.
• Traitez un résultat non-erreur de update_shader comme un succès. Enregistrez la version retournée si présente ; une réponse réussie peut l'omettre.
• Sur une erreur de compilation, utilisez la sortie du compilateur retournée pour faire la correction source minimale et réessayez une seule fois. Si cela échoue toujours, signalez l'erreur au lieu de réécrire le shader à plusieurs reprises.

Achèvement

Signalez le nom, le type et l'id du shader, ainsi que la version retournée si présente. Identifiez brièvement les contrôles ou le comportement qui ont été ajoutés.