DigiAye/agent-skills

assemble

Quatro modelos, uma resposta, muitas rodadas. A cada turno, lê-se a melhor resposta atual, critica-se a partir de um papel específico e escreve-se uma versão melhorada. O progresso é mantido em arquivos, não na conversa, para que cada turno comece com contexto novo (a técnica Ralph Wiggum).

Comandos

Comando	O que fazer
assemble <tarefa>	Iniciar uma execução com o cronograma padrão (36 turnos).
assemble --quick <tarefa>	Um bloco de 2 passadas x 4 modelos (8 turnos).
assemble resume [<slug>]	Continuar a execução mais recente (ou nomeada) não finalizada.
assemble cancel [<slug>]	Definir status: cancelled no arquivo de estado e parar.
assemble status	Mostrar iteração, bloco, itens MUST abertos e modelos usados.

Antes de começar

1. Carregar .assemble/config.json se existir, caso contrário assets/config.example.json.
2. Escolher o adaptador de modelo (veja abaixo) e informar ao usuário quais quatro modelos serão executados e para onde o texto da tarefa será enviado. Se algum modelo estiver fora de allowedModels, ou se localOnly for verdadeiro e um modelo for remoto, descartá-lo e avisar.
3. Reafirmar a tarefa e os critérios de aceitação em um parágrafo curto. Se a tarefa não estiver clara, perguntar ao usuário antes de gastar qualquer rodada.
4. Criar .assemble/<slug>/ com task.md, answer.md (vazio) e state.md conforme descrito em references/state-format.md. Garantir que .assemble/ esteja em .gitignore.

O cronograma

Uma rodada é um turno de modelo. Uma passada são todos os quatro modelos realizando um turno cada, em ordem.

Bloco	Passadas	Turnos	Total acumulado
1	4	16	16
2	3	12	28
3	2	8	36

Após o turno 36, mostrar o relatório e perguntar ao usuário se deseja executar outro bloco. Nunca ultrapassar 36 sem perguntar.

Os papéis rotacionam a cada passada para que cada modelo execute todos os papéis: na passada p (base 0), o modelo m executa roles[(m + p) % 4] de references/roles.md.

Cada turno

Construir o prompt do turno apenas a partir dos arquivos, usando references/handoff-format.md:

• task.md
• a resposta atual answer.md
• a crítica do turno anterior (do round-NN.md mais recente)
• o cartão do papel para este turno

Não incluir rodadas anteriores, e não informar qual modelo escreveu a resposta atual. Então:

1. Enviar o prompt para o modelo deste turno usando o adaptador escolhido.
2. Analisar a resposta em uma crítica (cada problema marcado como MUST ou NICE), uma resposta revisada e um veredito.
3. Se a tarefa for código e checks estiverem configurados, aplicar a resposta revisada em uma cópia temporária, executar as verificações e adicionar quaisquer falhas na crítica como itens MUST.
4. Escrever round-NN.md (papel, id do modelo, crítica, resultados das verificações, veredito, tamanho do diff em linhas) e sobrescrever answer.md com a resposta revisada.
5. Atualizar state.md: iteração, bloco, passada, contagem de MUST abertos e sequência de nenhuma mudança.
6. Fornecer ao usuário uma nota de progresso de uma linha: Rodada 7/36 · cético · 2 MUST, 1 NICE · diff 14 linhas.

Se um modelo apresentar erro ou timeout, registrar em round-NN.md, pular o turno e continuar. Se dois modelos consecutivos falharem, pausar e informar o usuário.

Parando

Um turno conta como nenhuma mudança quando não levanta itens MUST e altera menos de noChangeLines linhas de answer.md.

Parar antes do previsto quando:

• quatro turnos consecutivos (uma passada completa) não apresentarem mudanças, ou
• um turno terminar com <promise>CONVERGED</promise> e o turno seguinte confirmar sem itens MUST.

Se a contagem de MUST abertos não cair por um bloco inteiro, parar e escrever uma nota curta de "travado": o que está bloqueando, o que foi tentado e o que o usuário poderia decidir para desbloquear.

Relatório

Quando a execução terminar, escrever .assemble/<slug>/report.md e exibi-lo:

• a resposta final
• rodadas executadas e por que parou
• as principais mudanças em cada bloco
• quaisquer itens NICE abertos
• modelos usados, com falhas
• uma estimativa aproximada de tokens e custo (soma dos tamanhos do prompt e das respostas, vezes os preços no config, se fornecidos)

Adaptadores de modelo

Usar o primeiro que estiver disponível e informar ao usuário qual foi escolhido.

1. Subagentes da ferramenta. Se o host puder gerar subagentes e escolher seu modelo, usar um por turno. Cursor pode misturar fornecedores. Claude Code e Kiro só oferecem modelos Claude, então os quatro serão variantes de Claude.
2. CLIs de fornecedores. Executar scripts/run-model.sh <model-id> <prompt-file> uma vez por turno. Esta é a opção verdadeiramente multi-fornecedor. Verificar se cada CLI existe (command -v) antes do início da execução.
3. Modelo único. Executar cada turno você mesmo, interpretando o papel daquele turno. Ler apenas os arquivos do turno e tratar cada turno como um novo começo.

Ajudantes opcionais específicos da ferramenta, como um hook de parada do Claude Code para execuções não supervisionadas, estão na pasta adapters/ do repositório.