Synthèse automatique
Prépare une release générique : génération du changelog depuis git log, bump de version semver et création du tag Git.
Points forts
- Découpe le processus en six phases explicites, de la pré-vérification à la vérification finale
- Détermine le type de bump semver en lisant le manifeste du projet (package.json, Cargo.toml, go.mod, pyproject.toml)
- Regroupe les commits conventionnels par type pour un changelog structuré
- Contrôle l'état de la branche, l'arbre de travail propre et le CI vert avant toute modification
Limites
- Suppose des commits conventionnels pour un regroupement optimal du changelog
- Dépend de skills externes (@oath-verifier, @flow-git, dev-verify) qui doivent être disponibles
- Exclut explicitement les releases EvoNexus, qui relèvent de custom-release
À utiliser pour publier une nouvelle version d'un projet non-EvoNexus maintenu dans workspace/projects/, avec un workflow semver standard.
Ne pas l'utiliser pour une release d'EvoNexus ou pour un projet disposant déjà de son propre processus de release personnalisé.
Analyse de sécurité
PrudenceThe skill is a conventional release workflow: inspect git history, edit manifest/CHANGELOG, commit, tag, and push. It uses powerful tools (git, network push) but only for their intended purpose, and it explicitly gates the push on user confirmation. No curl|sh, no rm -rf, no credential/token harvesting, no decoded payloads, and no attempt to bypass safety. Risk is limited to ordinary version-control side effects, so 'caution' rather than 'safe' or 'risky'.
- •Uses git commands including commit, tag, and push to origin (network write) after user confirmation
- •References git log/manifest reading — read-only, but operates inside a real repo
- •No destructive commands, no secret exfiltration, no obfuscation
Exemples
Prépare la release patch de la librairie Evolution API : génère le changelog depuis le dernier tag, bump la version dans package.json et crée le tag.Génère un CHANGELOG.md pour Evo Go en regroupant les commits conventionnels depuis le dernier tag, puis propose le type de bump semver.Vérifie que je suis sur la bonne branche, que l'arbre de travail est propre et que le CI est vert avant de préparer la release v1.4.0 de Evo AI.name: dev-release description: Release preparation — changelog generation, version bump, tag creation. Generic version (not project-specific). For EvoNexus releases, use custom-release instead.
Dev Release
Derived from oh-my-claudecode (MIT, Yeachan Heo). Adapted for the EvoNexus Engineering Layer.
Generic release preparation: changelog generation from git log, version bump, tag creation. For EvoNexus-specific releases, use custom-release (the existing skill that handles git-flow develop→main).
Use When
- Releasing a non-EvoNexus project (Evolution API, Evo AI, Evo Go, etc.)
- Generic semver bump on a library you're maintaining
Do Not Use When
- Releasing EvoNexus itself → use
custom-releaseinstead - Project has its own custom release process → follow that
Workflow
Phase 1 — Pre-flight
- Verify on the right branch (not
main/masterdirectly) - Verify clean working tree (no uncommitted changes)
- Verify CI is green on the target commit
- Verify tests pass locally (
dev-verify)
Phase 2 — Determine version
- Read current version from manifest (
package.json,Cargo.toml,go.mod,pyproject.toml) - Determine bump type: major / minor / patch (semver)
- Confirm with user
Phase 3 — Generate changelog
- Read commits since last tag:
git log {last-tag}..HEAD --oneline - Group by type (feat / fix / docs / etc.) if conventional commits
- Save to
CHANGELOG.mdwith new version section
Phase 4 — Bump version
- Update manifest file
- Update any version references in docs
Phase 5 — Commit and tag
git commit -m "chore(release): vX.Y.Z"git tag vX.Y.Zgit push origin vX.Y.Z(after user confirmation)
Phase 6 — Verify
@oath-verifierconfirms the release commit and tag are correct
Output
Save release notes to workspace/development/research/[C]release-{version}-{date}.md.
Pairs With
@flow-git(commits and tags)@oath-verifier(verification)@quill-writer(changelog formatting)dev-verify(pre-flight)
EvoNexus-Specific Note
EvoNexus has its own release skill (custom-release) that handles the git-flow develop→main workflow with EvoNexus-specific gates (CHANGELOG entry, version sync across files, GitHub release creation). Use custom-release for EvoNexus releases. Use dev-release only for projects in workspace/projects/ that have their own release lifecycle.
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/dev-release-mrx3xzs8/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/dev-release-mrx3xzs8' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/dev-release-mrx3xzs8/download' --output '.skill-downloads/dev-release-mrx3xzs8/SKILL.md.part' && mv '.skill-downloads/dev-release-mrx3xzs8/SKILL.md.part' '.skill-downloads/dev-release-mrx3xzs8/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Aucune section de prérequis reconnue dans ce fichier. Cela ne signifie pas qu’il est autonome : les bibliothèques, outils et accès peuvent être cités ailleurs dans le contenu ou dans le dépôt source.
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/dev-release-mrx3xzs8/SKILL.md' && test -s '.skill-downloads/dev-release-mrx3xzs8/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/dev-release' && cp -R '.skill-downloads/dev-release-mrx3xzs8' '.claude/skills/dev-release'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/dev-release-mrx3xzs8'openskills read 'dev-release-mrx3xzs8'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/dev-release-mrx3xzs8/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Configurer un canal de discussion avec SecretRefs
DevOps
Configurez des canaux de discussion avec des commandes non interactives, les secrets étant uniquement des SecretRefs. Couvre les étapes de collecte, modification, réparation et vérification.
Enquêter sur les échecs CI de ClickHouse
DevOps
Investigue un échec CI de ClickHouse de bout en bout à partir d'une URL de PR ou de rapport S3. Récupère les tests échoués, classe flaky vs vraie régression, et cherche des issues/fixes existants.
Revue de PR Ansible
DevOps
Examine une PR Ansible selon le processus standardisé du projet, incluant la validation des changelogs, la couverture de tests et le suivi des commentaires.