think

Visão geral do skill think

O que o skill think faz

think é um skill de apoio à decisão para transformar uma ideia vaga em um plano claro e aprovado antes que alguém escreva código. Ele é ideal para definição de funcionalidades, escolhas de arquitetura, análise de trade-offs e perguntas do tipo “vale a pena fazer isso?”, em que a necessidade principal é julgamento, não implementação.

Quem deve instalar

Instale o skill think se você costuma precisar de ajuda com decisões de produto, direção técnica ou planejamento com escopo definido em um fluxo de trabalho repo-first. Ele é especialmente útil quando um pedido começa com “planeje isso”, “qual é a melhor abordagem?”, “devemos manter isso?” ou outras perguntas baseadas em julgamento de valor.

O que o torna diferente

O skill é opinativo: ele puxa para uma recomendação concreta, explicita quais evidências poderiam mudar essa recomendação e evita partir cedo demais para o código. Isso faz think for Decision Support ser mais forte do que um prompt genérico de brainstorming quando você precisa de uma saída pronta para decisão.

Como usar o skill think

Instale e acione

Instale com npx skills add tw93/Waza --skill think. Depois, use-o quando a tarefa for escolher, moldar ou validar uma direção, e não corrigir um defeito já conhecido. A etapa think install é simples, mas a qualidade depende de você fornecer um contexto real de decisão.

Dê a forma certa de entrada

Um bom prompt de think usage deve incluir o objetivo, as restrições, o público e qual decisão está realmente em aberto. Por exemplo: “Precisamos de um fluxo de onboarding mais rápido para admins de SMB; só podemos mexer na UI, não dá para adicionar trabalho de backend neste sprint, e precisamos de uma recomendação com trade-offs.”

Leia o arquivo certo primeiro

Comece por SKILL.md, já que o repositório é intencionalmente minimalista e não há pastas de suporte como rules/, references/ ou resources/. A orientação prática principal vem do próprio corpo do skill: modo leve, modo de avaliação e a regra de não entrar em implementação antes da aprovação.

Use o fluxo como um funil de decisão

Um bom fluxo de think guide é: declarar a decisão, listar as restrições, pedir o melhor caminho e, só se necessário, solicitar um plano com riscos e alternativas. Se você não tiver certeza entre usar o modo leve ou o modo completo, descreva se o problema já está bem definido; esse único detalhe muda bastante a saída.

FAQ do skill think

O think é só para recursos novos?

Não. Ele também é útil para decisões de arquitetura, julgamentos de valor de produto, refactors com trade-offs reais e perguntas do tipo “isso vale a pena?”. Não é a melhor opção para correções simples de bug ou ajustes pequenos em que a resposta já é óbvia.

Como isso é diferente de um prompt normal?

Um prompt normal часто produz opções vagas. O skill think foi desenhado para forçar uma decisão: um caminho recomendado, trade-offs explícitos e uma fronteira clara contra codificar antes da aprovação. Isso o torna melhor quando você precisa de um plano que possa ser revisado por alguém do time ou por uma parte interessada.

O think é amigável para iniciantes?

Sim, desde que a pessoa consiga descrever o objetivo em linguagem simples. Iniciantes aproveitam mais quando trazem o problema, as restrições e o resultado desejado, mesmo sem conhecer os termos técnicos.

Quando não devo usar o think?

Não use quando você já sabe a solução e só precisa executar, ou quando a tarefa é tão pequena que editar diretamente é mais rápido do que analisar. Ele também agrega menos quando não existe uma decisão real a tomar e você só precisa de uma reescrita rápida.

Como melhorar o skill think

Forneça contexto no nível de uma decisão

As melhores entradas para o think skill incluem o estado atual, o estado desejado, as restrições inegociáveis e como é o sucesso. Por exemplo, “Precisamos reduzir o tempo de configuração de 10 minutos para 2 minutos, manter o backend atual e evitar novas dependências” gera uma orientação melhor do que “melhore o onboarding”.

Peça a decisão, não só ideias

Se você quer um think usage melhor, peça uma recomendação com justificativa, e não uma lista de possibilidades. Bom: “Escolha uma abordagem e explique por que ela vence sob estas restrições.” Fraco: “Me dê algumas ideias.”

Deixe explícitos os trade-offs que importam

Diga ao skill o que pesa mais: velocidade, manutenção, custo, UX, risco ou capacidade do time. Isso ajuda think for Decision Support a produzir um plano alinhado às suas prioridades, em vez de uma resposta genérica de boas práticas.

Itere com restrições mais afiadas

Se o primeiro resultado vier amplo demais, afine com um único follow-up: adicione um prazo, uma dependência proibida, um usuário-alvo ou um componente que não pode ser removido. A forma mais rápida de melhorar a saída é transformar suposições ocultas em restrições explícitas antes de pedir o próximo plano.