identify-assumptions-existing
von phurynidentify-assumptions-existing hilft dir, eine Feature-Idee in einem bestehenden Produkt einem Stresstest zu unterziehen, indem riskante Annahmen über Value, Usability, Viability und Feasibility sichtbar gemacht werden. Dabei werden Perspektiven aus Product Management, Design und Engineering sowie eine Devil’s-Advocate-Perspektive für strategische Planung und die Risikoprüfung vor dem Build genutzt.
Dieser Skill erreicht 78/100 und ist damit ein solider Kandidat für ein Verzeichnis für Nutzer, die eine strukturierte Analyse von Annahmen und Risiken für ein bestehendes Produkt suchen. Er hat einen klaren Anwendungsfall, eine gut lesbare Trigger-Sprache und einen definierten Workflow, der Agenten die Ausführung mit weniger Rätselraten ermöglicht als ein generischer Prompt. Allerdings fehlen unterstützende Assets und tiefere operative Beispiele.
- Klarer Trigger und klarer Umfang für den Stresstest von Feature-Ideen in einem bestehenden Produkt
- Konkreter Workflow über Value, Usability, Viability und Feasibility hinweg mit Vertrauenswerten und Testvorschlägen
- Keine Platzhalter; der Inhalt ist substanziell und für den Agenten-Einsatz ausreichend konkret
- Keine Support-Dateien, Referenzen oder Beispiele, daher müssen Nutzer sich größtenteils auf den Text in SKILL.md verlassen
- Kein Installationsbefehl und keine Zusatzressourcen, was Onboarding und Hinweise für Randfälle einschränkt
Überblick über identify-assumptions-existing
identify-assumptions-existing ist ein Product-Discovery-Skill zum Belastungstest einer Feature-Idee in einem bestehenden Produkt, bevor du Zeit in Design oder Entwicklung investierst. Er hilft dir, die riskanten Annahmen hinter einem Vorschlag über Value, Usability, Viability und Feasibility sichtbar zu machen – mit einer eingebauten Devil’s-Advocate-Perspektive.
Der Skill eignet sich besonders für Product Manager, Designer, Engineers und Founder, die schnell eine Annahmenkarte brauchen, nicht ein ausgefeiltes Strategie-Deck. Wenn du entscheiden willst, ob sich ein Feature überhaupt lohnt, oder wenn du die versteckten Bruchstellen in einer bereits vielversprechenden Idee finden möchtest, passt identify-assumptions-existing sehr gut.
Der wichtigste Nutzen ist bessere Entscheidungsqualität: Das Gespräch wird von „klingt gut“ hin zu „was muss wahr sein, damit das funktioniert?“ verschoben. Genau deshalb ist der Skill besonders nützlich für Strategic Planning, Roadmap-Triage und das frühe Risiko-Review vor Research.
Wofür identify-assumptions-existing gedacht ist
Nutze den identify-assumptions-existing Skill, wenn du bereits eine Feature-Idee hast und sie gegen reale Rahmenbedingungen prüfen willst. Er ist dafür gemacht, sichtbar zu machen, wo die Idee im Markt, in der User Experience, im Business oder in der Umsetzung scheitern könnte.
Wer ihn installieren sollte
Installiere identify-assumptions-existing, wenn du grobe Produktideen regelmäßig in testbare Annahmen übersetzt. Am meisten bringt er Teams, die einen wiederholbaren Weg brauchen, Feature-Vorschläge zu hinterfragen, bevor daraus Tickets, Spezifikationen oder Experimente werden.
Was ihn unterscheidet
Im Gegensatz zu einem generischen Brainstorming-Prompt fordert identify-assumptions-existing das Modell auf, aus drei Rollen zu denken: PM, Designer und Engineer. Dieses cross-funktionale Framing hilft dir, blinde Flecken schneller zu erkennen und liefert für jede Annahme deutlich besser umsetzbare Tests.
Wie du den Skill identify-assumptions-existing verwendest
Installieren und starten
Nutze den identify-assumptions-existing install-Ablauf mit dem Repo-Befehl aus der Quelle:
npx skills add phuryn/pm-skills --skill identify-assumptions-existing
Rufe den Skill danach mit einer Feature-Idee für ein bestehendes Produkt auf. Je konkreter dein Input, desto besser wird die Annahmenliste.
Den richtigen Input geben
Das Muster identify-assumptions-existing usage funktioniert am besten, wenn du Folgendes mitgibst:
- Produkt- oder Feature-Name
- Zielgruppe
- gewünschtes Ergebnis
- die Feature-Idee selbst
- relevante Constraints wie Plattform, Zeitplan, Compliance oder Abhängigkeiten
Ein schwacher Prompt ist: „Analysiere mein Feature.“
Ein stärkerer Prompt ist: „Belastungstest für eine Dashboard-Export-Funktion für SMB-Finanzadmins in unserer B2B-App. Ziel: Support-Tickets reduzieren. Constraints: nur Web, zwei Engineers, kein neues Data Warehouse.“
Die Quelle in der richtigen Reihenfolge lesen
Für einen identify-assumptions-existing guide solltest du zuerst SKILL.md lesen. Wenn das Repository später erweitert wird, prüfe zusätzlich README.md, AGENTS.md, metadata.json sowie eventuelle Ordner wie rules/, resources/, references/ oder scripts/ für weiteren Kontext. In diesem Repo ist SKILL.md die maßgebliche Quelle.
Workflow, der bessere Ergebnisse liefert
Ein praxistauglicher identify-assumptions-existing usage-Workflow sieht so aus:
- Produktkontext und Feature-Idee beschreiben.
- Um Annahmen gruppiert nach Value, Usability, Viability und Feasibility bitten.
- Für jede Annahme ein Confidence-Level und einen Test anfordern.
- Das Ergebnis nutzen, um zu entscheiden, was zuerst validiert wird.
Wenn du den Skill für Strategic Planning nutzt, gib Marktsegment, Business-Ziel und Launch-Constraints mit an, damit der Skill strategisches Risiko von UX- oder Engineering-Risiko trennen kann.
FAQ zum Skill identify-assumptions-existing
Ist identify-assumptions-existing nur für bestehende Produkte gedacht?
Ja, genau dafür ist er ausgelegt. Der Skill ist darauf optimiert, eine Feature-Idee in einem bestehenden Produkt zu testen – nicht für offenes Konzept-Ideieren von Grund auf.
Wie unterscheidet er sich von einem normalen Prompt?
Ein normaler Prompt listet vielleicht Vor- und Nachteile auf. Der identify-assumptions-existing Skill geht tiefer, indem er Risiken in vier Kategorien strukturiert und fragt, was schiefgehen könnte, wie sicher du bist und wie sich das testen lässt. Dadurch wird das Ergebnis deutlich handlungsfähiger.
Ist identify-assumptions-existing anfängerfreundlich?
Ja, wenn du Produkt, Zielgruppe und Feature in einfacher Sprache beschreiben kannst. Du brauchst kein formales Framework für Assumption Mapping, um ihn sinnvoll zu nutzen, aber du brauchst genug Kontext, damit das Modell die Trade-offs realistisch einschätzen kann.
Wann sollte ich ihn nicht verwenden?
Verwende identify-assumptions-existing nicht, wenn du detaillierte UX-Texte, Implementierungscode oder einen finalen Launch-Plan brauchst. Es ist ein Skill zur Risikoerkennung und funktioniert deshalb am besten vor den eigentlichen Build-Entscheidungen.
So verbesserst du den Skill identify-assumptions-existing
Mehr präzisen Kontext liefern
Der größte Hebel für die Qualität von identify-assumptions-existing ist die Genauigkeit bei Nutzer und Business-Ziel. Wenn du nur „AI Search hinzufügen“ schreibst, muss der Skill zu viel raten. Wenn du dagegen schreibst „AI Search für Support Agents, um die Time-to-Answer bei wiederkehrenden Tickets zu senken“, werden die Annahmen wesentlich brauchbarer.
Nach Tests fragen, nicht nur nach Risiken
Die Quelle weist den Skill an, nicht nur mögliche Probleme, sondern auch Testmöglichkeiten zu nennen. Bleib also nicht bei Risiken stehen. Bitte um leichte Validierungs-Ideen wie Interviews, Prototyp-Tests, Log-Reviews oder einen internen Dogfood-Check. So wird das Ergebnis zu einem Planungsartefakt statt zu einer bloßen Kritik.
Produkt-Risiko und Delivery-Risiko trennen
Die nützlichsten Ergebnisse von identify-assumptions-existing unterscheiden meist zwischen Nutzerwert, Adoptionshürden, Business-Constraints und technischer Machbarkeit. Wenn dein Prompt all das in eine vage Anfrage packt, wird die Antwort weniger entscheidungsreif. Gib Constraints ausdrücklich an, damit der Skill die gefährlichsten Annahmen zuerst priorisieren kann.
Nach dem ersten Durchlauf iterieren
Nutze das erste Ergebnis, um den Scope einzugrenzen, und führe den Skill dann noch einmal mit einem engeren Ausschnitt aus. Wenn der erste Durchlauf zum Beispiel Usability- und Integrationsrisiken zeigt, frage danach nur noch für den Onboarding-Flow oder nur für die Data-Sync-Abhängigkeit. Das ist oft der schnellste Weg, eine Strategic-Planning-Diskussion zu schärfen.