Feature Spec

Feature Spec ist ein offizieller Produktmanagement-Skill aus Anthropic knowledge-work-plugins. Die ursprüngliche Quelle war unter dem Pfad product-management/skills/feature-spec vorgesehen. Im aktuell erreichbaren Hauptzweig ist dieser Arbeitsablauf unter product-management/skills/write-spec veröffentlicht; der Kandidatenname feature-spec beschreibt weiterhin denselben dokumentierten Zweck. Die direkte Primärquelle für den derzeitigen Inhalt ist https://github.com/anthropics/knowledge-work-plugins/tree/main/product-management/skills/write-spec. Laut Anbieter verwandelt der Skill ein Feature, eine Problemstellung, eine Nutzeranfrage oder eine noch vage Idee in eine strukturierte Produktspezifikation beziehungsweise ein Product Requirements Document.

Problem und Kontext

Der Workflow beginnt mit einer verständlichen Beschreibung dessen, was spezifiziert werden soll. Danach fragt er schrittweise nach dem Nutzerproblem, den betroffenen Zielgruppen, gewünschten Erfolgskriterien, technischen oder organisatorischen Einschränkungen und bereits vorhandenen Lösungen. Diese Gesprächsführung ist bewusst nicht als langer Fragebogen angelegt. Laut Anbieter sollen zuerst die wichtigsten Unklarheiten geklärt und fehlende Details im weiteren Verlauf ergänzt werden. Wenn verbundene Projekt-, Wissens-, Design- oder Feedbackquellen vorhanden sind, können relevante Tickets, Recherchen, Entwürfe und Rückmeldungen einbezogen werden. Ohne solche Verbindungen arbeitet der Skill mit den Informationen, die das Team bereitstellt.

Struktur des Ergebnisses

Die empfohlene Spezifikation enthält eine Problemstellung mit betroffenen Personen und Auswirkungen, messbare Ziele sowie klare Nicht-Ziele. Nutzerberichte beschreiben konkrete Rollen, Fähigkeiten und Nutzen, ohne eine bestimmte technische Lösung vorwegzunehmen. Anforderungen werden nach Priorität in unverzichtbare Bestandteile, wertvolle Ergänzungen und spätere Überlegungen gegliedert. Zu jeder wichtigen Anforderung gehören überprüfbare Akzeptanzkriterien, häufig in einer Given-When-Then-Form. Erfolgsmessung unterscheidet laut Anbieter zwischen kurzfristigen Signalen wie Aktivierung, Abschlussrate, Bearbeitungszeit und Fehlerquote sowie langfristigen Signalen wie Bindung, Zufriedenheit, Supportaufwand oder Geschäftswirkung. Offene Fragen werden Verantwortlichen aus Engineering, Design, Recht, Daten oder Stakeholdern zugeordnet. Zeitliche Abhängigkeiten und eine mögliche Phasierung halten den Umfang realistisch.

Priorisierung und Umfang

Ein zentraler Nutzen liegt in der bewussten Begrenzung. Nicht-Ziele schützen vor schleichender Erweiterung, während die Einteilung in P0, P1 und P2 sichtbar macht, was zum ersten nutzbaren Schnitt gehört. Die Quelle beschreibt zusätzlich MoSCoW als mögliches Denkmodell. Ein guter Entwurf benennt Annahmen, Risiken und Abhängigkeiten, statt eine scheinbare Gewissheit zu erzeugen. Akzeptanzkriterien sollen Erfolgsfälle, Fehlerzustände, leere Zustände und Grenzfälle abdecken. Vage Begriffe wie schnell oder intuitiv werden durch beobachtbare Bedingungen ersetzt. Die Spezifikation ist damit eine Grundlage für Abstimmung und Umsetzung, kein unveränderlicher Vertrag.

Grenzen, Sicherheit und Einordnung

Feature Spec ist weder Projektmanagementsoftware noch Produktanalyse, Priorisierungsentscheidung oder automatische Freigabe. Laut Anbieter soll der Entwurf nach seiner Erstellung gemeinsam mit den Beteiligten überprüft und iteriert werden. Eine Modellantwort kann fehlende Nutzerforschung, unvollständige Metriken, rechtliche Vorgaben oder technische Abhängigkeiten nicht ersetzen. Angeschlossene Quellen dürfen nur im genehmigten Umfang verwendet werden. Interne Tickets, personenbezogene Rückmeldungen und vertrauliche Produktpläne sollten minimiert und nach den jeweiligen Zugriffsregeln verarbeitet werden. Ein lokaler Skill-Ordner bedeutet nicht, dass Eingaben und Ergebnisse lokal bleiben; ein verbundenes Modell kann Daten an seinen Modellanbieter übertragen. Keine Zugangsdaten, Tokens oder Produktionsdaten gehören in Spezifikationsbeispiele. Anthropic veröffentlicht das Repository laut Anbieter unter Apache-2.0. Diese Beschreibung wurde am 9. September 2026 anhand des offiziellen Repositorys, der dortigen Produktmanagement-Übersicht und der offiziellen Claude-Code-Dokumentation geprüft. Sie beschreibt den dokumentierten Arbeitsablauf, nicht eine Garantie für korrekte Anforderungen oder erfolgreiche Produktentscheidungen.