performance-engineer

Überblick über das performance-engineer Skill

Was das performance-engineer Skill macht

Das performance-engineer Skill ist ein fokussierter Workflow für Fehlersuche und Optimierung, um langsame Systeme zu analysieren, Engpässe zu finden und vage Aussagen wie „dieser Endpoint ist langsam“ in messbare Verbesserungen zu überführen. Es ist für konkrete Performance-Optimierung gedacht, nicht für allgemeines Code-Review. Der Mehrwert liegt darin, konsequent einen Baseline-Messen-Profiling-Verifizieren-Zyklus durchzusetzen, statt ins Blaue hinein zu raten.

Für wen sich performance-engineer eignet

Dieses Skill passt zu Entwicklern, SREs, Backend Engineers und Nutzern von AI-Agents, die bereits ein bestehendes System untersuchen und gezielt herausfinden wollen, wo Zeit, Speicher oder Durchsatz verloren gehen. Besonders nützlich ist es, wenn sich eine Verlangsamung reproduzieren lässt, ein Latenzziel existiert oder ein Hotspot vermutet wird, du aber nicht mit einem komplett offenen Prompt anfangen möchtest.

Der eigentliche Job-to-be-done

Die meisten Nutzer wollen nicht einfach nur „schnelleren Code“. Sie müssen praktische Fragen beantworten:

• Welche Metrik ist tatsächlich problematisch?
• Wo liegt der Engpass: Datenbank, API, Frontend, Netzwerk oder Runtime?
• Was sollte vor Codeänderungen gemessen werden?
• Wie weisen wir nach, dass die Optimierung geholfen hat und nichts verschlechtert wurde?

Das performance-engineer Skill ist am stärksten, wenn es genau diese Untersuchung strukturiert.

Warum sich dieses Skill von einem generischen Prompt unterscheidet

Ein generischer Prompt springt oft direkt zu spekulativen Fixes. Für Performance-Optimierung ist dieses Skill besser geeignet, weil es explizit diese Punkte ins Zentrum stellt:

• Baseline-Metriken und Zielwerte
• Profiling vor der Optimierung
• Eingrenzung des Bottlenecks nach Schicht
• Validierung nach Änderungen
• schlanke Reporting- und Profiling-Templates aus scripts/

Dadurch ist es für echte Engineering-Arbeit deutlich brauchbarer und nicht nur für lose Ideenfindung.

Was du vor der Installation prüfen solltest

Dieses Skill passt gut, wenn du Folgendes liefern kannst:

• eine Codebasis oder einen Endpoint zur Analyse
• einen reproduzierbaren langsamen Pfad
• mindestens ein messbares Performance-Ziel
• die Möglichkeit, Profiling-, Logging- oder Benchmark-Kommandos auszuführen

Weniger geeignet ist es, wenn es dir vor allem um Korrektheit, Architekturauswahl oder Kostenschätzung ohne beobachtbare Performance-Symptome geht.

So nutzt du das performance-engineer Skill

So installierst du performance-engineer

Installiere das Skill aus der Repository-Sammlung mit:

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

Wenn du das Skill vor der Installation bewerten willst, schau dir zuerst diese Dateien an:

• 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

Welche Eingaben das performance-engineer Skill braucht

Das performance-engineer Skill funktioniert am besten, wenn du nicht nur Code, sondern auch operativen Kontext mitgibst. Gute Inputs sind:

• der langsame Endpoint, Query, die Seite, der Job oder das Kommando
• aktuelle versus angestrebte Latenz, Durchsatz, Speichernutzung oder CPU
• Umgebungsdetails wie Sprache, Framework, Runtime und Infrastruktur
• wie sich das Problem reproduzieren lässt
• vorhandene Profiler-Ausgaben, Traces oder Logs
• die vermutete Schicht: DB, API, Frontend, Netzwerk, Caching oder Compute

Ohne diese Angaben kann das Skill zwar immer noch einen sinnvollen Prozess vorschlagen, die Qualität der Ergebnisse sinkt aber deutlich, weil zu viel geraten werden muss.

Aus einer vagen Anfrage einen starken Prompt machen

Schwach:

Optimize this code.

Besser:

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.

Warum das besser ist:

• es definiert die Metrik
• es nennt das Ziel
• es beschreibt die Last bzw. den Workload
• es grenzt wahrscheinliche Bottleneck-Schichten ein
• es fordert eine Untersuchungsreihenfolge statt zufälliger Tweaks

Empfohlener performance-engineer-Workflow in der Praxis

Ein gutes Muster für performance-engineer usage ist:

1. Den betroffenen User-Pfad oder Systemvorgang definieren.
2. Baseline-Metriken erfassen.
3. Den langsamen Pfad profilieren oder inspizieren.
4. Erkenntnisse den wahrscheinlichen Bottleneck-Schichten zuordnen.
5. zuerst den kleinsten Fix mit hohem erwarteten Effekt vorschlagen.
6. Nach jeder Änderung erneut messen.
7. Erkenntnisse und Regression-Checks dokumentieren.

Das entspricht der Phasenstruktur des Skills und sorgt dafür, dass Optimierung auf belastbaren Daten basiert.

Welche Repository-Dateien du zuerst lesen solltest

Wenn du den schnellsten Einstieg willst, lies diese Dateien in dieser Reihenfolge:

1. SKILL.md für Aktivierungssignale und die Analysephasen
2. references/checklist.md für die minimale Prozessdisziplin
3. references/optimization.md für typische Optimierungshebel
4. references/monitoring.md dafür, was nach dem Rollout überwacht werden sollte
5. README.md für Beispielziele und Hilfsskripte

Die Scripts sind keine Profiler an sich; sie sind Vorlagen, mit denen sich Untersuchungsergebnisse standardisiert festhalten lassen.

Eingebaute Skripte, die das performance-engineer Skill praktisch ergänzen

Zwei Hilfsskripte geben diesem performance-engineer guide echten Praxiswert:

• python scripts/profile.py erzeugt ein Profiling-Template mit Feldern für Umgebung, Workload und Hotspots.
• python scripts/perf_report.py erzeugt einen Markdown-Report für Zusammenfassung, Ownership, Baseline-Metriken, Ergebnisse, Empfehlungen und Validierung.

Beispiel:

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"

Das ist besonders nützlich, wenn du wiederholbare Untersuchungsnotizen statt einmaliger Chat-Antworten haben willst.

Wofür das performance-engineer Skill optimiert ist

Das Quellmaterial lenkt Nutzer auf typische Bottleneck-Stellen wie:

• Datenbankprobleme wie N+1-Queries, fehlende Indizes oder große Result Sets
• API-Over-Fetching oder ineffiziente Serialisierung
• Runtime-Hotspots, die in Profiler-Ausgaben sichtbar werden
• ineffiziente Payloads und Netzwerkpfade
• Caching-Lücken auf häufig genutzten Hot Paths

Damit ist das Skill am wertvollsten, wenn tatsächlich ein Engpass isoliert werden soll, und nicht nur der allgemeine Wunsch besteht, „alles schneller zu machen“.

Praktisches Prompt-Muster für bessere Ergebnisse mit performance-engineer

Nutze beim Aufruf von performance-engineer for Performance Optimization diese Struktur:

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

Mit diesem Prompt-Muster bekommst du in der Regel deutlich umsetzbarere Ergebnisse als mit einer bloßen Anfrage wie „why is this slow?“.

Typische Hürden bei der Einführung

Bevor du dich auf die performance-engineer install verlässt, solltest du die wichtigsten Einschränkungen kennen:

• es ersetzt keine echten Profiler oder APM-Tools
• es braucht messbare Symptome, um wirksam zu sein
• es hilft deutlich weniger, wenn sich der Workload nicht reproduzieren lässt
• es kann Verbesserungen nicht validieren, wenn kein Benchmark-Pfad vorhanden ist

Anders gesagt: Das Skill verbessert die Methode der Untersuchung, es erzeugt aber nicht von selbst belastbare Messwerte.

Wann normale Prompts ausreichen

Wenn du nur ein schnelles Code-Style-Cleanup, Mikro-Optimierungen in einem kleinen Skript oder sprachspezifische Tuning-Hinweise ohne Untersuchung brauchst, reicht oft ein Standard-Prompt. Nutze das performance-engineer skill, wenn mehr auf dem Spiel steht und du einen strukturierten Weg vom Symptom bis zum verifizierten Fix brauchst.

performance-engineer Skill FAQ

Ist performance-engineer gut für Einsteiger?

Ja, sofern Einsteiger bereits ein konkretes langsames Szenario haben. Das Skill gibt eine disziplinierte Reihenfolge vor — Baseline, Profiling, Bottleneck, Validierung — und hilft so, vorschnelle Optimierung zu vermeiden. Weniger einsteigerfreundlich ist es, wenn du erwartest, dass es Grundlagen zu Observability oder Benchmarking komplett von Grund auf vermittelt.

Was macht performance-engineer besser, als einfach eine AI nach Code-Optimierung zu fragen?

Der Hauptunterschied ist Prozesskontrolle. Ein normaler Prompt schlägt oft sofort Caching, Indizes, Async-Verarbeitung oder Refactorings vor. Das performance-engineer skill ist nützlicher, wenn du zuerst klären musst, ob das Problem in der Datenbank, der API-Schicht, im Speicherverhalten, in der Payload-Größe oder in einem Runtime-Hotspot liegt.

Enthält das Skill echte Tools?

Teilweise. Das Repository enthält Template-Generatoren in scripts/profile.py und scripts/perf_report.py sowie Referenzdokumente für Checklisten, Monitoring und Optimierungshebel. Eigene Runtime-Profiler, Logs, Benchmarks und umgebungsspezifische Kommandos brauchst du trotzdem.

Ist performance-engineer nur für Backend-Services gedacht?

Nein. Das README enthält Performance-Ziele, die sowohl APIs als auch page-load-artige Metriken abdecken, und in den Referenzen werden auch Payload- und Netzwerk-Effizienz angesprochen. Trotzdem sind die Beispiele stärker auf die Untersuchung von Anwendungen und Services ausgerichtet als auf tiefgehende Frontend-Rendering-Analysen.

Wann sollte ich performance-engineer nicht verwenden?

Lass es weg, wenn:

• es noch kein messbares Performance-Problem gibt
• du nur breit über Architektur brainstormen willst
• es primär um Reliability oder Korrektheit statt um Geschwindigkeit geht
• du den Workload nicht reproduzieren oder keinerlei Metriken erfassen kannst

In diesen Fällen bringt die Struktur des Skills deutlich weniger Mehrwert.

Kann performance-engineer beim Monitoring nach Fixes helfen?

Ja. references/monitoring.md fordert Nutzer dazu auf, Perzentile, Durchsatz, Fehlerraten und Alerts für Regressionen zu verfolgen. Das ist hilfreich, wenn das Skill nicht nur einmaliges Tuning unterstützen soll, sondern auch die Validierung beim Rollout.

So verbesserst du das performance-engineer Skill

Liefere bessere Baselines statt nur längerer Prompts

Der schnellste Weg, performance-engineer usage zu verbessern, ist die Angabe von:

• aktueller p50-, p95- oder p99-Latenz
• Durchsatz und Fehlerrate
• Speicher- oder CPU-Symptomen
• exaktem Benchmark- oder Request-Pfad
• einem Vorher-Nachher-Vergleichsplan

Das ist wertvoller, als einfach nur viel narrativen Kontext hinzuzufügen.

Gib Umgebung und Workload-Form mit an

Performance-Empfehlungen hängen stark vom Workload ab. Teile dem Skill mit:

• Request-Konkurrenz bzw. Parallelität
• Datensatzgröße
• warmer oder kalter Cache-Zustand
• CPU- und Speichergrenzen
• lokale, Staging- oder Produktionsumgebung

Das mitgelieferte scripts/profile.py-Template erinnert gut daran, was erfasst werden sollte: Umgebung, Workload, Kommando, Dauer und Hotspots.

Bitte um priorisierte Fixes mit Validierungsschritten

Ein starker Follow-up-Prompt ist:

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.

Das reduziert vage „probier einfach alles“-Ausgaben und macht Iterationen günstiger und zielgerichteter.

Vermeide typische Fehlermuster

Die häufigsten Gründe für schwache Ergebnisse mit performance-engineer sind:

• keine Baseline-Metriken
• kein reproduzierbarer Workload
• keine Profiler- oder Trace-Evidenz
• nach Fixes fragen, bevor das Bottleneck isoliert wurde
• mehrere Systeme in einer einzigen vagen Anfrage zusammenwerfen

Wenn das erste Ergebnis generisch wirkt, fehlt meistens genau einer dieser Punkte.

Nutze die Checkliste als Qualitätsgrenze

references/checklist.md ist kurz, aber wichtig. Behandle sie als Mindeststandard:

• Baseline-Metriken erfasst
• Bottlenecks identifiziert
• Fixes mit Benchmarks verifiziert
• Regressionstests ergänzt

An dieser Checkliste wird aus dem Skill ein operatives Werkzeug statt nur einer beratenden Hilfe.

Dokumentiere Ergebnisse, damit die nächste Iteration besser wird

Nach dem ersten Durchlauf solltest du mit scripts/perf_report.py einen Report erzeugen und ihn in den nächsten Run zurückspielen. So kann das performance-engineer skill Empfehlungen anhand echter Ergebnisse, Ownership und Validierungsnotizen verfeinern, statt jedes Mal wieder bei null zu starten.

Verbessere Prompts mit Evidenz-Snippets

Statt nur zu sagen „DB seems slow“, füge einen kompakten Evidenzblock ein, zum Beispiel:

• Query-Durationsbeispiel
• Top-Funktionen aus dem Profiler
• Trace-Span-Zusammenfassung
• Endpoint-Timings nach Perzentilen

Selbst partielle Evidenz verbessert die Ausgabequalität stark, weil das Skill Empfehlungen dann mit beobachteten Hotspots statt mit Standardannahmen verknüpfen kann.

Kenne die Grenze zwischen Diagnose und Umsetzung

Der Workflow performance-engineer for Performance Optimization ist besonders stark bei Diagnose, Priorisierung und Validierungsplanung. Noch wirksamer wird er in Kombination mit einem zweiten Durchlauf, der sich auf die Umsetzung des gewählten Fixes in deinem Stack konzentriert. Nutze ihn zuerst, um zu entscheiden, was wirklich relevant ist, und hole dir danach gezielte Coding-Hilfe, um die Änderung sicher umzusetzen.