Synthèse automatique
Gère les releases de conteneurs Docker en mettant à jour les versions dans les fichiers de configuration et de documentation, et en relançant les workflows CI.
Points forts
- Automatise la mise à jour des versions dans plusieurs fichiers simultanément
- Réduit les erreurs manuelles lors des releases
- S'intègre avec GitHub Actions pour le déploiement
- Fourit un guide étape par étape clair
Limites
- Fonctionne uniquement avec une structure de projet spécifique (GAIA)
- Nécessite que VERSION.json et les README soient correctement configurés
- Ne gère pas les conflits de branches ni les tags complexes
Lors de la publication de nouvelles versions de conteneurs Docker dans un projet standardisé avec VERSION.json et des README dédiés.
Pour des projets sans fichier VERSION.json ou lorsque les releases nécessitent des branchements ou des tags avancés.
Analyse de sécurité
SûrThe skill only reads version files and updates them with user-supplied version numbers; the only command that interacts with external systems is 'gh workflow run', which triggers a predefined CI workflow and does not run arbitrary destructive commands or exfiltrate data.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
/releaseManage releases for GAIA Docker containers.
Usage
/release
Workflow
- Read current versions from
VERSION.json - Ask user for action:
- New Release: Bump version for gaia-linux, gaia-dev, or both
- Re-trigger Workflow: Re-publish current versions to Docker Hub
- For New Release:
- Ask which container(s) to release
- Ask for new version number(s)
- Update
VERSION.json - Update hardcoded versions in README files
- Commit and push changes
- For Re-trigger:
- Run
gh workflow runto re-publish
- Run
Instructions
When the user invokes /release:
Step 1: Read Current State
Read VERSION.json to get current versions:
cat VERSION.json
Step 2: Ask User Intent
Use AskUserQuestion to ask:
- "What would you like to do?"
- New gaia-linux release - Bump gaia-linux version
- New gaia-dev release - Bump gaia-dev version
- Re-trigger workflow - Re-publish current versions
Step 3a: For New Release
If user chose new release:
- Ask for the new version number
- Update
VERSION.jsonwith the new version - Update version references in these files:
docs/gaia-linux/README.md- Update all occurrences of the old versiondocs/gaia-dev/README.md- Update all occurrences of the old versionREADME.md- Update version in "Current Versions" line and examples
- Commit changes with message:
Release <container> v<version> - Push to main branch
Step 3b: For Re-trigger
If user chose re-trigger:
gh workflow run "Test, Publish, Release" --ref main
Then inform user that the workflow has been triggered and they can check progress at the Actions tab.
Files to Update on New Release
For gaia-linux release:
VERSION.json- Update"gaia-linux"valuedocs/gaia-linux/README.md- Replace allgaia-linux:<old>withgaia-linux:<new>README.md- Update "Current Versions" line and docker examples
For gaia-dev release:
VERSION.json- Update"gaia-dev"valuedocs/gaia-dev/README.md- Replace allgaia-dev:<old>withgaia-dev:<new>README.md- Update "Current Versions" line and docker examples
Example Interaction
User: /release
Claude: Current versions:
- gaia-linux: 0.15.3
- gaia-dev: 1.0.0
What would you like to do?
[New gaia-linux release] [New gaia-dev release] [Re-trigger workflow]
User: New gaia-linux release
Claude: What version should gaia-linux be released as?
Current: 0.15.3
User: 0.15.4
Claude: I'll update the following:
- VERSION.json: gaia-linux → 0.15.4
- docs/gaia-linux/README.md: Update version references
- README.md: Update version references
[Makes changes, commits, and pushes]
Done! Release v0.15.4 has been pushed. The CI workflow will:
1. Run tests
2. Build and push Docker images
3. Update Docker Hub README
4. Create GitHub release
Check progress: https://github.com/<repo>/actions
</release-skill>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/gaia-docker-release-management-mmk3ni40/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/gaia-docker-release-management-mmk3ni40' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/gaia-docker-release-management-mmk3ni40/download' --output '.skill-downloads/gaia-docker-release-management-mmk3ni40/SKILL.md.part' && mv '.skill-downloads/gaia-docker-release-management-mmk3ni40/SKILL.md.part' '.skill-downloads/gaia-docker-release-management-mmk3ni40/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
Le fichier ne fournit pas un en-tête name/description exploitable pour cette procédure native. Le téléchargement reste disponible pour lecture ; utilisez le mode manuel ci-dessous.
Mode 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/gaia-docker-release-management-mmk3ni40/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.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.