why

Überblick über den why skill

Der why skill ist ein fokussiertes Five-Whys-Analysewerkzeug, mit dem Sie ein Symptom in eine Root-Cause-Kette und daraus in eine umsetzbare Lösung überführen. Wenn Sie den why skill für ein UX Audit, ein Produktproblem, einen Bug oder eine Prozessstörung brauchen, hilft er dabei, sauber zwischen dem, was passiert ist, und dem, warum es passiert ist, zu unterscheiden.

Wofür why gedacht ist

Nutzen Sie why, wenn die erste Erklärung wahrscheinlich zu oberflächlich ist: „Nutzer sind abgesprungen“, „der Build ist fehlgeschlagen“ oder „das Team hat die Frist verpasst“. Der skill ist darauf ausgelegt, die Analyse so lange weiterzuführen, bis Sie bei einer systemischen Ursache landen und nicht nur bei einem sichtbaren Symptom.

Für wen es am besten passt

Dieser why-Guide eignet sich am besten für Operators, Analysten, Engineers und UX-Reviewer, die einen strukturierten Root-Cause-Pfad wollen, ohne selbst erst ein Framework zu bauen. Er passt zu Menschen, die bereits ein konkretes Problem formulieren können und dafür eine disziplinierte Methode zur Ursachenprüfung brauchen.

Warum das nützlich ist

Der Hauptnutzen liegt in Tempo und Fokus: Sie bekommen eine wiederverwendbare Prompt-Struktur, eine Standardtiefe und einen Validierungsschritt, damit Sie prüfen können, ob die Ursache das Symptom tatsächlich erklärt. Gerade dann lohnt sich die Installation von why, wenn generisches Brainstorming immer wieder bei derselben offensichtlichen Antwort hängen bleibt.

why skill verwenden

why installieren und auslösen

Installieren Sie den why skill in Ihrem Skills-Workflow und rufen Sie ihn dann mit einem konkreten Symptom auf, nicht mit einem vagen Thema. Ein guter Einstieg sieht so aus: /why checkout conversion fell 18% after the redesign oder /why CI failures spike on main branch.

Geben Sie eine Problemstellung, keine Theorie

Der skill funktioniert am besten, wenn Sie ein einzelnes beobachtbares Problem, den Kontext, in dem es auftritt, und bekannte Einschränkungen mitgeben. Starkes Beispiel: Mobile users abandon the signup form on step 2 after the new validation rules shipped; analyze root causes in the current UX flow. Schwaches Beispiel: Why is UX bad?

Lesen Sie zuerst die relevanten Quelldateien

Beginnen Sie mit SKILL.md, um den Analyseablauf zu verstehen, und prüfen Sie dann README.md, AGENTS.md, metadata.json sowie alle vorhandenen Ordner rules/, resources/, references/ oder scripts/ in Ihrer Umgebung. In diesem Repository ist SKILL.md die maßgebliche Quelle, daher ist der schnellste Weg, zuerst die Analyseschritte und Beispiele zu lesen und sie dann anzupassen.

Führen Sie die Analyse als Arbeitssitzung durch

Nutzen Sie why als geführte Kette: Beschreiben Sie das Symptom, beantworten Sie jedes „why“ mit Belegen und stoppen Sie erst, wenn die Ursache grundlegend und überprüfbar ist. Wenn mehrere Ursachen sichtbar werden, verzweigen Sie die Analyse, statt eine einzige Linie zu erzwingen, und enden Sie mit Änderungen, die die Root Cause beseitigen, statt nur das Symptom zu überdecken.

FAQ zum why skill

Ist why nur für technisches Debugging gedacht?

Nein. Der why skill funktioniert für UX Audit, Operations, Produkt, Support und Teamprozesse, solange Sie ein echtes Symptom beschreiben können. Entscheidend ist ein Problem, das sich als Ursache-Wirkungs-Kette nachvollziehen lässt.

Muss es immer genau fünf Iterationen geben?

Nicht zwingend. Fünf ist die Standardtiefe, aber die bessere Regel lautet: „Stoppen, wenn die Erklärung handlungsfähig und stabil ist.“ Wenn die Kette bereits nach drei Schritten bei einer echten Root Cause angekommen ist, bringen zwei weitere Schritte meist nur Rauschen.

Worin unterscheidet sich why von einem normalen Prompt?

Ein normaler Prompt fragt oft nach Ideen; why fragt nach disziplinierter Kausalität. Es ist die bessere Wahl, wenn Sie eine Root-Cause-Analyse, eine Korrekturmaßnahme oder eine Prüfung wollen, die sich rückwärts von der Ursache zum Symptom validieren lässt.

Wann sollte ich why nicht verwenden?

Verwenden Sie es nicht für offene Ideensammlungen, breite Strategiefragen oder Probleme ohne beobachtbares Symptom. Wenn Sie das Problem nicht klar genug definieren können, um eine Ursache-Kette zu testen, liefert der why skill nur oberflächliche Vermutungen.

Den why skill verbessern

Beginnen Sie mit einem schärferen Symptom

Die Qualität der why-Ausgabe hängt vom ersten Satz ab. Nennen Sie, was kaputtging, wer es gespürt hat, wann sich etwas geändert hat und in welcher Umgebung: After the new onboarding copy, first-time activation dropped on iOS only. Das ist deutlich besser als activation is down.

Ergänzen Sie Belege, nicht Schlussfolgerungen

Geben Sie Logs, Nutzerzitate, Funnel-Schritte, Screenshots, Zeitstempel oder Release-Marker mit, wenn Sie sie haben. Belege helfen why, Korrelation von Ursache zu trennen, und verhindern, dass die Analyse bei der ersten plausiblen Erklärung stehen bleibt.

Prüfen Sie die Kette rückwärts

Ein gutes why-Ergebnis sollte das Symptom von der Root Cause aus nach oben erklären. Wenn die letzte Ursache die vorherigen Schritte nicht klar hervorbringt, verfeinern Sie die Kette oder teilen Sie sie in Verzweigungen auf, bevor Sie handeln.

Machen Sie aus den Erkenntnissen eine konkret umsetzbare Maßnahme

Die besten why-Ergebnisse enden mit einer Änderung, die Sie ausrollen, dokumentieren oder messen können. Konzentrieren Sie die nächste Runde auf die Ursache, die Sie tatsächlich beeinflussen können, und führen Sie den skill nach dem Fix erneut aus, um zu bestätigen, dass sich das Symptom in die erwartete Richtung bewegt.