Marre des prompts à la main ? Cette fonction Claude Code a triplé mon efficacité

Une histoire vraie

En octobre dernier, je devais refactoriser un projet React : une god class de plus de 2 000 lignes, décourageante. À chaque fois que je demandais à Claude Code d’optimiser le code, je répétais les mêmes consignes :

• « Pense au mode strict TypeScript »
• « Les appels API doivent gérer les erreurs »
• « Les composants respectent le principe de responsabilité unique »

Copier-coller ces exigences prenait deux ou trois minutes minimum. Pire : après une dizaine d’échanges, Claude Code « oubliait » souvent mes exigences initiales et repartait sur du code non conforme.

Jusqu’à ce que je tombe sur la fonctionnalité Skill dans la doc.

Une semaine d’essai plus tard, j’avais encapsulé toutes ces consignes répétitives dans quelques fichiers skill. Maintenant, un simple @skill react-refactor suffit. Cette classe de 2 000 lignes, que j’estimais à trois jours de refactor, a été terminée en deux après-midis.

Qu’est-ce qu’un Skill, concrètement

En bref, un Skill équipe Claude Code d’un paquet de compétences.

Vous créez un fichier Markdown dans .claude/skills/, y décrivez prompts, flux de travail et conventions. Au besoin, @skill nom-du-skill l’invoque. Comme équiper un personnage de jeu : skill d’attaque pour produire, skill défensif pour sécuriser.

Exemple minimal :

---

title: "Expert revue de code React"
description: "Revue React axée qualité, performance et bonnes pratiques"

---

# Processus de revue React
Vous êtes un expert React expérimenté en revue de code. Suivez ces critères :

## Points clés
1. **Conception des composants**
   - Principe de responsabilité unique
   - Complétude des types Props
   - Pertinence du découpage
2. **Performance**
   - Re-renders inutiles
   - Usage de useMemo/useCallback
   - Clés de listes
3. **Qualité**
   - Sécurité des types TypeScript
   - Error boundaries
   - Accessibilité (a11y)

## Format de sortie
- Liste des problèmes (par gravité)
- Suggestions de code concrètes
- Priorités P0/P1/P2

Enregistrez sous .claude/skills/react-review.md ; pour une revue React, @skill react-review suffit. Claude Code suit vos critères.

Pourquoi les prompts à la main ne tiennent plus

J’étais « ingénieur de prompts » : des dizaines de modèles soignés dans Notion. Après quelques mois, les limites sont apparues :

Trop de répétition

Copier-coller depuis Notion, parfois ajuster quelques mots selon le projet. Une demi-heure par jour rien que pour ça.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Versions ingérables

Le prompt d’aujourd’hui n’est plus celui de la semaine dernière ; retrouver « la bonne version » ? Impossible.

Collaboration préhistorique

Un collègue veut votre meilleur prompt ? WeChat. Il l’améliore ? Resynchronisation manuelle.

L’IA oublie

Sur de longs fils, Claude Code oublie vos exigences initiales. Au tour 20, les mêmes erreurs reviennent.

Les Skills règlent tout ça :

• Versionnement : Git, retour arrière facile
• Partage : un pull sur le dépôt d’équipe
• Persistance : pas d’effet « fin de conversation »

"La valeur centrale des Skills : réutilisabilité et cohérence. L’ingénierie des prompts devient un actif projet maintenable et partageable."

Mon premier Skill : générateur d’API

Sur un projet e-commerce, le backend m’a envoyé une doc Swagger de plus de 100 endpoints. Pour chaque endpoint, à la main :

1. Types TypeScript
2. Fonctions axios
3. Gestion d’erreurs
4. États de chargement

Estimation : ~30 heures pour 100 endpoints.

J’ai passé une heure à écrire le skill api-generator :

---

title: "Générateur de code API"
description: "Génère types TS et encapsulation axios depuis la doc API"
version: "1.3.0"

---

# Expert génération API
Vous êtes un ingénieur full stack. Générez du TypeScript de qualité à partir de la documentation API.

## Contenu généré
### 1. Types TypeScript
```typescript
// Paramètres de requête
interface GetUserRequest {
  userId: string;
  includeDetails?: boolean;
}
// Réponse
interface GetUserResponse {
  id: string;
  name: string;
  email: string;
  createdAt: string;
}

2. Fonctions Axios

import request from '@/utils/request';
export const getUserAPI = async (
  params: GetUserRequest
): Promise<GetUserResponse> => {
  try {
    const response = await request.get<GetUserResponse>('/api/user', { params });
    return response.data;
  } catch (error) {
    console.error('Échec récupération utilisateur:', error);
    throw error;
  }
};

3. Hook React (optionnel)

export const useGetUser = (userId: string) => {
  const [data, setData] = useState<GetUserResponse | null>(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState<Error | null>(null);
  useEffect(() => {
    const fetchData = async () => {
      setLoading(true);
      try {
        const result = await getUserAPI({ userId });
        setData(result);
      } catch (err) {
        setError(err as Error);
      } finally {
        setLoading(false);
      }
    };
    fetchData();
  }, [userId]);
  return { data, loading, error };
};

Conventions

• camelCase pour les noms
• Fonctions API suffixées API
• Hooks préfixés use
• Gestion d’erreur sur tout async
• JSDoc sur types et exports

Format de sortie

1. Types d’abord
2. Puis fonctions API
3. Hook si endpoint fréquent
4. Exemple d’usage en fin

Un endpoint : de 30 minutes à 5. Les 100 endpoints en deux jours. Les juniors produisent le même style — cohérence forte sur tout le projet.

## Usage avancé : faire coopérer les Skills

Un seul skill ne suffit pas toujours. Le refactor suit souvent une chaîne :

```bash
# Étape 1 : analyser
@skill code-analyzer src/legacy/UserService.ts
# Étape 2 : plan
@skill refactor-planner
# Étape 3 : tests avant refactor
@skill test-generator
# Étape 4 : refactor (manuel ou assisté)
# Étape 5 : revue finale
@skill code-reviewer

J’ai même scripté le flux :

#!/bin/bash
# refactor-workflow.sh
echo "🔍 Étape 1/4 : analyse..."
claude-code @skill code-analyzer $1
read -p "Entrée pour continuer..."
echo "📋 Étape 2/4 : plan de refactor..."
claude-code @skill refactor-planner
read -p "Entrée pour continuer..."
echo "🧪 Étape 3/4 : génération de tests..."
claude-code @skill test-generator
read -p "Après tests OK, Entrée pour continuer..."
echo "✅ Étape 4/4 : revue finale..."
claude-code @skill code-reviewer

Sur une god class de 2 000 lignes : 7 classes ciblées, couverture de tests de 40 % à 85 %.

Partage d’équipe : les Skills comme infra

Nous gérons un dépôt Git team-skills :

team-skills/
├── frontend/
│   ├── react-review.md
│   ├── vue-component-gen.md
│   └── css-optimizer.md
├── backend/
│   ├── api-design.md
│   ├── database-review.md
│   └── security-audit.md
└── common/
    ├── code-cleaner.md
    ├── test-generator.md
    └── commit-msg.md

Lien symbolique local :

git clone git@github.com:your-team/team-skills.git ~/.team-skills
ln -s ~/.team-skills/* .claude/skills/

Effets :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• Onboarding : bibliothèque complète dès le jour 1
• Sync : git pull pour la dernière version
• Style uniforme pour tout le monde

Un stagiaire écrivait déjà du code conforme au bout du deuxième jour — avant, une semaine de formation.

Skills + CLAUDE.md : le duo gagnant

Dans CLAUDE.md à la racine, règles globales :

# Contexte projet
- Stack : React 18 + TypeScript 5.0 + Vite 4
- Lint : règles Airbnb ESLint
- Commits : Conventional Commits
- État : Zustand (pas Redux)

## Conventions
- Types TypeScript complets sur tous les composants
- API via src/utils/request.ts
- Composants en PascalCase (UserProfile.tsx)
- Utilitaires en camelCase (formatDate.ts)

## Arborescence
src/
├── components/
├── pages/
├── hooks/
├── utils/
├── services/
└── stores/

Le skill référence ces règles :

---

title: "Générateur de composants React"

---

# Instructions
Respectez strictement stack, arborescence et nommage de CLAUDE.md.
Le composant doit :
- Utiliser TypeScript
- Respecter ESLint du projet
- Être au bon emplacement
- Suivre la gestion d'état définie

Le skill lit CLAUDE.md ; le code généré colle au projet, même après un clone.

Mes 5 Skills indispensables

Plus de 20 skills après six mois ; les plus utilisés :

1. Générateur de tests (test-gen.md)

Analyse la logique, génère tests unitaires, cas limites et erreurs. Couverture de 40 % à 85 %, moitié moins de temps sur les tests.

2. Messages de commit (commit-msg.md)

Analyse le diff, propose un message Conventional Commits. Exemple :

feat(user-auth): ajout connexion OAuth2.0
- Intégration Google et GitHub
- Rafraîchissement JWT
- Middleware de permissions
Closes #123

~30 lignes, usage quotidien — des heures économisées.

3. Assistant refactor (refactor.md)

Détecte les code smells, priorise, plan pas à pas, garde le comportement. La god class de 2 000 lignes est passée par là.

4. Audit sécurité (security-audit.md)

SQL injection, XSS, fuites de secrets, permissions. Avant une mise en prod : 3 failles potentielles trouvées.

5. Générateur de doc (doc-gen.md)

Doc API depuis le code, Markdown depuis les commentaires, changelog. De 2 h à 10 minutes, fini le « code à jour, doc oubliée ».

5 conseils pour bien écrire un Skill

1. Frontmatter soigné

title et description apparaissent dans la liste :

---

title: "Expert revue full stack"
description: "Revue front/back : sécurité, performance, maintenabilité"
version: "2.1.0"
tags: ["revue", "sécurité", "performance"]

---

version pour le suivi ; tags pour classer.

2. Rôle explicite

« Vous êtes un expert… » aide Claude Code à tenir le rôle mieux qu’un simple « revoyez ce code ».

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

3. Exemples ✅ / ❌

### Risque injection SQL
❌ Dangereux :
```javascript
const query = `SELECT * FROM users WHERE id = ${userId}`;

✅ Sûr :

const query = 'SELECT * FROM users WHERE id = ?';
db.query(query, [userId]);

### 4. Format de sortie précis

```markdown
## Format de sortie
### 🔴 Critique (à corriger)
- [fichier:ligne] description
- Risque
- Correctif (exemple de code)
### 🟡 Recommandé
- [fichier:ligne] description
- Raison
- Piste d'amélioration

5. Règles en cas d’erreur

## Gestion des erreurs
- Erreur de syntaxe : indiquer l'emplacement, ne pas poursuivre la revue
- Fichier inaccessible : vérifier le chemin
- Fichier > 5000 lignes : proposer une revue par lots

FAQ

Trop de Skills, noms oubliés ?

Convention de nommage :

• review-* : revue
• gen-* : génération
• util-* : utilitaires
• fix-* : correctifs

Exemples : review-frontend.md, gen-api.md, util-commit.md

Sortie trop longue ?

Mode concis dans le skill :

Mode détaillé par défaut. Avec `--brief` :
- Liste des problèmes (une ligne chacun)
- Gravité
- Correctifs essentiels

Comportement différent selon les projets ?

Demander le contexte au départ :

## Prérequis
1. Lire package.json (versions)
2. tsconfig.json
3. .eslintrc
4. README.md (architecture)

En bref

Six mois de Skills : +40 % d’efficacité, moins de tâches répétitives, plus de temps pour l’architecture et le métier.

Si vous tapez encore vos prompts à la main :

1. Commencez aujourd’hui — un skill simple (revue ou tests)
2. Affinez après chaque usage
3. Partagez en équipe
4. Suivez la doc officielle

La valeur d’un Skill n’est pas sa complexité, mais le problème réel qu’il résout. Mon commit-msg fait ~30 lignes et tourne tous les jours.

Rangez vos prompts répétitifs en Skills. Dans trois mois, vous vous remercierez.

Ressources

• Documentation Claude Code
• Bonnes pratiques Skills
• Modèles communautaires