think

Überblick über den think skill

Was der think skill macht

think ist ein Decision-Support-Skill, der aus einer groben Idee einen klaren, freigegebenen Plan macht, bevor jemand Code schreibt. Er eignet sich besonders für Feature-Design, Architekturentscheidungen, Trade-off-Analysen und „Sollen wir das überhaupt machen?“-Fragen, bei denen Urteilskraft wichtiger ist als Umsetzung.

Wer den think skill installieren sollte

Installiere den think skill, wenn du in einem repo-first Workflow häufig Unterstützung bei Produktentscheidungen, technischer Ausrichtung oder eingegrenzter Planung brauchst. Er ist vor allem dann hilfreich, wenn eine Anfrage mit „plan this“, „what’s the best approach“, „should we keep this“ oder ähnlichen Wertungsfragen beginnt.

Was ihn unterscheidet

Der Skill ist meinungsstark: Er drängt auf eine konkrete Empfehlung, macht deutlich, welche Evidenz die Empfehlung ändern würde, und vermeidet vorschnellen Code. Dadurch ist think for Decision Support stärker als ein generischer Brainstorming-Prompt, wenn du ein entscheidungsreifes Ergebnis brauchst.

So nutzt du den think skill

Installieren und auslösen

Installiere ihn mit npx skills add tw93/Waza --skill think. Nutze ihn dann, wenn es darum geht, eine Richtung zu wählen, zu formen oder zu validieren, statt einen bekannten Fehler zu beheben. Der Schritt think install ist einfach, aber die Qualität hängt davon ab, ob du ihm echten Entscheidungskontext gibst.

Die richtige Eingabeform geben

Ein starkes think usage-Prompt sollte Ziel, Einschränkungen, Zielgruppe und die tatsächlich offene Wahl enthalten. Zum Beispiel: „Wir brauchen einen schnelleren Onboarding-Flow für SMB-Admins; wir dürfen nur die UI ändern, können in diesem Sprint kein Backend anfassen, und wir brauchen eine Empfehlung mit Trade-offs.“

Zuerst die richtige Datei lesen

Beginne mit SKILL.md, denn das Repo ist bewusst minimal und enthält keine unterstützenden Ordner wie rules/, references/ oder resources/. Die wichtigste praktische Orientierung steckt direkt im Skill-Text: Lightweight Mode, Evaluation Mode und die Regel, bis zur Freigabe nicht mit der Implementierung zu beginnen.

Den Workflow als Entscheidungs-Trichter nutzen

Ein guter think guide-Ablauf ist: Entscheidung benennen, Einschränkungen auflisten, nach dem besten Weg fragen und dann nur bei Bedarf einen Plan mit Risiken und Alternativen anfordern. Wenn du unsicher bist, ob du Lightweight Mode oder Full Mode verwenden sollst, beschreibe, ob das Problem bereits klar definiert ist; dieses eine Detail verändert die Ausgabe deutlich.

FAQ zum think skill

Ist think nur für neue Features?

Nein. Er ist auch nützlich für Architekturentscheidungen, Produktbewertungen, Refactorings mit echten Trade-offs und Fragen wie „Lohnt sich das überhaupt?“. Für einfache Bugfixes oder kleine Änderungen, bei denen die Antwort ohnehin klar ist, ist er weniger geeignet.

Worin unterscheidet sich das von einem normalen Prompt?

Ein normaler Prompt liefert oft vage Optionen. Der think skill ist darauf ausgelegt, eine Entscheidung zu erzwingen: ein empfohlener Weg, klare Trade-offs und eine eindeutige Grenze gegen das Coden vor der Freigabe. Dadurch eignet er sich besser, wenn du einen Plan brauchst, der von Teammitgliedern oder Stakeholdern geprüft werden kann.

Ist think anfängerfreundlich?

Ja, wenn die Person das Ziel in einfacher Sprache beschreiben kann. Anfänger holen den größten Nutzen heraus, wenn sie Problem, Einschränkungen und gewünschtes Ergebnis nennen, auch wenn sie die technischen Begriffe nicht kennen.

Wann sollte ich think nicht verwenden?

Nutze ihn nicht, wenn du die Lösung schon kennst und nur noch Umsetzung brauchst, oder wenn die Aufgabe so klein ist, dass eine direkte Änderung schneller ist als Analyse. Weniger Mehrwert bringt er auch dann, wenn es keine echte Entscheidung gibt und nur ein schnelles Umformulieren gebraucht wird.

So verbesserst du den think skill

Entscheidungstauglichen Kontext liefern

Die besten think skill-Eingaben enthalten den aktuellen Stand, den Zielzustand, nicht verhandelbare Einschränkungen und das Bild davon, wie Erfolg aussieht. Zum Beispiel liefert „Wir müssen die Einrichtungszeit von 10 Minuten auf 2 Minuten senken, das bestehende Backend beibehalten und keine neuen Abhängigkeiten einführen“ bessere Empfehlungen als „Onboarding verbessern“.

Nach der Entscheidung fragen, nicht nur nach Ideen

Wenn du bessere think usage willst, bitte um eine Empfehlung mit Begründung statt um eine Liste von Möglichkeiten. Gut: „Wähle einen Ansatz und erkläre, warum er unter diesen Bedingungen gewinnt.“ Schwach: „Gib mir ein paar Ideen.“

Die Trade-offs sichtbar machen, die dir wichtig sind

Sag dem Skill, was am meisten zählt: Geschwindigkeit, Wartbarkeit, Kosten, UX, Risiko oder Teamkapazität. So kann think for Decision Support einen Plan liefern, der zu deinen Prioritäten passt, statt einer generischen Best-Practice-Antwort.

Mit schärferen Einschränkungen iterieren

Wenn das erste Ergebnis zu breit ist, schränke es mit einer Rückfrage ein: mit einer Deadline, einer verbotenen Abhängigkeit, einem Zielnutzer oder einer Komponente, die auf jeden Fall erhalten bleiben muss. Der schnellste Weg zu besserer Ausgabe ist, versteckte Annahmen vor der nächsten Anfrage in explizite Einschränkungen zu übersetzen.