Roles y me.md

No todo el mundo en una raíz juega el mismo papel. Una persona sostiene la intención; otra construye a partir de ella; otra la revisa. Necesitan respuestas distintas a la misma pregunta. Eidos lo resuelve con dos archivos.

.eidos/roles/<role>.md

Un contrato de respuesta por rol: cómo le habla un agente a ese tipo de persona. Vocabulario y profundidad, qué mostrar y qué plegar, quién tiene qué decisiones. Los archivos están en commit y el equipo los ajusta: si tus desarrolladores quieren menos acompañamiento, edita developer.md y todos lo reciben.

Semilla	Su reparto
software	Developer · Designer · Project Manager · Stakeholder
book	Author · Editor · Reader · Collaborator
research	Researcher · Reviewer · Sponsor

Uno real, recortado:

.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.

Incluso el rol escrito para el lector más técnico devuelve las decisiones de producto a las personas dueñas del producto. Ese es el principio de la persona primero, rol por rol.

.eidos/me.md

Local, ignorado por git, uno por persona. Nombra el rol en el que estás y lo calibra en tres ejes:

Eje	Qué cambia
Propiedad	Qué es tuyo en esta raíz, y por tanto qué decisiones vuelven a ti
Experiencia con el alcance	Cuánta orientación recibes antes de la respuesta
Capacidad técnica	Vocabulario y profundidad, independientemente del rol

Un desarrollador sénior nuevo en este producto y uno júnior que lleva dos años en él necesitan cosas opuestas; el rol solo no puede distinguirlos. En blanco también vale: significa facilitación completa, como para las personas dueñas del producto.

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

En eidosmd, el rol, la propiedad y la experiencia con el alcance son de cada raíz, y el resto de quién eres no: tu nombre, tu correo, tu capacidad técnica y una nota sobre cómo te gusta que te ayuden se fijan una vez (eidos whoami --global, o Preferences → Yo en el navegador) y se copian en el me.md de cada raíz cuando se abre, como líneas sencillas que un agente lee. Un campo que cambies en el me.md de una raíz se queda en esa raíz; los demás siguen tus cambios.

Quién es dueño del producto

Ningún rol es obligatorio. Las personas dueñas del producto sostienen la intención, el alcance y las decisiones, sea cual sea su rol: un product manager, un tech lead, un autor, un investigador principal. Una semilla puede escribir un rol para ese asiento (el Author de la semilla del libro), y la calibración Propiedad de cada persona en me.md dice de qué es dueña. Lo que importa es que una cuestión de alcance se pueda zanjar, y que todos sepan quién la zanja.

Un agente lee me.md antes de actuar, después el archivo de rol que nombra, y responde como ese archivo define. Sin dueño no hay nadie a quien devolver una decisión, y el agente o se atasca o decide.

En eidosmd, ser dueño del Framework y poder cambiarlo son además interruptores de un usuario, aparte del rol: Propietario marca quién tiene la última palabra, y Editor quién puede cambiar el Framework y los ajustes compartidos de sus plugins. Un rol dice cómo responde un agente a alguien; los interruptores dicen quién decide y quién edita. Usuarios →

Siguiente

• Trabajar con agentes