Como ir de uma máquina recém-instalada a uma tarefa em execução, e o mapa completo do que o harness consegue fazer — cada caso de uso aos seus módulos e comandos. Esta é a última lição: um comando para configurar, um comando para conduzir e um quadro com todos os 36 casos de uso, para que você sempre saiba qual parte do suite responde ao trabalho à sua frente.
Você já viu cada parte agora — o loop, os portões, o Forge, a observabilidade AFK, a delegação entre agentes, o fusion, o Council, as ferramentas, o visual-teach, o Publish Gate, o monolito. Esta última lição para de explicar partes e se torna o guia do operador: como pegar uma máquina recém-instalada, deixar o harness instalado e colocar uma tarefa em movimento — além de um mapa completo para que você sempre saiba qual parte responde ao trabalho à sua frente.
A forma é deliberadamente pequena. O harness é o modo de trabalho padrão: qualquer tarefa não-trivial é conduzida pelo loop. Um comando configura tudo. Um comando inicia uma tarefa. E o humano apenas observa — você lê o diário enquanto ele roda, e só é chamado quando aparece uma decisão genuinamente humana. Todo o resto do suite é uma ferramenta nomeada que você usa quando o trabalho pede, e o quadro ao final desta lição é o índice de todas elas.
Pense nisso como… receber as chaves de uma oficina bem construída. Uma visita prepara a bancada e cada máquina (configuração). Para começar um trabalho, você pendura a ordem de serviço com um "pronto" claro escrito nela (conduzir uma tarefa). Então você observa o chão de fábrica pela janela — a equipe opera cada máquina e só bate à sua porta para uma decisão que é genuinamente sua. O quadro de parede ao lado da porta lista cada máquina e para que serve: esse quadro é o board de casos de uso.
Esta lição é estruturada como o runbook: (1) Configuração — um bootstrap idempotente que distribui o monolito a cada agente; (2) Iniciar uma tarefa — classificar (ideia bruta → Forge; spec precisa → o loop diretamente), então a invocação exata por agente; (3) o board de casos de uso — todos os 36 casos de USE-CASES.md, cada um mapeado aos seus módulos e ao seu comando.
O papel do humano é observabilidade AFK, não operação: você lê LOOP-LOG.md e review.md enquanto o loop roda por conta própria, e só entra num handoff pronto para decisão. Coloque as instruções do harness em $HOME (o CLAUDE.md / AGENTS.md global) e o loop se torna o modo padrão para cada tarefa, não algo que você ativa por pedido.
O harness inteiro se instala com um único bootstrap. Ele é autossuficiente — o método, o ensino e a configuração viajam todos em uma skill — então não há nada para clonar em pedaços e nenhuma etapa de build.
faça o bootstrap do harness nesta máquina# one command — preflight, distribute to every agent, verify, report
bash ~/.claude/skills/loop-engineering/setup.sh
Esse comando faz quatro coisas em ordem. Ele faz o preflight dos pré-requisitos e das ferramentas de linha de comando dos agentes, reportando quais estão presentes e quais estão faltando (nunca fatal — o loop é agnóstico a modelo). Ele distribui a skill monolito, por symlink, ao diretório de skills de cada agente de codificação a partir do seu ~/.claude/skills/ canônico. Ele verifica que a skill resolve em cada lugar. E imprime um relatório de prontidão mais os próximos passos exatos que cabem só ao humano (autenticar uma CLI, rodar npx wrangler login, habilitar o Cloudflare Access).
Ele é idempotente e seguro: só cria symlinks e lê arquivos. Nunca apaga nada, nunca sobrescreve seu CLAUDE.md e nunca envia nada para fora. Rode de novo a qualquer momento — depois de editar um módulo, ou depois de adicionar um novo agente ao roster — e ele simplesmente reconcilia.
Pense nisso como… ligar um interruptor mestre a cada cômodo. Você o aciona uma vez e as luzes acendem em todo lugar; aciona de novo depois de refazer a fiação de um cômodo e só aquele cômodo se reconecta. Nada é arrancado, nada sai do prédio — ele apenas garante que cada cômodo esteja no mesmo circuito.
Numa máquina recém-instalada onde a skill ainda não está sob ~/.claude/skills/, copie-a primeiro, depois faça o bootstrap. Como a skill é um monolito, os módulos embutidos (Forge, fusion, Council, visual-teach, as ferramentas, o brief, os scripts de publicação) vêm junto.
# 1 · place the monolith under your canonical skills dir cp -R skills/loop-engineering ~/.claude/skills/ # 2 · distribute + verify (idempotent; symlinks + reads only) bash ~/.claude/skills/loop-engineering/setup.sh
Coloque as instruções do harness em $HOME — o CLAUDE.md global (ou AGENTS.md para os agentes que leem esse arquivo) — para que cada tarefa não-trivial seja conduzida pelo loop por padrão, em vez de algo que você ativa por pedido. Depois disso, o mesmo jeito de trabalhar está presente não importa qual agente instalado pegue a próxima unidade (caso 1 no board).
Com o harness instalado, iniciar uma tarefa é uma sequência curta e fixa. Percorra-a uma vez e ela se torna automática. A única ramificação está no topo: se a tarefa chega como uma ideia bruta ou como uma spec precisa.
Se você está em um dos agentes instalados, ele já está pronto — o monolito está no diretório de skills dele. Uma máquina totalmente nova apenas roda primeiro os dois comandos de configuração da seção 2.
Se o agente nunca rodou o harness, faça-o ler o módulo harness-brief primeiro — um brief denso, de cima a baixo, de todo o suite, escrito para uma máquina absorver rápido (harness-brief/MODULE.md + suas 6 lições).
Uma ideia bruta ou vaga entra pelo Forge — grill → research (opt) → prototype (opt) → PRD → issues + /goal — que a afia em um done-when mensurável. Uma spec precisa com uma linha de chegada clara entra direto no loop; pule o Forge e capture o done-when inline.
No Claude Code, invoque /loop-engineering <task + done-when>. No Codex, Kimi, Grok e nos demais, diga ao agente para usar a skill loop-engineering para conduzir a tarefa. Para delegação headless de uma unidade delimitada, as flags provadas por agente estão abaixo.
# Claude Code — JSON out claude -p "<task + done-when>" --output-format json # Codex — quiet exec codex exec --quiet "<one bounded unit>" # Kimi — text out (never -p WITH --yolo; no --work-dir) kimi -p "<one bounded unit>" --output-format text # Grok — plain out, auto-approve, explicit cwd grok -p "<one bounded unit>" --output-format plain --always-approve --cwd .
O loop roda por conta própria. Você lê LOOP-LOG.md (o diário por passagem — o que ele olhou, a única unidade que escolheu, se a prova passou) e review.md (o relatório de QA). Você só é chamado para uma bifurcação genuinamente do usuário, exposta como um handoff pronto para decisão.
Quando o done-when é satisfeito, a execução entrega um curso visual-teach e passa pelo Publish Gate — um gist privado sempre, um site Cloudflare Pages quando configurado — e reporta as URLs de volta a você.
Aqui está um início para copiar e colar com um done-when mensurável embutido no pedido, do jeito que o loop quer.
um início real — done-when mensurável incluído# Claude Code — crisp spec, straight into the loop /loop-engineering Add rate limiting to the /search endpoint. done-when: a real request burst of 100/s returns HTTP 429 after the 60th request within 1s, proven by a live curl loop against the running server (not a mock), and the existing test suite stays green.
Antes de delegar, o orquestrador roda command -v (ou a etapa de detecção de painel, bash fusion/scripts/detect_panel.sh) para que apenas agentes vivos recebam despacho. O roster é declarado no início de uma execução; o padrão é agnóstico — qualquer agente roda qualquer unidade, e o Validador é sempre um agente diferente do construtor, o que é o que torna o Proof Gate confiável.
O Forge existe para satisfazer o Scope Gate quando o pedido é vago: seus 7 passos terminam em um GOAL.md com um done-when mensurável (a disciplina ultragoal se recusa a compilar até que o done-when possa falhar em um boundary real). Uma spec precisa já tem essa linha de chegada, então o loop a captura inline e começa a iterar — sem precisar do Forge.
Este é o índice de todo o suite: 36 casos de uso em 8 categorias, cada um mapeado aos módulos que usa e ao comando ou aos passos que o conduzem. Filtre por categoria e clique em qualquer card para revelar seus módulos e exatamente como ele roda. Quando um trabalho cai na sua mesa, encontre-o aqui e você sabe qual parte do harness responde a ele.
Nenhuma categoria selecionada.
A frente de cada card é o título do caso com suas tags de módulo (as partes embutidas que ele usa: o loop + portões, forge, fusion, council, visual-teach, ultragoal, brightdata-cli, computer-use-cli, harness-brief, os scripts de publicação). Expandi-lo mostra o como — o comando ou os passos, literais de USE-CASES.md. As invariantes valem para todos os casos: provar no boundary real, uma unidade delimitada por passagem, o Validador nunca é o construtor, agnóstico a modelo, sem atribuição de IA.
A Configuração & distribuição · B Conduzir uma tarefa (o loop central) · C Endurecer o escopo (submétodos do Forge) · D Verificação & decisões · E Multi-agente / delegação AFK · F Ferramentas · G Ensino & entrega · H Combinado / ponta a ponta. O cookbook completo é USE-CASES.md; o runbook humano é USAGE.md.
Esse é o guia do operador inteiro. O harness é o modo de trabalho padrão; um comando o configura, um comando conduz uma tarefa, e o board acima é o mapa para todo o resto. Você acompanha por LOOP-LOG.md e review.md; o loop roda por conta própria e te entrega um resultado finalizado mais um curso publicado.
O guia inteiro em três linhas
Um comando para configurar (setup.sh). Um comando para conduzir (/loop-engineering <task + done-when>, ou o Forge para uma ideia bruta). Um board de 36 casos para todo o resto — encontre o trabalho, leia seus módulos e comando, rode-o.
USE-CASES.md (cada caso → módulos → comando) e o runbook humano em USAGE.md; o brief voltado para agentes é harness-brief/MODULE.md. Volte ao índice do curso para revisitar qualquer lição, ou escolha um card acima e rode-o. Esta é a última lição — o resto é fazer o trabalho.