03 — Skills et workflows disciplinés — Codex — Le guide pratique

Ce que tu vas apprendre

Choisir le bon skill pour chaque type de tâche
Passer du brainstorming à un plan d’implémentation
Déboguer systématiquement sans deviner
Éviter les erreurs classiques d’utilisation des skills

Prérequis

Modules 01 et 02 maîtrisés
Avoir lancé au moins 3 sessions Codex
Comprendre la différence entre process et exécution

Les skills ne sont pas des décorations. Ce sont des disciplines de workflow. Un skill de process change l’ordre des opérations. Un skill d’implémentation réduit la surface d’exécution. Le plus petit ensemble applicable est le meilleur.

Étapes

1. Choisir le bon skill

Règle : commencer par le process, puis ajouter l’exécution.

Situation	Skill de départ
Nouvelle fonctionnalité, idéation	Brainstorming → Spec
Bug, test qui échoue	Débogage systématique
Construction multi-étapes après design	Plan d’implémentation
Revue de PR	Review PR
Correction CI	Fix CI

Règle pratique : si un skill s’applique, utilise-le avant d’improviser.

2. Du brainstorming au plan

Le chemin propre pour les tâches multi-étapes :

@diagram:steps
Comprendre le repo actuel
Clarifier l'objectif
Comparer les approches
Écrire une spec de design
Convertir la spec en plan d'implémentation
Exécuter contre le plan

Template de spec :

# [Nom de la fonctionnalité] — Design

Date : YYYY-MM-DD

## Résumé
Un paragraphe décrivant le problème et le changement prévu.

## Objectifs
- Objectif 1
- Objectif 2

## Hors périmètre
- Non-objectif 1
- Non-objectif 2

## Décisions clés
- Décision 1
- Décision 2

## Impact fichiers / workflow
- `chemin/vers/fichier`
- `chemin/vers/fichier`

## Validation
- Vérifications ciblées
- Vérifications globales

## Risques
- Risque 1
- Risque 2

Template de plan d’implémentation :

# [Nom] — Plan d'implémentation

**Objectif** : Le résultat attendu en une phrase.

**Architecture** : Deux ou trois phrases sur l'approche.

**Stack** : Langages, outils, frameworks, test runners.

## Structure des fichiers
- `chemin/fichier` : responsabilité

## Tâche 1 : Nom

**Fichiers** :
- Créer : `chemin/fichier`
- Modifier : `chemin/existant`
- Tester : `chemin/test`

- [ ] **Étape 1 : Écrire le test qui échoue**
- [ ] **Étape 2 : Le lancer pour confirmer l'échec**
  - Commande : `commande exacte`
  - Attendu : échec exact
- [ ] **Étape 3 : Écrire l'implémentation minimale**
- [ ] **Étape 4 : Lancer la vérification**
  - Commande : `commande exacte`
  - Attendu : résultat passant exact
- [ ] **Étape 5 : Commit**
  ```bash
  git add chemin/fichier chemin/test
  git commit -m "type: description courte"
  ```

3. Déboguer systématiquement

Quand le comportement est incorrect, ne saute pas sur la première correction plausible.

Boucle de débogage forte :

@diagram:steps
Reproduire le problème
Isoler où le comportement diverge
Écrire ou lancer le plus petit test échouant
Faire la plus petite correction qui explique l'échec
Lancer une vérification de régression

Boucle de débogage faible :

Deviner
Patcher
Espérer

Checklist bugfix :

Le problème est reproduit
Le chemin d’échec est isolé
Le plus petit test échouant est écrit ou lancé
La plus petite correction expliquant l’échec est faite
Une vérification de régression est lancée
Ce qui a changé et comment c’est vérifié est résumé

4. Éviter les erreurs de skills

Erreur 1 : Sauter la vérification des skills → Se transforme en implémentation prématurée.

Erreur 2 : Empiler les skills sans raison → Trop de skills à la fois brouillent les responsabilités et rendent le workflow illisible.

Erreur 3 : Traiter le skill comme de la prose → Un skill de process doit changer l’ordre des opérations, pas seulement le wording de la réponse.

Vérification

Le skill choisi correspond au type de tâche
Pas plus de 2 skills actifs simultanément
La spec existe pour les tâches multi-étapes
Le plan d’implémentation a des cases à cocher
La boucle de débogage systématique est suivie pour les bugs
Les skills sont traités comme des contraintes, pas des suggestions

Pièges courants

Sauter un skill requis parce que la tâche semble petite → Même 3 fichiers méritent un plan
Utiliser trop de skills à la fois → Un process + un exécution max
Traiter le guide de skill comme un conseil de style → C’est un contrat d’opérations
Passer directement de l’idée au code → Brainstorm → Spec → Plan → Code
Déboguer sans reproduction → Si tu ne peux pas reproduire, tu ne peux pas vérifier la correction

Récapitulatif

Skill	Quand l’utiliser	Output attendu
Brainstorming	Idéation, nouvelle feature	Spec de design
Plan d’implémentation	Multi-étapes après design	Plan avec checkboxes
Débogage systématique	Bug, test qui échoue	Test + correction + régression
Review PR	Revue de code	Findings ordonnés par sévérité
Fix CI	CI qui échoue	Root cause + correction + re-run

Pour aller plus loin

Inspiré du guide codex-howto de anup4khandelwal (MIT)