thierryc/glyphs3-to-glyphs4-skill

Migrer un plug-in Glyphs 3 vers Glyphs 4

Créez une copie migrée et révisable d'un plug-in Python. Considérez la migration statique comme une préparation en vue d'un test de lancement manuel dans Glyphs 4, et non comme une preuve de compatibilité runtime.

Garde-fous

• Préservez le plug-in ou le dépôt d'origine.
• Ne migrez jamais sur place. Refusez un chemin de sortie existant.
• N'installez, n'exécutez, ne rechargez, ne redémarrez jamais Glyphs, et ne modifiez jamais un dossier Plugins actif, sauf si l'utilisateur le demande explicitement.
• Utilisez les outils docs_search et docs_get de Glyphs MCP comme base de connaissances de développement principale. Les espaces de noms des outils varient selon le client ; résolvez-les par leurs noms d'outils finaux et leurs descriptions.
• Récupérez les directives officielles ciblées avant de modifier les API GlyphsApp, les méthodes de cycle de vie des plug-ins, les sélecteurs, les callbacks, les métadonnées de bundle ou la gestion des formes.
• N'appelez pas docs_enable_page_resources pour un travail normal. Récupérez les pages à la demande.
• Préférez la branche actuelle Glyphs4 de schriftgestalt/GlyphsSDK ; ne supposez pas qu'un modèle Glyphs 3 ou un chargeur en cache est à jour.
• Séparez les changements comportementaux des changements de migration mécanique.

Flux de travail de la base de connaissances Glyphs MCP

Lisez references/glyphs-mcp-development-kb.md avant d'examiner les résultats spécifiques à l'API.

1. Confirmez que docs_search et docs_get sont disponibles depuis le serveur Glyphs MCP.
2. Établissez une base de référence documentaire avant toute édition :
   • Recherchez plugins et récupérez le résultat du manuel officiel des plug-ins.
   • Recherchez Info.plist et récupérez l'aperçu du modèle de plug-in Python et le modèle plist.
   • Recherchez la classe de base exacte, par exemple GeneralPlugin, ReporterPlugin, FilterWithoutDialog, PalettePlugin, SelectTool ou FileFormatPlugin ; récupérez son guide, son modèle source et la section API du plug-in correspondante.
3. Recherchez chaque classe, propriété, callback ou sélecteur non familier séparément. Préférez les symboles exacts courts comme GSLayer, shapes ou addCallback.
4. Récupérez les résultats via le doc_id ou path renvoyé. Si truncated est vrai, continuez à partir de nextOffset jusqu'à ce que la section pertinente soit complète.
5. Enregistrez le titre, docId, sourceKind, sourceUrl de chaque page récupérée, ainsi que la décision de migration qu'elle soutient. Incluez ces preuves dans la transmission.
6. Si les outils ne sont pas disponibles, signalez que la révision de la documentation Glyphs MCP est bloquée. Un audit statique peut continuer, mais ne présentez pas de modifications d'API ou de cycle de vie non vérifiées comme étant prêtes pour la migration.

Flux de travail

1. Résolvez le plug-in ou le dépôt source, la cible de compatibilité prévue (Glyphs 4 uniquement ou Glyphs 3 et 4), et un nouveau chemin de sortie.

2. Connectez-vous à la base de connaissances de développement Glyphs MCP et récupérez les pages de base pour la famille de plug-ins détectée.

3. Obtenez ou localisez une copie à jour de la branche officielle Glyphs4 de GlyphsSDK.

4. Auditez avant de copier :

   python3 scripts/migrate_plugin.py "/chemin/vers/source" \
     --sdk "/chemin/vers/GlyphsSDK"
   

5. Lisez references/migration-review.md. Pour chaque résultat spécifique à l'API, recherchez dans la documentation Glyphs fournie cette classe, propriété, callback, sélecteur ou type de plug-in et récupérez uniquement les pages pertinentes.

6. Créez la copie migrée et appliquez des correctifs de framework d'import conservateurs :

   python3 scripts/migrate_plugin.py "/chemin/vers/source" \
     --output "/chemin/vers/nouvelle-copie-glyphs4" \
     --sdk "/chemin/vers/GlyphsSDK" \
     --apply-safe-fixes
   

7. Utilisez les réécritures optionnelles uniquement après avoir examiné leur impact :

   • Ajoutez --rewrite-wildcard-imports pour remplacer les instructions from GlyphsApp import * simples en utilisant les symboles trouvés dans le fichier .pyi de Glyphs 4.
   • Ajoutez --replace-loader pour copier le modèle Contents/MacOS/plugin du SDK dans chaque bundle.
   • Ajoutez --align-glyphs4-plist pour supprimer les clés de flux de mise à jour héritées absentes des modèles Glyphs 4 actuels. Confirmez d'abord que le plug-in ne dépend pas de son propre flux de mise à jour.

8. Examinez le rapport de migration généré et la diff complète du code source. Corrigez manuellement les problèmes de cycle de vie, d'API, de dépendances, d'interface utilisateur ou de formes mixtes. Liez chaque modification spécifique à l'API à une page de la base de connaissances récupérée.

9. Validez chaque bundle :

   • Analysez tous les fichiers Python avec la version Python prévue de Glyphs.
   • Exécutez plutil -lint sur chaque Contents/Info.plist.
   • Confirmez que NSPrincipalClass, PyMainFileNames et la classe Python principale sont cohérents.
   • Comparez la structure du bundle avec le modèle SDK Glyphs 4 actuel correspondant.
   • Recompilez les fichiers .xib lorsque leur interface a changé.

10. Transmettez un plan de test manuel. Testez une copie jetable dans Glyphs 4, exercez chaque entrée de menu et callback, inspectez la sortie du Macro Panel et de la Console, et testez les chemins d'annulation, d'exportation, de dessin et de dépendances pertinents pour le plug-in.

Décision de compatibilité

• Pour Glyphs 4 uniquement, autorisez les API et la syntaxe Python supportées par le runtime Glyphs 4 après les avoir confirmées dans les stubs actuels.
• Pour Glyphs 3 et 4, conservez un chemin de code partagé lorsque c'est pratique, séparez les vraies différences d'API avec des vérifications de capacité, et testez les deux applications. N'ajoutez pas de syntaxe propre à Glyphs 4 uniquement à des fins d'annotations.
• Si le plug-in reconstruit layer.paths, layer.components ou layer.shapes, inspectez s'il doit préserver l'ordre des formes mixtes ou des types de formes plus récents. Ne déduisez jamais qu'une réécriture uniquement basée sur les chemins est sans perte.

Livrables

Retournez la nouvelle copie, le rapport de migration, la cible de compatibilité, les résultats de validation statique et les tests Glyphs 4 manuels restants. Incluez un tableau de preuves documentaires avec le titre de chaque page, le docId Glyphs MCP, le sourceUrl officiel et la décision qu'elle soutient. Indiquez clairement qu'aucune installation en direct ou test runtime n'a eu lieu, sauf si cela a réellement été le cas.

Ressources

• scripts/migrate_plugin.py : assistant d'audit et de copie non destructive.
• references/migration-review.md : liste de contrôle de révision basée sur les preuves et points d'escalade.
• references/glyphs-mcp-development-kb.md : protocole exact de recherche MCP, pagination, preuves et récupération.
• .mcp.json : connexion du plug-in Claude Code au serveur Glyphs MCP local.
• mcp.json : connexion du plug-in Cursor au serveur Glyphs MCP local.
• .claude-plugin/plugin.json : métadonnées de la communauté/plugin Claude Code ; chargez ce dossier avec claude --plugin-dir.
• .cursor-plugin/plugin.json : métadonnées du plugin Cursor qui enregistrent le SKILL.md racine et mcp.json.
• agents/openai.yaml : métadonnées d'affichage Codex et dépendance Glyphs MCP.