Flaguer et Publier une Modification de PR

Tu utilises une skill qui prend une pull request dont la modification doit être déployée derrière un feature flag et la pilote de bout en bout : décide si elle a besoin d'un flag, crée le flag de garde, câble le nouveau comportement derrière lui sur la branche de la PR, et enregistre une publication automatisée pour que la modification soit déployée en toute sécurité une fois la PR fusionnée.

Le déploiement n'est pas la publication. La fusion déploie le chemin de contrôle — le flag est créé DÉSACTIVÉ, donc le déploiement sert toujours le comportement pré-modification. La publication est l'opération de flag que le déploiement automatisé effectue après, régi par la politique de l'environnement. Créer le flag DÉSACTIVÉ et enregistrer la publication sont volontairement des étapes séparées.

Cette skill est un orchestrateur de PR portable. Elle ne possède pas la mécanique du flag ni celle de la publication — elle compose trois skills ciblées et ajoute le workflow PR (lire le diff, travailler dans un clone, pousser vers la branche) plus le séquençage plan→implémentation :

Ne duplique la mécanique d'aucune skill composée ici. Le seul contenu unique de cette skill est le wrapper PR (clone, diff en trois points, commit/push vers la branche) et le flux plan→implémentation qui les trois ensemble.

Note automation. Un harnais d'orchestration (p. ex. un pipeline PR) peut ignorer cette skill et invoquer directement les trois skills composées — should-flag-change → launchdarkly-flag-create → flag-release — en pilotant lui-même git et le séquençage. Cette skill est le chemin portable, avec intervention humaine, pour un développeur travaillant une PR à la main.

Tu travailles en deux phases — plan, puis implémentation — et tu te mets d'accord avec l'utilisateur entre les deux. Ne crée ni ne modifie rien pendant la phase de plan.

Prérequis

• Le serveur MCP LaunchDarkly hébergé à distance.
• Une CLI git capable de lire et pousser vers le dépôt de la PR.
• Les skills composées disponibles : launchdarkly-flag-create (création de flag + câblage de code) et flag-release (enregistrement du déploiement). should-flag-change est utilisée si la décision du flag n'a pas été prise.

Les outils MCP sont utilisés via les skills composées — create-flag/get-flag via flag-create, match-release-policies/create-automated-rollout-config via flag-release. Cette skill n'en appelle aucun directement.

Travailler avec la Pull Request

Travaille à partir d'un clone pour que tu puisses lire la modification et pousser le câblage du flag vers sa branche. Les identifiants sont fournis par l'environnement — ne demande jamais, n'affiche jamais et ne stocke jamais de tokens.

git clone https://github.com/<owner>/<repo>.git && cd <repo>
git fetch origin pull/<pr_number>/head
git diff origin/HEAD...<head_sha>       # trois points : modification relative à la base de la PR

Le diff en trois points (base...head) montre exactement ce que la PR introduit. Lis les fichiers modifiés dont tu as besoin pour comprendre la modification et son risque. Reste dans ce clone pendant les deux phases — en implémentation tu édites, commits et pousses ici. Les mécaniques complètes de PR (clone, diff en trois points, commit/push vers la branche) : references/pr-wiring.md.

Phase de Plan

Ne crée rien dans cette phase.

1. Confirme que le flag est justifié. Si should-flag-change a déjà été exécutée, agis selon son verdict. Sinon applique le même jugement : favorise un flag pour les modifications visibles par l'utilisateur ou risquées ; ignore les modifications de configuration seule, les mises à jour de dépendance, l'infra, les tests seuls, ou la documentation. Si un flag n'est clairement pas justifié, dis-le et arrête.
2. Comprends la modification et les conventions. Lis le diff en trois points et les fichiers modifiés — que fait-elle, quel est le rayon de souffle ? Puis suis l'étape 1 de flag-create pour apprendre comment cette base de code utilise déjà les flags (SDK, wrapper, constantes clé, nommage). Ne réinvente pas cette exploration ici.
3. Conçois le flag. Généralement un seul booléen kill-switch autour du nouveau chemin (les flag-types de flag-create couvrent le choix). Ne propose pas plus de flags que la modification n'en a besoin. Si l'étape 1 (ou should-flag-change) a mis au jour une dépendance envers un flag/feature parent qui n'est pas encore live, note-le — l'étape de publication peut les coupler avec une condition préalable.
4. Planifie la publication. Suis la phase de plan de flag-release : choisis les environnements cibles, prévisualise chacun avec match-release-policies, et capture l'intention de publication de l'humain (publication à la fusion / mise en attente / notBefore / segment / condition préalable). Ne redérive pas le modèle de déploiement ici — c'est le travail de flag-release.
5. Présente le plan combiné et arrête. Résume : le flag (key, name, booléen, tags) et pourquoi il garde cette modification ; où dans le code va la garde ; le plan de publication par environnement + intention capturée (et tout ce qui doit être mis en attente). Puis attends. Révise sur retours ; procède seulement sur approbation claire. Pose une question ciblée si tu manques véritablement quelque chose (clé de projet, environnements, une politique manquante) plutôt que de deviner.

Phase d'Implémentation

Seulement après approbation :

1. Crée le flag et câble le code en utilisant launchdarkly-flag-create (ses étapes 3–4) : flag créé DÉSACTIVÉ avec la clé/les tags convenus, évaluation de garde ajoutée avec une valeur par défaut sûre correspondant au pattern de la base de code. Échoue fermé sur les erreurs de création : seul un résultat « déjà existe » est un succès par réutilisation. Tout autre échec de create-flag (authentification, permissions, non trouvé, erreur serveur) est un arrêt définitif — ne câble pas le code, n'enregistre pas la publication, ne signale pas le succès. Un faux « flag créé » donne une PR verte référençant un flag qui n'existe pas, pire qu'un échec honnête. Remonte l'erreur et arrête.
2. Ajoute des tests flag-on / flag-off appairés. Si le dépôt a une suite de tests, ajoute un test pour chaque état du chemin enrobé — flag ON sert le nouveau comportement, flag OFF préserve l'ancien — correspondant au framework et à la convention de mock de flag du dépôt. Exécute-les et continue seulement une fois au vert. Limite la portée des tests au chemin flagué, pas la couverture générale. Si le dépôt n'a pas de tests, passe et dis-le.
3. Committe et pousse vers la branche de la PR. Committe le câblage et pousse vers la branche existante de la PR pour qu'il atterrisse dans la même PR — ne crée pas une nouvelle PR ni ne touche la branche de base. Voir references/pr-wiring.md.
4. Enregistre la publication en transmettant à la phase d'implémentation de flag-release : elle enregistre le déploiement automatisé, en respectant l'intention capturée (mettant en attente tout environnement que l'intention ne libère pas) et retourne un config_id. Ne réenseigne pas la mécanique du déploiement ici.
5. Signale la modification complète : clé de flag + lien LaunchDarkly (créé DÉSACTIVÉ) ; le(s) fichier(s)/chemin de code câblé(s) ; les tests ajoutés ; le plan de publication par environnement + config_id ; ce qui a été mis en attente (et pourquoi) par rapport à ce qui publie à la fusion. Signale seulement ce que tu as vérifié.

Cas Limites

Ce qu'il NE FAUT PAS Faire

• Ne crée rien dans la phase de plan. Le plan propose ; l'implémentation crée.
• Ne réenseigne pas la création de flag, le câblage du SDK, ou la mécanique du déploiement ici — ce sont launchdarkly-flag-create et flag-release. Relie-toi à eux.
• Ne mets pas le flag à ON toi-même. La publication enregistrée possède cela ; créer le flag DÉSACTIVÉ est le point.
• Ne sur-flagge. Un kill-switch vaut mieux que plusieurs flags spéculatifs.
• Ne manipule ni n'affiche les identifiants. L'accès git est injecté.

Références

• references/pr-wiring.md : mécaniques PR — clone, diff en trois points, commit vers la branche PR. (La seule référence unique de cette skill.)
• should-flag-change : la décision de mérite du flag.
• launchdarkly-flag-create : création de flag + patterns de câblage par SDK.
• flag-release : enregistrement du déploiement automatisé (et son modèle de publication auto-release.md).