wgm

Visão Geral

wgm ("well, gosh... make") é uma metodologia de build portátil, não uma habilidade de domínio — um único SKILL.md protocolo que qualquer host compatível com agentskills.io carrega para transformar uma solicitação bruta em software funcional. Ele une três ideias: uma entrevista de alinhamento implacável antes que qualquer código seja escrito, um loop no estilo Ralph (uma tarefa por iteração, um plano persistente como estado compartilhado, guiado por contrapressão determinística) e julgamento de LLM em cenários de espera (cenários que o build nunca vê, para que uma pontuação de satisfação alta não possa ser manipulada). Ele também executa seu próprio loop interno de auditoria de documentação e autoaperfeiçoamento, cruzando lições duráveis de projetos irmãos de codificação de agentes de volta para seu próprio protocolo.

Quando Usar Esta Habilidade

• Use ao construir ou implementar um recurso, aplicativo ou protótipo a partir de uma intenção bruta ou ambígua.
• Use quando uma tarefa se beneficia de um plano governado mais execução iterativa e validada por testes, em vez de geração única.
• Use quando você deseja que um build convirja contra critérios de aceitação que um juiz LLM pontua às cegas (0-100), em vez de confiar em um único "parece bom" auto-relatado.
• Não para edições triviais de um único arquivo, depuração pura, perguntas apenas de pesquisa ou tarefas que já possuem instruções passo a passo completas e inequívocas — o wgm explicitamente fica fora do caminho nesses casos.

Como Funciona

Etapa 1: Triagem

Classifique o trabalho em uma trilha adaptável à escala (Rápida / Padrão / Completa) para que a cerimônia corresponda ao risco — uma correção de um arquivo pula cenários de espera e o enxame de auditoria de documentação; um aplicativo greenfield recebe o pacote completo. O portão de contrapressão determinística em si nunca é pulado, apenas a cerimônia em torno dele.

Etapa 2: Interrogar (alinhar)

Entreviste o usuário uma pergunta por vez, sempre com uma resposta recomendada, até que o objetivo, critérios de sucesso e restrições sejam conhecidos — limitando a interrogação após ~5 perguntas para evitar teatro. Explore a base de código para auto-responder antes de perguntar qualquer coisa em que um humano não precise opinar.

Etapa 3: Planejar

Produza uma constituição do projeto, uma especificação por fatia coerente (cada uma com um momento mágico e um caminho de demonstração), cenários de aceitação de espera que o build nunca deve ler, e IMPLEMENTATION_PLAN.md — o estado compartilhado persistente em todas as iterações posteriores. Verifique cada artefato contra todos os outros antes de prosseguir.

Etapa 4: Pré-voo

Pontue a prontidão do plano de 0 a 100 em clareza do objetivo, critérios de sucesso observáveis, cobertura de cenário e mapeamento de contrapressão. Abaixo do limite, retorne a Interrogar/Planejar e corrija a dimensão mais fraca — não comece a construir sobre um plano instável.

Etapa 5: Loop (construir)

Execute Analyze -> Implement -> Validate -> Review -> Record, uma tarefa por iteração: escolha a única tarefa pendente mais importante, faça a menor alteração que a complete, execute seu comando de validação determinístico (verde ou não está pronto), julgue a satisfação do cenário de espera, revise a diferença quanto a desvio de escopo, então registre o status e qualquer lição durável antes de avançar exatamente uma tarefa.

Etapa 6: Enviar / Entregar

Resuma o que foi enviado e como validá-lo, execute uma passagem obrigatória de auditoria de documentação com quatro personas (perspectivas júnior/sênior/principal/PM, consolidadas em um único relatório de trilha de papel) e colete qualquer lição durável e entre projetos de volta para o próprio livro-razão da habilidade compartilhada.

Exemplos

Exemplo 1: Ciclo de vida completo a partir de uma solicitação bruta

User: "Build a CLI todo app with add/list/complete commands, from scratch."

wgm declara sua Trilha (Padrão), interroga os ~3-5 desconhecidos que realmente importam, escreve especificações + IMPLEMENTATION_PLAN.md, pontua a prontidão do Pré-voo, então itera uma tarefa por vez — o comando de teste/lint/build de cada tarefa deve sair 0 antes de ser marcado como concluído — e finalmente envia com uma passagem de auditoria de documentação.

Exemplo 2: Apenas planejamento com escopo definido

User: "/wgm plan: add OAuth login to this existing Express API"

wgm escreve as especificações e o plano, então para abruptamente no portão de saída do Plano sem iniciar o loop de build — útil quando um humano quer revisar o plano antes que qualquer código seja tocado.

Melhores Práticas

• Permita que o plano seja o estado compartilhado — um agente novo deve ser capaz de retomar um build apenas a partir de IMPLEMENTATION_PLAN.md.
• Mantenha os cenários de espera genuinamente ocultos do agente gerador; é isso que impede que uma pontuação julgada seja manipulada.
• Mapeie cada critério de aceitação para uma verificação executável e determinística antes de considerar qualquer coisa concluída.
• Não pule a entrevista de alinhamento em trabalhos ambíguos, de várias semanas ou críticos de segurança/UX apenas para