Antes de Construir

Visão Geral

O "Antes de Construir" (Before You Build) ajuda um fluxo de trabalho de codificação de IA a pausar antes da implementação e verificar se o recurso, produto ou ferramenta vale a pena ser construído. Ele foca no risco do produto em vez da estrutura do código: quem precisa da coisa, o que usam hoje, por que mudariam, como a distribuição funciona e que evidências tornariam o projeto mais seguro para começar.

O projeto upstream fornece um repositório de habilidades autônomo e um instalador npx para vários assistentes de codificação.

Quando Usar Esta Habilidade

• Use quando um usuário pede a um assistente de codificação de IA para criar um novo aplicativo, recurso, ferramenta interna, SaaS ou projeto paralelo.
• Use quando a ideia parece plausível, mas o comprador, o fluxo de trabalho, o caminho de distribuição ou o motivo da mudança ainda são vagos.
• Use antes de escrever código para que o assistente possa transformar a solicitação em suposições mais claras, verificações de risco e etapas de validação.

Como Funciona

Etapa 1: Identificar a Aposta de Construção

Reformule o produto ou recurso em uma frase concreta. Nomeie o usuário pretendido, a tarefa que ele está tentando concluir e a solução alternativa ou concorrente atual.

Etapa 2: Verificar os Principais Riscos

Revise a ideia em termos de demanda, adequação ao fluxo de trabalho, disposição para mudar, distribuição, precificação, acesso a dados e carga operacional. Prefira dúvidas específicas em vez de brainstorming genérico.

Etapa 3: Decidir o Próximo Pequeno Teste

Sugira a menor etapa de validação útil antes da implementação. Isso pode ser uma conversa com o comprador, teste de página de destino, fluxo de trabalho manual de concierge, protótipo, lista de espera, piloto pago ou teste interno restrito.

Etapa 4: Continuar ou Parar

Se o risco for aceitável, prossiga para a implementação com as suposições registradas. Se o risco for alto ou a evidência for fraca, recomende um experimento menor em vez de construir a versão completa.

Exemplos

Exemplo 1: Solicitação de Recurso SaaS

User: Build a dashboard for AI trend monitoring.

Before coding, check:
- Which role needs this dashboard every week?
- What source do they use today?
- What decision changes because of the dashboard?
- Would they pay for alerts, reports, or workflow integration?
- What is the smallest manual report that proves repeat use?

Exemplo 2: Ferramenta Interna

User: Build an internal CRM for our small team.

Before coding, check:
- What breaks in the current spreadsheet or existing CRM?
- How many people will use it daily?
- What data must be imported or kept in sync?
- What process change is required after launch?
- Can a no-code workflow prove the need first?

Melhores Práticas

• ✅ Peça o usuário, a tarefa, a alternativa atual e o motivo da mudança antes da implementação.
• ✅ Separe o risco do produto do risco de engenharia para que a equipe não resolva o problema errado de forma eficiente.
• ✅ Recomende pequenas etapas de validação quando a ideia tiver pouca evidência de demanda.
• ✅ Mantenha nomes de produtos, números e declarações alinhados com o que o usuário fornece.
• ❌ Não apresente uma lista de verificação genérica como prova de que uma ideia foi validada.
• ❌ Não invente tamanho de mercado, receita, tração de concorrentes ou citações de compradores.

Limitações

• Esta habilidade não substitui pesquisa de cliente, revisão jurídica, aconselhamento financeiro ou revisão por especialista no assunto.
• Ela não pode provar a demanda por si só; ajuda o assistente a expor suposições e escolher uma etapa de validação menor.
• Se o usuário já tiver evidências fortes e uma especificação clara, mantenha a revisão curta e prossiga para a implementação.

Notas de Segurança e Proteção

• Esta habilidade é segura para ser executada como uma camada de planejamento, pois não requer credenciais, acesso à rede externa ou modificação de arquivos.
• Se emparelhada com um instalador ou busca de repositório, instale apenas do repositório upstream ou pacote npm em que você confia.

Armadilhas Comuns

• Problema: O assistente repete o discurso do produto em vez de desafiar as suposições. Solução: Peça alternativas atuais, gatilhos de mudança e uma etapa de validação antes do código.

• Problema: A revisão se torna muito ampla e bloqueia o progresso. Solução: Escolha a suposição mais arriscada e teste apenas essa primeiro.

• Problema: A ideia é tratada como uma startup, mesmo quando é um pequeno fluxo de trabalho interno. Solução: Ajuste a revisão de risco ao tamanho do projeto e faça apenas perguntas que alterem a decisão de construção.

Habilidades Relacionadas

• @saas-mvp-launcher - Use ao passar da validação para o planejamento do MVP e a execução do lançamento.
• @ux-research-methodology - Use quando a próxima etapa precisar de pesquisa estruturada do usuário.