Was macht Produktfähigkeit?
Dieser Skill wandelt Produktabsichten in explizite technische Einschränkungen um.
Verwenden Sie ihn, wenn die Lücke nicht "was sollen wir bauen?" ist, sondern "was genau muss vor Beginn der Implementierung wahr sein?"
Wann verwenden
- Ein PRD, Roadmap-Element, eine Diskussion oder eine Gründer-Notiz ist vorhanden, aber die Implementierungseinschränkungen sind noch implizit
- Eine Funktion erstreckt sich über mehrere Dienste, Repos oder Teams und benötigt vor dem Codieren einen Fähigkeitsvertrag
- Die Produktabsicht ist klar, aber die Auswirkungen auf Architektur, Daten, Lebenszyklus oder Richtlinien sind noch vage
- Leitende Ingenieure wiederholen während der Überprüfung immer wieder dieselben versteckten Annahmen
- Sie benötigen ein wiederverwendbares Artefakt, das über verschiedene Umgebungen und Sitzungen hinweg Bestand hat
Kanonisches Artefakt
Wenn das Repo eine dauerhafte Produktkontextdatei wie PRODUCT.md, docs/product/ oder ein Programmspezifikationsverzeichnis enthält, aktualisieren Sie es dort.
Falls noch kein Fähigkeitsmanifest existiert, erstellen Sie eines mit der Vorlage unter:
docs/examples/product-capability-template.md
Das Ziel ist es, keinen weiteren Planungsstapel zu erzeugen. Das Ziel ist es, versteckte Fähigkeitseinschränkungen dauerhaft und wiederverwendbar zu machen.
Nicht-verhandelbare Regeln
- Erfinden Sie keine Produktwahrheit. Markieren Sie ungelöste Fragen explizit.
- Trennen Sie benutzersichtbare Zusagen von Implementierungsdetails.
- Heben Sie hervor, was feste Richtlinie, was Architekturpräferenz und was noch offen ist.
- Wenn die Anfrage mit bestehenden Repo-Einschränkungen in Konflikt steht, sagen Sie dies deutlich, anstatt es zu glätten.
- Bevorzugen Sie ein wiederverwendbares Fähigkeitsartefakt gegenüber verstreuten Ad-hoc-Notizen.
Eingaben
Lesen Sie nur, was benötigt wird:
- Produktabsicht
- Issue, Diskussion, PRD, Roadmap-Notiz, Gründer-Nachricht
- Aktuelle Architektur
- relevante Repo-Dokumente, Verträge, Schemas, Routen, bestehende Arbeitsabläufe
- Bestehender Fähigkeitskontext
PRODUCT.md, Design-Dokumente, RFCs, Migrationsnotizen, Betriebsmodell-Dokumente
- Lieferbeschränkungen
- Authentifizierung, Abrechnung, Compliance, Rollout, Rückwärtskompatibilität, Leistung, Überprüfungsrichtlinie
Kernarbeitsablauf
1. Formulieren Sie die Fähigkeit
Verdichten Sie die Anfrage zu einer präzisen Aussage:
- wer der Benutzer oder Betreiber ist
- welche neue Fähigkeit nach diesem Release existiert
- welches Ergebnis sich dadurch ändert
Wenn diese Aussage schwach ist, wird die Implementierung abweichen.
2. Lösen Sie Fähigkeitseinschränkungen auf
Extrahieren Sie die Einschränkungen, die vor der Implementierung gelten müssen:
- Geschäftsregeln
- Umfangsgrenzen
- Invarianten
- Vertrauensgrenzen
- Datenverantwortung
- Lebenszyklusübergänge
- Rollout- / Migrationsanforderungen
- Fehler- und Wiederherstellungserwartungen
Dies sind die Dinge, die oft nur im Gedächtnis des leitenden Ingenieurs existieren.
3. Definieren Sie den implementationsorientierten Vertrag
Erstellen Sie einen SRS-artigen Fähigkeitsplan mit:
- Zusammenfassung der Fähigkeit
- explizite Nicht-Ziele
- Akteure und Oberflächen
- erforderliche Zustände und Übergänge
- Schnittstellen / Eingaben / Ausgaben
- Auswirkungen auf das Datenmodell
- Sicherheits- / Abrechnungs- / Richtlinieneinschränkungen
- Beobachtbarkeits- und Betreiberanforderungen
- offene Fragen, die die Implementierung blockieren
4. Übersetzen Sie in die Ausführung
Beenden Sie mit der genauen Übergabe:
- bereit zur direkten Implementierung
- erfordert zuerst eine Architekturüberprüfung
- erfordert zuerst eine Produktklärung
Falls nützlich, verweisen Sie auf den nächsten ECC-nativen Pfad:
project-flow-opsworkspace-surface-auditapi-connector-builderdashboard-buildertdd-workflowverification-loop
Ausgabeformat
Geben Sie das Ergebnis in dieser Reihenfolge zurück:
FÄHIGKEIT
- ein Absatz mit der Neuformulierung
EINSCHRÄNKUNGEN
- feste Regeln, Invarianten und Grenzen
IMPLEMENTIERUNGSVERTRAG
- Akteure
- Oberflächen
- Zustände und Übergänge
- Schnittstellen-/Datenauswirkungen
NICHT-ZIELE
- was dieser Pfad explizit nicht besitzt
OFFENE FRAGEN
- Blockaden oder Produktentscheidungen, die noch erforderlich sind
ÜBERGABE
- was als Nächstes passieren sollte und welcher ECC-Pfad es übernehmen sollte
Gute Ergebnisse
- Die Produktabsicht ist nun konkret genug, um implementiert zu werden, ohne versteckte Einschränkungen während des PRs wiederzuentdecken.
- Die technische Überprüfung hat ein dauerhaftes Artefakt, anstatt sich auf das Gedächtnis oder Slack-Kontext zu verlassen.
- Der resultierende Plan ist wiederverwendbar in Claude Code, Codex, Cursor, OpenCode und ECC 2.0-Planungsoberflächen.