Copie de feature flags entre projets

Cette skill vous guide pour dupliquer un feature flag d'un projet source vers un ou plusieurs projets cibles au sein de la même organisation PostHog.

Quand utiliser cette skill

• L'utilisateur demande de « copier un flag vers un autre projet », « dupliquer ce flag » ou « synchroniser un flag entre projets »
• L'utilisateur veut promouvoir un flag d'un projet de staging vers production (ou l'inverse)
• L'utilisateur veut répliquer une configuration de flag dans un workspace différent et conserver les dépendances de cohorts intactes
• L'utilisateur contourne l'absence de vrais environnements en utilisant des projets comme environnements

Ce que cette skill ne couvre pas

• Copie cross-organisation non supportée. L'endpoint requiert que les projets source et cible appartiennent à la même organisation.
• Copie en masse de tous les flags d'un projet. L'outil copie un flag à la fois. Pour des copies par lot, bouclez sur les clés de flags ; chaque appel est indépendant.
• Nettoyage de flags anciens ou obsolètes — voir la skill cleaning-up-stale-feature-flags à la place.

Workflow

1. Résoudre le flag source

Vous avez besoin de la clé du flag et de l'id du projet source.

• Si l'utilisateur a donné une clé de flag et un id de projet, utilisez-les directement.
• Si l'utilisateur a donné un nom de flag (par ex. « le nouveau flag de tarification »), appelez posthog:feature-flag-get-all dans le projet source pour trouver le flag correspondant et lire sa key.
• Si l'utilisateur n'a donné que le flag et pas de projet, demandez dans quel projet il se trouve. Ne supposez pas le projet MCP actif — copier depuis la mauvaise source est une erreur courante.

2. Résoudre les ids des projets cibles

Les cibles doivent être dans la même organisation que la source. Appelez posthog:projects-get pour lister les projets disponibles et confirmer l'appartenance avant d'émettre la copie.

Pour une copie multi-cible, l'outil accepte jusqu'à 50 ids de projets cibles en un seul appel. Les succès et les échecs sont rapportés par cible, donc un échec partiel ne bloque pas le reste.

3. Prévisualiser le flag source

Appelez posthog:feature-flag-get-definition sur le flag source et présentez un résumé concis à l'utilisateur avant la copie :

• Clé du flag, nom et état actif dans la source
• Groupes de filtres (%, filtres de propriétés, variantes)
• Toute référence de cohort dans filters.groups[].properties[] — elles seront remappées côté serveur, mais l'utilisateur doit savoir si le projet cible a déjà des cohorts correspondants
• Si le flag a des payloads chiffrés (has_encrypted_payloads) ou est une remote configuration (is_remote_configuration)
• Si des changements planifiés existent (l'utilisateur peut choisir de les copier à l'étape 4)

4. Confirmer les options de copie

Utilisez par défaut la combinaison la plus sûre et demandez à l'utilisateur de remplacer uniquement s'il veut explicitement un comportement différent :

• disable_copied_flag: true — le flag copié arrive désactivé dans la cible. Recommandé par défaut ; activer un flag dans un nouveau projet doit être une action délibérée et observée.
• copy_schedule: false — les changements planifiés ne sont pas inclus. Recommandé par défaut ; les planifications sont généralement spécifiques au projet.

Si l'utilisateur dit « promouvoir tel quel » ou « l'activer en prod », passez disable_copied_flag à false. S'il dit « inclure le planning de déploiement » ou « avec le déploiement planifié », passez copy_schedule à true.

5. Exécuter la copie

Appelez posthog:feature-flags-copy-flags-create avec :

• feature_flag_key : la clé du flag source
• from_project : l'id du projet source
• target_project_ids : la liste résolue des ids de projets cibles
• disable_copied_flag : de l'étape 4 (défaut true)
• copy_schedule : de l'étape 4 (défaut false)

6. Rapporter les résultats par cible

La réponse inclut un tableau success (une entrée par flag copié) et un tableau failed (erreurs par cible). Exposez les deux :

• Pour chaque succès : id du projet cible, id du nouveau flag et son état active dans la cible.
• Pour chaque échec : id du projet cible et message d'erreur. Les causes courantes sont l'absence d'accès éditeur sur l'équipe cible, ou le flag existant déjà comme ressource non modifiable dans la cible.

Si des cibles ont échoué, demandez à l'utilisateur s'il faut réessayer les défaillantes, les ignorer ou corriger le problème sous-jacent (par ex. accorder l'accès, puis réessayer).

Notes importantes

• Les cohorts sont remappés automatiquement. Quand le flag source référence un cohort, l'endpoint crée ou réutilise un cohort équivalent dans chaque projet cible et réécrit les filtres du flag pour pointer vers l'id de cohort du projet cible. Vous n'avez pas besoin de gérer cela — mais dites à l'utilisateur que c'est en cours pour qu'il comprenne les nouveaux cohorts qui peuvent apparaître dans la cible.
• Les payloads chiffrés sont préservés. Les flags de remote configuration avec payloads chiffrés conservent leur chiffrement lors de la copie ; le payload est re-chiffré sous la clé du projet cible.
• Les changements planifiés sont copiés avec remapping de cohort aussi. Si copy_schedule: true, toute référence de cohort planifiée est remappée comme les conditions de filtres actifs.
• Exigences d'authentification. La clé API de l'utilisateur doit inclure le scope explicite feature_flag:write (ou feature_flag:*). Une clé *-only sera rejetée — cet endpoint est gardienné par un viewset INTERNAL et le consentement * ne le satisfait pas. Les clés scoped à une équipe ne peuvent pas atteindre cet endpoint ; une clé scoped à l'organisation ou unscoped est requise.
• Accès éditeur sur la source. L'utilisateur doit avoir au minimum un accès au niveau éditeur sur l'équipe du flag source. L'endpoint applique cela via le contrôle d'accès PostHog avant de copier.
• Accès par cible sur les cibles. Les cibles que l'utilisateur ne peut pas voir sont silencieusement supprimées du résultat ; les cibles qu'il peut voir mais sur lesquelles il n'a pas de droits de modification apparaissent dans le tableau failed avec une erreur de permission.
• Pas d'annulation. Une copie crée un nouveau flag dans la cible (ou écrase un flag existant avec la même clé). Confirmez toujours avec l'utilisateur avant d'émettre la copie, particulièrement quand la cible est un projet production.

Exemple d'interaction

Utilisateur : Copie le flag new-checkout du projet 12345 vers le projet 67890.

Agent : Je regarde le flag source dans le projet 12345.

(appelle posthog:feature-flag-get-definition)

Le flag new-checkout est actuellement un booléen à 25 % de déploiement dans le projet 12345, sans filtres de cohort et sans changements planifiés. Je vais le copier comme désactivé dans le projet 67890 sans changements planifiés — c'est le défaut le plus sûr. Confirmez ?

Utilisateur : Oui, mais activez-le dans la cible.

Agent : D'accord — activation dans la cible.

_(appelle posthog:feature-flags-copy-flags-create avec disable_copied_flag: false, copy_schedule: false)_

Fait. Flag id 99887 créé dans le projet 67890 (active: true). Aucune cible défaillante.

Outils disponibles

• posthog:feature-flags-copy-flags-create — effectue la copie. Champs obligatoires : feature_flag_key, from_project, target_project_ids. Optionnels : disable_copied_flag, copy_schedule.
• posthog:feature-flag-get-all — trouver un flag par clé/nom dans un projet donné quand l'utilisateur n'a fourni qu'un nom convivial.
• posthog:feature-flag-get-definition — récupérer le flag source complet (filtres, variantes, références de cohort, flags de chiffrement) pour prévisualiser avant de copier.
• posthog:projects-get — lister les projets dans l'organisation active, utilisé pour résoudre et valider les ids de projets cibles.