Hogar

Skill

Productividad y flujo de trabajo

product-capability

affaan-m/ECC

Convertir los objetivos del producto, los documentos de requisitos de producto (PRD) o los debates sobre la hoja de ruta en planes de capacidades explícitos y listos para su implementación, que incluyan restricciones, invariantes, interfaces y cuestiones pendientes, antes de que comience el trabajo en el que participen varios servicios.

...Expandir todo

Tiempo actualizado 12 de octubre de 2026

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

Capacidades del producto

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

Úsala cuando la duda no sea «¿qué deberíamos construir?», sino «¿qué condiciones deben cumplirse exactamente antes de comenzar la implementación?».

Cuándo utilizarla

Existe un PRD, un elemento de la hoja de ruta, un debate o una nota del fundador, pero las restricciones de implementación siguen siendo implícitas
Una funcionalidad abarca varios servicios, repositorios o equipos y necesita un contrato de capacidades antes de la programación
La intención del producto está clara, pero las implicaciones en cuanto a arquitectura, datos, ciclo de vida o políticas siguen siendo confusas
Los ingenieros sénior siguen reiterando los mismos supuestos ocultos durante la revisión
Necesitas un artefacto reutilizable que perdure más allá de los entornos de prueba y las sesiones

Artefacto canónico

Si el repositorio cuenta con un archivo duradero de contexto del producto, como PRODUCT.md, docs/product/ o un directorio de especificaciones del programa, actualízalo allí.

Si aún no existe un manifiesto de capacidades, crea uno utilizando la plantilla que encontrarás en:

docs/examples/product-capability-template.md

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

Reglas no negociables

No inventes la «verdad del producto». Señala explícitamente las cuestiones sin resolver.
Separa las promesas visibles para el usuario de los detalles de implementación.
Señala qué es una política fija, qué es una preferencia de arquitectura y qué sigue abierto.
Si la solicitud entra en conflicto con las restricciones existentes del repositorio, dilo claramente en lugar de pasar por alto el tema.
Da preferencia a un único artefacto de funcionalidad reutilizable frente a notas dispersas y puntuales.

Aportaciones

Lee solo lo necesario:

Objetivo del producto
- incidencia, debate, PRD, nota de la hoja de ruta, mensaje del fundador
Arquitectura actual
- documentación relevante del repositorio, contratos, esquemas, rutas y flujos de trabajo existentes
Contexto de las capacidades existentes
- PRODUCT.md, documentos de diseño, RFC, notas de migración, documentos sobre el modelo operativo
Restricciones de entrega
- autenticación, facturación, cumplimiento normativo, implementación, compatibilidad con versiones anteriores, rendimiento, política de revisión

Flujo de trabajo principal

1. Reformular la funcionalidad

Resumir la solicitud en una afirmación precisa:

quién es el usuario u operador
qué nueva funcionalidad existirá una vez que se lance
qué resultados cambian gracias a ella

Si esta afirmación es débil, la implementación se desviará del objetivo.

2. Resolver las restricciones de funcionalidad

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

reglas de negocio
límites del ámbito
invariante
límites de confianza
propiedad de los datos
transiciones del ciclo de vida
Requisitos de implementación/migración
expectativas de fallo y recuperación

Estos son aspectos que, a menudo, solo permanecen en la memoria de los ingenieros sénior.

3. Definir el contrato orientado a la implementación

Elabora un plan de capacidades al estilo de un SRS que incluya:

un resumen de capacidades
objetivos no incluidos explícitos
actores e interfaces
estados y transiciones requeridos
interfaces / entradas / salidas
Implicaciones del modelo de datos
restricciones de seguridad, facturación y políticas
requisitos de observabilidad y de los operadores
cuestiones pendientes que impiden la implementación

4. Pasar a la fase de ejecución

Terminar con el traspaso exacto:

listo para su implementación directa
necesita una revisión de la arquitectura primero
necesita una aclaración sobre el producto primero

Si resulta útil, indica la siguiente vía propia de ECC:

project-flow-ops
auditoría-de-superficie-del-espacio-de-trabajo
creador-de-conectores-API
creador-de-cuadros-de-mandos
flujo-de-trabajo-tdd
bucle-de-verificación

Formato de salida

Devuelve el resultado en este orden:

CAPACIDAD
- reformulación en un párrafo

LIMITACIONES
- reglas fijas, invariantes y límites

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

NO OBJETIVOS
- lo que esta vía no abarca explícitamente

CUESTIONES ABIERTAS
- obstáculos o decisiones sobre el producto que aún son necesarias

TRANSFERENCIA
- qué debe suceder a continuación y qué vía del ECC debe hacerse cargo

Resultados positivos

La intención del producto es ahora lo suficientemente concreta como para implementarla sin tener que redescubrir restricciones ocultas a mitad de la solicitud de incorporación de cambios (PR).
La revisión de ingeniería cuenta con un artefacto duradero en lugar de depender de la memoria o del contexto de Slack.
El plan resultante es reutilizable en las plataformas de planificación de Claude Code, Codex, Cursor, OpenCode y ECC 2.0.

Ver en GitHub

---
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.