loop-goal — gerador de prompts de /loop com goal mensurável

Transforma um pedido frouxo ("fica rodando até ficar bom") num bloco /loop pronto pra colar, com goal mensurável, verificação independente e parada explícita. A skill NÃO dispara nem orquestra o loop - o /loop nativo do Claude Code é a engine de execução; esta skill só produz o artefato de texto.

When to use

• O usuário quer uma ação longa/repetitiva rodando até um alvo claro (qualidade de um artefato, contagem, check verde, estado externo).
• O usuário pede "o prompt do loop" pra colar e disparar quando quiser.
• O padrão "itera até bater threshold X" que ele já faz na mão e quer formalizar.

When NOT to use

• Recorrência sem fim agendada (todo dia às 9h): isso é /schedule, não /loop.
• Disparar ou conduzir o loop: a skill só gera o texto; quem executa é o /loop nativo.
• Tarefa de uma passada só (sem repetição): não precisa de loop.

O que a skill entrega

Um bloco de texto em PT-BR, sem travessões, pronto pra colar no chat. Opcionalmente salva uma cópia no scratch do repo pra reuso.

Regra dura: goal tem que ser mensurável

A skill NÃO emite loop enquanto o goal não encaixar em uma linha da taxonomia abaixo, com threshold concreto. Goal vago ("até ficar bom", "melhore", "deixe redondo") é recusado: a skill cobra "bom medido como - rubrica de quantas dimensões, qual threshold?" antes de gerar.

Qual template usar

• Goal de estado externo (algo que muda fora de você, e você só espera/observa) -> Template (b), intervalo.
• Goal de qualidade, contagem, check ou artefato (você trabalha ativamente a cada passada) -> Template (a), auto-ritmado.

Template (a) - loop auto-ritmado até qualidade/conclusão

Sem intervalo. O modelo trabalha, avalia e para sozinho. O /loop nativo se reagenda; o prompt só precisa dizer com clareza quando encerrar.

/loop Itere até o GOAL ser atingido.

GOAL: <estado final mensurável, uma frase>.

AÇÃO POR ITERAÇÃO:
1. <o que fazer ou revisar nesta passada>.
2. Avalie conforme a VERIFICAÇÃO.
3. Registre a iteração no PROGRESSO.

VERIFICAÇÃO (independente): <como medir>.
[se qualidade] Dispare um subagente fresco como juiz, com esta rubrica: <dimensões + escala>. Não avalie o próprio trabalho.

PARADA POR VITÓRIA: encerre o loop sem reagendar quando <métrica> >= <threshold>.

PARADA POR DESISTÊNCIA: encerre o loop se (a) 2 iterações seguidas sem ganho em <métrica>, OU (b) <N, ~15 a 25> iterações no total, OU (c) erro irrecuperável.

PROGRESSO: a cada iteração, anexe em <scratch>/progresso.md uma linha: numero, mudanca feita, score por dimensao, decisao.

ANTI-REGRESSÃO: guarde a melhor versao em <scratch>/melhor/. Nunca substitua por versao com score menor que a melhor ja obtida.

AO PARAR: entregue a melhor versao + resumo: score final, numero de iteracoes, o que destravou e o que ficou bloqueado.

Template (b) - loop de intervalo pra vigiar estado externo

Com intervalo. Você só observa um estado que muda fora de você, até a condição bater.

/loop <intervalo> Vigie até a CONDIÇÃO ser satisfeita.

CONDIÇÃO ALVO: <estado externo, ex.: deploy do PR #123 publicado e healthcheck 200>.

CHECAGEM: <comando ou observação que lê o estado>.

AÇÃO: se a condição ainda não bateu, <reporte o status atual / aja>. Se bateu, prossiga pra PARADA.

PARADA: encerre o loop quando <condição batida>. Encerre também se passar <janela máxima> sem mudança de estado.

PROGRESSO: registre cada checagem em <scratch>/progresso.md: estado observado e se mudou desde a última.

Verificação independente (não negociável pra qualidade)

Goal de qualidade NUNCA é verificado pelo próprio agente que produziu o trabalho (self-preference bias: o modelo aprova o que ele mesmo fez). A verificação vai por:

• juiz subagente fresco com rubrica explícita (dimensões + escala + threshold por dimensão), ou
• check determinístico (comando, teste, diff) quando existir.

Se o usuário não tem rubrica, a skill rascunha uma curta (3 a 5 dimensões com escala 0 a 10) e confirma antes de embutir.

Defaults de parada (propostos, ajustáveis)

• Desistência por estagnação: 2 iterações seguidas sem ganho na métrica.
• Teto de iterações: ~15 a 25 (tarefa focada converge em ~10 a 25; passar disso = escopo largo ou critério vago).
• Erro irrecuperável: sempre encerra.
• Janela máxima (intervalo): proporcional ao tempo esperado do estado externo.

Fluxo da entrevista (default)

Pergunte só os gaps, uma coisa por vez, com default recomendado em cada. Campos a fechar:

1. Ação - o que repetir (quase sempre o usuário já dá).
2. Goal mensurável - encaixa na taxonomia + threshold. Sempre cobrado se vier vago.
3. Verificação - derivada do tipo de goal; pra qualidade, confirma dimensões da rubrica.
4. Paradas - sucesso vem do threshold; desistência pelos defaults acima.
5. Modo - inferido do goal (estado externo -> intervalo; qualidade/conclusão -> auto-ritmado); confirma cadência se intervalo.
6. Pasta de progresso - dentro do repo atual. Em repo git, use .scratch/loop-<slug>/ (gitignorada, transitória). Em repo sincronizado sem git (ex.: Nextcloud, como o ibeia-os), NUNCA use pasta temporária (temporario/, tmp/, etc.) — ela sincroniza e vira lixo permanente. Grave o progresso e as melhores versões numa pasta devida e permanente do sub-projeto: <sub-projeto>/docs/loop-<slug>/ (ou <sub-projeto>/.claude/plans/loop-<slug>/). E os artefatos/entregáveis finais vão sempre pras suas pastas devidas (código em src/, renders em docs//out/, doc em docs/), nunca num dump temporário.

Quando todos os campos estão fechados, monte o template correto e entregue o bloco.

Modo YOLO

Se o usuário mandar um parágrafo com tudo, infira os 6 campos, aplique os defaults, gere o prompt na hora e liste embaixo as suposições feitas (ação, tipo de goal, threshold, paradas, modo, scratch) pra ele corrigir o que estiver errado. Sem entrevista.

Cheatsheet de pacing

• Auto-ritmado: o /loop nativo se reagenda sozinho. O prompt só precisa dizer "encerra quando <vitória>" e "encerra sem reagendar se <desistência>".
• Intervalo e janela de cache: menos de 270s mantém o cache quente (bom pra polling de estado rápido: CI, fila, deploy). 1200s ou mais pra estado lento ou idle. Evite 300s (paga o cache miss sem amortizar).

Exemplos completos

Exemplo 1 - qualidade (auto-ritmado)

Pedido: "loop pra refinar um criativo Remotion até ficar 9/10".

/loop Itere até o GOAL ser atingido.

GOAL: o criativo Remotion atinge score >= 9 em todas as 4 dimensões no juiz adversarial.

AÇÃO POR ITERAÇÃO:
1. Renderize a versao atual do criativo e assista ao resultado.
2. Avalie conforme a VERIFICAÇÃO.
3. Aplique a melhoria de maior impacto apontada pelo juiz.
4. Registre a iteração no PROGRESSO.

VERIFICAÇÃO (independente): dispare um subagente fresco como juiz, com a rubrica (escala 0 a 10 por dimensao): gancho nos 3s iniciais, clareza da mensagem, ritmo/timing, acabamento visual. Não avalie o próprio trabalho.

PARADA POR VITÓRIA: encerre o loop sem reagendar quando as 4 dimensões >= 9.

PARADA POR DESISTÊNCIA: encerre se (a) 2 iterações seguidas sem ganho de score, OU (b) 20 iterações no total, OU (c) erro irrecuperável de render.

PROGRESSO: a cada iteração, anexe em .scratch/loop-criativo-remotion/progresso.md: numero, mudanca feita, score por dimensao, decisao.

ANTI-REGRESSÃO: guarde a melhor versao em .scratch/loop-criativo-remotion/melhor/. Nunca substitua por versao com score menor.

AO PARAR: entregue a melhor versao + resumo: score final por dimensao, numero de iteracoes, o que destravou e o que ficou bloqueado.

Exemplo 2 - contagem (auto-ritmado)

Pedido: "loop pra achar 10 bugs reais nesse módulo".

/loop Itere até o GOAL ser atingido.

GOAL: 10 bugs reais e confirmados encontrados no módulo X.

AÇÃO POR ITERAÇÃO:
1. Procure por um novo bug ainda não listado (lente diferente a cada passada: input invalido, concorrencia, borda, estado nulo).
2. Confirme que é real conforme a VERIFICAÇÃO.
3. Se confirmado, adicione ao PROGRESSO.

VERIFICAÇÃO (independente): pra cada bug candidato, dispare um subagente fresco pra tentar REFUTAR. So conta se ele nao conseguir refutar.

PARADA POR VITÓRIA: encerre o loop sem reagendar quando a contagem de bugs confirmados >= 10.

PARADA POR DESISTÊNCIA: encerre se 3 iterações seguidas sem achar bug novo confirmado, OU 25 iterações no total.

PROGRESSO: mantenha em .scratch/loop-bugs/progresso.md a lista numerada: bug, arquivo:linha, por que é real.

AO PARAR: entregue a lista de bugs confirmados + resumo: quantos achou, quais lentes renderam mais.

Exemplo 3 - estado externo (intervalo)

Pedido: "fica checando se o deploy do PR #123 publicou".

/loop 4m Vigie até a CONDIÇÃO ser satisfeita.

CONDIÇÃO ALVO: o deploy do PR #123 está publicado em produção e o healthcheck responde 200.

CHECAGEM: consulte o status do deploy (gh / API do provedor) e faça um GET no /health.

AÇÃO: se ainda não publicou, reporte o estado atual (em fila, buildando, falhou). Se publicou e o healthcheck deu 200, prossiga pra PARADA.

PARADA: encerre o loop quando publicado E healthcheck 200. Encerre também se passar 40 minutos sem o deploy avançar de estado (provavel travado/falho).

PROGRESSO: registre cada checagem em .scratch/loop-deploy-123/progresso.md: estado observado e se mudou desde a última.

Anti-padrões (a skill bloqueia)

• Goal vago sem métrica/threshold ("melhore", "deixe bom").
• Loop sem parada (roda infinito): todo loop sai com vitória + desistência + teto.
• Auto-avaliação do próprio trabalho como critério de qualidade.
• Polling que queima cache (intervalo mal escolhido, ex.: 300s).
• Sem persistência de progresso (retrabalho, loop não retomável).

Language

Entrevista e prompts gerados em PT-BR. Travessões proibidos em qualquer texto user-facing produzido (o bloco do loop e a entrevista); permitidos só em comentários internos.