Imported from Felix-Hempel/claude-team-skills (plugins/claromind/skills/ideation/SKILL.md). Install upstream with npx skills add Felix-Hempel/claude-team-skills --skill ideation. Copyright stays with the author.

Ideation: $ARGUMENTS

ÜBER DIESEN SKILL

Dieser Skill führt einen vollständigen, strukturierten Ideation-Prozess durch — von einem vagen Problem oder einer Ausgangsidee bis hin zu 2-3 ausgearbeiteten, testbaren Concept Briefs mit Validierungsplan. Er basiert auf bewährten Methoden aus Design Thinking (Stanford d.school, IDEO), dem Google Ventures Design Sprint (Crazy 8s, How Might We) und dem Jobs-to-be-Done-Framework.

Was ist Ideation und warum brauche ich das? Ideation ist die divergente Phase des Produktentwicklungsprozesses: Du erzeugst zunächst möglichst viele, möglichst unterschiedliche Ideen, bevor du anfängst zu filtern, zu bewerten oder zu bauen. Der häufigste Fehler in der Praxis ist, zu früh zu konvergieren — die erste "gute Idee" wird direkt umgesetzt, ohne den Möglichkeitsraum überhaupt erkundet zu haben. Strukturierte Ideation verhindert das, indem sie Divergenz erzwingt (Quantität vor Qualität) und Bewertung explizit von Generierung trennt.

Was passiert in diesem Skill? Der Prozess läuft in fünf Phasen ab. In Phase 1 wird das Problem präzise gerahmt — nicht als "Wir brauchen Feature X", sondern als "How Might We"-Frage (HMW), die den Lösungsraum öffnet statt verengt. In Phase 2 werden schnell viele Ideen generiert: textbasierte Crazy 8s (8 Ideen in Folge, ohne innere Zensur), JTBD-Mapping (welche "Jobs" will der Nutzer erledigt haben?), und eine Wildcard-Runde, die bewusst unwahrscheinliche Ansätze provoziert. In Phase 3 werden die Ideen nach Themen geclustert, die interessantesten 5-8 durch strukturiertes Dot-Voting priorisiert. In Phase 4 werden die Top 2-3 Ideen zu vollständigen Concept Briefs ausgearbeitet — wer, welches Problem, welche Lösung, worin liegt die Differenzierung. In Phase 5 entsteht ein konkreter Validierungsplan: Wie kann man die Kern-Annahme hinter jedem Konzept testen, bevor etwas gebaut wird?

Was ist der Output? Ein digitaler Idea Backlog (alle generierten Ideen, nicht nur die besten), 2-3 ausformulierte Concept Briefs und ein Validierungsplan. Die Concept Briefs sind der direkte Input für /vision — dort wird aus dem besten Konzept eine formale Produktvision gebaut.

Was kommt zuerst — Idee oder Vision? Immer zuerst die Idee, dann die Vision. Ideation ist divergent und explorativ: Du erkundet den Möglichkeitsraum, ohne vorab festzulegen wo du ankommst. Vision ist konvergent und committet: Du entscheidest dich für eine Richtung und formulierst sie als belastbaren Nordstern. Wer die Vision schreibt, bevor er ideiert hat, schreibt oft die erste Idee auf, die ihm eingefallen ist — nicht notwendigerweise die beste. Die Reihenfolge ist also: /ideation → /vision → /sprint-plan → /spec.

Argumente parsen

Letztes Argument = Thema, Problem oder Produktbereich (Freitext, kein Alias nötig). Wenn kein Argument: Frage nach dem Ausgangs-Problem oder der Ausgangsidee.

Variable setzen:

• {THEMA} = Thema oder Problem-Statement

Kontext laden

Lies falls vorhanden:

ls ~/scripts/*/CLAUDE.md 2>/dev/null | head -5
ls ~/scripts/docs/specs/ 2>/dev/null

Falls ein konkretes Projekt erwähnt wurde: dessen CLAUDE.md und README lesen, um bestehende Constraints und Technik-Stack zu verstehen. Das verhindert, dass Ideen generiert werden, die dem Kontext grundsätzlich widersprechen.

Phase 1: Problem Framing

1a: Problemkontext verstehen

Stelle dem User eine Frage und warte auf die Antwort:

Beschreib das Problem oder den Kontext in 2-3 Saetzen. Was weisst du ueber den Nutzer der das Problem hat? Was habt ihr bisher schon versucht oder ausgeschlossen?

Fasse die Antwort in einem praezisen Problem-Statement zusammen:

Problem-Statement: {Wer} hat das Problem, dass {was passiert}, was dazu fuehrt, dass {welche Konsequenz}. Bisher wird das geloest durch {bestehender Ansatz}, was nicht funktioniert weil {Luecke}.

Frage ob das stimmt. Korrigiere bis der User bestaetigt.

1b: How Might We generieren

Generiere 5 "How Might We"-Fragen (HMW) basierend auf dem Problem-Statement. HMW-Fragen sind bewusst offen formuliert — sie sollen den Loesungsraum aufmachen, nicht verengen.

Regel fuer gute HMW-Fragen:

• Nicht zu eng ("HMW ein Dashboard bauen" → zu spezifisch)
• Nicht zu weit ("HMW die Welt verbessern" → zu vage)
• Optimum: Offen genug fuer 10+ verschiedene Antworten, eng genug um relevant zu bleiben

Beispielformat:

1. How Might We {Nutzer} helfen, {Ziel} zu erreichen ohne {unerwuenschter Aufwand}?
2. How Might We {Problem} so loesen, dass {positiver Nebeneffekt}?
3. How Might We {bestehende Loesung} so verbessern, dass {neue Nutzergruppe} profitiert?
4. How Might We {scheinbares Hindernis} in einen Vorteil verwandeln?
5. How Might We {radikal anderer Ansatz}, wenn wir {Constraint X} ignorieren?

Praesentiere die 5 HMW-Fragen und frage:

Welche 1-2 HMW-Fragen findest du am interessantesten? Oder soll ich andere Winkel probieren?

Merke dir die ausgewaehlten HMW-Fragen als Leitfaden fuer Phase 2.

Phase 2: Divergente Ideation

WICHTIG: In dieser Phase gilt absolutes Bewertungsverbot. Keine Idee ist zu abwegig, zu teuer oder zu komplex. Quantitaet vor Qualitaet. Alle Ideen werden gesammelt — gefiltert wird erst in Phase 3.

2a: Crazy 8s (textbasiert)

Generiere 8 Ideen in schneller Folge zur ausgewaehlten HMW-Frage. Jede Idee in 1-3 Saetzen, ohne lange zu erklaeren. Forciere Unterschiedlichkeit — jede Idee soll einen anderen Ansatz vertreten.

Format:

Idee 1: {Kurzbeschreibung — wer, was, wie} Idee 2: {Anderer Ansatz} ... Idee 8: {Noch ein anderer Ansatz}

Tipp fuer Diversitaet: Denke in verschiedenen Vektoren — digitales Tool, physisches Produkt, Service, Plattform, Automatisierung, Community, Regulierung, Pricing-Modell, Radikale Vereinfachung, Radikale Erweiterung.

2b: JTBD-Mapping

Identifiziere die Jobs-to-be-Done des Nutzers. Ein "Job" ist das, was der Nutzer eigentlich erreichen will — unabhaengig vom Produkt.

Strukturiere es so:

Funktionaler Job: Was will der Nutzer konkret erledigen? (z.B. "Ich will wissen, wann mein Team woran arbeitet")

Emotionaler Job: Wie will er sich dabei fuehlen? (z.B. "Ich will das Gefuehl haben, die Kontrolle zu haben ohne Mikromanagement zu betreiben")

Sozialer Job: Wie will er vor anderen wirken? (z.B. "Ich will als strukturierter Teamleiter wahrgenommen werden")

Generiere 2-3 weitere Ideen die direkt aus den JTBD-Insights entstehen — Ideen die nicht "ein Tool" verkaufen, sondern den Job erledigen.

2c: Wildcard-Runde

Generiere 2-3 bewusst unkonventionelle Ideen durch folgende Provokationen:

• Umkehrung: Was wenn wir das Problem genau andersrum angehen? ("Nicht wir loesen es — der Nutzer loest es fuer andere")
• Skalierung: Was wenn es 100x mehr Nutzer geben wuerde — was waere dann die Loesung?
• Analogie: Wie loest eine komplett andere Branche ein aehnliches Problem? (z.B. "Wie wuerde Airbnb dieses Problem loesen?")

Diese Ideen sind oft nicht direkt umsetzbar — aber sie bringen haeufig kreative Elemente, die in verfeinerten Ideen wiederauftauchen.

Zwischenstand praesentieren:

Liste alle generierten Ideen auf (8 Crazy 8s + 2-3 JTBD + 2-3 Wildcards = ca. 13-14 Ideen). Frage:

Das sind alle Ideen aus der Ideation-Runde. Siehst du etwas, das fehlt oder einen Winkel den wir noch nicht hatten? Oder sollen wir mit Clustering weitermachen?

Phase 3: Synthesis & Clustering

3a: Clustering

Gruppiere alle Ideen nach thematischer Aehnlichkeit. Gib jedem Cluster einen praegnanten Namen.

Format:

Cluster A: {Name}

• Idee 1, Idee 5, Idee 11

Cluster B: {Name}

• Idee 3, Idee 7

3b: Dot Voting (simuliert)

Bewerte jeden Cluster und jede Einzelidee nach drei Kriterien (1-3 Punkte je Kriterium):

Nutzerwert: Loest das wirklich den Kern-Job des Nutzers? Machbarkeit: Ist das mit realistischen Ressourcen umsetzbar? Differenzierung: Warum wuerde jemand das statt einer bestehenden Alternative nutzen?

Praesentiere die Rangliste und frage:

Das sind die Top-Ideen nach Scoring. Stimmt dein Bauchgefuehl damit ueberein? Oder gibt es eine Idee die das Scoring nicht erfasst, dir aber wichtig erscheint?

Einige auf 5-8 Top-Konzepte und dann weiter auf die 2-3 Finalisten die als Concept Briefs ausgearbeitet werden.

Phase 4: Concept Briefs

Schreibe fuer jeden Finalisten einen vollstaendigen Concept Brief nach folgendem Template:

Concept Brief: {Konzept-Name}

Kern-Idee {1 Satz: Wer bekommt was wodurch? Kein Jargon.}

Problem das geloest wird {2-3 Saetze: Welches konkrete Problem loest dieses Konzept? Fuer wen genau?}

Wie es funktioniert {3-5 Saetze oder ASCII-Sketch des Kernflusses: Was macht der Nutzer? Was passiert dahinter?}

Kern-Job-to-be-Done {Der funktionale + emotionale Job den dieses Konzept erledigt.}

Warum jemand das statt X nutzen wuerde {Abgrenzung zu naechstliegender Alternative — konkret, kein Marketing.}

Kern-Annahme die validiert werden muss {Die eine Annahme, die wenn sie falsch ist, das gesamte Konzept kippt. Z.B. "Nutzer sind bereit, ihre Arbeitszeiten offen zu teilen."}

Offene Fragen {Was wissen wir noch nicht?}

Wiederhole fuer alle 2-3 Finalisten.

Phase 5: Validierungsplan

Fuer jedes Konzept einen konkreten Validierungsplan erstellen. Ziel: Die Kern-Annahme testen, bevor etwas gebaut wird.

Validierungsmethode waehlen (je nach Annahme-Typ):

Fuer jeden Finalisten:

Validierungsplan: {Konzept-Name}

Kern-Annahme: {Die Annahme aus dem Concept Brief}

Methode: {Welche Methode — Interview, Survey, Smoke Test, PoC?}

Konkrete naechste Schritte:

1. {Schritt 1 — z.B. "5 Nutzer aus Zielgruppe X interviewen"}
2. {Schritt 2}
3. {Schritt 3}

Go-Kriterium: {Was muss passieren, damit das Konzept weiterverfolgt wird? Z.B. "3 von 5 Interviewten bestaetigen das Problem spontan ohne Nachfragen."}

No-Go-Kriterium: {Was wuerde das Konzept kippen?}

Zeitaufwand: {Realistisch in Stunden/Tagen}

Ablage

Speichere alle Outputs in einem Ordner:

mkdir -p ~/scripts/docs/specs/ideation-{slug}-{datum}

Dateien:

• idea-backlog.md — Alle generierten Ideen (auch verworfene)
• concept-brief-{n}.md — Ein File pro Finalist
• validation-plan.md — Validierungsplaene fuer alle Finalisten
• README.md — Kurz-Zusammenfassung der Session (5-10 Zeilen)

Zusammenfassung ausgeben

## Ideation: {THEMA} — {Datum}

### Ausgangsproblem
{Problem-Statement in 1-2 Saetzen}

### HMW-Fokus
{Ausgewaehlte HMW-Frage(n)}

### Generierte Ideen
{Anzahl} Ideen in {Anzahl} Clustern

### Finalisten
1. {Konzept-Name 1} — {1 Satz}
2. {Konzept-Name 2} — {1 Satz}
3. {Konzept-Name 3} — {1 Satz}

### Naechster Schritt
Validierungsplan ausfuehren → dann /vision mit dem staerksten Konzept starten.
Oder direkt /vision wenn das Konzept bereits klar validiert ist.

### Output
~/scripts/docs/specs/ideation-{slug}-{datum}/

QUALITAETS-REGELN (STRENG einhalten)

1. Divergenz vor Konvergenz — Niemals in Phase 2 bewerten. Alle Ideen werden gesammelt, keine wird waehrend der Generierung kommentiert oder abgelehnt.
2. HMW-Fragen sind Pflicht — Ohne Problem Reframing landet man in Loesungs-Tunnelblick. HMW erzwingt Offenheit.
3. Minimum 10 Ideen — Crazy 8s allein sind zu wenig. JTBD + Wildcards bringen die Ideen die hinter der ersten "offensichtlichen" Idee liegen.
4. Scoring ist strukturiert, nicht subjektiv — Nutzerwert, Machbarkeit, Differenzierung. Nicht "mir gefaellt Idee 3 am besten".
5. Concept Briefs muessen testbar sein — Ein Concept Brief ohne Kern-Annahme ist kein Concept Brief — es ist ein Wunsch.
6. Validierungsplan vor Vision — Ideation produziert Hypothesen. Vision baut auf dem besten validierten Konzept. /vision ohne vorherige Validierung ist Raten.
7. Idea Backlog ist permanent — Verworfene Ideen werden nicht geloescht — sie sind zukuenftige Optionen und Team-Wissen.
8. Kein HIPPO-Effekt — Scoring und Clustering sind anonym und strukturiert, damit die lauteste Stimme im Raum nicht automatisch gewinnt.
9. JTBD-Lens ist Pflicht — Feature-Ideen ohne Job-Verstaendnis loesen oft das falsche Problem praezise.
10. Output wird sofort digitalisiert — Kein "wir klären das spaeter" — alle Ideen landen in der Ablage noch in der Session.