juanmackie/juanskills

O Loop Fable

Esta habilidade orquestra o fable-method: leia o SKILL.md primeiro; suas regras governam cada estágio. Ele é instalado junto com esta habilidade (no diretório skills/fable-method/ deste plugin, ou ~/.claude/skills/fable-method/ para instalações manuais). O método diz O QUE verificar; este loop diz QUEM faz o trabalho: o que é executado na thread principal, o que é distribuído para subagentes e o que é atacado antes da entrega.

Portão primeiro.

Trivial de acordo com o portão de trivialidade do método: apenas faça, verifique com a única verificação óbvia, relate em duas frases. Sem estágios, sem subagentes. Todo o resto executa os quatro estágios abaixo em ordem.

Estágio 1 - PLANEJAR (o primeiro divisor)

1. Aplique os Passos 0-3 do método: classifique a solicitação, defina "pronto" com uma verificação nomeada, declare as suposições críticas.
2. Distribuição de evidência. Dispense os coletores de evidência como subagentes paralelos em UMA mensagem, nunca sequencialmente:
   • perguntas sobre o código-fonte: um agente Explore por área distinta ("como X funciona", "do que Y depende")
   • perguntas sobre bibliotecas ou fatos: um agente de pesquisa que busca documentação atual ou pesquisa na web
   • cada subagente retorna conclusões destiladas com citações, nunca despejos brutos de arquivos
   • Um lote mais um lote de acompanhamento é o orçamento; um terceiro precisa de uma razão declarada
3. Produza o artefato do plano neste formato:
   • classificação
   • definição de "pronto" mais sua verificação
   • evidência encontrada (citada)
   • UMA abordagem recomendada (alternativas descartadas em uma linha cada)
   • o escopo (os arquivos ou superfícies exatos que o trabalho tocará)
   • riscos e suposições
   • e a lista de verificação de execução
4. Portão de decisão.
   • Com formato de tarefa e reversível: prossiga para o Estágio 2 sem perguntar
   • Com formato de plano primeiro (escopo ambíguo, ações irreversíveis ou voltadas para o exterior, ou o usuário pediu um plano): apresente o artefato do plano e PARE para aprovação

Estágio 2 - EXECUTAR

1. Trabalhe a lista de verificação na thread principal (use a ferramenta todo se o ferramental tiver uma; marque itens conforme são concluídos). Decidir e editar permanecem na thread principal; apenas buscar e verificar são distribuídos.
2. Cada edição segue o Passo 4 do método: barreira de intenção antes de mudanças de comportamento, barreira de recordação antes do primeiro uso de algo não aberto, menor mudança correta, edições precisas, nunca destruir sem olhar.
3. Itens mecânicos independentes (mesma mudança em muitos arquivos, geração isolada de arquivos) podem ser distribuídos para subagentes paralelos, em uma mensagem, com isolamento de árvore de trabalho se puderem tocar nos mesmos arquivos.
4. Uma surpresa no meio da execução redireciona de acordo com a regra 7 do Passo 2 do método: diga-a e atualize o plano ou volte ao Estágio 1. Nunca force o plano através de uma surpresa.
5. Ignorância no meio de um item é uma pausa, não um palpite: no momento em que uma edição carregaria um fato da memória (uma assinatura, uma chave, uma figura), pare esse item, distribua um subagente de pesquisa de acordo com a barreira de recordação do método e retome quando ele retornar.
6. Itens da lista de verificação voltados para o exterior obedecem à barreira de autorização do método: sem autorização citada do usuário, nenhuma ação; o item se converte em uma próxima etapa proposta no relatório.
7. Pontos de verificação de orçamento de turnos. Limite iterações longas a ≤50 turnos de agente; em cada limite, escreva um artefato de ponto de verificação (o que foi concluído, caminhos de evidência, próxima ação exata) e retome a partir dele. A verificação final nunca deve ser a etapa que o limite de turnos elimina — verifique dentro do orçamento ou coloque-o como pendente explicitamente.

Estágio 3 - VERIFICAR (adversarialmente)

1. Execute a verificação nomeada você mesmo, ambas as metades: o critério de "pronto" observado (executado, renderizado, contado) e o sistema ao redor ainda saudável (build, testes, lint para a área tocada).

2. Para mudanças consequenciais, dispense atacantes. 1-3 subagentes paralelos, cada um instruído a REFUTAR o trabalho de uma perspectiva distinta, por exemplo:

   • "Leia este diff e prove que a mudança está errada ou incompleta"
   • "Execute o comportamento alterado em tempo de execução e encontre uma entrada que o quebre"
   • "Verifique esta afirmação contra a especificação/documentação e encontre uma contradição"
   • "Compare o conjunto completo de alterações com o escopo declarado no plano e prove que algo fora dele mudou"

   Perspectivas distintas são melhores do que revisores idênticos.

3. Uma descoberta que sobrevive à sua própria verificação retorna ao Estágio 2 como novo trabalho. Limite rígido de acordo com o método: 3 ciclos falhos de correção-verificação no mesmo problema, ou qualquer bloqueador fora do seu controle, significa parar e devolver com a saída e sua hipótese.

Estágio 4 - AUDITAR E RELATAR (o segundo divisor)

1. Auto-auditoria de acordo com o modo de auditoria do fable-method: para cada passo do método, seguido, pulado ou falsificado. Corrija o que uma passagem pode corrigir (geralmente uma afirmação não verificada: verifique-a agora ou reclassifique-a como ressalva).
2. Entregue de acordo com o Passo 6 do método: resultado na primeira frase, evidência de verificação mostrada, ressalvas honestas, acompanhamentos apenas se surgiram do trabalho. Sem nomes de estágios ou números de passo no relatório; as linhas INTENT e AUTH são os únicos artefatos do método que um relatório pode conter.

Quando NÃO usar este loop

• Tarefas triviais (o portão cuida delas)
• Perguntas puras sem trabalho de múltiplas etapas: o fable-method simples cobre o formato
• Dentro de uma fase GSD já orquestrada: o GSD possui os estágios lá; aplique as regras do fable-method dentro delas em vez de aninhar loops

Economia de modelo

O loop é agnóstico a modelo. Subagentes de evidência e atacantes são amigáveis a modelos baratos; mantenha a thread principal (decidir, editar) no modelo mais forte disponível e dê aos atacantes mais esforço do que aos coletores quando houver uma escolha.

Uso

/fable-loop <tarefa>   Execute o loop orquestrado completo