Roles & me.md

Not everyone on a root plays the same part. One person holds the intent; another builds from it; another reviews it. They need different answers to the same question. Eidos handles that with two files.

.eidos/roles/<role>.md

One response contract per role: how an agent talks to that kind of person. Vocabulary and depth, what to surface and what to fold away, who holds which decisions. The files are committed and team-tunable: if your developers want less hand-holding, edit developer.md and everyone gets it.

Seed	Its cast
software	Developer · Designer · Project Manager · Stakeholder
book	Author · Editor · Reader · Collaborator
research	Researcher · Reviewer · Sponsor

A real one, trimmed:

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

Even the role written for the most technical reader routes product decisions back to the people who own the product. That is the human-first principle, per role.

.eidos/me.md

Local, gitignored, one per person. It names the role you are in and calibrates it on three axes:

Axis	What it changes
Ownership	What you own on this root, and so which decisions come back to you
Experience with the scope	How much orientation you get before the answer
Technical capacity	Vocabulary and depth, independent of role

A senior developer new to this product and a junior developer who has been on it two years need opposite things; role alone cannot tell them apart. Blank is fine: it means full facilitation, as for the people who own the product.

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

In eidosmd, the role, ownership, and experience with the scope are each root’s, and the rest of who you are is not: your name, email, technical capacity, and a note on how you like to be helped are set once (eidos whoami --global, or Preferences → Me in the browser) and copied into each root’s me.md as it opens, as plain lines an agent reads. A field you change in one root’s me.md stays that root’s; the others follow when you change them.

Who owns the product

No role is required. The people who own the product hold the intent, the scope, and the decisions, whatever their role: a product manager, a tech lead, an author, a principal investigator. A seed may write a role for that seat (the book seed’s Author), and each person’s Ownership calibration in me.md says what they own. What matters is that a scope question can be settled, and everyone knows by whom.

An agent reads me.md before acting, then the role file it names, and responds as that file defines. Without an owner there is nobody to route a decision back to, and the agent either stalls or decides.

In eidosmd, owning the framework and being able to change it are also toggles on a user, apart from the role: Owner marks who holds the final call, and Editor who may change the framework and its plugins’ shared settings. A role says how an agent responds to someone; the toggles say who decides and who edits. Users →

Next

• Working with Agents