O que Capacidade do Produto faz?
Esta skill transforma a intenção do produto em restrições explícitas de engenharia.
Use-a quando a lacuna não for "o que devemos construir?", mas "o que exatamente deve 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 nebulosas
- Engenheiros seniores continuam repetindo as mesmas suposições ocultas durante a revisão
- Você precisa de um artefato reutilizável que sobreviva a diferentes ambientes 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 existir ainda, crie um usando o template 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 a verdade do produto. Marque questões não resolvidas explicitamente.
- Separe as promessas visíveis ao usuário dos detalhes de implementação.
- Indique o que é política fixa, o que é preferência de arquitetura e o que ainda está aberto.
- Se a solicitação entrar em conflito com as restrições existentes do repositório, diga isso claramente, em vez de amenizar.
- Prefira um artefato de capacidade reutilizável a notas ad hoc espalhadas.
Entradas
Leia apenas o que for necessário:
- Intenção do Produto
- issue, discussão, PRD, nota de roadmap, mensagem do fundador
- Arquitetura Atual
- documentação relevante do repositório, 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 reversa, 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
- qual nova capacidade existirá após o lançamento
- qual resultado muda por causa disso
Se esta declaração for fraca, a implementação irá derivar.
2. Resolva as restrições da capacidade
Extraia as restrições que devem ser verdadeiras antes da implementação:
- regras de negócio
- limites de escopo
- invariantes
- fronteiras de confiança
- propriedade dos dados
- transições de ciclo de vida
- requisitos de rollout / migração
- expectativas de falha e recuperação
Estas são as coisas que geralmente vivem apenas na memória de engenheiros seniores.
3. Defina o contrato orientado a 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 bloqueando a implementação
4. Traduza para execução
Termine com a entrega exata:
- pronto para implementação direta
- precisa primeiro de revisão de arquitetura
- precisa primeiro de esclarecimento do produto
Se for útil, aponte para o próximo canal ECC nativo:
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 canal explicitamente não possui
QUESTÕES EM ABERTO
- bloqueadores ou decisões de produto ainda necessárias
ENTREGA
- o que deve acontecer a seguir e qual canal ECC deve assumir
Resultados Esperados
- A intenção do produto agora é concreta o suficiente para implementar sem redescobrir restrições ocultas durante o PR.
- A revisão de engenharia tem 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 ECC 2.0.