Workflow Patterns
Maîtriser le flux de travail TDD avec Conductor
Vous avez du mal avec un flux de travail de développement désorganisé et une couverture de tests insuffisante. Cette compétence fournit un cadre TDD structuré avec des points de contrôle de phase, la gestion des commits git et des protocoles de vérification pour garantir la qualité du code tout au long de l'implémentation.
Télécharger le ZIP du skill
Importer dans Claude
Allez dans Paramètres → Capacités → Skills → Importer un skill
Activez et commencez à utiliser
Tester
Utilisation de "Workflow Patterns". Aidez-moi à créer un commit de point de contrôle après avoir terminé la phase 1
Résultat attendu:
- Exécution de la vérification automatisée...
- Suite de tests : 47 tests passés
- Couverture : 87% (cible : 80%)
- Linting : Pas d'erreurs
- Commit de point de contrôle créé : def5678
- Plan mis à jour avec le SHA du point de contrôle
- En attente d'approbation de vérification manuelle
Utilisation de "Workflow Patterns". Guidez-moi à travers le flux de travail TDD pour la tâche 2.1
Résultat attendu:
- Étape 1 : Sélectionner la prochaine tâche - Tâche 2.1 marquée
- Étape 2 : Marquer comme en cours [~] dans plan.md
- Étape 3 : RED - Écrire les tests qui échouent (test_validate_user_email)
- Étape 4 : GREEN - Implémenter le code minimum (méthode validate_email)
- Étape 5 : REFACTOR - Extraire les motifs, améliorer le nommage
- Étape 6 : Vérifier la couverture >= 80%
- Étape 7 : Documenter tout écart
- Étape 8 : Créer un commit structuré
- Étape 9 : Attacher des notes git avec le résumé
- Étape 10 : Mettre à jour plan.md avec le SHA du commit
- Étape 11 : Valider la mise à jour du plan
Audit de sécurité
SûrStatic analysis detected 80 potential security issues in resources/implementation-playbook.md, all of which are false positives. The file contains Markdown documentation with bash code examples for educational purposes. The external_commands patterns are git command examples in code blocks (lines 25-571), not executable code. The weak_crypto findings are documentation text, not cryptographic implementations. This skill contains only documentation and no executable code, posing no security risk.
Problèmes à risque moyen (1)
Score de qualité
Ce que vous pouvez construire
Implémenter une nouvelle fonctionnalité avec TDD
Un développeur implémente une nouvelle fonctionnalité d'authentification utilisateur en suivant le cycle rouge-vert-refactorer, avec une couverture de tests appropriée et des commits git à chaque étape.
Établir des points de contrôle de phase
Un lead technique crée des points de vérification à la fin de chaque phase de développement pour garantir que les portes de qualité sont respectées avant de continuer.
Suivre la progression de l'implémentation
Un développeur suit l'achèvement des tâches en mettant à jour plan.md avec les SHAs de commit et en maintenant la traçabilité de la planification au code.
Essayez ces prompts
Je commence la tâche 2.1 : Implémenter la validation utilisateur. Aidez-moi à suivre le flux de travail TDD pour écrire d'abord les tests qui échouent, puis implémenter le code minimum pour passer, et refactorer pour plus de clarté.
J'ai terminé toutes les tâches de la phase 1. Aidez-moi à créer un commit de point de vérification avec vérification : exécuter la suite de tests complète, vérifier une couverture supérieure à 80%, et générer une liste de vérification manuelle.
Aidez-moi à créer un message de commit structuré pour l'achèvement de la tâche 2.1 en suivant le format : type(scope): sujet, corps avec points de liste, et pied de page avec références de tâche/track.
Pendant l'implémentation, j'ai découvert que nous avons besoin d'une approche différente de celle planifiée. Aidez-moi à documenter cet écart correctement dans plan.md et tech-stack.md.
Bonnes pratiques
- Toujours écrire les tests qui échouent d'abord (RED) avant l'implémentation (GREEN) - ne jamais sauter la phase RED
- Créer des commits atomiques - un changement logique par commit avec des tests qui passent après chaque commit
- Attendre l'approbation explicite de l'utilisateur avant de passer les points de contrôle de phase - ne pas sauter les portes de vérification
- Mettre à jour plan.md immédiatement après chaque tâche avec le SHA de commit pour la traçabilité
Éviter
- Écrire du code d'implémentation avant les tests - cela viole les principes TDD et réduit l'efficacité des tests
- Regrouper plusieurs tâches dans un commit - cela rompt la traçabilité et rend la revert sémantique difficile
- Passer à la phase suivante sans approbation du point de contrôle - cela contourne les portes de qualité et risque d'accumuler de la dette technique
- Mettre à jour plan.md uniquement après plusieurs tâches - cela perd la traçabilité et rend l'audit de progression difficile