Um app, um serviço ou um sistema
Software@BuildableWorks/software
Frames de arquitetura, público, critérios e mercado, e specs agrupadas por domínio.
- Frames
- Specs
$ eidos install @BuildableWorks/softwareNo app: New Root, e depois escolha na lista.
O PRD que continua verdadeiro depois do lançamento.
Uma spec por funcionalidade, no repositório ao lado do código, para que os agentes dos seus engenheiros construam a partir do mesmo arquivo que você escreveu. Cada decisão tomada depois da aprovação cai na spec, com quem a confirmou e quando. Para o product manager e o tech lead de um time que entrega com agentes de código.
Grátis para macOS, Windows e Linux. Sem conta, sem assinatura.
Parece familiar?
“A gente discutiu isso há semanas.” “Não lembro de ter aprovado isso.”
O PRD foi aprovado. Depois os requisitos continuaram mudando, em reuniões, threads, demos e tickets.
Ninguém sabe dizer o que foi combinado
A decisão foi tomada em uma call e vive na lembrança que duas pessoas têm de uma thread. Quando o assunto volta, a reunião é sobre o que foi decidido, não sobre o que construir.
O PRD fica velho na semana em que a entrega começa
O escopo muda no gerenciador de tarefas enquanto o documento continua como foi aprovado. Seis meses depois, metade dele está desatualizada, e quem acabou de chegar não sabe qual metade.
Os agentes nunca o leem
Os agentes dos seus engenheiros constroem a partir do que está no repositório. O PRD mora em outro lugar, então chega até eles colado aos pedaços, quando chega.
Como se encaixa
Uma spec por funcionalidade, ao lado do código.
Instale o Framework (a estrutura) de software, e cada funcionalidade ganha um arquivo markdown no repositório: por que ela existe, o que ela promete e o que ela não vai fazer. O trabalho fica em tarefas que apontam para a spec, então a spec descreve o produto e nunca se enche de estado de sprint.
- Specs
- Uma por funcionalidade, agrupadas por domínio: Intent, Open Questions, Acceptance Criteria, Out of Scope, Constraints & Decisions.
- Frames (os enquadramentos)
- O produto como um todo: arquitetura, público, critérios e mercado. Cada spec é lida contra eles.
- Tarefas
- O trabalho em um quadro, cada tarefa apontando para a spec a que serve, exportado para CSV ou Excel quando alguém pede.
- Decisões
- Decisões dos tipos Development, Scope e Meeting, cada uma tomada para uma spec e confirmada por uma pessoa com nome.
- Comentários
- Conversas na seção ou no critério exato de que tratam, escritas no próprio arquivo.
O que você mais vai usar
As peças que mantêm uma spec honesta depois da aprovação.
- Decisões
Combinado quer dizer confirmado
Registre o que uma reunião resolveu como uma decisão do tipo Meeting na spec. Ela espera na caixa de entrada até a pessoa que decide confirmá-la, e guarda o nome dela e a data.
- Comentários
Perguntas na linha exata
Uma conversa começa no critério de aceite que ela questiona, acompanha esse critério pelas edições e é encerrada quando estiver respondida. Ela está no arquivo, então quem revisa a vê no merge request.
- Backlog
O trabalho ao lado da spec
Tarefas em um quadro, cada uma nomeando a spec a que serve. Feche o ticket e a spec continua verdadeira, porque ela nunca guardou o estado do ticket.
- Tela
Discovery em um quadro branco
Rascunhe o fluxo com o seu designer, depois promova um rascunho a uma spec de verdade. Ela mantém o seu lugar na tela e abre o seu arquivo.
- Agente de IA
Os agentes leem o que você escreveu
Claude Code ou Codex ao lado da página, com a spec anexada.
/grillfaz o agente perguntar onde a spec está vaga antes que alguém construa a partir dela. - Git
Toda mudança tem um autor
Um histórico e um diff para cada spec, e uma versão com nome para o que foi aprovado, sem abrir um terminal.
Quem concordou, e quando
A decisão está na spec, não em uma thread
Cada decisão tomada para uma spec aparece na seção Constraints & Decisions dela, marcada quando uma pessoa a confirma. Uma decisão que um agente tomou sozinho chega como Proposed e continua não confirmada até alguém assumi-la. O “não lembro de ter aprovado isso” tem resposta: o nome e a data estão no arquivo.
- Os tipos Development, Scope e Meeting para começar, e os seus próprios
- Atribuída à pessoa que decide, com uma caixa de entrada e um contador
- Os agentes registram em nome próprio e nunca confirmam as próprias decisões
Nada muda em silêncio
Um diff para cada mudança na spec
Abra o histórico do arquivo de uma spec para ver quem a mudou e quando, e o diff de qualquer commit contra a spec como ela está hoje. As decisões e as conversas de comentários fazem parte do arquivo, então aparecem no mesmo diff e no merge request.
Da discovery à spec
Rascunhe primeiro, depois torne real
Monte um fluxo em uma tela cujos cartões são as suas specs, desenhados ao vivo a partir dos arquivos delas. Quando uma ideia estiver pronta, promova o rascunho: ele vira uma spec na coleção que você escolher, e as setas ficam onde você as desenhou.
Para o tech lead
Configurado no repositório, verificado em cada pull request
Instale o Framework no repositório, aponte para ele todo agente que lê o AGENTS.md e rode eidos check na sua CI, para que um pull request que quebra uma spec falhe (um job de CI de um só comando, eidos ci, chega na próxima versão). Os product managers usam o app de desktop; ninguém precisa aprender git para escrever uma spec.
$ npm install -g eidosmd
$ eidos install @BuildableWorks/software
$ eidos agents --write
✓ created AGENTS.md with the Eidos nudge
$ eidos checkComece por aqui
Instale o Framework de software.
Frames para o produto e specs para as funcionalidades, com Out of Scope em todo template (o modelo). Escolha-o no app ao criar uma raiz nova no repositório, ou instale-o de um terminal. Depois ligue o Backlog e Decisões em Plugins do núcleo.
Coloque o PRD onde o código está.
Baixe o Eidos MD, instale o Framework de software no seu repositório e escreva a spec da próxima funcionalidade que o seu time vai começar.
Grátis para macOS, Windows e Linux. Seus arquivos continuam texto simples, em uma pasta que é sua.