Audit des expériences et des feature flags

Cette skill vous enseigne comment exécuter des audits de configuration sur les expériences et les feature flags. Tous les contrôles utilisent read_data et list_data — aucune requête SQL n'est nécessaire pour les contrôles de Phase 1.

Modes d'utilisation

Contrôle rapide (entité unique)

Lorsque l'utilisateur pose une question sur une expérience ou un flag spécifique :

1. Récupérez l'entité via read_data (par exemple, read_data("experiments", id) ou read_data("feature_flags", id)).
2. Appliquez les contrôles pertinents depuis experiment checks ou flag checks.
3. Rapportez les résultats inline en markdown, groupés par sévérité (CRITICAL en premier, puis WARNING, puis INFO).
4. Incluez des liens vers les entités sous la forme [Experiment: name](/experiments/id) ou [Flag: key](/feature_flags/id).

Audit ciblé (un domaine)

Lorsque l'utilisateur demande d'auditer toutes les expériences ou tous les flags :

1. Récupérez en masse via list_data (par exemple, list_data("experiments") ou list_data("feature_flags")).
2. Exécutez tous les contrôles pour ce domaine contre chaque entité.
3. Groupez les résultats par sévérité, puis par entité.
4. Rapportez en markdown inline.

Audit complet (exhaustif)

Lorsque l'utilisateur demande un audit complet des expériences et des flags :

1. Récupérez toutes les expériences via list_data("experiments") et tous les flags via list_data("feature_flags").
2. Exécutez tous les contrôles d'expérience et tous les contrôles de flag.
3. Appliquez recurring patterns pour identifier des patterns sur plusieurs résultats.
4. S'il y a plus de 5 entités avec des résultats, générez un artefact notebook via create_notebook pour faciliter la navigation. Sinon, rapportez inline.

Format de sortie

Pour chaque résultat, incluez :

• Badge de sévérité : 🔴 CRITICAL, 🟡 WARNING, ou 🔵 INFO
• Nom du contrôle : Quel contrôle a produit ce résultat
• Lien vers l'entité : Lien markdown vers l'entité
• Ce qui ne va pas : Description d'une phrase
• Action : Que faire à ce sujet (voir remediation actions)

Exemple :

🟡 WARNING — Flag integration · Experiment: checkout-redesign Le feature flag lié est inactif (en pause). Le trafic n'est pas réparti. Action : Réactivez le flag ou terminez l'expérience.

Gestion des données indisponibles

Certains contrôles nécessitent des logs d'activité, qui peuvent ne pas être disponibles via read_data. Si les données du log d'activité sont indisponibles :

• Ignorez checkActivityHistory (contrôle d'expérience) complètement.
• Ignorez les sous-contrôles « toggle instability » et « never activated » dans les contrôles de cycle de vie des flags.
• Dans votre rapport, notez quels contrôles ont été ignorés et pourquoi :

  Ignorés : Contrôles d'historique d'activité (logs d'activité non disponibles via les outils actuels)

Défaillances partielles

Si un appel read_data ou list_data échoue pour certaines entités :

• Continuez avec les entités que vous avez pu récupérer.
• Rapportez quelles entités n'ont pas pu être évaluées et pourquoi.
• N'omettez pas silencieusement d'entités de l'audit.

Fichiers de référence

• Experiment checks — contrôles de configuration d'expérience
• Flag checks — contrôles de feature flag
• Finding types — définitions de sévérité et de catégorie
• Recurring patterns — patterns sur plusieurs résultats
• Remediation actions — que faire concernant chaque résultat