Produktfähigkeit

Was macht Produktfähigkeit?

Diese Fähigkeit wandelt Produktabsichten in explizite technische Einschränkungen um.

Verwende sie, wenn die Lücke nicht "Was sollen wir bauen?", sondern "Was muss genau wahr sein, bevor die Implementierung beginnt?" ist.

Wann zu verwenden

• Ein PRD, ein Roadmap-Eintrag, eine Diskussion oder eine Gründernotiz existiert, aber die Implementierungseinschränkungen sind noch implizit
• Eine Funktion erstreckt sich über mehrere Dienste, Repositories oder Teams und benötigt einen Fähigkeitsvertrag, bevor mit dem Codieren begonnen wird
• Die Produktabsicht ist klar, aber die Auswirkungen auf Architektur, Daten, Lebenszyklus oder Richtlinien sind noch verschwommen
• Leitende Ingenieure wiederholen während der Überprüfung immer wieder dieselben versteckten Annahmen
• Du benötigst ein wiederverwendbares Artefakt, das über verschiedene Arbeitsumgebungen und Sitzungen hinweg bestehen kann

Kanonisches Artefakt

Wenn das Repository eine dauerhafte Produktkontextdatei wie PRODUCT.md, docs/product/ oder ein Programmspezifikationsverzeichnis enthält, aktualisiere es dort.

Wenn noch kein Fähigkeitsmanifest existiert, erstelle eines mit der Vorlage unter:

• docs/examples/product-capability-template.md

Das Ziel ist es nicht, einen weiteren Planungsstapel zu schaffen. Das Ziel ist es, versteckte Fähigkeitseinschränkungen dauerhaft und wiederverwendbar zu machen.

Unverhandelbare Regeln

• Erfinde keine Produktwahrheit. Markiere offene Fragen explizit.
• Trenne sichtbare Benutzerversprechen von Implementierungsdetails.
• Benenne, was festgelegte Richtlinie, was Architekturpräferenz und was noch offen ist.
• Wenn die Anfrage mit bestehenden Repository-Einschränkungen in Konflikt steht, sage dies deutlich, anstatt es zu glätten.
• Bevorzuge ein wiederverwendbares Fähigkeitsartefakt gegenüber verstreuten Ad-hoc-Notizen.

Eingaben

Lies nur, was benötigt wird:

1. Produktabsicht
   • Issue, Diskussion, PRD, Roadmap-Notiz, Gründernachricht
2. Aktuelle Architektur
   • relevante Repository-Dokumente, Verträge, Schemata, Routen, bestehende Arbeitsabläufe
3. Vorhandener Fähigkeitskontext
   • PRODUCT.md, Designdokumente, RFCs, Migrationsnotizen, Betriebsmodell-Dokumente
4. Lieferbeschränkungen
   • Authentifizierung, Abrechnung, Compliance, Rollout, Abwärtskompatibilität, Leistung, Überprüfungsrichtlinie

Kernarbeitsablauf

1. Formuliere die Fähigkeit neu

Komprimiere die Anfrage in eine präzise Aussage:

• wer der Benutzer oder Betreiber ist
• welche neue Fähigkeit nach der Auslieferung existiert
• welches Ergebnis sich dadurch ändert

Wenn diese Aussage schwach ist, wird die Implementierung abdriften.

2. Löse Fähigkeitseinschränkungen auf

Extrahiere die Einschränkungen, die vor der Implementierung gelten müssen:

• Geschäftsregeln
• Umfangsgrenzen
• Invarianten
• Vertrauensgrenzen
• Datenbesitz
• Lebenszyklusübergänge
• Rollout-/Migrationsanforderungen
• Erwartungen an Fehler und Wiederherstellung

Dies sind die Dinge, die oft nur im Gedächtnis leitender Ingenieure existieren.

3. Definiere den implementierungsorientierten Vertrag

Erstelle 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. Übersetze in die Ausführung

Beende mit der genauen Übergabe:

• bereit zur direkten Implementierung
• benötigt zuerst eine Architekturüberprüfung
• benötigt zuerst eine Produktklärung

Wenn hilfreich, verweise auf die nächste ECC-native Spur:

• project-flow-ops
• workspace-surface-audit
• api-connector-builder
• dashboard-builder
• tdd-workflow
• verification-loop

Ausgabeformat

Gebe das Ergebnis in dieser Reihenfolge zurück:

FÄHIGKEIT
- ein Absatz Neufassung

EINSCHRÄNKUNGEN
- feste Regeln, Invarianten und Grenzen

IMPLEMENTIERUNGSVERTRAG
- Akteure
- Oberflächen
- Zustände und Übergänge
- Schnittstellen-/Datenauswirkungen

NICHT-ZIELE
- was diese Spur explizit nicht besitzt

OFFENE FRAGEN
- Blockaden oder noch erforderliche Produktentscheidungen

ÜBERGABE
- was als nächstes passieren sollte und welche ECC-Spur es übernehmen sollte

Gute Ergebnisse

• Die Produktabsicht ist nun konkret genug, um implementiert zu werden, ohne versteckte Einschränkungen mitten im PR 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 auf Claude Code, Codex, Cursor, OpenCode und ECC 2.0-Planungsoberflächen.