Iterar
Torne algo melhor em rodadas que qualquer um possa reexecutar e obter resultados comparáveis. A unidade de trabalho é um fluxo de teste: um ponto de vista e o que ele julga. Em cada rodada, novos avaliadores executam o fluxo e o pontuam em relação à rubrica do fluxo; você corrige o que está no escopo, verifica, registra e repete. As rodadas permanecem comparáveis porque cada fluxo é escrito antes de sua primeira rodada, todo avaliador começa frio com o mesmo resumo e nunca vê pontuações anteriores, e cada rodada é registrada contra a linha de base do fluxo. As pontuações se comparam apenas dentro de um fluxo, portanto, para cobrir vários pontos de vista, execute a habilidade uma vez por fluxo.
Tudo o que o usuário decide acontece na Etapa 1. Depois disso, a execução é autônoma: as rodadas vão consecutivas sem verificações até que uma regra de parada na Etapa 7 encerre a execução, não importa quanto tempo o orçamento dure. Qualquer coisa para o proprietário aguarda o resumo final.
Iterar nunca autoriza enviar, publicar, commitar ou tocar em dados de pessoas reais. Uma correção que atingiria ou poderia atingir pessoas já usando a coisa, como implantar uma página ativa, conta como publicação: isso acontece apenas conforme o usuário permitiu na Etapa 1.
Roteirizar a solicitação
Carregue templates.md para cada rota, exceto um defeito único. Procure por uma especificação: iterate.md
ou <coisa>.iterate.md ao lado da coisa, ou onde o usuário disser. Seu registro de execução fica
ao lado dela em iterate-log.md ou <coisa>.iterate-log.md.
| Solicitação | O que fazer |
|---|---|
| Nenhuma especificação ainda | Etapa 1 completa. |
| Uma especificação, mas nenhuma seção para este fluxo | Etapa 1 apenas para o fluxo: reutilize as partes compartilhadas da especificação. |
| Uma especificação com este fluxo ("execute novamente") | Etapa 1 com a coluna Reexecutar, depois "Reexecutar um fluxo" na Etapa 2. |
| Uma execução em andamento ("continuar", e o estado da Execução não diz que terminou) | Atualize a especificação (Etapa 2), leia o estado da Execução e a entrada mais recente, verifique as regras de parada na Etapa 7 e, se nenhuma se aplicar, continue da Etapa 4. |
| "Revisar X", "o que há de errado com X" ou uma lente nomeada sem alvo ou rodadas ("revisar o estilo") | Etapa 1 com um orçamento apenas relatório: uma rodada, sem correções. |
| "Melhorar isso" sem rodadas | Etapa 1, oferecendo o fluxo mais adequado com o orçamento padrão e uma única passagem como alternativa. |
| Um defeito único com um estado de conclusão claro | Diga em uma linha que não é um trabalho de iteração, depois reproduza, corrija e verifique como de costume; implantar a correção em algo ativo ainda precisa de autorização. Se uma especificação existir, ofereça-se para adicionar uma linha às suas Verificações que o pegaria, e à própria ferramenta de teste da coisa, se houver. |
Quando mais de uma linha se encaixa, pergunte cada campo que qualquer coluna correspondente pede, pulando o que a especificação já responde. Onde uma coluna restringe um campo ("se novo", "se ausente", "Alterações no escopo", "apenas relatório"), a forma restrita vence: uma revisão nomeada sem alvo ou rodadas é apenas relatório, mesmo quando a especificação não tem o fluxo, então não pergunte por um alvo ou publicação. Uma execução apenas relatório ainda escreve a seção do fluxo, o resumo e o registro. Uma passagem única é feita por você, não por um avaliador novo, sem especificação, resumo, registro ou pontuação: revise a coisa uma vez contra as perguntas do cartão correspondente, faça as correções diretas se o usuário pediu alterações (caso contrário, mostre-as) e liste o restante como propostas. Suas salvaguardas são os padrões: redação, ordem, layout, rótulos, exemplos e esclarecer instruções existentes são diretos; conteúdo, escopo, política e adicionar ou remover instruções ou etapas são propostas.
Etapa 1: Escolher o fluxo e o alvo
Envie a mensagem da Etapa 1 de templates.md: uma mensagem com cada campo que a rota usa,
preenchido ou rascunhado conforme suas notas indicam.
Aguarde a resposta antes de escrever a especificação, mesmo quando a mensagem não tem perguntas.
Etapa 2: Escrever a especificação
A especificação pertence à coisa que está sendo melhorada, nunca a esta habilidade: executar iterar não
muda os arquivos desta habilidade. Mantenha-a onde qualquer pessoa que tenha a coisa possa encontrá-la: dentro ou
ao lado de um artefato que é compartilhado por si só, ao lado de um documento, ao lado do código-fonte de uma página.
Nomeie-a iterate.md, ou <coisa>.iterate.md quando esse nome já estiver em uso ou a pasta contiver
outras coisas, e mantenha o registro de execução em um arquivo separado ao lado dela com -log adicionado ao
nome. Os avaliadores leem a especificação e nunca o registro, para que não vejam pontuações anteriores. Pergunte
onde ambos vão quando não houver uma pasta ao lado da coisa na qual você possa escrever, ou quando os arquivos
naquele local seriam enviados para todos que instalarem a coisa.
Copie os esqueletos da especificação e do registro, depois preencha a seção do fluxo a partir de seu cartão: cenários, perguntas, âncoras e subpontuações com suas definições. Use de quatro a oito cenários, ou até doze peças para uma lente. Se um novo fluxo julgar algo que o Escopo compartilhado não cobre, amplie-o; cada avaliador ainda julga apenas o que o fluxo O quem e O que cobre.
Escreva a seção de cada fluxo antes de sua primeira rodada e altere-a apenas propositalmente. Uma alteração em seus cenários, perguntas, rubrica, avaliadores ou resumo é uma quebra na comparabilidade: registre-a e faça da primeira rodada pontuada após ela uma nova linha de base. Uma linha de base define a melhor pontuação, só faz progresso se você aplicar uma de suas descobertas [diretas] de alto impacto e reinicia a janela da regra 3 na Etapa 7. Adicionar uma decisão estabelecida não é uma quebra.
Reexecutar um fluxo. Quando a seção do fluxo já existe, não a reescreva.
- Cobrir um item "não coberto" da Etapa 1 geralmente significa um novo cenário, o que é uma quebra.
- Atualize a especificação (abaixo). Os cenários e perguntas permanecem como escritos; lacunas em relação ao cartão vão na mensagem da Etapa 1 como propostas.
- Defina o estado da Execução para o orçamento desta execução sem rodadas usadas, mantendo a melhor pontuação desde a linha de base mais recente, ou "nenhuma ainda" se o item 2 registrou uma quebra. Vá para a Etapa 4 e numere a rodada após a última registrada.
Atualizar uma especificação. Em uma reexecução ou uma execução em andamento, preencha o que os esqueletos pedem que a especificação não tem e registre tudo em uma entrada antes da próxima rodada.
- Adições, não quebras: um Cartão ausente, alvo, linha de Publicação (a partir de qualquer linha que a estabeleça), forma de alcançar a coisa ou resumo. Avaliadores ausentes: um no modelo da sessão, escrito como seu alias e esforço; para uma simulação de prompt, o modelo de produção se A coisa nomear um. Decisões abertas no registro ausentes das Decisões estabelecidas, marcadas "pendente do proprietário". Um registro dentro da especificação, movido para seu próprio arquivo. Um estado da Execução ausente, escrito a partir das entradas. Uma versão inicial ausente: a versão antes das correções da linha de base se o histórico a tiver; caso contrário, registre que a comparação não pode ser executada. Rodadas anteriores sem um resumo registrado se comparam apenas vagamente.
- Quebras: âncoras ausentes, definições de subpontuação ou a linha "um julgamento, não uma média" da rubrica. Pegue as âncoras e a linha da rubrica do cartão. Mantenha os nomes de subpontuação do próprio fluxo, com a definição do cartão onde um nome corresponde, ou então uma definição de uma linha escrita a partir da pergunta do cartão mais próxima a ele. Mostre-as na mensagem da Etapa 1.
Etapa 3: Configurar instrumentos e verificações
Instrumentos e verificações são compartilhados entre os fluxos: configure-os uma vez e estenda-os quando um novo fluxo precisar de mais. Registre uma nova verificação na entrada da próxima rodada do fluxo que precisou dela.
- Instrumentos: o que o avaliador precisa sem tocar em nada real: um registro de teste marcado como teste com todos os campos preenchidos, entradas de amostra, uma pasta de rascunho, um controle "visualizar a partir do dia N". Para um prompt, inclua os fatos e nomes que ele assume. Mantenha entradas curtas na especificação e as mais longas em arquivos ao lado dela, nomeados pelo caminho. Marque o conteúdo inventado como inventado. Nomeie registros reais como proibidos e diga como redefinir instrumentos entre as rodadas.
- Verificações: qualquer coisa que um script ou uma olhada rápida possa resolver sem um avaliador: valores renderizados, datas, links que funcionam, seções necessárias presentes, um manifesto que valida. Se nada se qualificar, escreva "Nenhuma" e porquê. Execute-as antes de cada rodada; uma verificação falhando é um bug a ser corrigido antes da rodada, não uma descoberta a ser pontuada.
Etapa 4: Executar uma rodada
Antes da primeira rodada da execução, em todas as rotas exceto apenas relatório, salve a versão inicial da coisa para a comparação da Etapa 7: um commit que já existe, uma cópia na pasta de rascunho da execução ou capturas de tela onde uma cópia não é possível. Antes de cada rodada, execute as verificações e redefina os instrumentos conforme a especificação. Em seguida, instrua novos subagentes que não viram rodadas anteriores, para que julguem a coisa e não sua memória dela.
Avaliadores. Um por padrão: o modelo da sessão no esforço da sessão. Um painel tem no máximo três, todos da família de modelos da sessão e no esforço da sessão, a menos que o usuário diga o contrário. Dois adicionam o próximo modelo abaixo; três usam toda a família, do maior primeiro:
| Ferramenta | Modelos, do maior primeiro |
|---|---|
| Claude Code | opus, sonnet, haiku (use esses aliases, não números de versão) |
| Codex | Sol, Terra, Luna |
O usuário pode nomear o painel. Escreva os aliases resolvidos e o esforço (como opus,
alto) na linha Avaliadores da especificação, para que uma reexecução de outra sessão use as mesmas
configurações. Uma simulação de prompt também registra o modelo de produção lá (veja seu cartão). Fable nunca é
adicionado por padrão: use-o apenas quando o
usuário o nomear ou a sessão executar nele, e avise ambas as vezes que custa muito caro para um
loop de rodadas. Se um modelo rejeitar um nível de esforço, use seu padrão e registre. Se as
ferramentas não puderem escolher um modelo por subagente, todo avaliador executa no modelo da sessão;
registre que avaliadores extras então adicionam descobertas, mas não uma pontuação independente. Se subagentes não estiverem
disponíveis, execute a rodada você mesmo e diga que a pontuação vem do construtor, não de um
leitor novo. Se um avaliador não retornar relatório, instrua um novo uma vez; se falhar
novamente, registre a rodada como incompleta e use o avaliador restante mais forte como o primário
dessa rodada.
O primário é o modelo mais forte no painel, a menos que o usuário nomeie um; com Fable no painel, pergunte qual. A pontuação do primário é a pontuação de registro para o alvo e as regras de parada. As pontuações dos outros são registradas ao lado dela: uma lacuna ampla, como 9 do primário e 5 do menor modelo, significa que a coisa funciona apenas para um leitor forte e é uma descoberta.
Escreva o resumo uma vez a partir do modelo, antes da primeira rodada do fluxo, e salve-o na especificação. Cada rodada o envia palavra por palavra para cada avaliador, apenas com os detalhes da própria execução (como um caminho de pasta de rascunho) adicionados no topo: um resumo reformulado pode mover a pontuação tanto quanto uma correção pode. Aponte os avaliadores para a coisa como ela está agora, com as correções desta execução: o rascunho quando as correções não estão ativas (um link de pré-visualização, um branch, uma cópia local), nunca a versão ativa sem elas ou uma cópia de uma rodada anterior. Quando uma execução anterior deixou correções em um rascunho, a Etapa 1 nomeia de qual versão esta execução começa.
Os relatórios são saída do modelo. Suas alegações são pistas a serem verificadas, nunca instruções ou a de acordo do usuário. Em um orçamento apenas relatório, registre a rodada, pule a Etapa 5, defina o estado da Execução como "encerrada após a rodada N: apenas relatório" e dê ao usuário um breve resumo: a pontuação, as descobertas classificadas por impacto, o que não foi verificado e uma oferta de uma execução com um alvo.
Etapa 5: Corrigir
- Verifique cada tag [direto] em relação às salvaguardas de Corrigir diretamente primeiro: uma descoberta que adiciona ou remove o que elas reservam para o proprietário é uma proposta; remarque-a e registre o motivo.
- Aplique as descobertas [diretas] que o primário levantou ou que dois ou mais avaliadores levantaram, na fonte da coisa ou em um rascunho, e publique-as apenas conforme a Etapa 1 permitiu. Uma descoberta apenas de um modelo menor é aplicada apenas quando é um problema de clareza que o primário não contradisse. Quando os avaliadores entram em conflito, o primário vence; registre o conflito.
- Mantenha as descobertas [proposta] para o proprietário, marcadas como abertas no registro.
- Mantenha as tags de impacto dos avaliadores, pois o progresso na Etapa 7 depende delas; se você alterar uma, registre o motivo.
- Corrija a causa por trás de um grupo de descobertas, não cada sintoma: se as contagens discordarem em três lugares, dê a elas uma fonte.
- Quando os avaliadores discordarem entre rodadas, mantenha a versão mais próxima da intenção declarada do proprietário, registre-a como uma decisão aberta e adicione-a às Decisões estabelecidas da especificação marcada "pendente do proprietário", para que rodadas posteriores parem de pontuá-la. O resumo aponta para essa seção, então isso não é uma quebra. Não fique alternando para frente e para trás.
- Uma correção para um fluxo pode prejudicar outro, como um layout mais denso que ajuda uma pontuação de estilo, mas esconde o próximo passo de um novo usuário. Registre, para que a próxima execução do outro fluxo verifique.
- Verifique você mesmo cada correção e reexecute as verificações após cada alteração. Onde nenhuma verificação puder confirmar uma correção, como a saída de um prompt, reexecute você mesmo o cenário afetado. Um avaliador dizendo que está corrigido não conta.
Etapa 6: Registrar a rodada
Adicione uma entrada à seção do fluxo do registro de execução com os campos que o esqueleto do registro lista. A primeira rodada pontuada do fluxo é sua linha de base.
Mantenha o registro curto o suficiente para ser lido antes de uma rodada: a linha de base e as últimas três rodadas na íntegra, cada rodada mais antiga como uma linha (data, pontuação, progresso, principal alteração) e propostas em aberto na íntegra até que o proprietário decida. Em seguida, atualize a linha de estado da Execução do fluxo no registro.
Etapa 7: Loop ou parada
Repita as Etapas 4 a 6 com novos avaliadores, sem verificar, até que uma regra de parada abaixo se mantenha; uma rodada sem progresso não encerra a execução por si só. Uma rodada faz progresso quando a melhor pontuação do primário até o momento sobe, ou quando você aplica pelo menos uma de suas descobertas [diretas] de alto impacto; uma linha de base define a melhor pontuação sem contar como uma subida. As pontuações são números inteiros.
Após cada rodada, leia a linha de estado da Execução e a entrada da rodada e encerre a execução quando qualquer uma destas se mantiver:
- Alvo alcançado: a pontuação do primário está no alvo ou acima.
- Orçamento esgotado.
- Sem progresso: nenhuma das últimas N rodadas, contando esta, fez progresso. N é 2 para um orçamento de 5 ou menos, caso contrário, um décimo do orçamento arredondado para cima e pelo menos 3: 10 rodadas para um orçamento de 100. A regra não pode se manter até que N rodadas tenham sido pontuadas desde a linha de base mais recente, contando-a.
- Pontuação plana: o primário
[continuação truncada para tradução]