Heim

Skill

Produktivität und Workflow

product-capability

affaan-m/ECC

Setzen Sie Produktkonzepte, PRDs oder Roadmap-Diskussionen in konkrete, umsetzungsreife Funktionspläne mit Einschränkungen, Invarianten, Schnittstellen und offenen Fragen um, bevor die dienstübergreifende Arbeit beginnt.

...Alle erweitern

Zeit aktualisiert 12. Oktober 2026

# roadmap # prd # capability plan # constraints # engineering planning # product capability # srs

Produktfunktionalität

Diese Kompetenz wandelt die Produktvision in konkrete technische Vorgaben um.

Setzen Sie sie ein, wenn die Frage nicht lautet: „Was sollen wir entwickeln?“, sondern: „Was muss genau gegeben sein, bevor mit der Umsetzung begonnen wird?“

Anwendungsfälle

Es liegt ein PRD, ein Roadmap-Punkt, eine Diskussion oder eine Notiz des Gründers vor, aber die Implementierungsvorgaben sind noch implizit
Eine Funktion erstreckt sich über mehrere Dienste, Repos oder Teams und erfordert vor der Programmierung einen Funktionsvertrag
Die Produktvision ist klar, aber die Auswirkungen auf Architektur, Daten, Lebenszyklus oder Richtlinien sind noch unklar
Erfahrene Entwickler wiederholen bei der Überprüfung immer wieder dieselben impliziten Annahmen
Sie benötigen ein wiederverwendbares Artefakt, das über verschiedene Testumgebungen und Sitzungen hinweg Bestand hat

Kanonisches Artefakt

Wenn das Repo über eine dauerhafte Produktkontextdatei wie „PRODUCT.md“, „docs/product/“ oder ein Verzeichnis „program-spec“ verfügt, aktualisieren Sie diese dort.

Falls noch kein Capability-Manifest vorhanden ist, erstellen Sie eines mithilfe der Vorlage unter:

docs/examples/product-capability-template.md

Das Ziel ist nicht, einen weiteren Planungs-Stack zu erstellen. Das Ziel ist es, verborgene Fähigkeitsbeschränkungen dauerhaft und wiederverwendbar zu machen.

Unumstößliche Regeln

Erfinden Sie keine Produktwahrheit. Kennzeichnen Sie ungelöste Fragen ausdrücklich.
Trennen Sie für den Benutzer sichtbare Versprechen von Implementierungsdetails.
Machen Sie deutlich, was feststehende Richtlinien sind, was architektonische Präferenzen sind und was noch offen ist.
Wenn die Anforderung mit bestehenden Repo-Einschränkungen in Konflikt steht, weisen Sie klar darauf hin, anstatt das Problem zu beschönigen.
Bevorzugen Sie ein wiederverwendbares Funktionsartefakt gegenüber verstreuten Ad-hoc-Notizen.

Eingaben

Lesen Sie nur das, was notwendig ist:

Produktziel
- Issue, Diskussion, PRD, Roadmap-Notiz, Mitteilung des Gründers
Aktuelle Architektur
- Relevante Repo-Dokumente, Verträge, Schemata, Routen, bestehende Workflows
Kontext der bestehenden Funktionen
- PRODUCT.md, Designdokumente, RFCs, Migrationshinweise, Dokumente zum Betriebsmodell
Bereitstellungsbeschränkungen
- Authentifizierung, Abrechnung, Compliance, Rollout, Abwärtskompatibilität, Leistung, Überprüfungsrichtlinie

Kern-Workflow

1. Formulieren Sie die Funktion neu

Fassen Sie die Anforderung in einer präzisen Aussage zusammen:

Wer ist der Nutzer oder Betreiber?
Welche neue Funktion steht nach der Veröffentlichung zur Verfügung?
welche Auswirkungen sich dadurch ändern

Ist diese Aussage zu vage, wird die Umsetzung vom Kurs abweichen.

2. Klären Sie die Einschränkungen der Funktionen

Ermitteln Sie die Einschränkungen, die vor der Umsetzung gelten müssen:

Geschäftsregeln
Grenzen des Anwendungsbereichs
Invarianten
Vertrauensgrenzen
Datenverantwortung
Lebenszyklusübergänge
Anforderungen an Rollout und Migration
Erwartungen hinsichtlich Ausfällen und Wiederherstellung

Dies sind die Dinge, die oft nur im Gedächtnis der leitenden Ingenieure verankert sind.

3. Definieren Sie den implementierungsbezogenen Vertrag

Erstellen Sie einen Funktionsplan im SRS-Stil mit:

Zusammenfassung der Funktionen
explizite Nicht-Ziele
Akteuren und Schnittstellen
erforderliche Zustände und Übergänge
Schnittstellen / Eingaben / Ausgaben
Auswirkungen auf das Datenmodell
Sicherheit / Abrechnung / Richtlinienbeschränkungen
Beobachtbarkeit und Anforderungen an den Betreiber
offene Fragen, die die Umsetzung blockieren

4. In die Umsetzung umsetzen

Abschluss mit der genauen Übergabe:

Bereit zur direkten Umsetzung
erfordert zunächst eine Architekturprüfung
erfordert zunächst eine Produktklärung

Falls sinnvoll, verweisen Sie auf den nächsten ECC-eigenen Pfad:

project-flow-ops
Workspace-Surface-Audit
API-Connector-Builder
Dashboard-Builder
tdd-workflow
Verifizierungsschleife

Ausgabeformat

Geben Sie das Ergebnis in dieser Reihenfolge zurück:

FÄHIGKEIT
– Zusammenfassung in einem Absatz

EINSCHRÄNKUNGEN
– feste Regeln, Invarianten und Grenzen

IMPLEMENTIERUNGSVERTRAG
– Akteure
– Schnittstellen
– Zustände und Übergänge
– Auswirkungen auf Schnittstellen/Daten

NICHT-ZIELE
- Was dieser Arbeitsbereich ausdrücklich nicht umfasst

OFFENE FRAGEN
- noch erforderliche Hindernisse oder Produktentscheidungen

ÜBERGABE
- Was soll als Nächstes geschehen und welcher ECC-Arbeitsbereich soll die Aufgabe übernehmen?

Erfolgreiche Ergebnisse

Die Produktvision ist nun konkret genug, um die Umsetzung durchzuführen, ohne dass während des PR versteckte Einschränkungen neu entdeckt werden.
Die technische Überprüfung verfügt über ein dauerhaftes Artefakt, anstatt sich auf das Gedächtnis oder den Slack-Kontext zu verlassen.
Der daraus resultierende Plan ist über die Planungsbereiche von Claude Code, Codex, Cursor, OpenCode und ECC 2.0 hinweg wiederverwendbar.

Auf GitHub ansehen

---
name: product-capability
description: Translate product intent, PRDs, or roadmap discussions into explicit, implementation-ready capability plans with constraints, invariants, interfaces, and open questions before multi-service work begins.
---

# Product Capability

This skill turns product intent into explicit engineering constraints.

Use it when the gap is not "what should we build?" but "what exactly must be true before implementation starts?"

## When to Use

- A PRD, roadmap item, discussion, or founder note exists, but the implementation constraints are still implicit
- A feature crosses multiple services, repos, or teams and needs a capability contract before coding
- Product intent is clear, but architecture, data, lifecycle, or policy implications are still fuzzy
- Senior engineers keep restating the same hidden assumptions during review
- You need a reusable artifact that can survive across harnesses and sessions

## Canonical Artifact

If the repo has a durable product-context file such as `PRODUCT.md`, `docs/product/`, or a program-spec directory, update it there.

If no capability manifest exists yet, create one using the template at:

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

The goal is not to create another planning stack. The goal is to make hidden capability constraints durable and reusable.

## Non-Negotiable Rules

- Do not invent product truth. Mark unresolved questions explicitly.
- Separate user-visible promises from implementation details.
- Call out what is fixed policy, what is architecture preference, and what is still open.
- If the request conflicts with existing repo constraints, say so clearly instead of smoothing it over.
- Prefer one reusable capability artifact over scattered ad hoc notes.

## Inputs

Read only what is needed:

1. Product intent
   - issue, discussion, PRD, roadmap note, founder message
2. Current architecture
   - relevant repo docs, contracts, schemas, routes, existing workflows
3. Existing capability context
   - `PRODUCT.md`, design docs, RFCs, migration notes, operating-model docs
4. Delivery constraints
   - auth, billing, compliance, rollout, backwards compatibility, performance, review policy

## Core Workflow

### 1. Restate the capability

Compress the ask into one precise statement:

- who the user or operator is
- what new capability exists after this ships
- what outcome changes because of it

If this statement is weak, the implementation will drift.

### 2. Resolve capability constraints

Extract the constraints that must hold before implementation:

- business rules
- scope boundaries
- invariants
- trust boundaries
- data ownership
- lifecycle transitions
- rollout / migration requirements
- failure and recovery expectations

These are the things that often live only in senior-engineer memory.

### 3. Define the implementation-facing contract

Produce an SRS-style capability plan with:

- capability summary
- explicit non-goals
- actors and surfaces
- required states and transitions
- interfaces / inputs / outputs
- data model implications
- security / billing / policy constraints
- observability and operator requirements
- open questions blocking implementation

### 4. Translate into execution

End with the exact handoff:

- ready for direct implementation
- needs architecture review first
- needs product clarification first

If useful, point to the next ECC-native lane:

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

## Output Format

Return the result in this order:

```text
CAPABILITY
- one-paragraph restatement

CONSTRAINTS
- fixed rules, invariants, and boundaries

IMPLEMENTATION CONTRACT
- actors
- surfaces
- states and transitions
- interface/data implications

NON-GOALS
- what this lane explicitly does not own

OPEN QUESTIONS
- blockers or product decisions still required

HANDOFF
- what should happen next and which ECC lane should take it
```

## Good Outcomes

- Product intent is now concrete enough to implement without rediscovering hidden constraints mid-PR.
- Engineering review has a durable artifact instead of relying on memory or Slack context.
- The resulting plan is reusable across Claude Code, Codex, Cursor, OpenCode, and ECC 2.0 planning surfaces.