Ovid/paad

Début

Annoncer : "Préparation d'une release paad…"

Lire @CLAUDE.md.

make release et make tag gèrent tout ce qui est mécanique : la promotion de preview/paad vers plugins/paad, la rotation du changelog, la réécriture de version dans chaque manifeste et ligne d'annonce des deux arbres, la régénération des exports, la suite de tests complète, et le tag annoté. Ce skill possède les parties qu'un Makefile ne peut pas décider — quel numéro incrémenter, si une release est même souhaitée, et si effectivement ce que les utilisateurs installent fonctionne après coup.

Ne jamais éditer manuellement plugin.json, marketplace.json, package.json, une ligne d'annonce de SKILL.md, ou les en-têtes de version et références de liens du changelog. Ceux-ci sont générés. Si le résultat généré est incorrect, corrigez le générateur.

Ne jamais éditer manuellement plugins/paad du tout. Il est écrit uniquement par promotion. Une édition manuelle ici ne survit pas : make release commence par make promote, dont rsync -a --delete copie le preview/paad pré-correction directement par-dessus. Rien ne le rattrape — l'arbre est commité donc le garde-fou de répertoire sale passe, et le résultat est auto-cohérent donc chaque vérification passe. La release est livrée et le changelog annonce une correction qui n'y est pas. Les correctifs vont dans preview/paad, hotfix inclus.

digraph release {
    "Lire [Unreleased]" [shape=box];
    "Y a-t-il quelque chose ?" [shape=diamond];
    "STOP — demander si une release est souhaitée" [shape=box, style=bold];
    "Entrées dans la règle de longueur ?" [shape=diamond];
    "STOP — d'abord réduire, dans son propre commit" [shape=box, style=bold];
    "Proposer MAJEUR/MINEUR/CORRECTIF avec justification" [shape=box];
    "L'utilisateur confirme la version ?" [shape=diamond];
    "Toute compétence preview dans le README ?" [shape=diamond];
    "STOP — ajouter l'entrée README comme son propre commit" [shape=box, style=bold];
    "Sur une branche ?" [shape=diamond];
    "Créer une branche de release" [shape=box];
    "make release VERSION=X.Y.Z" [shape=box];
    "Réussite ?" [shape=diamond];
    "STOP — signaler l'échec et l'état à moitié appliqué" [shape=box, style=bold];
    "Lire git diff plugins/ — le contenu" [shape=box];
    "Afficher le diff, obtenir l'approbation" [shape=box];
    "Commiter, fusionner dans main, pousser" [shape=box];
    "make tag" [shape=box];
    "Déléguer la vérification dans l'application" [shape=doublecircle];

    "Lire [Unreleased]" -> "Y a-t-il quelque chose ?";
    "Y a-t-il quelque chose ?" -> "STOP — demander si une release est souhaitée" [label="vide"];
    "Y a-t-il quelque chose ?" -> "Entrées dans la règle de longueur ?" [label="entrées"];
    "Entrées dans la règle de longueur ?" -> "STOP — d'abord réduire, dans son propre commit" [label="non"];
    "Entrées dans la règle de longueur ?" -> "Proposer MAJEUR/MINEUR/CORRECTIF avec justification" [label="oui"];
    "Proposer MAJEUR/MINEUR/CORRECTIF avec justification" -> "L'utilisateur confirme la version ?";
    "L'utilisateur confirme la version ?" -> "Proposer MAJEUR/MINEUR/CORRECTIF avec justification" [label="non"];
    "L'utilisateur confirme la version ?" -> "Toute compétence preview dans le README ?" [label="oui"];
    "Toute compétence preview dans le README ?" -> "STOP — ajouter l'entrée README comme son propre commit" [label="non"];
    "Toute compétence preview dans le README ?" -> "Sur une branche ?" [label="oui"];
    "Sur une branche ?" -> "Créer une branche de release" [label="sur main"];
    "Sur une branche ?" -> "make release VERSION=X.Y.Z" [label="sur une branche"];
    "Créer une branche de release" -> "make release VERSION=X.Y.Z";
    "make release VERSION=X.Y.Z" -> "Réussite ?";
    "Réussite ?" -> "STOP — signaler l'échec et l'état à moitié appliqué" [label="non"];
    "Réussite ?" -> "Lire git diff plugins/ — le contenu" [label="oui"];
    "Lire git diff plugins/ — le contenu" -> "Afficher le diff, obtenir l'approbation";
    "Afficher le diff, obtenir l'approbation" -> "Commiter, fusionner dans main, pousser";
    "Commiter, fusionner dans main, pousser" -> "make tag";
    "make tag" -> "Déléguer la vérification dans l'application";
}

1. Lire ce qui est réellement non publié

Lire la section ## [Unreleased] de CHANGELOG.md.

Si elle est vide, s'arrêter et demander. Il n'y a rien à publier. N'inventez pas une version à incrémenter, et ne fouillez pas git log pour des choses qui aur dû être enregistrées — un changement non enregistré est un bug de changelog à corriger d'abord, dans son propre commit, pas quelque chose à intégrer dans une release.

1.5. Vérifier les entrées contre la règle de longueur

CLAUDE.md la définit : 1 à 3 lignes par entrée, au maximum 8 pour une nouvelle compétence, se terminant par un pointeur vers paad-help ou le README. Une fois que cette section devient un en-tête de version, elle est publiée, et la réduire après signifie éditer l'historique publié. Rattrapez-la ici.

Lire chaque puce et demander ce qu'elle fait :

Dans l'entrée	Verdict
Ce qui a changé, qui cela affecte, quoi faire	Conserver
Un pointeur vers paad-help ou le README	Conserver
Comment la fonctionnalité fonctionne en interne — phases, agents, portes	Couper
Pourquoi la conception est correcte, ou ce qui a été rejeté	Couper
Preuve de test, nombre d'exécutions, avant/après mesuré	Couper

Le test de CLAUDE.md : si cela explique un mécanisme, c'est dans le mauvais fichier. Ce matériel vaut la peine d'être conservé — il appartient dans le message de commit, dans le README, ou dans paad-help, qui existent déjà. Une copie dans le changelog est une troisième copie qui doit être synchronisée manuellement et dérive.

Vérifier la taille :

awk '/^## \[/{if(n)print len" lignes  "n; n=$0; len=0; next} {len++} END{print len" lignes  "n}' CHANGELOG.md | head -5

Une section dépassant ~40 lignes pour une release normale est le signal. Les sections dans l'historique de ce fichier atteignent 200 lignes ; ce sont les erreurs, pas le précédent.

Si les entrées sont trop longues, s'arrêter et le dire. La réduction est son propre commit avant la release, exactement comme une entrée manquante — pas une modification silencieuse pendant celle-ci, et pas quelque chose à intégrer dans le commit de release. Proposer le texte raccourci, obtenir l'approbation, le commiter, puis recommencer à l'étape 1.

2. Proposer la version

Semver par rapport à ce qui est dans [Unreleased], pas par rapport à la quantité de travail ressentie :

Changement	Incrément
Une nouvelle compétence, ou un nouveau comportement visible par l'utilisateur dans une existante	MINEUR
Uniquement des corrections de formulation, de digraphe ou de bug	CORRECTIF
Une compétence renommée ou supprimée	rupture — le dire explicitement

paad est resté sur 1.x. Un changement de rupture est toujours signalé dans le changelog même si le majeur ne bouge pas ; soulevez-le et laissez Ovid décider.

Indiquez votre raisonnement et le numéro proposé, puis attendez la confirmation. Ne procédez pas avec une version que vous avez choisie unilatéralement.

Note pour les compétences expérimentales (agentic-dedup, test-roadmap) : leurs arguments et leur sortie peuvent changer dans n'importe quelle release, y compris un correctif, donc un changement de rupture sur l'une d'elles ne force pas un majeur.

2.5. Vérifier que le README couvre tout ce que preview est sur le point de livrer

check-readme s'exécute sur l'arbre livré, et la promotion est ce qui met une compétence exclusivement preview là. Donc une compétence qui est restée dans preview/ sans entrée README passe toutes les vérifications jusqu'à ce que la release la promeuve — et puis échoue make test à la toute fin de make release, avec le rsync, la rotation du changelog et les chaînes de version des deux arbres déjà écrites, et make release incapable de se ré-exécuter sur l'arbre sale qu'il vient de créer.

make promote exécute maintenant check-readme TREE=preview/paad avant son rsync, donc cela fait échouer la release avant que quoi que ce soit soit écrit plutôt qu'après. Exécutez-le en amont de toute façon — le savoir à l'étape 2.5 coûte une seconde, et le découvrir à l'étape 3 signifie recommencer :

make check-readme TREE=preview/paad

Tout ce qui est listé, s'arrêter. Écrire l'entrée README comme son propre commit sur cette branche, puis recommencer à l'étape 1. Cela ne coûte rien là et fusionne avec la release, donc le README ne fait jamais la promotion d'une compétence que personne ne peut installer. Il en va de même pour une entrée paad-help manquante, bien que check-help s'exécute par arbre et l'aurait déjà rattrapée.

3. La lancer

Confirmer que vous êtes sur une branche, pas sur main — make release refuse sur main, mais dites-le avant d'exécuter plutôt qu'après.

Créer la branche de release à partir d'un main à jour. L'ancienne règle — publier depuis la branche qui porte le travail — est retirée, et CLAUDE.md le dit : preview/ a fermé la fuite qu'elle existait pour éviter, donc le travail fusionne dans main non incrémenté et non promu et s'y accumule jusqu'à ce que quelqu'un décide de livrer.

Publier depuis une branche de fonctionnalité plus ancienne est désormais un risque plutôt qu'une habitude. make promote rsync le preview/paad de cet arbre de travail, donc une branche en retard sur main omet silencieusement tout ce qui a été fusionné depuis, et chaque vérification réussit parce que le travail omis n'est pas là pour échouer. make release refuse quand origin/main n'est pas un ancêtre de HEAD ; exécutez git fetch origin d'abord pour que cette vérification compare quelque chose de récent.

make release VERSION=X.Y.Z

Cette commande unique promeut preview/paad par-dessus plugins/paad et supprime les marqueurs preview, fait tourner le changelog avec la date réelle d'aujourd'hui, ouvre un nouveau [Unreleased], corrige les deux références de lien, réécrit chaque chaîne de version dans les deux arbres, régénère kiro_and_antigravity/ et pi/, et exécute make test.

La promotion refuse sur un arbre sale, donc le travail non commité arrête la release avant qu'elle ne modifie quoi que ce soit. Cela ne couvre que le travail non commité — ce n'est pas un filet de sécurité général, et tout ce qui suit suppose une exécution qui l'a dépassé.

Si elle échoue, s'arrêter et signaler l'échec. Ne corrigez pas manuellement autour. Un échec de vérification à ce stade signifie soit que la release n'est pas prête, soit qu'un générateur est erroné, et les deux nécessitent une décision d'Ovid.

Signaler l'état avec l'échec, car il n'est pas propre. Un échec à make test laisse trois mutations en place, et la première est la plus importante :

1. plugins/paad écrasé en bloc par le rsync de promotion — le contenu réel de la release, et la plus grande des trois.
2. Le changelog transformé en une section datée, avec un nouveau [Unreleased].
3. Chaque chaîne de version incrémentée, dans les deux arbres.

Dire que ré-exécuter make release ne fonctionnera pas : il refuse sur l'arbre maintenant sale, et roll_changelog.py refuse une deuxième fois sur une version qui a déjà une section.

Ne pas proposer make export && make test comme voie à suivre pour un échec qui nécessite une modification de SKILL.md. Cela ne peut pas fonctionner. La correction doit atterrir dans preview/, make promote refuse ensuite sur l'arbre sale, et make export régénère depuis le plugins/ non corrigé — donc la seule façon dont ce conseil réussit est l'édition manuelle de plugins/ que ce projet interdit partout ailleurs. Pour cette classe, la solution est une réinitialisation, pas un correctif. Elle est disponible pour un échec qui ne touche rien sous preview/ — une exportation obsolète, par exemple — où make export et un commit achèvent vraiment le travail.

La solution est une réinitialisation, et git checkout -- . seul ne suffit pas. La promotion apporte des compétences qui n'existent que dans preview/, et celles-ci arrivent comme des chemins non suivis que git checkout ne touche pas — .gitignore ne couvre rien sous plugins/, kiro_and_antigravity/ ou pi/, donc l'opérateur voit un git diff vert et conclut que la restauration a fonctionné alors qu'une compétence non publiée reste dans l'arbre livré, attendant le prochain git add -A. Utilisez les deux :

git checkout -- . && git clean -fd plugins/ kiro_and_antigravity/ pi/

Limiter git clean à ces trois est sûr car tous les trois sont uniquement générés. Ni l'une ni l'autre voie n'est le correctif manuel que cette étape interdit — cela signifie éditer la sortie générée pour faire réussir une vérification.

4. Lire le contenu, puis montrer le travail

git diff plugins/

Ce diff est le contenu réel de la release — tout ce que preview/ a accumulé depuis la dernière release, arrivant dans l'arbre livré d'un coup — et c'est le dernier moment pour rattraper quelque chose d'inattendu. Lisez-le avant toute autre chose. Dites ce que la promotion a fait : quelles compétences ont changé, lesquelles sont nouvelles, et lesquelles --delete a supprimées parce qu'elles ont quitté preview/.

Ensuite, montrez le diff — au minimum la limite de section du changelog et les chaînes de version. Obtenez l'approbation, puis commitez :

git commit -a -m "release: paad X.Y.Z"

5. Fusionner et étiqueter

Fusionner la branche dans main et pousser. Ovid utilise git-done ; un simple git checkout main && git merge --no-ff <branche> && git push fonctionne aussi.

Ensuite, sur main, après que la fusion soit poussée :

make tag

Il lit la version depuis plugin.json, refuse si vous n'êtes pas sur un main synchronisé, si l'arbre est sale, si le changelog n'a pas de section correspondante, ou si le tag existe déjà — puis annote et pousse.

Le tag va sur le commit de fusion car c'est l'arbre que les utilisateurs reçoivent. Ne jamais déplacer un tag publié ; si le mauvais commit a été étiqueté, demandez à Ovid avant de faire quoi que ce soit.

6. Déléguer la vérification que vous ne pouvez pas faire

Vous ne pouvez pas exécuter cette partie — elle se produit dans la session Claude Code d'Ovid. Dites-lui de :

1. /plugin → Installed → paad → Update now
2. Redémarrer Claude Code
3. Exécuter n'importe quelle compétence et confirmer que la ligne d'annonce lit vX.Y.Z

C'est le moyen le moins coûteux de rattraper un incrément qui n'a jamais atteint main.

L'étape 1 rafraîchit le catalogue du marketplace lui-même avant de vérifier une nouvelle version. C'est l'action du panneau et rien d'autre — si le plugin ne s'est jamais réellement mis à jour, la vérification de version à l'étape 3 lit l'ancienne version et signale une release qui a été livrée correctement comme cassée.

Ensuite, rapportez ce qui a été livré : la version, le tag, le commit auquel il pointe, et un résumé d'une ligne de la section du changelog.

Ce que ce skill ne fait pas

• Pas de GitHub Release. Le tag est l'enregistrement. N'exécutez pas gh release create sauf si Ovid le demande.
• Pas de ménage [Unreleased]. Si un changement manque dans le changelog, c'est un commit séparé avant la release, pas un ajout silencieux pendant celle-ci.
• Pas d'invention de version. L'étape 2 se termine toujours par une question.