claude-dev-skill

Qu'est-ce que claude-dev-skill ?

claude-dev-skill est une skill personnalisée pour Claude Code qui transforme Claude en un processus de « tech lead » pour développer du logiciel avec plusieurs agents IA workers. La skill fournit un workflow structuré en plusieurs phases qui coordonne le travail parallèle des workers dans des worktrees isolés, visant à réduire la perte de contexte et les conflits de merge en routant les changements via des PR et des revues.

Son objectif principal est de dépasser la génération de code mono-thread : elle guide l'alignement des exigences (PRD), les décisions d'architecture, la décomposition des tâches, l'implémentation parallèle, les vérifications QA statiques, et une étape structurée de revue/merge de PR.

Fonctionnalités clés

• Workflow de commande /dev (SOP multi-phases) : Démarre par la classification de la requête et passe par l'alignement PRD, l'architecture et la création d'issues, l'implémentation worker, la vérification QA, et la coordination de merge PR.
• Règle de routage tech-lead : La conversation principale est traitée comme un coordinateur ; elle « ne code jamais directement », exigeant que les changements passent par Worker Agent → PR → revue.
• Agents Workers parallèles via worktrees : Crée plusieurs agents workers qui développent en parallèle dans des worktrees isolés pour supporter différentes parties de la feature (ex. : auth, API, frontend).
• Scan de conflits pré-coding : Avant de commencer, les agents workers scannent les autres Issues ouvertes pour détecter les chevauchements de fichiers et anticiper les conflits.
• Coordination PR post-merge : Après les merges, elle scanne les PR ouvertes et notifie les branches nécessitant un rebase.
• Barrière de sécurité avant revue : Exige l'exécution d'outils de sécurité (ex. : bandit + pip-audit pour Python, ou npm audit pour Node) comme étape obligatoire avant la phase de revue.
• Checklist de revue PR structurée avec conditions de veto : La revue de code suit une checklist de 7 items avec des conditions de veto obligatoires.
• Auto-vérification par contre-exemples pour la couverture de tests : Inclut une auto-vérification en six catégories pour s'assurer que les workers considèrent les scénarios Null/Vide/Boundary/Échec externe/Concurrence/Entrée malveillante.

Comment utiliser claude-dev-skill

1. Installez les fichiers de la skill dans le répertoire de commandes de Claude Code (installation scriptée pour macOS/Linux/Windows, ou copie manuelle en préservant la structure des dossiers).
2. Assurez-vous d'avoir Claude Code (CLI officielle d'Anthropic) connecté.
3. Utilisez la GitHub CLI (gh) avec une session authentifiée (exécutez d'abord gh auth login).
4. Dans Claude Code, exécutez /dev [description optionnelle]. La skill classera la requête (ex. : nouveau projet, nouvelle feature, bug fix, hotfix, changement architectural, refactoring) et entrera dans le flux approprié.

Un run typique suit les phases montrées dans le repo : alignement PRD (deux rounds), architecture et décomposition des tâches avec GitHub Issues, exécution workers en worktrees parallèles, vérification QA statique, et revue/merge PR guidée par checklist.

Cas d'usage

• Construire une feature backend web petite/moyenne avec PRD existant : Utilisez /dev pour traduire un document de exigences produit existant en décisions d'architecture, GitHub Issues, et implémentations workers parallèles.
• Implémenter plusieurs modules simultanément en minimisant les conflits de merge : Faites gérer les composants distincts par des agents workers séparés (ex. : authentification vs. API CRUD tâches vs. composants frontend) et fiez-vous au scan de conflits pré-coding et à la coordination de rebase post-merge.
• Correction de bugs coordonnée ou hotfix : Pour les bug fixes ou hotfixes d'urgence, le flux classe le type de requête et le route via revue d'architecture, changements workers, vérification QA, et merge PR structuré.
• Refactoring systématique avec revue structurée : Lors du refactoring, l'auto-vérification par contre-exemples du SOP et la barrière de sécurité pré-merge aident à s'assurer que les workers considèrent les cas limites et exécutent les outils d'audit requis avant revue.
• Travail de changement d'architecture nécessitant un alignement avant coding : Utilisez l'alignement PRD de Phase 1 et les décisions d'architecture de Phase 2 pour clarifier le plan de l'équipe avant que les workers ne commencent l'implémentation.

FAQ

• Que signifie « tech lead » dans le workflow de cette skill ? La conversation principale agit comme un coordinateur : elle aligne sur le PRD, décide de la direction d’architecture, lance des agents workers, et impose que les changements de code passent par des PR des Worker Agents et une revue plutôt que des modifications directes dans le chat.

• claude-dev-skill écrit-il du code directement depuis la conversation principale ? Non. Le workflow inclut une « règle de fer » selon laquelle la conversation principale n’écrit jamais de code directement ; les changements doivent passer par un Worker Agent puis une PR pour revue.

• Comment les conflits sont-ils gérés pendant le développement parallèle ? La skill inclut un scan de conflits pré-codage (les agents workers vérifient les Issues ouvertes pour les chevauchements de fichiers avant de démarrer) et une étape post-merge qui scanne les PR ouvertes pour identifier les branches nécessitant un rebase.

• Quels contrôles de sécurité sont imposés ? Avant la phase de revue, elle exige l’exécution d’outils de sécurité tels que bandit plus pip-audit pour Python, ou npm audit pour Node, selon la description du Security gate du dépôt.

• Est-ce destiné aux travaux de déploiement en production ? Les notes de portée du dépôt indiquent qu’il n’est pas adapté aux projets nécessitant un déploiement en production car il ne fournit pas de capacités DevOps/déploiement.

Alternatives

• Assistants de code mono-agent (style autocomplétion/chat) : Ils se concentrent sur l’écriture directe de code à partir de prompts, mais ne fournissent généralement pas de workflow multi-agents du PRD au PR avec des gates de revue imposés.
• Prompting multi-étapes conventionnel + workflows PR manuels : Vous pouvez prompt Claude vous-même pour décomposer les tâches puis exécuter les workers manuellement, mais vous perdez la structure SOP intégrée (classification, scan de conflits, coordination QA et revue de checklist).
• Workflows d’équipe standards pilotés par GitHub (Issues/PRs sans SOP IA) : Les équipes peuvent reproduire des parties du flux via GitHub Issues et revues PR, mais la parallélisation des « worker agents » et le routage automatisé des phases ne sont pas fournis de la même manière.
• Autres skills personnalisées Claude Code axées sur la planification ou les tests : Au lieu de coordonner des agents workers parallèles de bout en bout, certaines skills ciblent une seule partie du workflow (ex. génération de tests), laissant l’intégration et la coordination de merge à l’utilisateur.