product-capability

Capacité Produit

Ce skill transforme l'intention produit en contraintes d'ingénierie explicites.

Utilisez-le lorsque le fossé n'est pas "que devrions-nous construire ?" mais "que doit être exactement vrai avant que l'implémentation commence ?"

Quand l'utiliser

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

Artefact Canonique

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

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

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

Le but n'est pas de créer une autre pile de planification. Le but est de rendre les contraintes de capacité cachées 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.
• Signalez ce qui est une politique fixe, ce qui est une préférence architecturale 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 le problème.
• Préférez un artefact de capacité réutilisable plutôt que des notes ad hoc dispersées.

Entrées

Lisez uniquement ce qui est nécessaire :

1. Intention produit
   • ticket, discussion, PRD, note de roadmap, message de fondateur
2. Architecture actuelle
   • documentation du dépôt, contrats, schémas, routes, workflows existants
3. Contexte de capacité existant
   • PRODUCT.md, documents de conception, RFCs, notes de migration, documents de modèle opérationnel
4. Contraintes de livraison
   • authentification, 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 grâce à elle

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

2. Résoudre les contraintes de capacité

Extrayez les contraintes qui doivent être vraies avant l'implémentation :

• règles métier
• limites de périmètre
• invariants
• limites 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 seniors.

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

Produisez un plan de capacité de type 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 avec le transfert exact :

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

Si utile, indiquez 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 d'interface / données

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

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

TRANSFERT
- ce qui devrait se passer ensuite et quelle voie ECC devrait le prendre

Résultats Attendus

• 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 sur les surfaces de planification Claude Code, Codex, Cursor, OpenCode et ECC 2.0.