Pular para o conteúdo

Papéis e me.md

Nem todo mundo em uma raiz faz o mesmo papel. Uma pessoa sustenta a intenção; outra constrói a partir dela; outra a revisa. Elas precisam de respostas diferentes para a mesma pergunta. O Eidos resolve isso com dois arquivos.

Um contrato de resposta por papel: como um agente fala com aquele tipo de pessoa. Vocabulário e profundidade, o que trazer à tona e o que dobrar, quem tem quais decisões. Os arquivos são commitados e ajustáveis pelo time: se os seus desenvolvedores querem menos acompanhamento, edite o developer.md e todos recebem.

Semente Seu elenco
software Developer · Designer · Project Manager · Stakeholder
book Author · Editor · Reader · Collaborator
research Researcher · Reviewer · Sponsor

Um de verdade, resumido:

.eidos/roles/developer.md
# Developer
## Who they are
Builds the product from its blueprints. Reads one to answer "what am I
building, exactly?" and to find the edges and the things still undecided.
## How to respond
- **Vocabulary & depth:** technical depth is welcome: data models, dependencies, failure modes.
- **Decisions:** clarify and flag, don't decide. Scope and direction belong to the owners.
- **Surface:** requirements, dependencies, out of scope, decisions, and anything underspecified that would block a build.

Até o papel escrito para o leitor mais técnico devolve as decisões de produto às pessoas donas do produto. Esse é o princípio da pessoa em primeiro lugar, papel por papel.

Local, ignorado pelo git, um por pessoa. Nomeia o papel em que você está e o calibra em três eixos:

Eixo O que muda
Propriedade O que é seu nesta raiz, e portanto quais decisões voltam para você
Experiência com o escopo Quanta orientação você recebe antes da resposta
Capacidade técnica Vocabulário e profundidade, independentemente do papel

Um desenvolvedor sênior novo neste produto e um júnior que está nele há dois anos precisam de coisas opostas; o papel sozinho não consegue distingui-los. Em branco também serve: significa facilitação completa, como para as pessoas donas do produto.

Janela do terminal
eidos roles
eidos whoami --role developer --experience "new to this product" --capacity fluent

No eidosmd, o papel, a propriedade e a experiência com o escopo são de cada raiz, e o resto de quem você é não: seu nome, seu email, sua capacidade técnica e uma nota sobre como você gosta de ser ajudado são definidos uma vez (eidos whoami --global, ou Preferences → Eu no navegador) e copiados para o me.md de cada raiz quando ela abre, como linhas simples que um agente lê. Um campo que você mudar no me.md de uma raiz fica nessa raiz; os outros acompanham quando você os muda.

Nenhum papel é obrigatório. As pessoas donas do produto sustentam a intenção, o escopo e as decisões, seja qual for o seu papel: um product manager, um tech lead, um autor, um pesquisador principal. Uma semente pode escrever um papel para esse lugar (o Author da semente do livro), e a calibração Propriedade de cada pessoa no me.md diz do que ela é dona. O que importa é que uma questão de escopo possa ser encerrada, e que todo mundo saiba por quem.

Um agente lê o me.md antes de agir, depois o arquivo de papel que ele nomeia, e responde como aquele arquivo define. Sem um dono não há ninguém para quem devolver uma decisão, e o agente ou trava ou decide.

No eidosmd, ser dono do Framework e poder mudá-lo são também interruptores de um usuário, à parte do papel: Proprietário marca quem tem a palavra final, e Editor quem pode mudar o Framework e as configurações compartilhadas dos seus plugins. Um papel diz como um agente responde a alguém; os interruptores dizem quem decide e quem edita. Usuários →