Workflow Recomendado

As seções anteriores foram sobre instalar e configurar ferramenta. Esta é sobre o que fazer com ela: o fluxo de trabalho que leva um projeto do começo ao fim — onde fica o escopo, como uma demanda começa, o que muda conforme o tamanho dela, como ela termina e como você encerra a sessão.

Um processo existe para aumentar a chance de chegar ao resultado desejado de forma consistente. Ele pega uma atividade que depende de talento e de improviso e transforma em algo repetível, previsível e passível de melhoria.

Este é o fluxo que eu uso, e ele tem um alvo declarado: sites e aplicativos web de pequeno a médio porte, MVPs, construídos 100% por agentes de IA, por um fundador trabalhando sozinho. Se o alvo fosse sistema corporativo grande, com equipe numerosa e construção mista entre agentes e programadores humanos, a recomendação seria outra, ou pelo menos sofreria ajustes.

#Por que o Claude Code não traz um processo pronto

O fluxo precisa ser construído por você. O Claude Code entrega mecanismo e não entrega método, e isso é escolha de projeto, não lacuna:

1. Ele é um primitivo, não um framework. É ferramenta de baixo nível e componível. Embutir processo limitaria o que dá para construir em cima.
2. Não existe processo que sirva para todos. Legado e greenfield, script e sistema distribuído, desenvolvedor solo e time com compliance. Escolher um seria errar para a maioria.
3. O terreno ainda está se movendo. As boas práticas de desenvolvimento com IA estão sendo descobertas agora. A comunidade itera em dias; um produto, em meses.
4. Mecanismo, não política. A Anthropic entrega hooks, subagents, skills, plugins, MCP e CLAUDE.md; a política — o processo — fica com você. É por isso que Superpowers e Spec Kit conseguem existir.
5. Processo embutido envelhece mal. A cerimônia necessária hoje vira desperdício quando o modelo melhora. Em camada externa, isso se descarta sem custo.

Uma ressalva: não é um vazio de processo. O Claude Code tem micro-processos — modo de planejamento, lista de tarefas, exploração antes de editar, CLAUDE.md. O que falta é o ciclo de vida completo: requisito, spec, design, implementação e verificação, com artefato e ponto de parada entre as fases. É essa lacuna que os frameworks da comunidade preenchem.

O custo de não preencher é direto: sem o ciclo, o resultado depende da habilidade de quem opera — que é o oposto de repetível, previsível e melhorável.

#Por que Superpowers, e por que ele não basta sozinho

Entre os frameworks da comunidade, o Superpowers é o que melhor atende esse alvo. É também o mais estrelado da categoria no GitHub hoje, com folga sobre o segundo colocado.

Três características explicam a escolha, e as três são sobre acoplamento baixo:

• É um conjunto de skills, não um sistema. Não tem CLI própria, não guarda estado, não exige arquivo de configuração e não impõe estrutura de diretório além de onde grava a spec e o plano. Cada skill funciona sozinha: dá para usar só o brainstorming numa demanda e só o systematic-debugging noutra, sem adotar o resto. A única coisa que ele instala além das skills é um hook de início de sessão, que injeta as instruções de uso a cada abertura, /clear ou /compact — e que não escreve nada no seu projeto.
• A instalação segue o padrão do próprio agente. No Claude Code ele entra como plugin, pelo mecanismo de marketplace que já existe. Não há runtime paralelo para manter.
• Sair custa o mesmo que entrar. Como não há estado nem amarração, desinstalar devolve o projeto ao que ele era. Num terreno que muda rápido isso pesa: quanto menos preso a um fluxo engessado, mais rápido você adapta o seu quando a ferramenta mudar.

Mas ele cobre uma implementação, não o projeto inteiro. Pense num aplicativo web que precisa de várias funcionalidades: as páginas públicas, o cadastro de usuários, o cadastro de serviços. O Superpowers dá conta de construir uma delas — o cadastro de usuários, digamos — do brainstorming à verificação. O que ele não faz é gerenciar a relação entre todas: a ordem, o que já foi entregue, o que continua em aberto, o que mudou de escopo no caminho.

Se o aplicativo for bem pequeno, dá para tratar as etapas como uma só e construir o todo numa rodada. Mas esse não é o caso da maioria dos projetos.

Outros frameworks cobrem essa camada de cima. O Spec Kit, do GitHub, é o exemplo mais conhecido. O preço é burocracia: mais documentos, mais fases e mais planejamento antes de escrever a primeira linha. Para o alvo desta seção, isso custa mais do que entrega.

A decisão foi então ter um fluxo simples, apoiado na combinação de duas coisas: as ferramentas nativas do Claude Code para gerenciar o projeto como um todo, e o Superpowers para a implementação de cada demanda grande. É esse fluxo que as seções seguintes descrevem.

#As três camadas de registro

Nem toda conversa com o agente precisa virar arquivo. Perguntar como uma coisa funciona, pesar duas alternativas, pedir que ele explique um trecho de código: isso se resolve na conversa e morre ali, sem prejuízo nenhum.

O que precisa ficar escrito é o que a próxima sessão vai precisar saber. E isso tem dois destinatários.

O primeiro é você. Planejamento aumenta a chance de acertar em qualquer projeto, com IA ou sem: saber o que já foi entregue, o que continua em aberto, e por que o código ficou do jeito que ficou.

O segundo é o agente, e essa parte é específica de trabalhar assim. Ele começa cada sessão sem a conversa da anterior. O que estiver escrito é o que ele tem; o que não estiver, para ele não existe. O registro deixa então de ser documentação sobre o trabalho e passa a ser insumo do trabalho — é ele que permite o agente construir o que você quer, em vez de uma aproximação do que ele conseguiu inferir. Quando falta, isso aparece como você reexplicando a mesma coisa toda semana, e de vez em quando como o agente desfazendo algo que a sessão anterior tinha feito de propósito.

Isso é o que precisa ficar registrado. Quando isso acontece é outra coisa: uma demanda pode começar sem arquivo nenhum — a partir de uma linha no checklist do PRD ou de uma ideia que você teve agora — e só virar registro no fechamento. O que ela não pode é terminar sem deixar nada escrito.

Esse registro se organiza em três camadas: