Claude Development

Que fait Claude Development ?

Présentation

Prenez en charge la séquence complète de développement dans Claude Code : implémenter la modification demandée, exécuter ses vérifications, puis obtenir une revue Codex indépendante si demandée avant la livraison. S'applique aux demandes en langage naturel ainsi qu'aux travaux initiés via une autre compétence. Il s'agit d'une orchestration basée sur des instructions ; la sélection automatique de compétence et son achèvement ne sont pas des garanties imposées par l'hôte.

Utilisation

Utilisez /claude-development <tâche> ou appliquez-la à une demande de développement Claude autorisée, par exemple : « Corrige ce bug et livre la modification vérifiée. » Incluez les changements de configuration déclaratifs même s'ils ne nécessitent pas de TDD. La planification, l'explication et la revue seules n'autorisent aucune implémentation.

Une demande d'implémentation autorise les corrections locales nécessaires au résultat demandé, y compris la correction limitée par Codex des défauts démontrés dans ce périmètre. Préservez les limites utilisateur plus strictes. Les commits, push, publication de PR, approbations et fusions conservent leurs exigences d'autorisation existantes. Les autres compétences gèrent leurs étapes spécialisées ; cette compétence détermine quand le développement se termine.

Étapes

1. Établir la tâche et les prérequis. Lisez les instructions du dépôt, l'état Git actuel, les sources pertinentes et les ADR. Identifiez les exigences, les fichiers autorisés, les modifications existantes et la limite de vérification. Ne résolvez que les inconnues matérielles avec requirements-clarification. Vérifiez que les vérifications requises sont disponibles. Si une revue Codex indépendante est demandée, vérifiez code-review-fix et son environnement d'exécution déclaré avant cette étape. Gardez les portes de revue Stop automatiques désactivées ; l'absence d'outillage de revue optionnel ne bloque ni l'implémentation ni la livraison ordinaire.
2. Respecter le workflow englobant. Pour une tâche Linear, laissez linear-start et linear-workflow gérer l'éligibilité, la branche, le suivi et l'état de la PR. Les autres workflows spécialisés conservent leur propre autorité et limites. Lorsque cette tâche répare une PR ouverte, utilisez le workflow pr-fix autorisé pour la réparation et la revue indépendante ; ne démarrez pas une boucle de réparation locale concurrente. L'implémentation locale ordinaire reste ici même si aucune autre compétence n'a été invoquée.
3. Implémenter le résultat déterminé. Préservez le travail non lié. Appliquez tdd pour le comportement exécutable concerné et la validation native ou existante pour les changements déclaratifs. Utilisez les compétences de domaine pertinentes sans transformer chaque test, appel d'outil ou sous-tâche en étape de livraison distincte. Enregistrez le delta complet de la tâche et toute modification intentionnellement exclue.
4. Exécuter les vérifications pertinentes. Indexez les nouveaux fichiers prévus avant le formatage, le lint et la vérification de type. Lancez la barrière du dépôt appropriée au changement réel, avec un environnement nommé et des limites. Les vérifications échouées sont un développement inachevé, pas une permission d'affaiblir les assertions. Ne corrigez que les échecs autorisés et gardez toute preuve essentielle manquante explicite.
5. Lancer une revue indépendante unique si demandée. La revue Codex est optionnelle ; une simple demande d'implémentation ne l'exige pas. Lorsque l'utilisateur demande une revue et des corrections limitées, activez code-review-fix sur le delta local complet avec les exigences, l'identité du candidat et les preuves de vérification brutes. Suspendez les écritures de Claude pendant que le workflow autorisé s'exécute. Une demande de revue seule n'autorise aucune correction et utilise code-review. Ne redémarrez aucune des deux séquences à l'intérieur d'une correction déléguée. Si pr-fix gère la réparation et la revue, préservez son périmètre au lieu de créer une seconde boucle.
6. Livrer le résultat observé. Rapportez le candidat final, le comportement modifié, les décisions concernant les constatations, les vérifications réelles, l'environnement et les limites restantes. Une revue demandée manquante, obsolète ou incomplète reste une limite explicite ; une revue non demandée n'est pas un prérequis à la livraison. Ne dites pas que le développement est terminé simplement parce que du code a été écrit, que les vérifications ont réussi, qu'un enfant est revenu ou qu'une tâche a été marquée comme achevée. Préservez tous les points de contrôle de publication et d'approbation existants dans le workflow englobant.

Pièges

• Une demande simple contourne les compétences spécialisées — la vérification peut disparaître ; ce workflow s'applique au développement Claude quelle que soit la manière dont la tâche a démarré.
• Le TDD devient le workflow externe — un seul test vert termine la livraison trop tôt ; vérifiez la tâche complète et effectuez toute revue demandée après l'implémentation et les vérifications.
• Chaque enfant démarre la séquence de fin — les revues se récursent et le compteur de passage se réinitialise ; seul le propriétaire du développement externe invoque l'étape finale.
• Une modification de configuration saute le TDD — sauter un test de valeur peut aussi sauter la revue par erreur ; utilisez la validation native et effectuez une revue indépendante lorsqu'elle est demandée.
• Une réparation de PR existante obtient une seconde boucle — des rédacteurs concurrents et des verdicts divergent ; conservez le propriétaire de pr-fix et sa revue indépendante finale.

Contraintes

• Ne jamais démarrer une implémentation, une réparation ou une publication à partir d'une demande de planification ou de revue uniquement.
• Ne jamais signaler une revue non effectuée comme terminée ni exiger une revue Codex non demandée.
• Ne jamais outrepasser les limites utilisateur ni s'étendre au-delà du résultat demandé et des corrections confirmées.
• Ne jamais dupliquer la boucle code-review-fix ou pr-fix à l'intérieur d'une correction déléguée.
• Ne jamais activer une porte de revue Stop ni présenter la sélection automatique de compétence comme techniquement imposée.
• Ne jamais installer des environnements d'exécution manquants ni remplacer des preuves manquantes par un résultat semblant réussi.