brmdias/enquête

Compétence de workflow d'enquête

Automatise le processus d'enquête complet du TAM pour les problèmes clients.

Utilisation

/investigate <nom-client> <description-problème>

Exemples :

• /investigate LSEG "erreur de timeout webhook"
• /investigate "Network International" "authentification BeyondTrust plugin"
• /investigate Roche "le planificateur ne déclenche pas les jobs"

Ce Que Fait Cette Compétence

Exécute le workflow d'enquête complet décrit dans CLAUDE.md :

1. Trouver le profil client - Localiser et lire les détails de l'environnement client
2. Rechercher dans la base de connaissances - Trouver des enquêtes similaires et les meilleures pratiques
3. Vérifier la documentation - Vérifier si le comportement est documenté
4. Vérifier dans le code - Rechercher le comportement réel dans le code source du produit
5. Vérifier les trackers externes - Rechercher les bugs connus / développements sur GitHub et Jira
6. Recommander un environnement de test - Suggérer un environnement sandbox approprié en fonction du type de problème
7. Résumer les résultats - Fournir un résumé structuré avec références
8. Documenter l'enquête - Créer un nouveau fichier d'enquête dans investigations/ en utilisant le modèle

Instructions

Lorsque cette compétence est invoquée, suivez ces étapes :

Étape 1 : Extraire les paramètres

À partir des arguments, identifiez :

• customer_name : Le nom du client / de l'entreprise
• issue_keywords : Mots-clés décrivant le problème (messages d'erreur, fonctionnalités, composants)

Étape 2 : Trouver le profil client

Grep pattern="<customer_name>" path="customers/" output_mode="files_with_matches"

Si trouvé :

• Lire le fichier de profil client
• Noter : environnement (cloud/on-prem), version Rundeck, échelle, problèmes passés
• Stocker le contexte client pour la suite

Si non trouvé :

• Noter : "Profil client non trouvé - il peut s'agir d'un prospect ou d'un premier engagement"
• Continuer l'enquête

Étape 3 : Rechercher dans la base de connaissances

Enquêtes similaires :

Grep pattern="<issue_keywords>" glob="investigations/**/*.md" output_mode="content" -C 3

Meilleures pratiques associées :

Grep pattern="<issue_keywords>" glob="best-practices/**/*.md" output_mode="content" -C 2

Pour chaque résultat :

• Noter le chemin du fichier, la date (du nom de fichier si enquête) et les résultats clés
• Identifier s'il s'agit d'une correspondance exacte ou d'un modèle similaire
• Extraire les solutions ou contournements

Étape 4 : Vérifier la documentation

Grep pattern="<issue_keywords>" path="repositories/docs/" output_mode="content" -C 2

Déterminer :

• Ce comportement est-il documenté ?
• Existe-t-il des options de configuration ou des limitations connues ?
• La documentation correspond-elle aux attentes du client ?

Étape 5 : Vérifier dans le code produit

Grep pattern="<classe_ou_méthode_pertinente>" path="repositories/rundeckpro/" output_mode="content" head_limit=50

Rechercher :

• Le comportement réel de l'implémentation
• Les valeurs par défaut ou constantes
• Les sources des messages d'erreur
• La logique spécifique aux versions

Étape 6 : Vérifier les trackers externes

Problèmes GitHub communauté (via le connecteur Runlayer) :

Interrogez GitHub via le connecteur Runlayer. Appelez search_tools pour localiser l'outil de recherche de problèmes GitHub, puis execute_tool pour rechercher rundeck/rundeck et rundeckpro/rundeckpro avec <issue_keywords> parmi les problèmes ouverts et fermés (limite ~10 chacun). N'utilisez pas gh en ligne de commande.

Suivi de développement Jira (via le connecteur Runlayer) :

Interrogez Jira via le connecteur Runlayer. Appelez search_tools pour localiser l'outil de recherche de problèmes Jira, puis execute_tool avec le tool_name exact et les arguments retournés pour rechercher le projet RUN avec <issue_keywords> trié par date de mise à jour (JQL équivalent : project=RUN AND text~"<issue_keywords>" ORDER BY updated DESC). N'appelez pas directement les outils mcp__atlassian__*.

Pour chaque résultat pertinent :

• Noter le numéro du problème, le statut et le résumé
• Vérifier si corrigé dans une version spécifique
• Noter tout contournement mentionné

Étape 7 : Recommander un environnement de test

Ne faites cela que si des environnements sandbox sont disponibles. Sinon, notez : "Aucun environnement sandbox disponible - recommander un WAR local pour une reproduction rapide". En fonction des caractéristiques du problème, recommandez un sandbox :

Logique de décision : Analysez les environnements sandbox disponibles et suggérez le plus approprié. Référence : Lire .claude/memory/sandbox-environments.md pour les détails de connexion si nécessaire N'établissez pas de connexion au sandbox dans cette compétence - fournissez simplement la recommandation.

Étape 8 : Générer un résumé structuré

Fournissez les résultats dans ce format :

# Résumé de l'enquête : <customer_name> - <issue_description>

## Contexte client
- **Profil :** [trouvé/non trouvé]
- **Environnement :** [cloud/on-prem, version, échelle]
- **Problèmes passés :** [historique pertinent s'il y en a]

## Résultats de la base de connaissances

### Enquêtes similaires
- [investigation-file.md](path) - <bref résumé>
- [Statut : résolu/contournement/en cours]

### Meilleures pratiques pertinentes
- [best-practice-file.md](path) - <bref résumé>

## Statut de la documentation
- **Documenté :** [Oui/Non/Partiel]
- **Références :** [chemins de fichiers avec numéros de ligne]
- **Détails clés :** [configuration pertinente, limitations, ou conseils]

## Analyse de code
- **Composant :** [noms des classes/méthodes]
- **Comportement :** [comportement réel de l'implémentation]
- **Source :** [chemin_fichier:numéro_ligne]

## Statut des trackers externes

### Problèmes GitHub
- rundeck/rundeck#<numéro> - <résumé> [statut]
- rundeckpro/rundeckpro#<numéro> - <résumé> [statut]

### Problèmes Jira
- RUN-<numéro> - <résumé> [statut, version de correction si applicable]

## Environnement de test recommandé
**Environnement :** [AWS EKS / AWS EC2 / WAR local / PDT-RDTAM]
**Raison :** [type de base de données / spécificités du problème / besoins de test]
**Connexion :** Voir .claude/memory/sandbox-environments.md

## Prochaines étapes
1. [Action immédiate]
2. [Recommandation de test]
3. [Conseils de communication client]

## Ressources associées
- Profil client : [chemin si existe]
- Enquêtes : [liste des fichiers associés]
- Meilleures pratiques : [liste des guides applicables]
- Documentation : [pages de documentation clés]

Directives de qualité

Soyez minutieux mais concis :

• N'incluez pas tous les résultats de recherche - priorisez les résultats pertinents
• Citez les chemins de fichiers pour toutes les références (par ex., investigations/2026-03-15-issue.md:45)
• Marquez clairement les inconnues ("Aucun cas similaire trouvé" plutôt que des affirmations vagues)

Fournissez des informations exploitables :

• Ne vous contentez pas de lister les résultats - synthétisez les tendances
• Si plusieurs enquêtes montrent la même solution, mettez-la en évidence
• Si la documentation contredit le code, signalez-le explicitement

Tenez compte du contexte client :

• Adaptez les recommandations à l'environnement du client (cloud vs on-prem, version)
• Référencez ses problèmes passés si des tendances pertinentes existent
• Ajustez la recommandation d'environnement de test pour correspondre à sa configuration

Gestion des erreurs

Si le client n'est pas trouvé :

• Continuez l'enquête sans contexte client
• Notez : "Recommander la création d'un profil client si engagement récurrent"

Si aucun résultat dans la base de connaissances :

• Essayez des termes de recherche plus larges
• Notez : "Nouveau problème - envisager de documenter comme enquête après résolution"

Si les trackers externes sont indisponibles :

• Notez l'échec de l'outil
• Continuez avec les informations disponibles
• Suggérez une vérification manuelle : "La recherche GitHub a échoué - vérifier manuellement les problèmes rundeck/rundeck"

Si la description du problème est ambiguë :

• Faites de votre mieux avec les mots-clés disponibles
• Notez : "Description du problème ambiguë - la recherche a couvert : [liste des termes utilisés]"
• Suggérez : "Affiner la recherche avec des messages d'erreur ou noms de composants spécifiques"

Étape 9 : Documenter l'enquête

Après avoir terminé l'enquête et présenté le résumé, créez un nouveau fichier d'enquête pour documenter les résultats :

Création du fichier :

investigations/YYYY-MM-DD-description-brève-en-kebab-case.md

Utilisez le modèle : Lire investigations/TEMPLATE.md pour la structure

Remplissez avec :

• Titre : Brève description du problème
• Date : Date d'aujourd'hui (format AAAA-MM-JJ)
• Client : Nom du client issu de l'enquête
• Domaine produit : Composant pertinent (webhooks, jobs, nœuds, etc.)
• Tags : Découverts dans les enquêtes similaires, plus des tags spécifiques au problème
• Énoncé du problème : Description du problème fournie par l'utilisateur
• Détails de l'environnement : Issus du profil client (si trouvé)
• Étapes de l'enquête : Résumé des étapes de recherche effectuées
• Cause racine : Si identifiée pendant l'enquête
• Solution / Résolution : Si trouvée dans la base de connaissances ou la documentation
• Documentation associée : Références découvertes pendant la recherche
• Références code/documentation : Chemins de fichiers avec numéros de ligne issus des résultats de recherche
• Notes/Enseignements : Tendances ou informations issues de l'enquête

Après avoir créé le fichier :

1. Mettre à jour investigations/INDEX.md avec une nouvelle entrée :
   • Ajouter à la section de catégorie appropriée
   • Ajouter au tableau chronologique
   • Ajouter des tags à la section "Recherche rapide par tag"
   • Mettre à jour la date de "Dernière mise à jour"

Remarques

• L'enquête crée un enregistrement permanent dans la base de connaissances
• Temps d'exécution moyen : 30-60 secondes pour la recherche + 2-3 minutes pour la documentation
• Tous les résultats sont des recherches - des tests réels sont toujours nécessaires dans l'environnement recommandé
• Pour des conseils de positionnement stratégique, invoquez séparément Lire .claude/memory/tam-advisory-philosophy.md
• La documentation garantit que les connaissances sont capturées et consultables pour les enquêtes futures