Para desenvolvedores · a máquina por trás de “vibe the project”
Todo projeto do Motir passa pelo mesmo instrumento. Os módulos são o Motir e seus agentes. Os botões e chaves são seus: nada avança até que uma pessoa os acione.
Motir e agentesVocê decide
Role o desenho para o lado →
Cada módulo do desenho acima, de perto. Passe o mouse sobre um para encontrá-lo no desenho.
[01] Planejamento com IA
Comece com uma frase, um repositório ou uma importação do Jira, Linear ou Plane. O planejador lê o que existe, incluindo um grafo de código dos seus repositórios, e faz perguntas de acompanhamento onde o pedido é ambíguo.
Ele redige Épicos, Histórias, Tarefas e Subtarefas, cada um com um tipo, um executor, um tamanho e suas arestas blocked_by. O validate_plan verifica a árvore antes de você vê-la.
[02] Você · portão do plano
Nada chega ao quadro até que uma pessoa aprove o plano. Peça alterações em palavras simples; cada rodada é uma nova interação, e o histórico do plano guarda cada versão e o motivo da mudança.
[03] Itens de trabalho
O plano aprovado vira itens de trabalho com Sprints, um Backlog e um roteiro. O executor de cada item de trabalho é agent ou human.
As tarefas manuais (uma conta, um segredo, um registro DNS, a aprovação de um lançamento) são conduzidas um passo de cada vez pelo motir guide.
[04] Execução de agente
Um agente pega o próximo item de trabalho pronto (motir next ou motir run <KEY>), reivindica-o, constrói em seu próprio branch e abre um pull request por repositório, vinculado ao item de trabalho.
Um bug que ele encontra fora do próprio item de trabalho não interrompe a execução: o agente encontra a causa raiz, registra-o com motir log bug na pasta de Bugs como um item de trabalho próprio e segue em frente.
Cada execução registra o harness do agente, o modelo, cada passo e o resultado. Os agentes se conectam por MCP, na sua máquina ou nos agentes hospedados do Motir.
[05] Você · portão do merge
O item de trabalho passa para Implemented e o agente publica Como testar. As Histórias ganham um vídeo de aceitação gravado no CI. Você revisa, aprova e faz o merge; o merge fecha o item de trabalho. Nada chega a Done sem uma pessoa.
[06] Reparo
Um pull request vermelho ou com conflito é reparado no próprio branch com motir fix, em até cinco tentativas. Uma execução que morreu (um notebook fechado, um sandbox perdido) é retomada com motir continue no branch que deixou.
Os bugs registrados pelo caminho esperam na pasta de Bugs; motir fix bugs trabalha neles, do mais antigo para o mais novo.
[07] Ciclo de aprendizado
Um agente que não consegue construir um item de trabalho primeiro pergunta se ele ainda é o que o plano aprovado aprovou (get_approved_shape_verdict), para que uma edição posterior não seja atribuída ao planejador. Se o plano estava errado, ele é replanejado e a mudança é registrada com o motivo.
O erro vira uma lição, ou reforça uma existente; sem uma regra que o cubra, um bug de planejamento é registrado. O próximo plano lê as lições primeiro. Lições que não se repetem em 90 dias são aposentadas.
[08] Memória
Designs, páginas de decisão, documentos, lições, revisões do plano e o histórico de cada execução ficam junto aos itens de trabalho. Você, um novo colega ou o próximo agente podem retomar o projeto meses depois sem que ninguém precise explicá-lo de novo.
O núcleo de gestão de projetos é código aberto sob a GPL-3.0. Hospede você mesmo ou use em motir.co.