Capacidad de Producto

¿Qué hace Capacidad de Producto?

Este skill convierte la intención del producto en restricciones de ingeniería explícitas.

Úsalo cuando la brecha no es "¿qué deberíamos construir?" sino "¿qué exactamente debe ser verdad antes de que comience la implementación?"

Cuándo Usarlo

• Existe un PRD, elemento de roadmap, discusión o nota de fundador, pero las restricciones de implementación aún son implícitas
• Una funcionalidad cruza múltiples servicios, repositorios o equipos y necesita un contrato de capacidad antes de codificar
• La intención del producto es clara, pero las implicaciones de arquitectura, datos, ciclo de vida o políticas aún son difusas
• Ingenieros senior siguen repitiendo las mismas suposiciones ocultas durante las revisiones
• Necesitas un artefacto reutilizable que pueda sobrevivir a través de entornos y sesiones

Artefacto Canónico

Si el repositorio tiene un archivo duradero de contexto de producto como PRODUCT.md, docs/product/, o un directorio de especificación del programa, actualízalo allí.

Si aún no existe un manifiesto de capacidad, crea uno usando la plantilla en:

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

El objetivo no es crear otra pila de planificación. El objetivo es hacer que las restricciones de capacidad ocultas sean duraderas y reutilizables.

Reglas No Negociables

• No inventes verdad de producto. Marca explícitamente las preguntas no resueltas.
• Separa las promesas visibles para el usuario de los detalles de implementación.
• Señala qué es política fija, qué es preferencia de arquitectura y qué sigue abierto.
• Si la solicitud entra en conflicto con las restricciones existentes del repositorio, dímelo claramente en lugar de suavizarlo.
• Prefiere un artefacto de capacidad reutilizable sobre notas ad hoc dispersas.

Entradas

Lee solo lo que sea necesario:

1. Intención del producto
   • issue, discusión, PRD, nota de roadmap, mensaje de fundador
2. Arquitectura actual
   • documentos del repositorio relevantes, contratos, esquemas, rutas, flujos de trabajo existentes
3. Contexto de capacidad existente
   • PRODUCT.md, documentos de diseño, RFCs, notas de migración, documentos de modelo operativo
4. Restricciones de entrega
   • autenticación, facturación, cumplimiento, despliegue, retrocompatibilidad, rendimiento, política de revisión

Flujo de Trabajo Principal

1. Reformular la capacidad

Comprime la solicitud en una declaración precisa:

• quién es el usuario u operador
• qué nueva capacidad existe después de que esto se lance
• qué resultado cambia debido a ello

Si esta declaración es débil, la implementación se desviará.

2. Resolver las restricciones de capacidad

Extrae las restricciones que deben cumplirse antes de la implementación:

• reglas de negocio
• límites del alcance
• invariantes
• límites de confianza
• propiedad de datos
• transiciones de ciclo de vida
• requisitos de despliegue / migración
• expectativas de fallo y recuperación

Estas son las cosas que a menudo viven solo en la memoria de los ingenieros senior.

3. Definir el contrato orientado a la implementación

Produce un plan de capacidad estilo SRS con:

• resumen de capacidad
• no-objetivos explícitos
• actores y superficies
• estados y transiciones requeridos
• interfaces / entradas / salidas
• implicaciones del modelo de datos
• restricciones de seguridad / facturación / políticas
• requisitos de observabilidad y operador
• preguntas abiertas que bloquean la implementación

4. Traducir a ejecución

Termina con el handoff exacto:

• listo para implementación directa
• necesita revisión de arquitectura primero
• necesita aclaración de producto primero

Si es útil, señala el siguiente carril nativo de ECC:

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

Formato de Salida

Devuelve el resultado en este orden:

CAPACIDAD
- reformulación de un párrafo

RESTRICCIONES
- reglas fijas, invariantes y límites

CONTRATO DE IMPLEMENTACIÓN
- actores
- superficies
- estados y transiciones
- implicaciones de interfaz/datos

NO-OBJETIVOS
- lo que este carril explícitamente no posee

PREGUNTAS ABIERTAS
- bloqueos o decisiones de producto aún requeridas

HANDOFF
- qué debería suceder después y qué carril de ECC debería tomarlo

Buenos Resultados

• La intención del producto ahora es lo suficientemente concreta para implementar sin redescubrir restricciones ocultas a mitad de un PR.
• La revisión de ingeniería tiene un artefacto duradero en lugar de depender de la memoria o el contexto de Slack.
• El plan resultante es reutilizable en Claude Code, Codex, Cursor, OpenCode y las superficies de planificación de ECC 2.0.