Une fonctionnalité approuvée peut traverser trois systèmes avant d’être terminée : un document d’exigences, une hiérarchie de tickets Jira et un dépôt. Claude Code peut aider à rédiger et implémenter, mais les liens entre ces systèmes nécessitent une approbation humaine et des contrôles directs. Ce guide accompagne un développeur ou responsable d’équipe sur une véritable fonctionnalité, avec chaque story approuvée, ses tests d’origine, les mises à jour Jira autorisées et une décision examinée sur les consignes du projet.

Cette procédure repose sur la documentation. BIG CHANGE n’a accédé à aucun projet Jira, exécuté Claude Code, modifié un dépôt ni mesuré un délai de livraison. Les types de tickets, champs, transitions, commandes et coûts exacts dépendent de votre projet et compte.

Le grand changement

  • Ce qui a changé : Une fonctionnalité peut être suivie de son exigence approuvée à un véritable parent Jira et à chaque story, puis au code revu, aux contrôles d’origine et aux mises à jour autorisées.
  • Pourquoi c’est important : La carte des tickets, les résultats de tests et les relectures directes dans Jira montrent le travail approuvé terminé et les stories encore ouvertes.
  • À surveiller : Les champs et transitions propres au projet, les écritures incertaines et les contrôles échoués nécessitent une résolution humaine ; les consignes de Claude Code n’autorisent pas le travail à elles seules.

Avant de commencer

Choisissez une fonctionnalité avec un brief approuvé par son responsable, un dépôt modifiable avec permission et une vérification d’acceptation d’origine exécutable. Le travail réel doit justifier un parent de niveau epic, ses stories approuvées et au moins une sous-tâche utile sous une story du projet Jira Cloud choisi. Sans véritable sous-tâche, ce résultat complet reste en attente ; ajouter un ticket décoratif fausserait le plan. Notez demandeur, autorité d’approbation, révision source, données permises, commit Git initial, isolation ou retour arrière et personne habilitée à revoir le code et changer le statut Jira.

Vérifiez les paramètres installés : version de Claude Code, l’authentification et les permissions. Confirmez que le CLAUDE.md du dépôt donne des consignes sans autoriser les modifications, commandes ou envois de données. Décidez quelles exigences et quel code Claude peut recevoir, quelles commandes il peut exécuter et la limite d’utilisation pour cette fonctionnalité. L’usage peut consommer un quota d’abonnement ou entraîner des frais fournisseur ; le guide des coûts d’Anthropic ne détermine pas votre facture à l’avance.

Pour Jira, obtenez la permission de consulter et créer les types concernés puis, ultérieurement, de commenter ou faire évoluer les tickets en tant qu’acteur autorisé. Un script privé peut utiliser la méthode par adresse e-mail et jeton API documentée par Atlassian ; une intégration peut nécessiter OAuth. Conservez les secrets dans un stockage privé. Excluez-les des prompts, du texte des tickets, de CLAUDE.md, des journaux et du contrôle de versions. Convenez de la visibilité avant d’envoyer les exigences à Jira.

Conservez sept enregistrements privés au fil du travail : docs/feature-prd.md, ticket-plan.json, un journal d’écriture des tickets avec ajout uniquement, ticket-map.json, un reçu d’implémentation par story, un journal des mises à jour Jira et une décision rétrospective. Ils concernent votre fonctionnalité ; ce ne sont pas des fichiers fournis ou exécutés par BIG CHANGE.

1. Approuver un PRD exact

Donnez à Claude Code le véritable brief approuvé et demandez-lui d’identifier les questions non résolues avant de rédiger docs/feature-prd.md. Le document doit préciser demandeur et responsable approbateur, révision d’entrée, problème et utilisateur visé, périmètre et exclusions, identifiants d’exigences numérotés, contrôles d’acceptation et sources de preuve, contraintes non fonctionnelles, projet Jira et questions ouvertes. Une personne responsable compare le brouillon au brief et approuve une révision de contenu et son empreinte exactes. Résolvez les questions importantes avant de créer des tickets ou de modifier le code.

L’empreinte fournit une source précise aux enregistrements ultérieurs. Si le PRD change, revoyez le plan de tickets et les contrôles affectés ; un échec d’implémentation ne justifie pas de réécrire les critères pour obtenir une réussite.

2. Découvrir la hiérarchie et les champs Jira de ce projet

Avec des requêtes Jira REST API v3 autorisées en lecture seule, parcourez les pages de GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes. Pour chaque type proposé, parcourez les pages de GET /rest/api/3/issue/createmeta/{projectIdOrKey}/issuetypes/{issueTypeId} pour connaître les champs de création obligatoires et valeurs permises. Atlassian marque l’opération générale GET /issue/createmeta comme obsolète dans sa référence de l’API des tickets.

Confirmez un véritable parent équivalent à un epic, des enfants de niveau story et les sous-tâches prises en charge. Atlassian décrit la hiérarchie par défaut et sa configuration ; les noms et identifiants de types ne sont pas universels. Examinez le champ Parent à chaque niveau enfant et les champs personnalisés ou paramètres de visibilité obligatoires. Si le projet ne peut représenter le graphe approuvé, notez le type, champ ou droit manquant et suspendez la création. Un simple lien entre tickets ne crée pas une relation parent-enfant.

3. Examiner tout le plan de tickets avant d’écrire

Associez chaque exigence et contrôle d’acceptation du PRD dans ticket-plan.json. Notez son planVersion, l’empreinte du PRD, le site et la clé de projet Jira, un identifiant d’exécution local ainsi que l’approbateur du plan et l’heure. Pour chaque ticket proposé, indiquez un identifiant local unique, l’identifiant local du parent prévu, le type découvert, les champs obligatoires, le résumé, la description, les identifiants d’exigences et d’acceptation, le responsable et la visibilité permise. Le travail approuvé fixe le nombre de stories et sous-tâches. Chacune doit faire un travail réel sous sa véritable story.

Jira REST v3 utilise Atlassian Document Format (ADF), un document JSON structuré, pour les descriptions et commentaires multilignes. Préparez ces documents à partir du contenu approuvé et vérifiez les métadonnées de champs renvoyées par le site avant chaque requête. L’API des tickets documente la création, mais ne fournit pas un objet de champs prêt à l’emploi pour un projet inconnu. Une personne doit approuver le graphe entier, la couverture de toutes les exigences, les relations parentales et la destination exacte avant tout POST.

4. Créer les parents d’abord et relire chaque ticket

Créez le parent approuvé avec POST /rest/api/3/issue, puis ses stories, puis chaque véritable sous-tâche. Avant chaque requête, ajoutez au journal privé l’identifiant d’exécution, l’identifiant local du ticket, la clé du parent confirmé si applicable, la destination, l’empreinte de la requête exacte approuvée, l’heure UTC et l’état pending. N’incluez aucun jeton. Sur HTTP 201, notez l’identifiant et la clé renvoyés par Jira, puis effectuez directement GET /rest/api/3/issue/{issueIdOrKey}. Comparez projet, type, résumé, description ou référence PRD et parent au plan approuvé. Marquez la ligne confirmed seulement après cette relecture. Un parent confirmé débloque ses enfants.

Si une requête expire ou sa réponse est perdue, marquez-la unknown. Cherchez dans Jira par projet, heure, résumé approuvé et référence du plan, puis ouvrez directement chaque résultat probable et faites trancher son identité par le responsable autorisé. Atlassian avertit que la recherche peut être en retard après une écriture. L’absence de résultat ne prouve pas l’échec de la création. L’identifiant d’exécution et le journal facilitent le rapprochement sans faire rejeter les doublons par le serveur. Ne rejouez jamais un POST incertain à l’aveugle.

Relisez directement le graphe fini dans ticket-map.json : identifiant local, identifiant et clé Jira réels, URL canonique, projet, type, clé parent, identifiants PRD et d’acceptation, heure de relecture et référence du journal. Comparez tous les tickets et critères approuvés au PRD. Arrêtez les écritures si un ticket manque ou a le mauvais parent ; utilisez le processus de correction examiné du projet.

5. Implémenter et faire revoir indépendamment chaque story approuvée

Traitez les stories dans l’ordre des dépendances. Pour chacune, notez sa clé Jira, le commit initial et la branche ou copie de travail, la commande d’acceptation d’origine, les chemins et commandes permis. Demandez à Claude Code d’utiliser Plan mode pour relier les critères de cette story au dépôt. Un développeur vérifie le plan et autorise une modification limitée. La limite de story rend le changement examinable ; elle ne retire pas les autres stories de la fonctionnalité.

Après modification, conservez le diff exact, la commande de contrôle d’origine avec sortie complète et code de fin, les tests ciblés pertinents et un verdict pour chaque identifiant d’exigence. Examinez le code et les journaux réels. Un plan écrit, des fichiers générés ou l’affirmation de Claude que les tests passent ne prouvent pas un changement fonctionnel. Suspendez la story en cas de contrôle échoué, secret inattendu, dépendance modifiée, écriture externe ou refonte large ; réparez dans le périmètre et relancez le contrôle d’origine. Un réviseur distinct décide d’accepter le commit ou de suspendre le diff. Notez cette décision pour chaque story. Notre précédent guide d’une modification Claude Code revue couvre cette étape plus étroite ; le PRD et le graphe Jira complet donnent ici le périmètre global.

6. Vérifier les mises à jour Jira autorisées

Pour chaque story revue, lisez son statut actuel et demandez GET /rest/api/3/issue/{key}/transitions?expand=transitions.fields. Examinez la transition réellement proposée à cet acteur, sa destination, les champs obligatoires et valeurs permises. Un responsable autorisé peut alors soumettre la transition choisie par POST /rest/api/3/issue/{key}/transitions avec les champs résolus pour le projet. Relisez directement le ticket et confirmez son nouveau statut. Un contrôle de code réussi n’autorise pas en soi Done, la fusion ou le déploiement.

Notez le statut avant écriture, la transition prévue, l’acteur, la requête et la réponse dans le journal Jira. Publiez un commentaire de preuve ADF factuel avec POST /rest/api/3/issue/{key}/comment : commit accepté ou diff suspendu, contrôle d’origine et tests ciblés, échecs restants et décision du réviseur. Relisez l’identifiant et le contenu du commentaire créé via l’API des commentaires de Jira. Si une écriture a une réponse incertaine, examinez directement statuts ou commentaires avant toute autre requête. Une liste de transitions vide ou un champ obligatoire indisponible est un manque de processus ou de permission à résoudre avec le responsable, pas une invitation à inventer un identifiant.

7. Décider si CLAUDE.md doit changer

Comparez les véritables journaux de PRD, tickets, diff, tests, revue et Jira. Demandez une courte rétrospective fondée sur les incompréhensions observées ou contrôles manquants. Un humain choisit une modification précise des consignes ou une décision de ne rien changer, avec réviseur et heure. Si c’est approuvé, examinez puis faites un commit uniquement de ce diff de CLAUDE.md et son empreinte. Le guide de mémoire d’Anthropic décrit les consignes de projet ; cette revue n’autorise pas automatiquement le travail futur. N’ajoutez aucun secret et ne transformez pas une leçon spéculative en règle.

Achèvement et récupération

La fonctionnalité n’est terminée que si la révision approuvée du PRD correspond au graphe epic/story/sous-tâches directement confirmé ; chaque story approuvée possède son état initial, diff accepté, contrôle d’origine, preuves de tests ciblés et revue indépendante ; chaque transition et commentaire autorisés ont été relus directement ; et un humain a décidé de la rétrospective. Si un élément manque, notez l’étape exacte restante. Choisir une première tâche d’IA s’arrête plus tôt, au choix et à une proposition de contrôle ; cela n’établit pas le résultat de cette implémentation.

Une création Jira incertaine reste unknown jusqu’à ce qu’une personne établisse son identité. Un mauvais parent bloque la création des enfants. Les tests échoués laissent intacts les critères d’origine. Une transition absente ou un quota épuisé laisse un état partiel daté pour le responsable. Limitez exigences et données clients au minimum approuvé pour Claude et Jira, vérifiez coûts et permissions actuels et prévoyez une revue humaine du code. Ce guide documente un chemin conditionnel ; BIG CHANGE ne rapporte aucune fonctionnalité livrée, écriture Jira, exécution de modèle, économie mesurée, fusion ou déploiement.

Sources et lectures complémentaires