GoCodeAlone/claude-superpowers

Transformando Ideias em Projetos

Visão Geral

Ajude a transformar ideias em designs e especificações totalmente formados por meio de um diálogo colaborativo natural.

Comece entendendo o contexto atual do projeto, depois faça perguntas usando agrupamento adaptativo para refinar a ideia. Uma vez que você entende o que está construindo, apresente o design e obtenha a aprovação do usuário.

Anti-Padrão: "Isso é Simples Demais para Precisar de um Design"

Todo projeto passa por esse processo. Uma lista de tarefas, um utilitário de função única, uma alteração de configuração — todos eles. Projetos "simples" são onde suposições não examinadas causam a maior quantidade de trabalho desperdiçado. O design pode ser curto (algumas frases para projetos verdadeiramente simples), mas você DEVE apresentá-lo e obter aprovação.

Lista de Verificação

Você DEVE criar uma tarefa para cada um destes itens e concluí-los em ordem:

1. Explorar o contexto do projeto — verificar arquivos, documentos, commits recentes
2. Fazer perguntas esclarecedoras — agrupamento adaptativo: agrupe perguntas relacionadas para reduzir idas e voltas; use perguntas únicas direcionadas para acompanhamentos
3. Propor 2-3 abordagens — com compensações e sua recomendação
4. Apresentar o design — em seções dimensionadas de acordo com sua complexidade, obtenha a aprovação do usuário após cada seção
5. Escrever o documento de design — salvar em docs/plans/YYYY-MM-DD-<topic>-design.md e fazer commit
6. Transição para implementação — invocar o skill writing-plans para criar o plano de implementação

Fluxo do Processo

digraph brainstorming {
    "Explorar o contexto do projeto" [shape=box];
    "Fazer perguntas esclarecedoras" [shape=box];
    "Propor 2-3 abordagens" [shape=box];
    "Apresentar seções do design" [shape=box];
    "Usuário aprova o design?" [shape=diamond];
    "Escrever documento de design" [shape=box];
    "Invocar skill writing-plans" [shape=doublecircle];

    "Explorar o contexto do projeto" -> "Fazer perguntas esclarecedoras";
    "Fazer perguntas esclarecedoras" -> "Propor 2-3 abordagens";
    "Propor 2-3 abordagens" -> "Apresentar seções do design";
    "Apresentar seções do design" -> "Usuário aprova o design?";
    "Usuário aprova o design?" -> "Apresentar seções do design" [label="não, revisar"];
    "Usuário aprova o design?" -> "Escrever documento de design" [label="sim"];
    "Escrever documento de design" -> "Invocar skill writing-plans";
}

O estado terminal é invocar o writing-plans. NÃO invoque frontend-design, mcp-builder ou qualquer outro skill de implementação. O ÚNICO skill que você invoca após o brainstorming é o writing-plans.

O Processo

Entendendo a ideia:

• Verifique primeiro o estado atual do projeto (arquivos, documentos, commits recentes)

• Faça perguntas usando agrupamento adaptativo — agrupe perguntas relacionadas para reduzir idas e voltas:

  • Primeiro lote: cobre propósito, restrições, escopo e escolhas técnicas
  • Acompanhamentos: Perguntas únicas direcionadas com base em respostas interessantes ou ambíguas

  <host: claude-code>

  • Use opções de múltipla escolha quando possível (AskUserQuestion suporta 2-4 opções por pergunta)
  • AskUserQuestion suporta até 4 perguntas por formulário — use isso para reduzir idas e voltas

  <host: codex, opencode, cursor>

  • Apresente opções como uma lista numerada e peça ao usuário para responder com o número escolhido
  • Agrupe no máximo 3 perguntas por vez para evitar sobrecarregar o chat

• Foco em entender: propósito, restrições, critérios de sucesso

Explorando abordagens:

• Proponha 2-3 abordagens diferentes com compensações
• Apresente opções de forma conversacional com sua recomendação e justificativa
• Lidere com sua opção recomendada e explique por quê

Apresentando o design:

• Assim que você acreditar que entende o que está construindo, apresente o design
• Dimensione cada seção de acordo com sua complexidade: algumas frases se for direto, até 200-300 palavras se for matizado
• Pergunte após cada seção se está correto até agora
• Cubra: arquitetura, componentes, fluxo de dados, tratamento de erros, testes
• Esteja pronto para voltar e esclarecer se algo não fizer sentido

Modo Apenas Design

Quando o usuário deseja exploração de design sem execução, ele passa --design-only para o brainstorming.

Comportamento sob --design-only:

1. Execute o fluxo completo de brainstorming (explorar contexto → perguntas → abordagens → design → escrever documento de design → commit).
2. Ao invocar o writing-plans, propague a flag --design-only.
3. O writing-plans honra a flag: verificação de alinhamento PASSOU → PARE (nenhuma execução despachada). Em falha de alinhamento, o writing-plans revisa e verifica novamente de acordo com seu tratamento normal de falha, então para — ainda sem execução despachada. Em falha persistente (após no máximo 2 ciclos de revisão), escalona para o usuário com um resumo de desvio não resolvido — nenhuma execução despachada independentemente.
4. O pipeline termina com um documento de design + plano em docs/plans/.

Padrão (sem flag): brainstorming → writing-plans → verificação de alinhamento -> desenvolvimento orientado por subagente -> … (handoff autônomo para execução).

Após o Design

Documentação:

• Escreva o design validado em docs/plans/YYYY-MM-DD-<topic>-design.md
• Use o skill elements-of-style:writing-clearly-and-concisely se disponível
• Faça commit do documento de design no git

Handoff autônomo:

• Este é o último ponto de interação do usuário — tudo depois disso roda de forma autônoma
• Invoque o skill writing-plans com contexto autônomo: o design está aprovado, nenhuma entrada adicional do usuário é necessária
• O skill writing-plans preferirá o Modo de Plano do Claude se disponível (Claude Code), recorrendo ao seu processo de planejamento interno em outros ambientes
• O pipeline a partir daqui: writing-plans → verificação de alinhamento → execução da equipe → criação de PR → monitoramento de PR
• NÃO invoque nenhum outro skill. O writing-plans é o próximo passo. Ele lida com o restante do pipeline autônomo.

Princípios Chave

• Agrupamento adaptativo de perguntas - Agrupe perguntas relacionadas para reduzir idas e voltas; use perguntas únicas direcionadas para acompanhamentos
• Múltipla escolha preferida - Mais fácil de responder do que perguntas abertas quando possível
• YAGNI impiedosamente - Remova funcionalidades desnecessárias de todos os designs
• Explore alternativas - Sempre proponha 2-3 abordagens antes de decidir
• Validação incremental - Apresente o design, obtenha aprovação antes de prosseguir
• Seja flexível - Volte e esclareça quando algo não fizer sentido
• Aprovação do design = handoff de autonomia - Após a aprovação do design, o pipeline roda sem entrada do usuário