product-capability

Überblick über die Produkt-Capability-Skill

product-capability ist eine Skill für die Planung bis zur Spezifikation, mit der sich vage Produktabsichten in einen umsetzungsreifen Capability-Plan überführen lassen. Sie ist besonders nützlich, wenn das Feature-Ziel bereits klar ist, das Team aber vor dem Code-Start noch Klarheit über Constraints, Schnittstellen, Lifecycle-Regeln, Datenfolgen und offene Entscheidungen braucht.

Bestes Einsatzszenario: PRDs, die noch zu ungenau sind

Nutze die product-capability-Skill, wenn zwar ein PRD, ein Roadmap-Punkt, eine Founder-Notiz oder ein Produktthema existiert, die technische Ausgestaltung aber noch nur implizit ist. Besonders hilfreich ist sie bei Arbeiten über mehrere Services hinweg, bei teamübergreifenden Abhängigkeiten oder bei Features, bei denen Reviewer immer wieder fragen: „Was muss genau gelten, bevor wir das bauen?“

Was sie dir über einen normalen Prompt hinaus gibt

Anders als ein generischer „write a spec“-Prompt ist product-capability auf dauerhafte Capability-Verträge ausgerichtet. Sie hilft dabei, Produktversprechen von Implementierungs-Constraints zu trennen, ungeklärte Fragen sichtbar zu machen, statt zu raten, und ein Artefakt zu erzeugen, das sich in späteren Sessions wiederverwenden lässt, statt in der Chat-Historie unterzugehen.

Wann sich die Installation lohnt

Wenn dein Team in Review-Zyklen regelmäßig versteckte Annahmen wieder neu aufdeckt, ist product-capability install wahrscheinlich sinnvoll. Wenn eure Arbeit meist aus einzelnen Dateien besteht, wenig Risiko hat oder bereits durch starke Architektur-Dokumente gut vorgegeben ist, bringt die Skill unter Umständen weniger als ein leichter Prompt.

So verwendest du die product-capability-Skill

Installieren und im Workspace laden

Installiere die Skill mit:

npx skills add affaan-m/everything-claude-code --skill product-capability

Öffne danach zuerst SKILL.md. Für product-capability usage solltest du außerdem jede dauerhafte Produkt-Kontextdatei prüfen, die das Repo erwartet, insbesondere PRODUCT.md, docs/product/ oder ein Verzeichnis für Program-Spezifikationen. Falls es so eine Datei nicht gibt, nutze den Template-Pfad, auf den die Skill verweist.

Eine grobe Anfrage in einen starken Input verwandeln

Die Skill funktioniert am besten, wenn du ihr ein Produktziel plus Kontext gibst und nicht nur einen Feature-Namen. Ein schwaches Briefing wie „add team sharing“ lässt zu viele Lücken offen. Ein stärkeres Briefing lautet etwa: „Erstelle einen Capability-Plan für Team-Sharing über Web und API hinweg, inklusive Berechtigungen, Audit-Events, Invite-Lifecycle und dem Verhalten bei einem Workspace-Downsize.“

Empfohlener Workflow für die product-capability-Skill bei Requirements Planning

Beginne mit der Produktaussage und frage dann nach Capability-Grenzen, Invarianten, Annahmen, offenen Fragen und den Auswirkungen auf die Implementierung. Die besten product-capability guide-Ausgaben beschreiben in der Regel, was vor Arbeitsbeginn wahr sein muss, nicht nur eine Liste von Features. Wenn sich die Anfrage über mehrere Services oder Teams erstreckt, sollte die Skill Ownership und Contract-Grenzen explizit benennen.

Erst lesen, dann erweitern

Das Repository ist bewusst schlank, daher ist der wichtigste erste Einstieg SKILL.md. Nutze die Datei, um das Regelwerk und das Ziel des Artefakts zu verstehen, und passe dann die Struktur an dein eigenes Repo an, statt das Beispiel eins zu eins zu kopieren. Wenn es in deiner Umgebung bereits einen kanonischen Speicherort für Produktdokumente gibt, richte die Ausgabe an diesem Pfad aus, damit keine parallelen Planungsdateien entstehen.

product-capability-Skill FAQ

Ist product-capability nur für PRDs gedacht?

Nein. Die product-capability-Skill passt auch zu Roadmap-Einträgen, Diskussionsnotizen und Founder-Vorgaben, wenn es im Kern darum geht, Absicht in einen umsetzbaren Vertrag zu übersetzen. Entscheidend ist, dass genug Produktsignal vorhanden ist, um Constraints zu definieren, ohne sie zu erfinden.

Wie unterscheidet sie sich vom normalen Prompt-Schreiben?

Ein normaler Prompt kann eine Zusammenfassung oder einen Entwurf erzeugen. product-capability ist enger gefasst: Sie versucht, für die Entwicklung relevante Wahrheiten zu bewahren, Unbekanntes explizit zu machen und ein wiederverwendbares Artefakt zu erzeugen. Das ist besonders wertvoll, wenn die Kosten einer übersehenen Einschränkung hoch sind.

Ist sie anfängerfreundlich?

Ja, wenn du das Feature und seinen Kontext beschreiben kannst. Du brauchst keine Architektur-Expertise, um product-capability zu nutzen, aber du musst die besten Fakten liefern, die dir vorliegen. Wenn kritische Eingaben fehlen, muss das Ergebnis trotzdem noch geprüft werden.

Wann sollte ich sie nicht verwenden?

Verwende product-capability nicht für triviale Aufgaben, isolierte UI-Anpassungen oder Arbeit, die bereits durch eine detaillierte Spezifikation geregelt ist. Sie ist auch kein guter Fit, wenn du ausgefeilte Marketing-Texte oder Implementierungscode willst, statt Material für Requirements Planning.

So verbesserst du die product-capability-Skill

Gib ihr die wichtigsten Fakten

Die größten Qualitätsgewinne entstehen, wenn du nutzer sichtbares Verhalten, Systemgrenzen und bekannte Constraints direkt am Anfang benennst. Nenne Datenfluss, Zugriffsregeln, Erwartungen an Rollbacks, abhängige Systeme sowie alle Policy- oder Compliance-Themen, die die Implementierung verändern würden.

Mache Unbekanntes explizit statt es mitzudenken

Ein starker product-capability-Input trennt bestätigte Anforderungen von offenen Fragen. Wenn das Team noch nicht entschieden hat, ob eine Aktion synchron ist, ob Audit-Logs erforderlich sind oder welcher Service die Source of Truth besitzt, sage das klar. So verhindert man, dass die Skill die Unsicherheit glattbügelt.

Bitte um ein entscheidungsreifes Artefakt

Wenn dein erster Entwurf zu breit ist, bitte die Skill darum, den Scope zu schärfen, Nicht-Verhandelbares aufzulisten und Trade-offs hervorzuheben, die Designentscheidungen blockieren. Eine solche Iteration verbessert die Ausgabe von product-capability usage meist stärker, als überall einfach mehr Details anzufordern.

Verwende denselben Capability-Rahmen wieder

Für wiederkehrende Produktarbeit solltest du über Sessions hinweg dieselbe Capability-Struktur beibehalten, damit Reviewer Pläne konsistent vergleichen können. Je stärker deine Inputs dem tatsächlichen Operating Model deines Teams entsprechen, desto eher liefert die product-capability-Skill brauchbare Orientierung statt generischer Planungsprosa.