Lar

Skill

Produtividade e fluxo de trabalho

product-capability

affaan-m/ECC

Transforme a visão do produto, os PRDs ou as discussões sobre o roteiro em planos de recursos explícitos e prontos para implementação, incluindo restrições, invariantes, interfaces e questões em aberto, antes do início do trabalho envolvendo vários serviços.

...Expandir tudo

Tempo atualizado 12 de Outubro de 2026

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

Capacidade do produto

Essa competência transforma a intenção do produto em restrições de engenharia explícitas.

Use-a quando a dúvida não for “o que devemos construir?”, mas “o que exatamente precisa ser verdade antes do início da implementação?”.

Quando usar

Existe um PRD, um item do roteiro, uma discussão ou uma nota do fundador, mas as restrições de implementação ainda são implícitas
Um recurso abrange vários serviços, repositórios ou equipes e precisa de um contrato de capacidade antes da codificação
A intenção do produto está clara, mas as implicações de arquitetura, dados, ciclo de vida ou políticas ainda são vagas
Engenheiros seniores continuam reiterando as mesmas suposições ocultas durante a revisão
Você precisa de um artefato reutilizável que possa ser mantido entre os harnesses e as sessões

Artefato canônico

Se o repositório tiver um arquivo durável de contexto do produto, como PRODUCT.md, docs/product/ ou um diretório de especificações do programa, atualize-o nesse local.

Se ainda não houver um manifesto de capacidades, crie um usando o modelo disponível em:

docs/examples/product-capability-template.md

O objetivo não é criar outra pilha de planejamento. O objetivo é tornar as restrições ocultas de capacidade duráveis e reutilizáveis.

Regras inegociáveis

Não invente verdades sobre o produto. Indique explicitamente as questões não resolvidas.
Separe as promessas visíveis ao usuário dos detalhes de implementação.
Destaque o que é política fixa, o que é preferência de arquitetura e o que ainda está em aberto.
Se a solicitação entrar em conflito com restrições existentes no repositório, diga isso claramente, em vez de amenizar a situação.
Prefira um artefato de funcionalidade reutilizável em vez de notas ad hoc espalhadas.

Entradas

Leia apenas o que for necessário:

Intenção do produto
- tópico, discussão, PRD, nota do roteiro, mensagem do fundador
Arquitetura atual
- documentação relevante do repositório, contratos, esquemas, rotas, fluxos de trabalho existentes
Contexto de recursos existentes
- PRODUCT.md, documentos de design, RFCs, notas de migração, documentos do modelo operacional
Restrições de entrega
- autenticação, faturamento, conformidade, implantação, compatibilidade com versões anteriores, desempenho, política de revisão

Fluxo de trabalho principal

1. Reformule a funcionalidade

Resuma a solicitação em uma única afirmação precisa:

quem é o usuário ou operador
qual é a nova funcionalidade disponível após o lançamento
quais resultados serão alterados por causa disso

Se essa declaração for fraca, a implementação se desviará do objetivo.

2. Resolva as restrições de capacidade

Identifique as restrições que devem ser respeitadas antes da implementação:

regras de negócios
limites de escopo
invariantes
limites de confiança
propriedade dos dados
transições do ciclo de vida
requisitos de implementação/migração
expectativas de falha e recuperação

Esses são os aspectos que, muitas vezes, ficam restritos apenas à memória dos engenheiros sênior.

3. Definir o contrato voltado para a implementação

Elabore um plano de capacidades no estilo SRS com:

resumo de capacidades
não-objetivos explícitos
atores e interfaces
estados e transições necessários
interfaces / entradas / saídas
implicações no modelo de dados
restrições de segurança / faturamento / políticas
observabilidade e requisitos dos operadores
questões em aberto que impedem a implementação

4. Traduzir em ação

Concluir com a transferência exata:

pronto para implementação direta
precisa de uma revisão da arquitetura primeiro
precisa de esclarecimento sobre o produto primeiro

Se for útil, indique a próxima etapa nativa do ECC:

fluxo-de-projeto-ops
auditoria-da-superfície-da-área-de-trabalho
construtor-de-conectores-de-API
criador-de-painéis
fluxo-de-trabalho-tdd
ciclo-de-verificação

Formato de saída

Retorne o resultado nesta ordem:

CAPACIDADE
- reformulação em um parágrafo

RESTRIÇÕES
- regras fixas, invariantes e limites

CONTRATO DE IMPLEMENTAÇÃO
- atores
- superfícies
- estados e transições
- implicações de interface/dados

NÃO OBJETIVOS
- o que esta linha de trabalho explicitamente não abrange

QUESTÕES EM ABERTO
- obstáculos ou decisões sobre o produto ainda necessárias

TRANSFERÊNCIA
- o que deve acontecer a seguir e qual linha de trabalho do ECC deve assumir a tarefa

Resultados positivos

A intenção do produto agora é concreta o suficiente para ser implementada sem redescobrir restrições ocultas no meio do PR.
A revisão de engenharia conta com um artefato duradouro, em vez de depender da memória ou do contexto do Slack.
O plano resultante é reutilizável nas superfícies de planejamento do Claude Code, Codex, Cursor, OpenCode e ECC 2.0.

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