KI beschleunigt kreative Arbeit — aber nicht an der Stelle, an der die meisten es versuchen. Wer „gib mir zehn Ideen für X" tippt, bekommt zehn Ideen für X. In zwei Stunden fällt auf, dass X die falsche Frage war. Der Zeitgewinn war eine Illusion.

Die eigentliche Arbeit mit einem Sprachmodell passiert davor und danach: in der Frage, was überhaupt entschieden werden muss, und in der Frage, mit welchem Material das Modell arbeitet. Prompten ist das kürzeste Stück der Kette.

Wie das konkret aussieht, lässt sich an einem Gegenstand zeigen, der genau diese Kette abbildet: design-thinking-methods, ein Open-Source Agent Skill (github.com/kopfwelt/skills, MIT). Der Skill wählt für eine gegebene Situation die passende Design-Thinking-Methode, rendert sie als interaktives Workshop-Canvas und analysiert die eingetragenen Ergebnisse, um den nächsten Prozessschritt vorzuschlagen. Drei Phasen — und dieselben drei Bewegungen, die kreative Arbeit mit KI überhaupt trägt: Recherche, Daten-Sourcing, Skill.

Hinweis: Das Praxisbeispiel weiter unten ist illustrativ — Zahlen und Zitate sind konstruiert, um den Durchlauf konkret zu machen. Der beschriebene Skill, seine Methodendateien und der Export-Vertrag sind real und öffentlich einsehbar.

1. Recherche: Diagnose vor Methode

Kreative Arbeit scheitert selten an der Ideenfindung. Sie scheitert an der Rahmung. Wer das aus Workshops kennt, kennt es aus der Arbeit mit KI wieder — nur schneller und billiger, weil das Modell keine Rückfragen stellt, wenn man es nicht dazu auffordert.

Der Skill kodiert das als harte Vorbedingung: Keine Methodenwahl ohne Diagnose. Vier Dinge werden vorher geklärt, nicht mehr:

1. Wo stehst du? (Problem unklar / Lösungen fehlen / Entscheidung fällig / testen)
2. Wie viele Leute?
3. Wie viel Zeit?
4. Was existiert schon? (Interviews, Personas, Ideenliste, nichts)

Das eigentliche Recherche-Ergebnis steckt aber nicht in den Fragen, sondern in dem, was der Skill über die typische Fehldiagnose weiß. Im Klartext steht dort: Teams, die „wir kommen auf keine Ideen" sagen, haben häufig ein unklares Problem. Also nicht ideieren, sondern erst definieren. Diese Art von Wissen ist Moderationserfahrung in drei Sätzen — und sie ist mehr wert als eine längere Methodenliste.

Zwei Prinzipien fallen daraus für die Zusammenarbeit mit KI generell ab:

Frage und Empfehlung nicht in dieselbe Nachricht packen. Der Skill verlangt, nur das Fehlende zu erfragen — und dann auf die Antwort zu warten. Ein Modell, das gleichzeitig fragt und empfiehlt, fragt nicht wirklich; es hat sich schon entschieden und holt sich Applaus.

Annahmen benennen statt still raten. Was nicht gewusst, sondern angenommen wird („vermutlich noch keine Interviews"), wird als Annahme markiert. Nur so kannst du eine falsche Prämisse korrigieren, bevor sie sich in drei Folgeschritte fortschreibt. Genau das ist der Unterschied zwischen einem Sparringspartner und einem Ideenautomaten: Ein Sparringspartner legt seine Prämissen offen.

Verdichtet ist die Recherche in einer Entscheidungstabelle, nicht in einer Wissenssammlung: Situation → Phase, dann Phase × Randbedingungen → Methode, plus Tie-Breaker. Und die sind kompromisslos:

Vorhandener Input schlägt Wunschphase. Fehlt der nötige Input einer Methode, geht es eine Phase zurück.

Zeit ist hart. Passt die Methode nicht in die Zeitbox, wird sie nicht gekürzt — andere Methode oder ehrlich sagen.

Und da, wo noch nichts da ist — Prototyping- und Test-Methoden fehlen bislang — sagt der Skill das ausdrücklich, statt zu improvisieren. Eine Lücke, die benannt wird, ist brauchbar. Eine Lücke, die überspielt wird, ist Schaden.

Das Ergebnis der Diagnose ist übrigens eine Empfehlung mit einer Begründung und einer Alternative. Nicht drei gleichwertige Optionen. Auswählen ist die Arbeit, nicht das Aufzählen — wer sich drei Vorschläge liefern lässt, hat die Entscheidung nur umbenannt und an sich selbst zurückdelegiert.

2. Daten-Sourcing: Die KI kennt deine Nutzer*innen nicht

Hier liegt die eigentliche Grenze. Claude weiß viel über Design Thinking und nichts über die Menschen, für die du gestaltest. Kreative Arbeit mit einem Modell ist genau so gut wie das Material, das hineingeht — und wie der Rückkanal, auf dem Ergebnisse zurückkommen. Systematisch verstehen statt plausibel klingen: Das ist Discovery-Arbeit, und die kann kein Modell für dich erledigen.

Material zuerst, Interpretation danach. Die Empathy Map im Skill füllt bewusst in dieser Reihenfolge: Says und Does zuerst — beobachtbar —, dann Thinks und Feels — interpretiert. Einträge ohne Belegstelle in den Rohnotizen gehören nicht in Says, sondern als markierte Hypothese in Thinks. Der wertvollste Fund ist der Widerspruch zwischen Says und Does. Ein leeres Quadrant ist ein Befund (Datenlücke), kein Mangel — und wird nicht aufgefüllt.

Und wenn keine Daten da sind? Das ist der Regelfall, und die Proxy-Variante der Methode ist der interessanteste Teil. Keine Interviews? Dann funktioniert die Map trotzdem — sofern Ersatzquellen existieren: Support-Tickets, Vertriebsgespräche, Analytics-Auffälligkeiten, eigene Beobachtung. Zwei Regeln trennen Methode von Kaffeesatzleserei:

1. Quelle und Annahme strikt trennen. Einträge ohne Quelle sind Hypothesen und werden als solche markiert.
2. Der Output verschiebt sich. Der Wert liegt nicht in der Wahrheit der Einträge, sondern darin, sichtbar zu machen, wo Wissen endet und Hypothese beginnt. Die markierten Hypothesen sind deine Interviewliste.

Und wenn auch keine Ersatzquellen da sind, ist die Methode falsch — dann verweist der Skill auf Nutzerforschung, statt eine Map aus reinem Raten zu bauen. Genau diese Ehrlichkeit unterscheidet ein Werkzeug von einem Textgenerator.

Der Rückkanal ist ein Vertrag. Die Ergebnisse aus dem Workshop müssen zurück ins Gespräch, sonst bleibt das Canvas ein schönes Bild. Dafür hat jedes Canvas einen Export-Knopf, der ein festgeschriebenes JSON-Schema in die Zwischenablage legt: Session, Methode, Phase, Kontext, Einträge, Metadaten inklusive gemessener Dauer. Ein Dokument ist die Single Source of Truth, vorwärtskompatibel gebaut — unbekannte Felder werden ignoriert, nicht abgelehnt — und Änderungen sind ausdrücklich Breaking Changes mit Versionssprung.

Zwei Details daran sind über den Skill hinaus lehrreich. Erstens: Beim Parsen wird nicht geraten. Fehlt ein Pflichtfeld, wird genau benannt, was fehlt. Sind keine Einträge enthalten, wird nicht analysiert, sondern gefragt, ob zu früh exportiert wurde. Zweitens: Derselbe Vertrag ist bereits als Payload eines künftigen MCP-Tools entworfen. Der Wechsel von Copy-Paste zu einer echten Schnittstelle ist damit ein Adapter, kein Rewrite. Ein Datenformat festzulegen, bevor man die Transportschicht wählt, ist die billigste Architekturentscheidung, die man treffen kann.

Arbeitsteilung zwischen Skript und Modell. Ab etwa 20 Einträgen läuft ein kleines Python-Skript als Vorsortierung — Wortüberlappung, Clustering, Stoppwortlisten für Deutsch und Englisch. Das Skript ist absichtlich dumm: Es clustert vor, das Benennen und Bewerten bleibt beim Modell. Deterministisch, wo Determinismus hilft; Modell, wo Urteil gebraucht wird.

Über allem steht ein Satz aus der Analysephase, der die Haltung des ganzen Skills zusammenfasst:

Ist eine Ideensammlung inhaltlich dünn, sag das. Ein Skill, der zwölf mittelmäßige Klebezettel zu „starken Impulsen" umdeutet, ist wertlos.

Das ist der Punkt, an dem KI in Innovationsprozessen meistens kippt. Modelle sind darauf trainiert, hilfreich zu klingen. Ein Prozess, der Annahmen validieren soll, braucht das Gegenteil: eine Instanz, die dünne Ergebnisse dünn nennt.

3. Skill: Verankerung in Strukturen und Prozesse

Verankert in Strukturen und Prozesse lässt sich Innovation gezielt steuern — und genau das leistet ein Skill für die Arbeit mit KI. Ein Prompt ist einmalig, liegt in einem Chatverlauf und stirbt mit ihm. Ein Skill ist ein Ordner, den Claude bei Bedarf selbst lädt: eine Einstiegsdatei, eine Wissensbasis, ein Renderer, ein paar Skripte. Kein Server, kein Deployment — Markdown und ein paar Dateien. Versionierbar, review-fähig, teilbar.

Vier Entwurfsentscheidungen machen den Unterschied zwischen „Prompt in einer Datei" und einem Skill, der trägt:

Progressive Disclosure statt Monolith. Das Methodenwissen liegt in einzelnen Dateien, und Claude lädt nur die, die es gerade braucht — erst die Auswahlmatrix für die Diagnose, dann genau eine Methodendatei. Nicht fünf Methoden ins Kontextfenster, sondern die eine, die zur Situation passt.

Maschinenlesbare Metadaten pro Methode. Jede Methode trägt dasselbe Schema: Phase, Dauer, Gruppengröße, benötigter Input, erzeugter Output, good_for, bad_for, Canvas-Aufbau, Folgemethoden. Auswahl und Rendering konsumieren dieselben Felder. Die Entscheidungstabelle ist damit keine Doppelung, sondern eine Projektion.

Ein Renderer für alle Methoden. Das Canvas-Template bekommt nur einen Konfigurationsblock injiziert, sonst wird nichts angefasst. Die Regel dazu ist die produktivste Zeile im ganzen Repository: Wenn eine Methode sich ohne Eingriff in den Renderer nicht rendern lässt, ist das ein Schema-Problem — melden, nicht forken. So bleibt „Methode hinzufügen" eine Dreiviertelstunde-Aufgabe und wird nicht zum Refactoring.

Sprache als Vertragsfrage. Das Methodenwissen ist auf Englisch, alles Sichtbare entsteht in der Gesprächssprache — Antworten, Canvas-Titel, Schritte, Facilitation-Tipps, Buttons. Zone-IDs und Exportfelder bleiben englisch: Contract, nicht Copy. Wer diese Grenze nicht zieht, hat irgendwann ein Canvas, dessen Export sich nur auf Deutsch parsen lässt.

Dazu kommt eine Sache, die man leicht unterschätzt: Die Beschreibung ist die Schnittstelle. In den Metadaten stehen die Sätze, die Leute tatsächlich sagen — „wir kommen nicht weiter", „welche Methode passt", „wie strukturiere ich diesen Workshop" — zweisprachig, und ausdrücklich mit dem Zusatz: auch dann, wenn „Design Thinking" nie fällt. Ein Skill, der nicht auslöst, existiert nicht. Entsprechend steht „Trigger-Rate messen" als eigener Punkt auf der Roadmap, mit Testprompts mit und ohne Skill.

Und schließlich das, was aus einer Methodensammlung einen Prozess macht: Der Output einer Methode ist der Input der nächsten. Empathy Map → How Might We → Crazy 8s → Dot Voting oder Impact-Effort-Matrix. Beim Rendern der Folgemethode werden die Ergebnisse der vorherigen in den Kontext des Canvas getragen, damit sie im Artefakt sichtbar sind. Deshalb wird auch genau ein Canvas gerendert, niemals die Folgemethode im Voraus — mit der Begründung: Ein HMW-Canvas ohne Insights ist ein leeres Formular, kein Werkzeug.

Genau hier liegt der Unterschied zu „KI im Workshop einsetzen". Nicht ein Tool pro Phase, das man sich zusammensucht, sondern eine Kette, in der jeder Schritt weiß, was er braucht und was er liefert.

Die Claude-Integration: Artefakte und Screenshots

Der entscheidende Unterschied zu „KI-Tool neben dem Workshop-Tool" ist, dass das Canvas im Gespräch selbst läuft. Claude rendert es als Artefakt — kein Bild, kein PDF, sondern eine funktionierende Anwendung direkt neben dem Chat. Das klingt nach einem Detail und ist der Grund, warum der Prozess überhaupt zusammenhält.

Was das Canvas dadurch kann:

• Eingeben statt abtippen. Jede Zone hat ein Eingabefeld, Enter legt einen Eintrag an, Shift+Enter macht einen Zeilenumbruch, ein Klick löscht wieder. Klebezettel-Logik, nur ohne Klebezettel.
• Timer, der die Methode durchsetzt. Bei Crazy 8s läuft der Timer 8 × 60 Sekunden, hebt die aktive Zone hervor und schaltet weiter — auch wenn die Idee nicht fertig ist. Der Timer ist die Methode. Wo keine Zonenzeit gesetzt ist, läuft ab dem ersten Eintrag still die Gesamtdauer mit.
• Gemessene statt geschätzte Dauer. Die tatsächliche Dauer landet im Export. Nach drei Sessions weißt du, dass eure „30-Minuten-Methode" bei euch 47 Minuten braucht — eine Information, die keine Planung dir gibt.
• Zustand bleibt erhalten. Die Einträge werden fortlaufend gespeichert (window.storage auf claude.ai, localStorage als Fallback), unter einer Session-ID wie dt-2026-08-06-a1. Fenster zugeklappt, Canvas wieder geöffnet — alles noch da, inklusive Teilnehmerzahl und Zeitstand.
• Hell und dunkel. Das Canvas übernimmt das Theme der Betrachterin, statt auf einem geteilten Bildschirm zu blenden.
• Export mit Notausgang. Der Export-Knopf legt das Vertrags-JSON in die Zwischenablage und quittiert mit der Zahl der Einträge („✓ 23 — kopiert, jetzt in den Chat einfügen"). Und weil die Zwischenablage in einem gesandboxten iframe blockiert sein kann, gibt es dafür einen Fallback: Das JSON erscheint in einem vorselektierten Textfeld zum Kopieren. Kleine Sache, aber genau die Sorte Detail, die entscheidet, ob ein Workshop-Werkzeug im echten Meeting überlebt.

Damit ist der Kreis geschlossen: Chat → Artefakt → Chat. Die Diagnose passiert im Gespräch, die Arbeit im Canvas, die Analyse wieder im Gespräch — mit dem vollen Kontext der Diagnose. Wer stattdessen ein Whiteboard-Tool daneben betreibt, wechselt für jeden Schritt das Werkzeug und muss den Kontext jedes Mal neu erzählen.

Ehrliche Grenze: Das Artefakt ist einsitzig. Eine Person tippt und teilt den Bildschirm, oder alle rufen zu. Für paralleles Arbeiten mehrerer Leute bräuchte es geteilten State — und genau deshalb steht der MCP-Server auf der Roadmap und nicht im Repository. In Präsenz mit einer moderierenden Person funktioniert das Setup gut; für ein verteiltes Team, das gleichzeitig schreiben will, noch nicht.

Screenshots: der Eingangskanal

Der Export ist der Rückkanal. Der Gegenkanal ist die Kamera — und der ist in der Praxis fast wichtiger, weil Material selten digital vorliegt.

Claude liest Bilder. Das heißt konkret: Das abfotografierte Flipchart aus dem Vorgespräch, die Klebezettelwand vom letzten Workshop, der Screenshot eines Miro-Boards, der Ausschnitt aus dem Support-Dashboard — alles davon kannst du in den Chat ziehen, und Claude zieht daraus die Rohnotizen für die Empathy Map oder die Ideenliste fürs Dot Voting. Kein Abtippen. Der analoge Workshop hört damit nicht auf, analog zu sein; er bekommt nur einen Anschluss.

Zwei Regeln dazu, denn hier wird gerne geschludert:

1. Transkription ist eine Fehlerquelle. Handschrift auf einem abfotografierten Flipchart wird nicht immer korrekt gelesen. Lass die erkannten Einträge einmal auflisten und gegenlesen, bevor sie in eine Analyse gehen — besonders bei Zahlen und Eigennamen.
2. Ein Foto ersetzt den Export nicht. Das Bild liefert Text ohne Struktur. Der Export liefert Zonenzuordnung, gemessene Dauer, Teilnehmerzahl und Session-ID — also alles, was die Analyse und die Prozesskette brauchen. Screenshot rein, Export raus.

Nützlich sind Screenshots außerdem als Dokumentation: Ein Bild des gefüllten Canvas geht ins Protokoll, wenn niemand daran denkt, den Export-Knopf zu drücken. Als Rettung, nicht als Plan.

Ein Beispiel: 90 Minuten, fünf Leute, keine Interviews

Zur Veranschaulichung ein realistischer Durchlauf. Regionaler Energieversorger, Self-Service-Portal, wöchentlicher 90-Minuten-Slot. Das Team: zwei aus dem Produkt, eine aus dem Kundenservice, einer aus der IT, eine aus dem Marketing.

Der Einstieg ist der übliche: „Wir brauchen Ideen, wie wir das Onboarding im Kundenportal besser machen."

Phase 1 — Diagnose

Claude fragt nach — und empfiehlt nicht das, wonach gefragt wurde:

• Wo stehst du? — „Lösungen fehlen"
• Wie viele Leute? — 5
• Wie viel Zeit? — 90 Minuten, wöchentlich
• Was existiert schon? — 40 Support-Tickets, Notizen aus 3 Vertriebsgesprächen, ein abfotografiertes Flipchart — keine Interviews

Empfehlung: Empathy Map in der Proxy-Variante, 40 Minuten. Ideensammlung wäre der naheliegende Schritt, aber es gibt kein Problem-Statement — und ohne das produziert Crazy 8s acht Ideen für eine ungeklärte Frage. Alternative: direkt zu How Might We, falls die Insights aus den Tickets für euch schon klar sind.

Zur Zeit: Empathy Map (40) und HMW (25) füllen den Slot. Crazy 8s kommt in Session zwei — die Methode zu kürzen macht sie kaputt.

Das ist Tie-Breaker eins in Aktion: Vorhandener Input schlägt Wunschphase. Und Tie-Breaker zwei: Zeit ist hart.

Session 1 — Empathy Map

Das Flipchart-Foto und die Tickets gehen in den Chat, Claude zieht die Rohnotizen heraus. Dann rendert es das Canvas: vier Quadranten, Says und Does zuerst.

Weil keine echten Interviews vorliegen, greift die Proxy-Regel — alles ohne Quelle bekommt eine Hypothesen-Markierung. Nach 40 Minuten stehen 31 Einträge, davon 9 als Hypothese markiert. Export, einfügen, Analyse.

Der Fund liegt im Widerspruch:

Says: „Die Rechnung ist völlig unverständlich." (7 Tickets)

Does: Ruft den Service an, ohne die Rechnung im Portal geöffnet zu haben. (Analytics: 68 % der Anrufenden hatten keinen Rechnungs-Abruf)

Das Problem ist möglicherweise nicht die Rechnung, sondern die Benachrichtigung. Die 9 Hypothesen sind eure Interviewliste — drei davon hängen an dieser einen Frage.

Das hätte kein Brainstorming ergeben. Es steht in den Daten, die vorher niemand nebeneinandergelegt hat.

Session 1, zweiter Teil — How Might We

Die vier Insights wandern als Kontext ins nächste Canvas — sichtbar im Artefakt, nicht nur im Chatverlauf. 25 Minuten, 11 Fragen, zwei Favoriten. Einer fliegt raus, weil er eine verkleidete Lösung war („Wie können wir eine App bauen, die …"). Übrig bleibt:

„Wie können wir Kund*innen dabei helfen, ihre neue Rechnung überhaupt wahrzunehmen, damit der Anruf beim Service gar nicht nötig wird?"

Session 2 — Crazy 8s

Problem-Statement im Kontext, Timer an, 8 × 60 Sekunden. Fünf Leute, 40 Einträge. Der Export meldet eine tatsächliche Dauer von 14 Minuten und fünf Teilnehmende.

Über 20 Einträge heißt: Vorsortierung per Skript, dann Bewertung durch das Modell. Ergebnis: 6 Cluster und 2 Solitäre — die bleiben als eigene Kategorie stehen, statt ins nächstliegende Cluster gedrückt zu werden. Einer der beiden Solitäre ist der Vorschlag, die Benachrichtigung ganz abzuschaffen und auf Abholung umzustellen. Unbequem, aber der einzige Eintrag, der die Prämisse angreift.

Session 2, zweiter Teil — Dot Voting

8 Optionen ergeben nach der Regel Optionen ÷ 3 drei Stimmen pro Person. Still abstimmen, Reihenfolge vorher gemischt, die Person mit dem meisten Senioritätsgewicht stimmt zuletzt — Ankereffekte sind real.

Die Analyse verkauft das Ergebnis nicht schöner, als es ist:

Rang 1 (7 Stimmen) und Rang 2 (6) sind klar. Rang 3 (4) und Rang 4 (3) liegen eine Stimme auseinander — das ist kein Ergebnis, sondern ein Gleichstand mit Rundungsfehler. Vorschlag: die Top 4 durch die Impact-Effort-Matrix, weil bei zwei davon der Aufwand die eigentliche Frage ist. Die Cluster mit null Stimmen bleiben im Protokoll.

Zwei Sessions, 180 Minuten, und das Team hat: ein belegtes Problem-Statement, eine Interviewliste aus markierten Hypothesen, 40 Ideen in 6 Clustern, eine begründete Shortlist — und einen dokumentierten Grund, warum die naheliegende erste Frage die falsche war.

Der Punkt des Beispiels ist nicht die Geschwindigkeit. Das hätte eine gute Moderatorin ohne KI genauso hinbekommen. Der Punkt ist, dass die Methodentreue nicht an der Tagesform hängt: Der Timer schaltet weiter, die Hypothesen bleiben markiert, der knappe Vorsprung wird knapp genannt.

Was daran übertragbar ist

Der Skill ist das Beispiel, nicht das Argument. Das Argument sind die Muster — und die funktionieren in jedem Innovations- oder Produktprozess, in dem KI mitarbeitet:

• Diagnose vor Lösung. Vier Fragen kosten zwei Minuten und retten den Nachmittag. Die Kenntnis der typischen Fehldiagnose ist mehr wert als eine längere Methodenliste.
• Eine Empfehlung, nicht drei Optionen. Auswählen ist die Arbeit.
• Belegtes und Angenommenes markieren — auf beiden Seiten: bei den Daten und bei den eigenen Aussagen.
• Fehlende Daten als Befund behandeln, nicht als Lücke, die das Modell plausibel füllt. Die markierten Hypothesen sind die Interviewliste.
• Den Rückkanal zuerst festlegen. Ein versioniertes, vorwärtskompatibles Datenformat macht den späteren Wechsel der Transportschicht zum Adapter.
• Deterministisch, wo es hilft; Modell, wo Urteil gebraucht wird.
• Arbeiten, wo das Gespräch ist. Ein Artefakt im Chat hält Diagnose, Arbeit und Analyse im selben Kontext. Jeder Werkzeugwechsel kostet die Vorgeschichte.
• Die Kamera ist ein Eingabegerät. Flipchart, Klebezettelwand, Dashboard-Ausschnitt — Material muss nicht digital entstehen, um digital weiterverarbeitet zu werden. Aber gegenlesen.
• Lücken benennen. Kein Material für Prototyping? Sagen. Dünne Ideensammlung? Sagen. Knapper Vorsprung? Knapp nennen.
• Wissen aus dem Prompt in Dateien holen. Damit wird aus persönlicher Übung eine Struktur, die ein Team teilen kann.

Der letzte Punkt ist der eigentliche Hebel. Solange KI-Kompetenz in den Chatverläufen einzelner Personen steckt, bleibt sie an diese Personen gebunden. Ein Skill macht daraus etwas, das reviewt, verbessert und weitergegeben werden kann — Innovationsarchitektur im Kleinen.

Ausprobieren

Der Skill ist Open Source unter MIT-Lizenz. Für Claude Code:

claude plugins install kopfwelt-skills@kopfwelt/skills

Für Codex und andere Agenten:

npx skills@latest add kopfwelt/skills

Für claude.ai lässt sich der Skill einzeln als Zip paketieren und unter Einstellungen → Capabilities → Skills hochladen.

Code und Dokumentation: github.com/kopfwelt/skills · kopfwelt.com/skills

Auf der Roadmap stehen Methoden für Prototyping und Testing (Storyboard, Wizard-of-Oz), ein Eval-Loop für die Trigger-Rate und — erst wenn sitzungsübergreifender State oder Team-Sharing gebraucht wird — ein optionaler MCP-Server. In dieser Reihenfolge. Nicht vorher.