Antes de queimares muitos tokens com um grande enxame de agentes num novo projeto, o velho ditado da marcenaria "Mede duas vezes, corta uma vez!" vale a pena ser revisto como "Verifica os teus beads N vezes, implementa uma vez," onde N é basicamente quantas vezes conseguires suportar. Descobri que continuas a obter mais e mais melhorias, mesmo que sejam subtis, quantas mais vezes executares isto em sequência com o Opus 4.5 (nota que o seguinte prompt é apenas para uso APÓS teres transformado o teu plano inicial em markdown em beads usando o outro prompt que te dei recentemente no meu post muito longo sobre os meus fluxos de trabalho): "Releia AGENTS dot md para que ainda esteja fresco na tua mente. Verifica cada bead super cuidadosamente-- tens a certeza de que faz sentido? É ótimo? Poderíamos mudar algo para fazer o sistema funcionar melhor para os utilizadores? Se sim, revisa os beads. É muito mais fácil e rápido operar no "espaço de planeamento" antes de começarmos a implementar estas coisas! NÃO SIMPLIFIQUES AS COISAS! NÃO PERDAS NENHUM RECURSO OU FUNCIONALIDADE! Além disso, certifica-te de que, como parte destes beads, incluímos testes unitários abrangentes e scripts de teste e2e com ótimos registos detalhados para que possamos ter a certeza de que tudo está a funcionar perfeitamente após a implementação. Lembra-te de usar APENAS a ferramenta `bd` para criar e modificar os beads e para adicionar as dependências aos beads. Usa ultrathink." Eu costumava executar isso apenas uma ou duas vezes antes de começar a implementação, mas experimentei recentemente executá-lo 6+ vezes, e continuou a fazer refinamentos úteis. Se começar a estabilizar em termos de melhorias incrementais nos beads, poderias tentar iniciar uma nova sessão CC, começando com: "Primeiro lê TODOS os arquivos AGENTS dot md e README dot md super cuidadosamente e compreende TODOS os dois! Depois usa o modo de agente de investigação de código para compreender totalmente o código, a arquitetura técnica e o propósito do projeto. Usa ultrathink." E depois seguir com o mesmo prompt mostrado acima, mas precedido por: "Recentemente transformámos um arquivo de plano em markdown numa série de novos beads. Quero que revises e analises cuidadosamente estes usando `bd` e `bv`." Quanto mais complexo e intrincado for o teu plano em markdown, mais relevante é esta técnica. Se tiveres um plano pequeno e trivial e um projeto muito simples, isto é obviamente exagerado. Mas nesse caso, provavelmente verás pouco em termos de ganhos/alterações incrementais com cada rodada, então deve ser bastante óbvio quando é hora de parar. Apenas lembra-te: os tokens de planeamento são muito menos e mais baratos do que os tokens de implementação. Mesmo um plano em markdown muito grande e complexo é mais curto do que alguns arquivos de código substanciais, quanto mais um projeto inteiro. E os modelos são muito mais inteligentes ao raciocinar sobre um plano que é muito detalhado e desenvolvido, mas ainda trivialmente pequeno o suficiente para caber facilmente na sua janela de contexto (esta é realmente a chave por trás do meu foco obsessivo no planeamento e porque passei mais de 80% do meu tempo nessa parte). E se te apoiares no GPT Pro com Raciocínio Estendido na aplicação web para o planeamento inicial, como eu defendo fortemente (ou seja, para criar e melhorar o teu plano em markdown que eventualmente transformas em beads), basicamente obténs isso numa base de "tudo o que puderes comer" com um plano Pro, então aproveita ao máximo isso! Nenhum outro modelo pode tocar no Pro na web quando lida com entradas que cabem facilmente na sua janela de contexto. É verdadeiramente único. ...