Découverte de drapeaux LaunchDarkly

Vous utilisez une skill qui vous guidera dans l'audit et la compréhension du paysage des drapeaux de fonctionnalité dans un projet LaunchDarkly. Votre travail consiste à explorer le projet, évaluer la santé de ses drapeaux, identifier ce qui nécessite une attention particulière et fournir des recommandations exploitables.

Prérequis

Cette skill nécessite que le serveur MCP LaunchDarkly hébergé à distance soit configuré dans votre environnement.

Outils MCP requis :

• list-flags : rechercher et parcourir les drapeaux avec filtrage par état, type, tags
• get-flag : obtenir la configuration complète d'un drapeau unique dans un environnement spécifique
• get-flag-status-across-envs : vérifier le statut du cycle de vie d'un drapeau dans tous les environnements

Outils MCP optionnels (renforcent la profondeur) :

• find-stale-flags : trouver les drapeaux candidats au nettoyage, triés par ancienneté
• get-flag-health : obtenir une vue de santé combinée pour un drapeau unique (fusionne statut + configuration)
• check-removal-readiness : vérification de sécurité détaillée pour un drapeau spécifique

Flux de travail

Étape 1 : Comprendre le projet

Avant de vous plonger dans les données des drapeaux, établissez le contexte :

1. Identifier le projet. Confirmez le projectKey avec l'utilisateur. S'il ne l'a pas spécifié, demandez-le.
2. Comprendre la portée. Demandez à l'utilisateur ce qu'il essaie d'accomplir :
   • Audit large ? ("Quel est l'état de nos drapeaux ?")
   • Investigation ciblée ? ("Ce drapeau spécifique est-il toujours nécessaire ?")
   • Planification du nettoyage ? ("Quels drapeaux pouvons-nous supprimer ?")

Étape 2 : Explorer le paysage des drapeaux

Adaptez votre approche à l'objectif de l'utilisateur :

Pour un audit large :

• Utilisez list-flags limité à un environnement critique (par défaut production).
• Notez le nombre total : cela vous indique l'échelle de la surface des drapeaux.
• Filtrez par state (active, inactive, launched, new) pour segmenter le paysage.
• Filtrez par type (temporary vs permanent) : les drapeaux temporaires sont les principaux candidats au nettoyage.

Pour la planification du nettoyage :

• Utilisez find-stale-flags : c'est le point d'entrée le plus efficace. Il retourne une liste priorisée de candidats au nettoyage triés par ancienneté, catégorisés comme :
  • never_requested : créé mais jamais évalué (possiblement abandonné)
  • inactive_30d : aucune évaluation SDK dans la période spécifiée
  • launched_no_changes : entièrement déployé, aucun changement récent
• inactiveDays par défaut est 30. Augmentez pour un nettoyage conservateur (60, 90) ou diminuez pour un nettoyage agressif (7, 14).
• includeOnly par défaut est temporary. Défini sur all pour inclure les drapeaux permanents.

Pour une investigation ciblée :

• Utilisez get-flag-health pour une exploration approfondie d'un seul drapeau. Elle fusionne les données de statut avec le contexte de configuration en un seul appel, retournant l'état du cycle de vie, le timestamp de la dernière demande, le résumé du ciblage, l'âge et si c'est un drapeau temporaire.
• Ou utilisez get-flag pour la configuration complète incluant les règles, les cibles et les détails de fallthrough.

Étape 3 : Évaluer la santé du drapeau

Pour les drapeaux qui nécessitent une investigation plus approfondie, évaluez les signaux de santé. Consultez Flag Health Signals pour le guide d'interprétation complet.

Signaux clés à évaluer :

Utilisez get-flag-status-across-envs pour vérifier si un drapeau est cohérent entre les environnements. Un drapeau inactif en production mais actif en staging raconte une histoire différente de celui inactif partout.

Étape 4 : Catégoriser et prioriser

Regroupez les drapeaux en catégories exploitables :

1. Prêt à supprimer : Inactif partout, temporaire, aucune dépendance. Dirigez l'utilisateur vers la skill de nettoyage de drapeaux pour la suppression du code.
2. Probablement sûr, nécessite vérification : Déployé (entièrement déployé), aucun changement de règle récent. L'utilisateur doit confirmer que le déploiement est intentionnellement complet.
3. Nécessite investigation : Actif dans certains environnements mais pas dans d'autres, ou a un ciblage complexe. Ne recommandez pas d'action sans plus de contexte.
4. Laisser tel quel : Drapeaux actifs qui font leur travail, ou drapeaux permanents intentionnellement durables.

Étape 5 : Évaluer la préparation à la suppression (le cas échéant)

Si l'utilisateur veut savoir si un drapeau spécifique peut être supprimé, utilisez check-removal-readiness. Cet outil orchestre plusieurs appels API en parallèle et retourne un verdict structuré :

• safe : Aucun blocage ou avertissement. Procédez au nettoyage.
• caution : Des avertissements existent (références au code, cibles qui expirent, type de drapeau permanent). Présentez et laissez l'utilisateur décider.
• blocked : Bloqueurs durs (drapeaux dépendants, requêtes actives, règles de ciblage). Doit être résolu d'abord.

Consultez Removal Readiness Checklist pour les détails complets sur l'interprétation de chaque signal.

Étape 6 : Présenter les résultats

Structurez votre réponse en fonction de ce que l'utilisateur a demandé :

Pour les audits : Commencez par un résumé (nombre total de drapeaux, répartition par état et type), puis mettez en évidence ce qui nécessite une attention particulière, puis fournissez des recommandations spécifiques.

Pour les drapeaux spécifiques : Commencez par le verdict (sain / nécessite attention / prêt à supprimer), puis soutenez-le avec les signaux que vous avez trouvés.

Pour la planification du nettoyage : Commencez par le nombre de candidats au nettoyage, priorisez par confiance (suppressions les plus sûres en premier) et liez au flux de travail de nettoyage pour l'exécution.

Contexte important

• "Lancé" signifie entièrement déployé : le ciblage est activé, une variante unique est servie à tout le monde et aucun changement n'a été effectué récemment. Cela ne signifie pas "récemment déployé".
• "Inactif" ne signifie pas toujours sûr à supprimer. Le drapeau peut être utilisé dans du code qui n'a pas encore été fourni, ou référencé comme prérequis par un autre drapeau.
• Les drapeaux permanents peuvent être inactifs intentionnellement. Certains drapeaux sont conçus pour être dormants jusqu'à ce qu'ils soient nécessaires (kill switches, bascules d'urgence). Ne les signalez pas automatiquement pour nettoyage.
• Les poids sont mis à l'échelle par 1 000 dans l'API. Un poids de 60000 signifie 60 %. Convertissez toujours en pourcentages lisibles par l'homme.
• Cette skill concerne la découverte, pas l'action. Si l'utilisateur veut supprimer un drapeau du code, dirigez-le vers la skill de nettoyage de drapeaux. S'il veut modifier le ciblage, dirigez-le vers la skill de ciblage de drapeaux.

Références

• Flag Health Signals : Comment interpréter les états du cycle de vie, l'ancienneté et les données de santé
• Removal Readiness Checklist : Évaluation de sécurité complète avant de recommander la suppression d'un drapeau