performance-engineer

Vue d’ensemble de la skill performance-engineer

Ce que fait la skill performance-engineer

La skill performance-engineer propose un workflow ciblé de diagnostic et d’optimisation pour analyser des systèmes lents, repérer les goulots d’étranglement et transformer des retours vagues comme « cet endpoint est lent » en correctifs mesurables. Elle est conçue pour le travail d’optimisation des performances, pas pour la relecture de code généraliste : sa vraie valeur est d’imposer une boucle baseline-mesure-profiling-vérification au lieu de partir sur des suppositions.

À qui s’adresse performance-engineer

Cette skill convient aux développeurs, SRE, ingénieurs backend et utilisateurs d’agents IA qui ont déjà un système à inspecter et veulent être aidés pour circonscrire l’endroit où se perdent le temps, la mémoire ou le débit. Elle est particulièrement utile si vous avez un ralentissement reproductible, un objectif de latence ou un hotspot suspect, sans vouloir partir d’un prompt vide.

Le vrai besoin auquel elle répond

La plupart des utilisateurs ne cherchent pas seulement du « code plus rapide ». Ils doivent répondre à des questions concrètes :

• Quelle métrique est réellement dégradée ?
• Où se situe le goulot d’étranglement : base de données, API, frontend, réseau ou runtime ?
• Que faut-il mesurer avant de modifier le code ?
• Comment prouver que l’optimisation a aidé, sans introduire de régression ?

La skill performance-engineer est particulièrement pertinente quand elle sert à structurer cette investigation.

Pourquoi cette skill est différente d’un prompt générique

Un prompt générique saute souvent directement à des correctifs hypothétiques. Cette skill est meilleure pour l’optimisation des performances, car elle met explicitement au centre :

• les métriques de référence et les objectifs
• le profiling avant l’optimisation
• la localisation du goulot d’étranglement par couche
• la validation après les changements
• des modèles légers de reporting et de profiling issus de scripts/

Elle est donc plus exploitable pour un vrai travail d’ingénierie, et pas seulement pour générer des idées.

Ce qu’il faut vérifier avant l’installation

Cette skill est bien adaptée si vous pouvez fournir :

• un codebase ou un endpoint à inspecter
• un chemin lent reproductible
• au moins un objectif de performance mesurable
• l’autorisation d’exécuter des commandes de profiling, de logs ou de benchmark

Elle est moins adaptée si votre problème relève surtout de la justesse fonctionnelle, du choix d’architecture ou de l’estimation des coûts sans symptôme de performance observé.

Comment utiliser la skill performance-engineer

Comment installer performance-engineer

Installez-la depuis la collection du dépôt avec :

npx skills add https://github.com/zhaono1/agent-playbook --skill performance-engineer

Si vous évaluez la skill avant installation, inspectez :

• skills/performance-engineer/SKILL.md
• skills/performance-engineer/README.md
• skills/performance-engineer/references/checklist.md
• skills/performance-engineer/references/monitoring.md
• skills/performance-engineer/references/optimization.md
• skills/performance-engineer/scripts/profile.py
• skills/performance-engineer/scripts/perf_report.py

Les entrées dont la skill performance-engineer a besoin

La skill performance-engineer fonctionne mieux si vous lui donnez du contexte opérationnel, pas seulement du code. Les entrées les plus utiles incluent :

• l’endpoint, la requête, la page, le job ou la commande lente
• la latence, le débit, la mémoire ou le CPU actuels versus la cible
• les détails d’environnement comme le langage, le framework, le runtime et l’infra
• la façon de reproduire le problème
• toute sortie existante de profiler, trace ou logs
• la couche suspectée : DB, API, frontend, réseau, cache ou calcul

Sans cela, la skill peut encore proposer une méthode, mais la qualité de sortie baisse, car elle doit inférer trop d’éléments.

Transformer une demande vague en prompt solide

Faible :

Optimize this code.

Mieux :

Use the performance-engineer skill on this Python API endpoint. Current p95 latency is 1.4s, target is under 500ms. Traffic spikes at 50 concurrent requests. We use PostgreSQL and Redis. Please identify what to measure first, likely bottlenecks, profiling commands to run, and the order of fixes to test.

Pourquoi c’est meilleur :

• la métrique est définie
• l’objectif est donné
• la charge est précisée
• les couches de goulot d’étranglement probables sont resserrées
• la demande porte sur une séquence d’investigation, pas sur des ajustements aléatoires

Workflow recommandé en pratique avec performance-engineer

Un bon schéma d’usage de performance-engineer est le suivant :

1. Définir le parcours utilisateur ou l’opération système concernée.
2. Enregistrer les métriques de référence.
3. Profiler ou inspecter le chemin lent.
4. Relier les constats aux couches de goulot d’étranglement probables.
5. proposer d’abord le plus petit correctif à fort impact.
6. Re-mesurer après chaque changement.
7. Documenter les constats et les vérifications de non-régression.

Cela reflète la structure par phases de la skill et garde l’optimisation ancrée dans des preuves.

Fichiers du dépôt à lire en premier

Lisez-les dans cet ordre si vous voulez adopter la skill rapidement :

1. SKILL.md pour les signaux d’activation et les phases d’analyse
2. references/checklist.md pour la discipline de processus minimale
3. references/optimization.md pour les leviers d’optimisation courants
4. references/monitoring.md pour savoir quoi suivre après mise en production
5. README.md pour les exemples de cibles et les scripts utilitaires

Les scripts ne sont pas eux-mêmes des profilers ; ce sont des modèles qui aident à standardiser la sortie de l’investigation.

Scripts intégrés qui facilitent l’usage

Deux scripts de support apportent une valeur pratique à ce guide performance-engineer :

• python scripts/profile.py génère un modèle de profiling avec des champs pour l’environnement, la charge et les hotspots.
• python scripts/perf_report.py génère un rapport markdown pour le résumé, le propriétaire, les métriques de référence, les constats, les recommandations et la validation.

Exemple :

python scripts/profile.py --name "checkout latency" --tool "cProfile" --command "python app.py" --duration "60s"
python scripts/perf_report.py --name "checkout API" --owner "payments-team"

Ces scripts sont utiles si vous voulez des notes d’investigation répétables plutôt qu’une sortie de chat ponctuelle.

Ce que la skill est optimisée pour détecter

Le contenu source oriente les utilisateurs vers des localisations fréquentes de goulots d’étranglement, comme :

• des problèmes de base de données tels que les requêtes N+1, les index manquants ou de gros jeux de résultats
• de l’over-fetching côté API ou une sérialisation inefficace
• des hotspots runtime mis en évidence par la sortie d’un profiler
• des inefficacités de payload et de réseau
• des lacunes de cache sur des chemins chauds

Autrement dit, la skill a le plus de valeur lorsqu’il existe un vrai goulot d’étranglement à isoler, pas seulement une envie générale de « tout rendre plus rapide ».

Modèle de prompt pratique pour de meilleurs résultats avec performance-engineer

Utilisez cette structure lorsque vous invoquez performance-engineer for Performance Optimization :

Use the performance-engineer skill.

System:
- Service/page/job:
- Language/framework:
- Infra/dependencies:

Problem:
- Symptom:
- Current metric:
- Target metric:
- Reproduction steps:

Evidence:
- Logs/traces/profile snippets:
- Suspected bottleneck layer:

Task:
- Define measurement plan
- Identify likely root causes
- Recommend ordered fixes
- Specify how to validate improvement

Ce format de prompt produit en général une sortie plus actionnable qu’une simple demande du type « pourquoi est-ce lent ? ».

Freins courants à l’adoption

Avant de vous appuyer sur l’installation de performance-engineer, gardez en tête ses principales limites :

• elle ne remplace pas de vrais profilers ni des outils APM
• elle a besoin de symptômes mesurables pour être efficace
• elle aide moins quand la charge ne peut pas être reproduite
• elle ne peut pas valider les gains si vous ne fournissez pas un chemin de benchmark

En clair, la skill améliore la méthode d’investigation ; elle ne produit pas magiquement des mesures fiables toute seule.

Quand préférer des prompts ordinaires

Si vous avez seulement besoin d’un nettoyage rapide du style de code, de micro-optimisations dans un petit script, ou de conseils de tuning spécifiques à un langage sans investigation, un prompt standard peut suffire. Utilisez la skill performance-engineer quand l’enjeu est plus élevé et que vous avez besoin d’un chemin structuré allant du symptôme au correctif vérifié.

FAQ sur la skill performance-engineer

performance-engineer est-elle adaptée aux débutants ?

Oui, si le débutant dispose déjà d’un scénario de lenteur concret. La skill fournit une séquence disciplinée — baseline, profiling, goulot d’étranglement, validation — qui aide à éviter l’optimisation prématurée. Elle est moins adaptée aux débutants si vous attendez d’elle qu’elle enseigne de zéro toute l’observabilité ou les bases du benchmarking.

Qu’est-ce qui rend performance-engineer meilleure que le simple fait de demander à une IA d’optimiser du code ?

La différence principale tient au contrôle du processus. Un prompt classique propose souvent immédiatement du cache, des index, de l’async ou des refactorings. La skill performance-engineer est plus utile quand vous devez d’abord déterminer si le problème vient de la base de données, de la couche API, du comportement mémoire, de la taille des payloads ou d’un hotspot runtime.

La skill inclut-elle de vrais outils ?

Partiellement. Le dépôt inclut des générateurs de modèles dans scripts/profile.py et scripts/perf_report.py, ainsi que des documents de référence sur la checklist, le monitoring et les leviers d’optimisation. Vous avez toujours besoin de vos propres profilers runtime, logs, benchmarks et commandes adaptées à votre environnement.

performance-engineer est-elle réservée aux services backend ?

Non. Le README inclut des objectifs de performance qui couvrent à la fois les API et des métriques de type chargement de page, et les références mentionnent l’efficacité des payloads et du réseau. Cela dit, les exemples penchent davantage vers l’analyse d’applications et de services que vers une analyse poussée du rendu frontend.

Quand ne faut-il pas utiliser performance-engineer ?

Évitez-la si :

• il n’y a pas encore de problème de performance mesurable
• vous voulez seulement un brainstorming large sur l’architecture
• le sujet relève de la fiabilité ou de la justesse plutôt que de la vitesse
• vous ne pouvez ni reproduire la charge ni collecter de métriques

Dans ces cas-là, la structure de la skill apporte moins de valeur.

performance-engineer peut-elle aider pour le monitoring après les correctifs ?

Oui. references/monitoring.md pousse les utilisateurs à suivre les percentiles, le débit, les taux d’erreur et les alertes de régression. C’est utile si vous voulez que la skill accompagne la validation du rollout, et pas seulement un tuning ponctuel.

Comment améliorer la skill performance-engineer

Donnez de meilleures baselines, pas simplement des prompts plus longs

Le moyen le plus rapide d’améliorer l’usage de performance-engineer est de fournir :

• la latence actuelle p50, p95 ou p99
• le débit et le taux d’erreur
• les symptômes mémoire ou CPU
• le chemin exact de benchmark ou de requête
• un plan de comparaison avant/après

C’est plus utile que d’ajouter un long contexte narratif.

Incluez l’environnement et la forme de la charge

Les conseils de performance changent selon la charge. Indiquez à la skill :

• la concurrence des requêtes
• la taille du jeu de données
• l’état du cache, chaud ou froid
• les contraintes CPU et mémoire
• l’environnement local, staging ou production

Le modèle fourni par scripts/profile.py rappelle bien ce qu’il faut capturer : environnement, charge, commande, durée et hotspots.

Demandez des correctifs classés avec étapes de validation

Un bon prompt de suivi est :

Use the performance-engineer skill to rank the top three likely bottlenecks by expected impact and confidence. For each, give the measurement to confirm it, the smallest fix to test, and the benchmark to verify improvement.

Cela réduit les réponses vagues du type « essayez tout » et rend les itérations moins coûteuses.

Évitez les modes d’échec les plus fréquents

Les raisons les plus courantes pour lesquelles les utilisateurs obtiennent des résultats faibles avec performance-engineer sont :

• aucune métrique de référence
• aucune charge reproductible
• aucune preuve issue d’un profiler ou de traces
• demander des correctifs avant d’avoir isolé le goulot d’étranglement
• regrouper plusieurs systèmes dans une seule demande vague

Si votre premier résultat paraît générique, il manque généralement un de ces éléments.

Utilisez la checklist comme garde-fou qualité

references/checklist.md est court, mais important. Considérez-le comme le standard minimum :

• métriques de référence enregistrées
• goulots d’étranglement identifiés
• correctifs vérifiés par benchmark
• tests de non-régression ajoutés

C’est à ce niveau que cette skill devient réellement opérationnelle, et non plus seulement consultative.

Documentez les constats pour améliorer l’itération suivante

Après le premier passage, générez un rapport avec scripts/perf_report.py, puis réinjectez-le dans l’exécution suivante. Cela aide la skill performance-engineer à affiner ses recommandations à partir de constats réels, d’un propriétaire identifié et de notes de validation, au lieu de repartir de zéro à chaque fois.

Améliorez les prompts avec des extraits de preuves

Au lieu de dire « la DB semble lente », collez un bloc de preuves compact, par exemple :

• un échantillon de durée de requête
• les principales fonctions dans le profiler
• un résumé des spans de trace
• les timings d’endpoint par percentile

Même des preuves partielles améliorent fortement la qualité de sortie, car la skill peut relier ses recommandations à des hotspots observés plutôt qu’à des réponses par défaut.

Bien distinguer diagnostic et implémentation

Le workflow performance-engineer for Performance Optimization est particulièrement fort pour le diagnostic, la priorisation et la planification de validation. Il devient plus efficace lorsqu’il est suivi d’un second passage centré sur l’implémentation du correctif retenu dans votre stack. Utilisez-le d’abord pour décider de ce qui compte vraiment, puis appuyez-vous sur une aide au code pour appliquer le changement en toute sécurité.