O que Capacidade de Produto faz?
Esta skill transforma a intenção do produto em restrições explícitas de engenharia.
Use quando a lacuna não é "o que devemos construir?" mas "o que exatamente precisa ser verdade antes da implementação começar?"
Quando Usar
- Um PRD, item de roadmap, discussão ou nota do fundador existe, mas as restrições de implementação ainda estão implícitas
- Uma funcionalidade cruza múltiplos 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 difusas
- Engenheiros seniores continuam repetindo as mesmas suposições ocultas durante a revisão
- Você precisa de um artefato reutilizável que sobreviva entre harnesses e sessões
Artefato Canônico
Se o repositório possui um arquivo de contexto de produto durável, como PRODUCT.md, docs/product/ ou um diretório de especificação de programa, atualize-o lá.
Se nenhum manifesto de capacidade existe ainda, crie um usando o template em:
docs/examples/product-capability-template.md
O objetivo não é criar outra camada de planejamento. O objetivo é tornar as restrições de capacidade ocultas duráveis e reutilizáveis.
Regras Inegociáveis
- Não invente a verdade do produto. Marque questões não resolvidas explicitamente.
- Separe 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 conflitar com as restrições existentes do repositório, diga claramente em vez de suavizar.
- Prefira um artefato de capacidade reutilizável a anotações ad hoc espalhadas.
Entradas
Leia apenas o necessário:
- Intenção do produto
- issue, discussão, PRD, nota de roadmap, mensagem do fundador
- Arquitetura atual
- documentos do repositório relevantes, contratos, esquemas, rotas, fluxos de trabalho existentes
- Contexto de capacidade existente
PRODUCT.md, documentos de design, RFCs, notas de migração, documentos de modelo operacional
- Restrições de entrega
- autenticação, faturamento, conformidade, rollout, compatibilidade retroativa, desempenho, política de revisão
Fluxo de Trabalho Principal
1. Reafirme a capacidade
Comprima a solicitação em uma declaração precisa:
- quem é o usuário ou operador
- que nova capacidade existe após esta entrega
- que resultado muda por causa dela
Se esta declaração for fraca, a implementação irá derivar.
2. Resolva as restrições de capacidade
Extraia as restrições que devem ser válidas antes da implementação:
- regras de negócio
- limites de escopo
- invariantes
- fronteiras de confiança
- propriedade de dados
- transições de ciclo de vida
- requisitos de rollout / migração
- expectativas de falha e recuperação
Estas são as coisas que muitas vezes vivem apenas na memória de engenheiros seniores.
3. Defina o contrato voltado para implementação
Produza um plano de capacidade no estilo SRS com:
- resumo da capacidade
- não-objetivos explícitos
- atores e superfícies
- estados e transições necessários
- interfaces / entradas / saídas
- implicações no modelo de dados
- restrições de segurança / faturamento / política
- requisitos de observabilidade e operador
- questões em aberto que bloqueiam a implementação
4. Traduza em execução
Termine com a entrega exata:
- pronta para implementação direta
- precisa de revisão de arquitetura primeiro
- precisa de esclarecimento de produto primeiro
Se útil, aponte para o próximo pipeline nativo da ECC:
project-flow-opsworkspace-surface-auditapi-connector-builderdashboard-buildertdd-workflowverification-loop
Formato de Saída
Retorne o resultado nesta ordem:
CAPACIDADE
- reafirmação de 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 este pipeline explicitamente não assume
QUESTÕES EM ABERTO
- bloqueadores ou decisões de produto ainda necessárias
ENTREGA
- o que deve acontecer a seguir e qual pipeline da ECC deve assumir
Resultados Positivos
- A intenção do produto agora é concreta o suficiente para implementar sem redescobrir restrições ocultas no meio de um PR.
- A revisão de engenharia possui um artefato durável em vez de depender de memória ou contexto do Slack.
- O plano resultante é reutilizável em Claude Code, Codex, Cursor, OpenCode e superfícies de planejamento da ECC 2.0.