Matt Pocock / improve-codebase-architecture
Um agente consegue dizer onde sua arquitetura realmente dói?
Ele produz candidatos. Escolher quais importam continua com você.
O que vale lembrar
- Primeiro relatório, depois mudança. Essa ordem é o que torna seguro rodar.
- Limite a um subsistema, porque relatório de repositório inteiro é grande demais para agir.
- Achados são candidatos, não veredictos. Alguns estarão errados por razões que só seu time conhece.
- Combina com grill-me quando você quer testar o raciocínio antes de se comprometer.
01O que muda na prática
Trabalho de arquitetura costuma falhar por razões sociais e não técnicas: ninguém concorda por onde começar, então nada começa. Uma lista concreta de candidatos com motivos transforma essa discussão em decisão.
Apresentar achados como relatório também evita a coisa mais perigosa que um agente pode fazer, que é refatorar vários módulos ao mesmo tempo enquanto você assiste.
02Onde decepciona
Ela vê o código, não a história. Algumas fronteiras estranhas existem por uma restrição que não está escrita em lugar nenhum, e a skill vai propor remover com toda a confiança.
Relatórios longos também convidam ao aumento de escopo. A disciplina de escolher um candidato é inteiramente sua.
Instalação e primeira execução
- Instale com o CLI de skills a partir de mattpocock/skills, sob MIT.
- Rode em uma área e não no repositório inteiro, para o relatório continuar revisável.
- Escolha um ou dois candidatos. Uma lista de trinta achados é uma forma de não escolher nada.
Perguntas que as pessoas realmente fazem
- Ela muda o código sozinha?
- Ela relata primeiro e explora os candidatos que você escolher, em vez de refatorar de imediato.
- Que tamanho de base aguenta?
- Limite a um subsistema. Relatórios de repositório inteiro costumam ser grandes demais.
- Quem mantém?
- Matt Pocock, no repositório público de skills sob licença MIT.
Fontes
Versões legíveis por máquina desta página