product-capability

Capacité Produit

Cette compétence transforme l'intention produit en contraintes explicites d'ingénierie.

Utilisez-la lorsque l'écart n'est pas que devrions-nous construire ? mais que doit exactement être vrai avant de commencer l'implémentation ?

Quand l'utiliser

• Un PRD, un élément de roadmap, une discussion ou une note fondateur existe, mais les contraintes d'implémentation restent implicites
• Une fonctionnalité traverse plusieurs services, dépôts ou équipes et nécessite un contrat de capacité avant de coder
• L'intention produit est claire, mais les implications architecture, données, cycle de vie ou politique sont encore floues
• Les ingénieurs senior répètent les mêmes hypothèses cachées pendant les revues
• Vous avez besoin d'un artefact réutilisable qui survivra à travers les environnements et sessions

Artefact canonique

Si le dépôt possède un fichier durable de contexte produit comme PRODUCT.md, docs/product/, ou un répertoire de spécifications programme, mettez-le à jour là-bas.

Si aucun manifeste de capacité n'existe encore, créez-en un en utilisant le modèle suivant :

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

L'objectif n'est pas de créer une autre couche de planification. L'objectif est de rendre les contraintes cachées de capacité durables et réutilisables.

Règles non-négociables

• N'inventez pas de vérité produit. Marquez explicitement les questions non résolues.
• Séparez les promesses visibles par l'utilisateur des détails d'implémentation.
• Désignez ce qui est une politique fixe, ce qui est un choix d'architecture, et ce qui est encore ouvert.
• Si la demande entre en conflit avec les contraintes existantes du dépôt, dites-le clairement au lieu de lisser.
• Préférez un artefact de capacité réutilisable à des notes ad hoc dispersées.

Entrées

Lisez uniquement ce qui est nécessaire :

1. Intention produit
   • issue, discussion, PRD, note de roadmap, message fondateur
2. Architecture actuelle
   • docs du dépôt, contrats, schémas, routes, flux de travail existants
3. Contexte de capacité existant
   • PRODUCT.md, docs de conception, RFCs, notes de migration, docs de modèle opérationnel
4. Contraintes de livraison
   • auth, facturation, conformité, déploiement, rétrocompatibilité, performance, politique de revue

Workflow principal

1. Reformuler la capacité

Compressez la demande en une déclaration précise :

• qui est l'utilisateur ou l'opérateur
• quelle nouvelle capacité existe après cette livraison
• quel résultat change à cause de cela

Si cette déclaration est faible, l'implémentation dérivera.

2. Résoudre les contraintes de capacité

Extrayez les contraintes qui doivent tenir avant l'implémentation :

• règles métier
• limites de portée
• invariants
• frontières de confiance
• propriété des données
• transitions de cycle de vie
• exigences de déploiement / migration
• attentes en cas d'échec et de reprise

Ce sont les choses qui vivent souvent uniquement dans la mémoire des ingénieurs senior.

3. Définir le contrat orienté implémentation

Produisez un plan de capacité de style SRS avec :

• résumé de la capacité
• non-objectifs explicites
• acteurs et surfaces
• états et transitions requis
• interfaces / entrées / sorties
• implications sur le modèle de données
• contraintes de sécurité / facturation / politique
• exigences d'observabilité et d'opérateur
• questions ouvertes bloquant l'implémentation

4. Traduire en exécution

Terminez par la remise exacte :

• prêt pour implémentation directe
• nécessite d'abord une revue d'architecture
• nécessite d'abord une clarification produit

Si utile, pointez vers la prochaine voie ECC native :

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

Format de sortie

Retournez le résultat dans cet ordre :

CAPACITÉ
- reformulation d'un paragraphe

CONTRAINTES
- règles fixes, invariants et limites

CONTRAT D'IMPLÉMENTATION
- acteurs
- surfaces
- états et transitions
- implications interface/données

NON-OBJECTIFS
- ce que cette voie ne possède explicitement pas

QUESTIONS OUVERTES
- bloqueurs ou décisions produit encore nécessaires

REMISE
- ce qui doit se passer ensuite et quelle voie ECC doit le prendre

Bons résultats

• L'intention produit est maintenant suffisamment concrète pour être implémentée sans redécouvrir des contraintes cachées en cours de PR.
• La revue d'ingénierie dispose d'un artefact durable au lieu de se fier à la mémoire ou au contexte Slack.
• Le plan résultant est réutilisable à travers Claude Code, Codex, Cursor, OpenCode et les surfaces de planification ECC 2.0.