Technical Impact Presentation Builder

Technical Impact Presentation (TIP) Builder

Erstellt eine kundenorientierte, gebrandete Technical Impact Presentation, die die Erfolgskriterien eines Kunden mit den von Dynatrace gelieferten Ergebnissen verknüpft – untermauert durch Live-Tenant-Zahlen und Deep-Links zu den exakten Ansichten für Screenshots. Die Markenregeln werden aus dem dynatrace-pptx-skill übernommen – lies zuerst dort nach, um Farben und Schriftarten zu verstehen.

Goldene Regel: Erfinde niemals Metriken. Jede Zahl auf einer Folie muss aus einer dtctl-Abfrage stammen, die in dieser Sitzung ausgeführt wurde. Wenn ein Kriterium „In Bearbeitung“ ist, sag das – Ehrlichkeit ist besser als Perfektion.

Benötigte Eingaben vom Benutzer

Eingabe	Erforderlich	Hinweise
DT PowerPoint-Vorlage (.pptx)	ja	Das Basis-Deck; dessen Layouts/Theme werden übernommen.
Beispiel-Deck (.pptx)	optional	Spiegelung des Folienablaufs (z. B. ein früheres POV eines anderen Kunden).
Erfolgskriterien (Bild/Tabelle/Text)	ja	Der Inhaltsrahmen – Anwendungsfall · Ziel · aktueller Stand · Status.
Tenant / dtctl-Kontext	ja	z. B. <tenant-id> → dtctl --context <ctx>.
Präsentationsname / Datum	optional	Standardmäßig der authentifizierte Benutzer + aktueller Monat.

Pipeline (in Reihenfolge ausführen)

1 – PREFLIGHT-VALIDIERUNG (zwingend, nicht überspringen)

Beide Prüfungen müssen bestehen, bevor mit dem Bau begonnen wird. Führe zuerst die dtctl-Prüfung, dann die MCP-Prüfung durch.

1a. dtctl-Validierung – führe scripts/preflight.sh <Kontext> aus:

bash scripts/preflight.sh <dtctl-Kontext>

Er prüft: aktuellen Kontext, auth whoami (Token nicht abgelaufen), Lesezugriff (eine triviale DQL), Schreibzugriff (erforderlich, wenn Dashboards hochgeladen werden) und listet die installierten App-IDs auf (für Deep-Links benötigt). Wenn das Token abgelaufen ist, gibt er den Befehl zur erneuten Authentifizierung aus – teile dem Benutzer mit, dass er !dtctl auth login --context <ctx> in der Sitzung ausführen soll (OAuth ist interaktiv; du kannst es nicht selbst tun).

1b. Dynatrace MCP-Validierung – du (der Agent) musst bestätigen, dass der Dynatrace MCP-Server erreichbar ist, da Skripte MCP nicht aufrufen können. Rufe ein leichtgewichtiges MCP-Lese-Tool auf, z. B. get_dql_knowledgebase oder list_strato_components (die Namen sehen aus wie mcp__<server>__<tool>).

• Erfolg → notiere „MCP: verbunden“ und verwende es zur Validierung/Autorisierung von DQL und Dashboards.
• Fehlschlag/nicht vorhanden → notiere „MCP: nicht verfügbar – fahre nur mit dtctl fort“ und mache weiter (MCP ist empfohlen, aber nicht erforderlich). Gehe nicht stillschweigend davon aus, dass es funktioniert.

Notiere beide Ergebnisse in einer kurzen Preflight-Zeile vor dem Fortfahren, z. B. Preflight ✓ dtctl(Lesen+Schreiben, 47 Apps) · MCP(verbunden).

2 – LIVE-TENANT-DATEN SAMMELN

Führe scripts/gather_tenant_data.sh <Kontext> aus, um die wichtigsten Statistiken abzurufen (Hosts, Services, Prozessgruppen/-instanzen, K8s-Cluster/Namespaces/Workloads, Spans/2h, Logs/2h, eindeutige Probleme/7d), die installierten App-IDs (für Deep-Links) und mögliche Entitäts-IDs (Top-Services, Host-Gruppen, DB-Systeme) für Premium-Links. Erfasse die Ausgabe; du wirst diese Zahlen später in die Konfiguration einfügen. Füge bei Bedarf kriterienspezifische Abfragen hinzu (z. B. db.system, Oracle/MSSQL-Services, Azure-Regionen, gen_ai-Spans).

3 – KONFIGURATION ERSTELLEN

Kopiere references/example_config.json und bearbeite es für diesen Kunden: Deckblatt, Executive Overview, Kunden-POV (4 Karten), Zeitleiste, die Erfolgskriterien-Zeilen, einen Feature-Eintrag pro Kriterium (+ Zusatznutzen), Wertzusammenfassung, Abschluss. Jeder Feature-Eintrag = {title, done, status, bullets[], url, capture}. url = ein echter App-Deep-Link (<base>/<appId> aus Schritt 1/2); capture = eine Zeile, die dem Benutzer genau sagt, was er screenshoten soll.

Deep-Link-Basis = https://<tenant>.apps.dynatrace.com/ui/apps/. Häufige App-IDs (pro Tenant über Schritt 1 bestätigen): dynatrace.infraops, dynatrace.discovery.coverage, dynatrace.classic.smartscape, dynatrace.services, dynatrace.distributedtracing, dynatrace.database.overview, dynatrace.clouds, dynatrace.automations (Workflows/ServiceNow), dynatrace.davis.problems (Probleme), dynatrace.logs, dynatrace.kubernetes, dynatrace.devobs.debugger (Live Debugger), dynatrace.dashboards, dynatrace.security.vulnerabilities.

4 – DECK GENERIEREN

python3 scripts/build_tip.py config.json

build_tip.py lädt die Vorlage, löscht die Skelettfolien ordnungsgemäß (entfernt Beziehungen, sodass es keine doppelten Teile oder Beschädigungen gibt), baut das Deck aus den Vorlagenlayouts neu auf und erkennt automatisch pro Layout, ob der Hintergrund dunkel oder hell ist – es wählt automatisch weißen Text auf dunklen Deckblatt-/Abschnittsfolien und marineblauen Text auf hellen Inhaltsfolien. Benutzerdefinierte Karten, Zeitleistenknoten, Link-Boxen und Tabellen werden immer dunkel gefüllt mit hellem Text, damit sie auf jeder Folie lesbar sind.

5 – QA (zwingend)

python3 scripts/qa_tip.py "<Ausgabe>.pptx"

Meldet laut Fehler bei: weiß-auf-hell (unsichtbarem) Text, defekten/leeren Hyperlinks, übrig gebliebenem Skeletttext („Anwendungsfall 1“, „Kundenname“, „Lorem“), leeren Tabellen. Korrigiere und führe erneut aus, bis alles sauber ist. Falls LibreOffice/soffice verfügbar ist, exportiere auch ein PDF und überprüfe es visuell; falls nicht, sage dem Benutzer, er solle die Datei öffnen und die Textpassung auf dichten Folien bestätigen.

6 – AUSLIEFERN

Gib den absoluten Pfad + file://-Link an. Biete an, die Datei mit open zu öffnen. Fasse die Folienübersicht, die verwendeten Metriken und die Screenshot-Links pro Folie zusammen.

Deck-Blaupause (Standardablauf)

Deckblatt → Agenda → Executive Overview → Kunden-POV (4 Karten) → POV-Zeitleiste → Erfolgskriterien-Tabelle → Abschnittstrenner → eine Feature-Folie pro Erfolgskriterium → Zusatznutzen-Folien (Probleme/RCA, Logs, Kubernetes, Live Debugger, Dashboards, Sicherheit) → Abschnittstrenner → Ergebnis-Scorecard → Gelieferter Wert & Nächste Schritte → Danke.

Jede Feature-Folie: Titel + Status-Badge (✅ Abgeschlossen / 🔄 In Bearbeitung) + 3–4 Nutzen-Aufzählungspunkte + eine türkisfarbene „SCREENSHOT-PLATZHALTER“-Box auf der rechten Seite mit der Screenshot-Anweisung und dem klickbaren Deep-Link.

Hart erarbeitete Lektionen, die in den Skripten eingebaut sind (nicht zurückentwickeln)

1. Helle vs. dunkle Layouts. DT-„Technical Impact“-Vorlagen enthalten helle (weiße) Inhaltslayouts und dunkle Deckblatt-/Abschnittslayouts (randloses Bild). Weißer Text auf einer hellen Folie ist unsichtbar. build_tip.py erkennt dies automatisch (ein randloses Bild oder eine dunkle Vollflächenfüllung ⇒ dunkel) und färbt den Text entsprechend. Hartkodiere niemals weißen Text auf Inhaltslayouts.
2. Folien richtig löschen. Das Entfernen von sldId-Einträgen allein hinterlässt verwaiste Folienteile und führt zu Zip-Beschädigungen durch doppelte Namen. Entferne immer prs.part.drop_rel(rId) und die sldId.
3. Markenbegriffsersetzungen sind case-sensitiv. Ersetze z. B. sichtbares Davis → Dynatrace Intelligence, lasse aber kleingeschriebenes davis in App-ID-URLs (dynatrace.davis.problems) unverändert, sonst brechen die Links. qa_tip.py markiert keine URLs.
4. Nur echte App-IDs. Hole sie von dtctl get apps (Schritt 1) – rate nicht. dynatrace.database.overview (nicht dynatrace.databases), dynatrace.davis.problems usw.
5. Ehrlicher Status. Behalte die vom Kunden gesetzten Flags „Abgeschlossen“/„In Bearbeitung“ bei; färbe „In Bearbeitung“ bernsteinfarben.

Dieses Skill teilen

Es ist in diesem Verzeichnis in sich geschlossen. Zum Teilen: Kopiere ~/.claude/skills/technical-impact-presentation/ in das ~/.claude/skills/ (oder ~/.agents/skills/) eines Teamkollegen oder übertrage es in ein gemeinsames Skills-Repository. Es gibt keine externen Abhängigkeiten außer python-pptx (pip3 install python-pptx) und dtctl.