Use Cases

Eidos is for anyone who needs a system of organization with adherence: a place where the definition of what you are building is written once, kept true, and read by every person and every agent who works on it. The payoff is speed. When the definition holds, nobody re-explains it, nobody argues from memory, and an agent can be pointed at it and trusted to stay inside it.

The test

If you have ever answered the same question about your product twice, or found two documents that disagree about what a feature is, you have the problem Eidos solves.

A software product

A team building an app keeps one blueprint per feature: what it is, why it exists, what counts as done, what is out of scope. Every spec is born from the same template, carries the same properties, and is checked against the framework the team wrote. The work happens elsewhere, in a backlog of tasks that point at the blueprint they serve, so the definition never fills up with sprints and estimates.

• A new engineer reads the root and knows the product in an afternoon.
• A coding agent runs eidos instructions, reads the blueprint it is implementing, and writes code that matches it, because there is exactly one place the answer lives.
• A product manager changes the definition in the blueprint, and the change is a commit everyone sees, with the discussion beside it.
• A release is a version: a name for a commit of the root, so what was promised can be read later exactly as it stood.

The software seed → · Agents →

A solo builder with agents

One person, several agents, and a product that grows faster than memory. The root is the memory: each session starts by reading the blueprints that matter, each change to the definition goes into a file the next session will read, and the check says when a blueprint drifted from the framework. The browser is where the person thinks, on a canvas of sketches that promote into blueprints, and where the agent is asked, through Plato, with the open blueprint as context.

A studio or an agency

A framework is reusable. A studio writes one for the kind of product it builds, publishes it to the Registry, and installs it into every new client’s repository with one command. Every project then reads the same way, every spec has the same shape, and a person moving between clients never relearns the structure. The client signs off on blueprints, not on a slide deck, and the signed-off state is a version.

The Registry → · eidos install →

A book, a study, a body of work

The same system holds anything with parts that must agree. A book is chapters and characters that stay consistent across a manuscript; a research programme is investigations that share a method and a vocabulary. The seeds for both ship in the CLI, and the framework is yours to reshape.

The book seed → · The research seed →

What you get either way

Adherence

A framework in .eidos/ that every blueprint is checked against. Drift is reported, never silently accepted.

One source of truth

One markdown file per unit of the product, in your repository, as true of what is planned as of what shipped.

Speed

Scaffolding, validation, an index, a browser, and the agent workflow are one command. The thinking is yours; the mechanics are not.

Utility for agents

A root an agent can read, cite, and stay inside. The guidance is a command, not a prompt someone has to remember.

Next

Quick StartInstall the CLI, create a root, write your first blueprint.

Why Eidos ExistsThe problem it solves, and when not to use it.