metyatech/skill-release-publish

Workflow de release et publication

Métadonnées des dépôts publics

• Pour un dépôt public, l'agent DOIT définir la Description, les Topics et la page d'accueil GitHub.
• Un dépôt public DOIT contenir : .github/workflows/ci.yml, des templates d'issues, un template de PR, SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md et CHANGELOG.md.
• La CI DOIT exécuter les commandes standard de lint, test et build du dépôt.

Gestion des versions et flux de release

• L'agent DOIT mettre à jour les métadonnées de version lorsque le contenu de la release change et DOIT garder la version du package et le tag Git cohérents.
• Lorsqu'on lui demande de choisir une version, l'agent DOIT la décider lui-même.
• Lors de l'incrémentation d'une version, l'agent DOIT créer la GitHub Release et publier le package dans la même mise à jour.
• Pour la publication npm sur les packages appartenant à metyatech, l'agent DOIT exécuter npm publish directement. Un token d'automatisation est configuré.
• Pour les autres packages, l'agent DOIT demander à l'utilisateur d'exécuter npm publish.
• Avant de publier, l'agent DOIT exécuter les commandes de préparation requises (npm install, npm test, npm pack --dry-run, etc.) et ne DOIT procéder que lorsque tout est prêt.
• Si l'authentification échoue pendant la publication, l'agent DOIT demander à l'utilisateur de terminer l'étape de publication.
• L'agent DOIT exécuter des vérifications de sécurité des dépendances avant chaque release, DOIT traiter les problèmes critiques et DOIT rapporter les résultats.

Vérification post-publication

Après la publication, l'agent DOIT mettre à jour toute copie installée localement vers la nouvelle release publiée et DOIT vérifier la version résolue. L'agent NE DOIT PAS signaler "terminé" tant que cette vérification n'est pas achevée (ou que l'utilisateur ne refuse pas explicitement).

L'agent DOIT exprimer la vérification comme des critères d'acceptation explicites avec des résultats (PASS / FAIL / N/A) et des preuves :

• AC1 (registre) — vérifier que la version publiée existe dans le registre (ex. npm view <pkg> version).
• AC2 (installation fraîche) — vérifier que le dernier package se résout et s'exécute (ex. npx <pkg>@latest --version).
• AC3 (mise à jour globale, le cas échéant) — si le package est installé globalement, le mettre à jour vers la version publiée et vérifier (ex. npm ls -g <pkg> --depth=0, npm i -g <pkg>@latest, puis <cmd> --version). Si AC3 ne s'applique pas, l'agent DOIT le marquer comme N/A et indiquer explicitement la raison.

Pour les CLI npm :

• Si installé globalement : vérifier npm ls -g <pkg> --depth=0, mettre à jour via npm i -g <pkg>@latest, puis vérifier avec <pkg> --version.
• Si non installé globalement : ignorer la mise à jour globale et vérifier la disponibilité via npx <pkg>@latest --version (ou l'équivalent écosystème).

Topics standards des dépôts

L'agent DOIT attribuer des topics issus de l'ensemble standard ci-dessous. Chaque dépôt DOIT avoir au moins un topic standard lorsque applicable. Un dépôt qui ne correspond à aucun topic standard DOIT utiliser des topics descriptifs pertinents pour son domaine.

• agent-skill — le dépôt contient un SKILL.md (une compétence d'agent installable).
• agent-tool — outil CLI ou serveur MCP utilisé par des agents (ex. task-tracker, agents-mcp, compose-agentsmd).
• agent-rule — source de règles ou dépôt de règles (ex. agent-rules).
• unreal-engine — plugin Unreal Engine ou projet exemple.
• qti — outil ou bibliothèque de l'écosystème d'évaluation QTI.
• education — contenu de cours, matériel pédagogique ou plateforme destinée aux étudiants.
• docusaurus — plugin ou extension Docusaurus.

Des topics descriptifs supplémentaires (langage, framework, mots-clés de domaine) PEUVENT être ajoutés librement en complément des topics standards. L'agent DOIT revoir et mettre à jour l'ensemble des topics standards lorsque le paysage des dépôts change de manière significative. L'agent DOIT vérifier que les topics sont définis dans le cadre du contrôle de conformité des nouveaux dépôts.

Exigences relatives aux artefacts publiés

• L'agent DOIT renseigner les métadonnées du package (name, description, repository, issues, homepage, engines).
• L'agent DOIT valider les points d'entrée exécutables et les shebangs requis pour que les commandes installées fonctionnent.
• Si un dépôt représente un outil ou produit unique, l'agent DOIT publier un seul package (en regroupant les scripts associés).