Aller au contenu principal

Skills personnalisées

Les skills sont des slash commands qui automatisent des flux de travail complets avec Claude Code. Lorsque vous saisissez /implement dans votre terminal, Claude Code lit les instructions de la skill correspondante et exécute une séquence d'étapes prédéfinie : lire la tâche, écrire le code, exécuter les tests, déplacer l'item vers la colonne appropriée.

Almirant inclut des skills intégrées qui couvrent les flux les plus courants, mais vous pouvez créer vos propres skills pour les adapter aux besoins de votre équipe.

Skills intégrées

Almirant inclut ces skills par défaut :

SkillDescription
/implementLit le work item assigné, implémente le code nécessaire et déplace la tâche vers la colonne Review
/review-taskExamine l'implémentation actuelle en la comparant avec la définition du work item et sa definition of done
/validatePipeline de validation complet : code review + exécution des tests + captures d'écran
/test-taskGénère des tests automatiques pour l'implémentation actuelle et les exécute
/prCrée une Pull Request sur GitHub à partir de la branche actuelle avec une description générée
/ideateDémarre une session de brainstorming interactive et crée des work items à partir des idées
/create-tasksCrée des work items bien structurés avec un titre, une description, des critères d'acceptation et une estimation

Fonctionnement de chaque skill

/implement

  1. Lit le work item assigné depuis Almirant via MCP
  2. Analyse la description, les critères d'acceptation et la definition of done
  3. Explore le code existant pour comprendre le contexte
  4. Implémente les changements nécessaires
  5. Déplace le work item vers la colonne Review

/review-task

  1. Récupère le work item et sa definition of done depuis Almirant
  2. Lit les changements implémentés dans le code
  3. Compare l'implémentation avec les critères d'acceptation
  4. Génère un rapport détaillé avec les constats et les suggestions

/validate

  1. Exécute /review-task pour examiner l'implémentation
  2. Exécute les tests du projet
  3. S'il existe une interface, effectue des captures d'écran pour la vérification visuelle
  4. Génère un rapport consolidé avec le résultat de chaque étape

/test-task

  1. Lit le work item pour comprendre ce qui doit être testé
  2. Analyse l'implémentation actuelle
  3. Génère des tests unitaires et/ou d'intégration
  4. Exécute les tests et rapporte les résultats

/pr

  1. Analyse les commits et les changements de la branche actuelle
  2. Génère un titre et une description pour la Pull Request
  3. Crée la PR sur GitHub avec les informations générées

/ideate

  1. Démarre un dialogue interactif pour explorer les idées
  2. Pose des questions pour affiner les concepts
  3. Transforme les idées en work items structurés dans Almirant

/create-tasks

  1. Reçoit une description de haut niveau de ce qui est nécessaire
  2. Découpe le travail en tâches granulaires
  3. Crée les work items dans Almirant avec toutes les informations nécessaires

Créer des skills personnalisées

Les skills sont définies comme des fichiers Markdown dans le répertoire .claude/skills/ de votre projet.

Emplacement

tu-proyecto/
.claude/
skills/
implement.md
review-task.md
mi-skill-custom.md # <-- tu skill personalizada

Structure d'une skill

Chaque fichier de skill comporte deux parties :

  1. Frontmatter : métadonnées au format YAML (nom et description)
  2. Instructions : étapes que Claude Code doit suivre, écrites en Markdown
---
name: mi-skill
description: Brève description de ce que fait cette skill
---

## Instructions pour l'agent

1. Première étape : description détaillée
2. Deuxième étape : description détaillée
3. Troisième étape : description détaillée

Exemple : skill de déploiement

---
name: deploy-staging
description: Déploie la branche actuelle dans l'environnement de staging
---

## Instructions

1. Vérifie qu'il n'y a pas de changements non commités en exécutant `git status`
2. Exécute le linter avec `bun run lint` et corrige les erreurs éventuelles
3. Exécute les tests avec `bun run test` et vérifie qu'ils passent
4. Effectue le push de la branche actuelle vers origin
5. Exécute le déploiement vers le staging avec `bun run deploy:staging`
6. Vérifie que le déploiement a réussi en consultant l'URL de staging
7. Rapporte le résultat à l'utilisateur avec l'URL de l'environnement

Exemple : skill de documentation

---
name: document-feature
description: Génère la documentation technique d'une feature implémentée
---

## Instructions

1. Lit le work item associé à la feature depuis Almirant à l'aide de MCP
2. Identifie les fichiers nouveaux ou modifiés dans l'implémentation
3. Pour chaque nouveau composant/module :
- Génère un JSDoc avec une description, des paramètres et des exemples
- S'il s'agit d'un hook, documente les valeurs de retour
- S'il s'agit d'un endpoint, documente la request/response
4. Met à jour le README du domaine s'il existe
5. Crée un commentaire dans le work item avec le résumé de la documentation générée

Exemple : skill de migration de base de données

---
name: db-migrate
description: Génère et applique des migrations de base de données de manière sûre
---

## Instructions

1. Lit les changements en attente dans les fichiers de schema (`backend/packages/database/src/schema/`)
2. Génère la migration avec `bun run db:generate`
3. Examine le SQL généré dans le dossier des migrations
4. Si le SQL contient des opérations destructrices (DROP, ALTER avec perte de données),
avertit l'utilisateur et attend sa confirmation avant de continuer
5. Applique la migration avec `bun run db:migrate`
6. Vérifie que la migration a été correctement appliquée

Bonnes pratiques

Instructions claires et spécifiques

Écrivez des instructions qui ne laissent aucune place à l'ambiguïté. Au lieu de « examine le code », précisez quels fichiers ou patterns doivent être examinés.

# Moins efficace
1. Examine le code
2. Effectue les changements nécessaires

# Plus efficace
1. Lis tous les fichiers dans `src/domains/[feature]/` pour comprendre la structure
2. Vérifie que les composants de présentation ne contiennent ni useState ni useEffect
3. Si tu trouves de la logique dans les composants .tsx, extrais-la dans un custom hook au sein de `application/hooks/`

Utilisez des outils MCP dans les instructions

Référencez les outils MCP d'Almirant afin que la skill interagisse avec votre board.

1. Utilise l'outil `get_work_item` pour lire la tâche assignée
2. Implémente les changements conformément à la description
3. Utilise `update_work_item` pour déplacer la tâche vers la colonne "Review"

Incluez des conditions et des validations

Définissez ce que la skill doit faire lorsqu'un élément échoue ou lorsque des conditions particulières s'appliquent.

3. Exécute les tests avec `bun run test`
- Si des tests échouent, analyse les erreurs et tente de les corriger
- Si tu ne peux pas les corriger après 2 tentatives, rapporte les échecs à l'utilisateur
4. Si le work item a le label "needs-review", ne le déplace pas automatiquement vers Done

Garder les skills ciblées

Chaque skill doit bien faire une seule chose. Si vous avez besoin d'un flux complexe, divisez-le en plusieurs skills et combinez-les manuellement.

Conseil

Commencez par dupliquer une skill intégrée et modifiez-la pour votre cas d'usage. Il est plus facile d'adapter quelque chose d'existant que de créer à partir de zéro.

Important

Les skills sont des instructions pour l'IA, pas des scripts exécutables. Claude Code les interprète et décide comment exécuter chaque étape. Écrivez les instructions en pensant à un développeur qui les lit pour la première fois.

Partager des skills avec votre équipe

Puisque les skills se trouvent dans .claude/skills/, elles sont versionnées avec Git avec le reste du projet. Tout membre de l'équipe qui clone le dépôt aura accès aux mêmes skills.

Pour maintenir la cohérence :

  1. Documentez chaque skill avec une description claire dans le frontmatter
  2. Utilisez des conventions de nommage cohérentes (kebab-case)
  3. Regroupez les skills associées avec des préfixes : deploy-staging.md, deploy-production.md
  4. Examinez les skills en code review comme tout autre fichier du projet