laojin1900/365Skill

Méthode de Développement en Cinq Étapes (Version Développeur Métier)

Public cible : développeurs qui comprennent le métier mais ne lisent pas le code ligne par ligne. Les points de contrôle utilisateur sont Plan (approbation métier) et Verify (validation par preuves), pas les lignes de code.

Orientation de conception : à l'ère des modèles puissants, ne mettre des barrières minimales qu'aux endroits où le modèle est naturellement faible (exécution docile d'instructions précipitées, absence de vérification active, saut d'étapes). Les règles doivent être supprimées plutôt qu'ajoutées ; chaque rallongement de ce fichier est un coût.

Étape 0 : Classification de la Tâche (Obligatoire, sortir la conclusion de classification avant d'agir)

Niveau	Critère	Processus
A Mineure	Texte/style/espacement/bug évident mineur unique ; ne touche ni base de données, ni API, ni droits d'accès	Localisation rapide → Modification minimale → Vérification page (pas les cinq étapes complètes)
B Normale	Nouvelle page/formulaire/liste/API standard/évolution de fonctionnalité dans un module ; ne touche pas l'architecture cœur	Cinq étapes complètes, Review délègue à un sous-agent
C Critique	Structure de base de données, système de droits, paiement/commandes, refonte de module commun, déploiement en production, capacité partagée entre plusieurs projets	Cinq étapes complètes + Vérification des points de contrôle métier + Révision indépendante + Approbation humaine

En cas d'hésitation sur le niveau, choisir le plus élevé. La conclusion de classification doit être accompagnée d'une phrase expliquant la raison à l'utilisateur.

Étape 0.5 : Confirmation Préalable du Niveau du Modèle (Obligatoire après classification, avant d'agir)

En sortant la conclusion de classification, vérifier la correspondance avec le modèle de la session principale (voir le nom du modèle dans l'invite système) :

Niveau	Modèle Principal Actuel	Action
Niveau A	Fable 5 ou Opus	Ne pas bloquer : terminer la tâche directement, ajouter une ligne de rappel de descente de niveau dans la sortie finale (ex. « C'est une petite modification de niveau A, déjà effectuée ; si vous avez d'autres tâches courantes, suggérez /model sonnet »)
Niveau B	Fable 5 ou Opus	S'arrêter, ne pas commencer. Afficher l'invite de confirmation de descente de niveau (voir ci-dessous), attendre la réponse de l'utilisateur avant de continuer
A / B	Sonnet / Haiku	Correspondant, commencer directement
C	Tout modèle	Entrer directement dans le processus en cinq étapes (au point de décision, rappeler la montée de niveau selon les règles)

Modèle d'invite de confirmation de descente de niveau :

【Confirmation de niveau】Cette tâche est classée en niveau B, Sonnet est suffisant. Le modèle actuel est Fable 5 (consommation rapide de crédits). Suggérez /model sonnet puis renvoyez cette demande ; si vous voulez continuer avec le modèle actuel, répondez "continuer".

Une fois que l'utilisateur a clairement répondu "continuer" (ou équivalent), ce rappel ne sera pas répété dans cette tâche. Si l'utilisateur change de modèle et renvoie la demande, exécuter normalement avec le nouveau modèle.

Étape 0.8 : Confrontation des Besoins (Dernière Barrière avant d'agir)

La qualité de la sortie du grand modèle est déterminée par la qualité de l'entrée des besoins, et les instructions de l'utilisateur sont souvent une première intuition précipitée. Le rôle de cette étape : avant l'exécution, transformer les instructions précipitées en besoins complets — c'est la responsabilité de l'IA, pas de l'utilisateur.

Quatre règles d'attitude :

1. Demander l'objectif plutôt que le moyen — distinguer "ce que l'utilisateur dit vouloir faire" et "le problème que l'utilisateur veut résoudre", toujours confirmer ce dernier en premier. Si l'utilisateur dit "ajouter un bouton d'exportation", demandez d'abord "pour qui exporte-t-on, pour quel scénario ?" ; la réponse peut orienter vers une solution complètement différente.
2. En cas de désaccord, le dire — si vous estimez que la solution de l'utilisateur n'est pas optimale, dites-le clairement et proposez une alternative + les raisons du choix ; n'exécutez pas docilement. Si l'utilisateur insiste, respectez sa décision.
3. Vérifier avant de demander — avant de poser une question, vérifiez par vous-même : la réponse peut-elle être obtenue en lisant le code/la documentation du projet/la configuration existante ? Si oui, ne demandez pas à l'utilisateur, allez vérifier directement.
4. Chaque question doit venir avec une réponse recommandée — ne posez jamais une question vide qui oblige l'utilisateur à trouver la réponse lui-même. Faites d'abord un jugement, donnez la réponse recommandée et les raisons ; l'utilisateur n'a qu'à confirmer ou infirmer, sans avoir à concevoir à partir de zéro. Si vous ne trouvez pas de réponse recommandée, c'est que vos recherches sont insuffisantes : faites d'abord vos devoirs (reprenez la règle 3) avant de demander.

Appliquer la profondeur de confrontation selon le niveau :

Niveau	Profondeur de Confrontation	Rythme des Questions	Action
A	Zéro confrontation	—	Reformuler la compréhension en une phrase, exécuter directement
B	Confrontation légère	Questions groupées, max 3 à la fois	Sortir : objectif métier compris + max 3 questions de clarification clés (chacune avec réponse recommandée) + 1 à 2 points que l'utilisateur pourrait ne pas avoir considérés ; après réponse, passer à Research
C	Confrontation complète	Une par une, une à la fois	Voir liste ci-dessous, former un Brief des Besoins et le consigner ; l'utilisateur valide le brief avant de passer à Research

Le groupement rapide pour B et les questions une par une pour C sont un choix délibéré : les tâches de niveau B ont un risque faible, le groupement économise des allers-retours ; les décisions de niveau C sont souvent interdépendantes (la réponse à une question peut rendre la suivante inutile ou en modifier le sens), poser les questions une par une permet de creuser précisément, une fois une question posée, attendre la réponse de l'utilisateur avant de poser la suivante.

Quatre choses à faire impérativement pour la confrontation complète de niveau C :

1. Interview en questionnement : creuser par arbre de décision, une question à la fois, en suivant les dépendances jusqu'au bout (demander d'abord ce qui peut changer la direction, les branches éliminées par les réponses précédentes ne sont pas posées), chaque question doit être accompagnée d'une réponse recommandée (peut utiliser la compétence interview-me comme support pour le cadre global).
2. Alternatives : proposer au moins 1 solution différente de l'instruction originale de l'utilisateur, avec les raisons du choix.
3. Compléter les limites : lister ce que l'utilisateur n'a pas mentionné — flux d'exception, impact sur les droits, compatibilité des données, méthode de rollback.
4. Consigner le Brief des Besoins : écrire dans un fichier du projet (pour contrer la compression du contexte dans les longues sessions), modèle : objectif métier / critères de succès vérifiables / dans le périmètre et hors périmètre / décisions clés confirmées / alternatives et raisons de rejet / liste des risques et limites / non encore clarifié (zone de brouillard : questions impossibles à répondre maintenant, à déverrouiller par des décisions préalables — ne pas forcer des questions et réponses conduisant à de fausses décisions).

Research et les étapes suivantes se basent sur le Brief des Besoins (niveau C) ou les conclusions confirmées après confrontation (niveau B), et non plus sur l'instruction originale de l'utilisateur.

Mise à Niveau Hors Norme : Quand la Tâche Dépasse une Session Unique (D'abord Cartographier, puis Agir)

Déclencheur : lors de la confrontation 0.8 ou de la phase Research, si la tâche dépasse la capacité d'une session — signaux : plus de 5 problèmes interdépendants, implémentation visiblement en plusieurs phases, implication de 3 sous-systèmes ou plus. Dans ce cas, arrêter d'entrer directement dans les cinq étapes, d'abord cartographier, et signaler à l'utilisateur "Cette tâche dépasse la norme, suggérons d'abord de créer une carte".

1. Créer le fichier de carte : docs/maps/<nom de la tâche>.md (si pas de dossier docs, mettre dans .claude/maps/), structure en cinq parties — destination (résultat métier à atteindre) / remarques (contexte et contraintes) / décisions prises (chacune avec raison et date) / non encore clarifié (zone de brouillard) / hors périmètre.
2. Tickets de décision : dans la carte, maintenir une liste de tickets. Chaque ticket = un élément à décider (question "faut-il, comment faire ?", pas une tâche de code), avec statut (à résoudre/en cours de résolution/résolu) et dépendances (tickets bloquant). Les parties de la zone de brouillard où "on ne peut pas encore poser de question précise" deviennent de nouveaux tickets une fois que les tickets préalables sont résolus.
3. Plan, don't do : la carte est complète lorsque la zone de brouillard est vide et qu'aucun ticket n'est en attente de décision — rien ne doit être décidé avant de commencer l'implémentation.
4. Une session, un ticket : chaque session ne s'occupe que d'un seul ticket (ou de l'implémentation d'une phase d'un plan déjà décidé). Une fois terminé, mettre à jour la carte et clore la session ; la session suivante hérite du contexte de la carte, sans dépendre de la mémoire de session.
5. Chaque phase d'implémentation dans la carte suit normalement les cinq étapes selon son niveau ; la mise à jour de la carte fait partie de l'action de clôture de la phase Verify (au même titre que l'écriture du journal de bord, sans mise à jour de la carte, la tâche n'est pas considérée comme terminée).

Règles d'Exécution des Cinq Étapes

1. Research — D'abord Comprendre, ne pas Écrire Directement

• Lire d'abord la documentation du projet (CLAUDE.md / AGENTS.md / docs/) et le code existant concerné, trouver les capacités réutilisables et les dépendances.
• Sortir une brève compréhension de l'état actuel + lister clairement les incertitudes, les soumettre avec le Plan pour approbation ; si Research découvre des faits qui contredisent les conclusions de la confrontation ou les prémisses du Brief des Besoins, s'arrêter immédiatement et le signaler à l'utilisateur, sans écrire le Plan avec les prémisses modifiées.
• Pour les niveaux B/C, la recherche va du large au profond : survoler largement pour comprendre → se concentrer sur les zones clés → vérifier les oublis et les dépendances cachées.

2. Plan — Point de Contrôle Principal de l'Utilisateur

• Sortir : objectif / ce qui est fait cette fois / ce qui n'est pas fait cette fois / fichiers modifiés / impact sur base de données, droits, API, composants communs, déploiement / comment vérifier / comment rollbacker.
• Écrire en langage métier, pour que quelqu'un qui ne lit pas le code puisse juger "ce processus est-il ce que je veux ? le périmètre a-t-il gonflé ?".
• Pour les tâches de niveau C, sortir le rappel de changement de modèle à ce nœud (voir règles ci-dessous).
• Attendre l'approbation explicite de l'utilisateur avant de passer à l'implémentation.

3. Implement — Exécuter selon le Plan Approuvé

• Faire uniquement ce qui est dans le plan approuvé ; modifications minimales ; prioriser la réutilisation des modules existants ; ne pas refactoriser des zones non concernées ; si la tâche dépasse le plan, s'arrêter immédiatement et le signaler.
• Pour les modifications multi-fichiers, déléguer d'abord à implementer (Sonnet) ; pour les tâches de simple copie où le plan contient déjà le code complet, déléguer à scribe (Haiku).
• Après chaque élément terminé, effectuer une vérification locale et l'enregistrer, puis passer à l'élément suivant.

4. Review — Changer de Point de Vue pour Vérifier, ne pas se Contenter d'une Auto-évaluation

• Niveau B : déléguer à task-reviewer (Sonnet) pour une révision au niveau de la tâche.
• Niveau C : déléguer à final-reviewer (Opus) pour une révision finale indépendante.
• Liste de vérification : conformité aux besoins / gonflement du périmètre / modifications de fichiers non concernés / duplication / risques de droits et de données / gestion des erreurs / tests réels.

5. Verify — Apporter des Preuves d'Achèvement

• "C'est fait / ça devrait marcher" n'est pas une preuve ; il faut fournir des preuves, chaque preuve accompagnée d'une phrase en langage métier expliquant quel objectif métier elle démontre. Si l'utilisateur peut confirmer en personne (ouvrir la page, cliquer, vérifier que les données sont toujours là), privilégier la validation finale par l'utilisateur :
  • Sortie réelle des commandes de build / vérification de type / tests.
  • Pour les modifications Web, ouvrir la page et l'utiliser (validation par navigateur).
  • Les données sont réellement enregistrées en base et persistent après rechargement.
  • Les comptes avec différents droits ne peuvent pas outrepasser leurs permissions.
  • Les fonctionnalités anciennes ne sont pas cassées.
• Sans preuve, ne pas déclarer la tâche terminée ; lister explicitement les "éléments non vérifiés".
• Action de clôture (sans quoi la tâche n'est pas terminée) : ajouter un enregistrement d'exécution de cette tâche dans ~/.claude/skills/five-step-dev/logbook.md (format dans l'en-tête de ce fichier) ; si le journal atteint 10 entrées, suggérer activement à l'utilisateur d'exécuter une « rétrospective cinq étapes » (compétence five-step-retro).

Rappel de Changement de Modèle (Spécifique au Changement Manuel dans le Client Bureau)

La session principale doit normalement rester sur sonnet ; les phases de révision sont gérées par délégation (le modèle des sous-agents est fixé), pas besoin de changer le modèle principal. Trois signaux nécessitent de rappeler à l'utilisateur de changer de modèle manuellement — le signal de descente de niveau est exécuté avant à l'étape 0.5 (voir ci-dessus), les signaux de montée de niveau sont les suivants :

1. Point de décision du plan pour une tâche de niveau C — après avoir écrit le Plan, lors de la demande d'approbation, ajouter en sortie :

   【Suggestion de changement】Cette tâche est de niveau C (critique), suggérons d'abord /model fable pour examiner ce plan avant de l'approuver ; après examen, /model sonnet pour revenir à l'implémentation.

2. Escalade de problème — si une même erreur échoue pour la 3ème fois, arrêter les tentatives : si l'environnement dispose d'un advisor (settings.json global), l'appeler d'abord pour un diagnostic (transmission automatique du contexte complet, pas besoin de brief, pas d'action utilisateur) ; si l'advisor n'est pas disponible ou que son avis ne résout pas le problème, alors sortir :

   【Suggestion de changement】Le même problème a échoué 3 fois, l'advisor n'a pas diagnostiqué, suggérons /model fable pour creuser.

Avant le rappel de changement, consigner le contexte clé (brief de décision / journal de progression) pour éviter la perte de contexte due à la compression de la longue session.

Points de Contrôle Métier de Niveau C (Avant l'Implémentation, l'IA répond point par point avec une justification ; l'utilisateur valide seulement par "oui" ou signale les risques à trancher)

• Cela impacte-t-il les processus de vente existants / le fonctionnement normal de la boutique Shopify ?
• Cela impacte-t-il les droits ou la structure de données Supabase ?
• Cela impacte-t-il la structure commune multi-entreprises, multi-projets, multi-ventes ?
• Cela crée-t-il une capacité redondante avec les interfaces IA existantes ?
• Cela modifie-t-il des composants communs ? La liste d'impact est-elle fournie ?
• Cela touche-t-il le site de production ? Quelle est la procédure de rollback ?
• Quelles actions nécessitent une confirmation humaine avant d'être exécutées ?

Instructions de Portage (Pour les Autres Utilisateurs)

Cette compétence provient de l'environnement de travail réel de l'auteur. Avant de l'utiliser directement, deux adaptations sont nécessaires :

1. Sous-agents nommés : implementer / task-reviewer / final-reviewer / scribe sont des agents personnalisés pré-créés par l'auteur dans ~/.claude/agents/ (modèles fixés respectivement à Sonnet / Sonnet / Opus / Haiku). Si votre environnement n'a pas ces agents, vous pouvez :
   • Créer vos propres agents du même nom (recommandé, pour éviter d'oublier les paramètres de modèle) ; ou
   • Remplacer ces noms par l'agent general-purpose avec un paramètre model explicite.
2. Points de contrôle métier de niveau C : la liste avec Shopify / Supabase / structure multi-entreprises correspond à la stack métier de l'auteur. Remplacez-la par votre propre liste d'actifs à risque (par ex. vos canaux de paiement, bases de données, plateformes de déploiement).

Les noms de modèles (fable / sonnet / opus / haiku) correspondent à la série Claude d'Anthropic. D'autres systèmes de modèles peuvent être remplacés par l'équivalent "meilleur / standard / léger".

Migration vers Codex

Le format de cette compétence est indépendant de Claude Code et peut être directement migré vers Codex, avec les quatre modifications suivantes :

1. Installation : créer un lien symbolique dans le répertoire personnel des compétences de Codex, comme pour discover-project-skills :

   mkdir -p ~/.codex/skills
   ln -s "$PWD/skills/five-step-dev" ~/.codex/skills/five-step-dev
   

   Le mode d'appel devient $five-step-dev (syntaxe d'appel explicite de compétence de Codex). Le déclencheur implicite reste disponible — il suffit de mapper « cinq-étapes » dans le AGENTS.md global de Codex :

   Quand je dis « cinq-étapes » = appeler explicitement $five-step-dev pour traiter cette demande
   

2. Correspondance des niveaux de modèle : tous les /model fable, /model sonnet dans la compétence doivent être remplacés par les commandes de changement de niveau de raisonnement de Codex (ex : commutateur de niveau de raisonnement haut/bas pour GPT-5.6). La logique de l'étape 0.5 (classification vs niveau actuel, arrêt si niveau trop élevé) reste inchangée, seuls les textes de commande sont modifiés.

3. Sous-agents nommés → sessions d'audit indépendantes : Codex n'a pas le mécanisme de sous-agents nommés de Claude Code (implementer/task-reviewer/final-reviewer/scribe). Équivalent :

   • Pour la phase Implement, au lieu de "déléguer à implementer", "implémenter directement dans la session actuelle selon le plan approuvé" (Codex n'a pas de délégation native de sous-agents, ne pas simuler artificiellement).
   • Pour la phase Review, au lieu de "déléguer à task-reviewer / final-reviewer", "ouvrir une nouvelle session Codex, coller uniquement le Plan + le Diff, sans le processus d'implémentation, demander un audit indépendant" — utiliser l'isolation de session au lieu de l'isolation d'agent pour obtenir le même effet de "vérification par un autre point de vue".
   • La phase Verify n'est pas affectée, les exigences de preuve restent identiques.

4. Chemin de consignation du Brief des Besoins : le fichier généré à l'étape 0.8 doit être placé selon les conventions du projet Codex (dans .codex/ ou répertoire équivalent s'il existe, sinon dans docs/decisions/ à la racine du projet).

Les autres étapes (critères de classification, trois règles de confrontation des besoins, règles d'exécution des cinq étapes, liste des points de contrôle métier de niveau C) sont indépendantes de l'outil et ne nécessitent pas de modification.

Remerciements

La discipline de questionnement de l'étape 0.8 « Confrontation des besoins » (questions une par une, chaque question avec une réponse recommandée, vérifier avant de demander) s'inspire de la compétence grilling de obra/superpowers, adaptée avec une gradation selon le niveau de la tâche (B : questions groupées, C : questions une par une). Le mécanisme de carte/tickets de décision/zone de brouillard de la section « Mise à niveau hors norme » s'inspire de la compétence wayfinder de mattpocock/skills, simplifié en un fichier markdown dans le projet pour s'adapter à la chaîne d'outils des utilisateurs non-ingénieurs.