Warum ich gws-slides-cli gebaut habe Link zu Überschrift

Ich wollte einen Workflow, mit dem ich Google Slides nicht nur manuell, sondern auch agentisch und reproduzierbar bearbeiten kann. Das Ziel war eine CLI, die direkt auf dem gws-Tool aufsetzt, aber für echte Produktionsarbeit in Decks robuster und ergonomischer ist.

Der Fokus war dabei klar:

  • wiederholbare Slides-Operationen statt einmaliger Snippets,
  • agentenfreundliche JSON-Ausgaben,
  • und ein sauberer Entwicklungsfluss mit uv, python3 und klaren Guardrails.

Was ich konkret entwickelt habe Link zu Überschrift

gws-slides-cli ist als einzelnes Python-Paket aufgebaut (src/gws_slides_cli/) und registriert die Commands zentral über Click.

Über die Zeit hat sich das Tool von einem Wrapper für Read/Write-Operationen zu einem vollständigen Deck-Workflow entwickelt:

  • Deck- und Slide-Grundlagen: get, slide-map, slide-summary, find-text, update, replace-text, delete-object, insert-image, slide-image
  • Analyse-Workflows: slide-brief, deck-brief, deck-refactor-plan, find-thin-slides, find-overloaded-slides, check-checklist
  • Style-Workflows: style init, style apply, style verify
  • Projektdefaults: project init/show/refresh-style/clear über .gws-slides/project.json
  • Asset-Pipeline: lokale Assets und Prompt-Historie unter .gws-slides/assets
  • Bild-Workflows: generate-image, edit-image, generate-icons, generate-variants, plus webbasierte Bildsuche via SerpApi

Kurz: Ich habe aus einzelnen API-Aufrufen einen konsistenten End-to-End-Workflow für Deck-Produktion gemacht.

Wie ich es entwickelt habe Link zu Überschrift

1) Solide CLI-Basis vor Feature-Tempo Link zu Überschrift

Ich habe früh die Struktur stabilisiert:

  • cli.py für Command-Registrierung,
  • runner.py als Kapselung für gws-Subprozesse,
  • project_config.py für robuste Konfigurationslogik,
  • Command-Module pro Domäne (commands/).

Dadurch konnte ich neue Funktionen ergänzen, ohne dass die CLI unübersichtlich wurde.

2) Native Commands statt ad-hoc Shell-Skripte Link zu Überschrift

Ein wichtiges Prinzip war: lieber einen klaren Command in der CLI als fragile Heredoc-Ketten. Das hat in der Praxis massiv geholfen, weil Workflows dadurch testbar und wiederverwendbar wurden.

Beispiel: statt mehrstufiger manueller Bildersetzung gibt es einen atomaren replace-image-Workflow.

3) Visuelle QA als fester Teil des Loops Link zu Überschrift

Nach Style- oder Layout-Änderungen habe ich konsequent Slides als PNG gerendert (slide-image) und visuell geprüft. Das war entscheidend, um echte Design-Probleme (Clipping, Gewichtung, Komposition) zuverlässig zu finden.

4) Guardrails aus echten Fehlern abgeleitet Link zu Überschrift

Ein zentraler Lernpunkt war ein klassischer Google-Slides-Fehler:

  • updateTextStyle darf nur an Shapes mit echtem Text gesendet werden.
  • Leere Boxen müssen ausschließlich per updateShapeProperties angepasst werden.

Aus genau solchen Fällen sind die Guardrails in style apply entstanden.

5) Projektkonfiguration für reproduzierbare Ergebnisse Link zu Überschrift

Mit .gws-slides/project.json habe ich den Projektkontext stabil gemacht:

  • Standard-Deck,
  • Modell-/Aspect-Ratio-/Image-Size-Defaults,
  • Style-Ableitung aus Referenzdecks,
  • Prompt- und Style-Präfixe.

Das reduziert Kontextverlust und macht Ergebnisse konsistenter, auch wenn mehrere Sessions oder Agents beteiligt sind.

Milestones aus der Entwicklung Link zu Überschrift

  • Aufbau einer 6-Slide-Präsentation komplett über den CLI-Workflow
  • Einführung robuster Style-Profile (style init/apply/verify)
  • Erweiterung um Analyse-Commands zur inhaltlichen Verdichtung von Decks
  • Ausbau der Asset- und Prompt-History für wiederverwendbare Bild-Workflows
  • Härtung der Konfiguration und Fehlerbehandlung (inkl. JSON-Parsing-Kantenfälle)

Visuelle Eindrücke aus dem Deck Link zu Überschrift

Zusätzlich zum Code-Teil sind visuelle Checks ein zentraler Teil meines Workflows. Die folgenden Beispiele stammen aus der Präsentation “agentic coding un:locked Neu” und zeigen den Stil, in dem ich Inhalte über gws-slides-cli iteriere und QA’e:

Workflow-Visualisierung (CLI-Loop) Link zu Überschrift

Workflow-Visualisierung fuer den gws-slides-cli Loop

Von Prompt bis Deck-Optimierung: der visuelle Workflow fuer wiederholbare Slides-Produktion.

Slide: Machine vs. Human Context

Visual: Machine vs. Human Context als Beispiel fuer agentenorientierte Dokumentationsstruktur.

Slide 8: Model-Auswahl

Slide 8: Vergleich und Einordnung von Modellklassen fuer unterschiedliche Tasks.

Slide 13: Guardrails

Slide 13: Fokus auf Guardrails und kontrollierte Agent-Autonomie.

Mein wichtigstes Fazit Link zu Überschrift

Die größte Verbesserung war nicht ein einzelnes Feature, sondern der Wechsel vom “Script, das irgendwie läuft” zu einer klaren Command-Surface mit Guardrails.

Genau dadurch wurde gws-slides-cli im Alltag schnell genug für spontane Iterationen und gleichzeitig stabil genug für wiederholbare Produktions-Workflows.

Links: