Entra em modo de maturação de ideias — pesquisa, analisa criticamente, aponta trade-offs e sugere melhorias sem criar ou executar nada até o usuário solicitar explicitamente. Usar quando o usuário quiser explorar, discutir ou refinar uma ideia antes de implementá-la. Ativado por frases como "quero criar", "tenho uma ideia", "pensa comigo", "me ajuda a planejar", "vamos fazer um brainstorm", "entra em modo brainstorm", ou qualquer ideia de produto, feature, sistema, skill ou fluxo ainda não especificada o suficiente para implementação. Tem uma lente especializada para especificação de projeto de desenvolvimento — ative também quando o usuário quiser "especificar um projeto", "levantar os requisitos", "montar a spec antes de codar", "definir a arquitetura antes de começar", ou descrever um sistema que pretende construir. Também ativa quando o usuário pedir para documentar, resumir ou preservar em markdown um brainstorm já em andamento ou recém-concluído, independentemente do tema (sistema, processo, email, idei
Escreve PRDs (Product Requirements Documents) — cria novos ou edita existentes que ainda não foram concluídos. Funciona no modo draft-first: gera o documento completo imediatamente a partir do que o usuário fornecer, marcando premissas inferidas inline para revisão pontual — sem entrevistas longas. Quando o input cobre múltiplas features, detecta automaticamente e propõe divisão em PRDs separados, criando-os em sequência na mesma sessão. Cada PRD é autocontido e foca em comportamento e regras de negócio; detalhes técnicos ficam em TRD/ADR. Use quando o usuário quiser criar ou editar um PRD, documento de requisitos, especificação de feature, planejar uma funcionalidade, definir escopo de uma entrega, documentar requisitos, ou avaliar a quebra/granularidade de um PRD — mesmo que não use o termo "PRD" explicitamente. Também quando mencionar "requisitos do produto", "spec de feature", "escopo da feature", "documento de requisitos", "refinar PRD", "ajustar PRD", "quebra de PRD", "granularidade de PRD", ou fornecer
Escreve manifestos Kubernetes no padrão da operação, seguindo seis regras inegociáveis: requests e limits sempre declarados, liveness e readiness separadas com propósitos diferentes, variáveis de ambiente sempre via ConfigMap ou Secret, imagem sempre com tag fixada, Service coerente com a exposição pretendida, e labels e namespace no padrão do time. Use sempre que o usuário disser "cria o deployment", "escreve o manifesto", "monta o service", "preciso subir isso no Kubernetes", "cria o YAML do k8s", "coloca essa aplicação no cluster", "cria o configmap", "revisa esses manifestos", ou apontar arquivos YAML de Kubernetes querendo criá-los ou mudá-los. Ative também quando o pedido parecer pequeno — "só um deployment rapidinho", "só ajusta a porta do service" — porque é exatamente no manifesto avulso que o recurso não declarado e a tag latest entram; e quando for revisar manifesto que já existe no projeto. NÃO acione para: Dockerfile, docker-compose e build de imagem (isso é containerizar-aplicacao), Terraform e
Escreve e organiza Terraform seguindo quatro regras estruturais inegociáveis: tudo em módulos próprios pensados para reaproveitamento, ambientes separados em pastas (nunca em workspace), zero módulos de comunidade, e versão de provider sempre consultada no registry antes de ser escrita. Use sempre que o usuário disser "escreve o terraform", "cria a infra como código", "provisiona isso com terraform", "monta a estrutura do projeto terraform", "organiza esse terraform", "revisa meu terraform", "cria o módulo", "adiciona um ambiente novo", ou apontar um repositório com arquivos .tf querendo criar ou mudar infraestrutura. Ative também quando for apenas criar ou editar um único arquivo .tf — a estrutura errada nasce justamente do "só um main.tf rapidinho" — e quando o pedido mencionar um módulo de comunidade (terraform-aws-modules, Azure/, terraform-google-modules), porque nesse caso o certo é escrever o módulo próprio equivalente. Vale para qualquer cloud ou provider. NÃO acione para: manifestos Kubernetes/Helm p
Coloca uma aplicação em container Docker de ponta a ponta: investiga o repositório para derivar o contrato de containerização (porta, variáveis de ambiente e seus defaults, serviços de dependência, caminhos relativos ao CWD), gera Dockerfile, .dockerignore e compose, builda, sobe a stack e valida que a aplicação realmente funciona dentro do container. Use sempre que o usuário disser "coloca essa aplicação em container", "conteineriza esse projeto", "cria o Dockerfile", "preciso rodar isso no Docker", "monta o docker-compose", "sobe esse projeto com os serviços dele", ou apontar um repositório querendo executá-lo em container. Ative mesmo quando o pedido parecer parcial — quem pede só o Dockerfile precisa que ele funcione, e isso inclui descobrir os serviços de dependência e provar o comportamento depois de subir. Ative também para revisar, corrigir ou otimizar artefatos Docker que já existem no projeto. NÃO acione para: manifestos Kubernetes (Deployment, Service, Helm), pipelines de CI/CD, publicação de image
Gera a mensagem de commit no padrão conventional commits a partir do diff em stage. Use ao pedir para commitar ou criar mensagem de commit.