Every part of your product, one file you can check.
A blueprint is a plain markdown file: typed properties on top, a body shaped by a template, and a permanent id that every task, decision, and canvas node points at. You declare the framework it follows, and eidos check tells you where a file has drifted from it.
Free for macOS, Windows, and Linux. No account, no subscription.
Your framework
A structure you declare, not one you are handed
The framework lives in your root: the collections you keep (specs, chapters, characters, investigations, whatever your work is made of), a template for each variant with the sections it offers and the ones it requires, and a Properties table with types, options, and what each one means. Edit it as forms under Framework settings, or with eidos configure from a terminal.
- Collections and variants, named in your words
- Required sections and typed properties with options
- Vocabulary and roles, so people and agents use the same words
The health check
A health check you can act on
eidos check reads every blueprint against your framework: a value off a property’s options, a required property left empty, a work-tracking field on a blueprint, a stale index, a broken link. The Health Check lists each finding under its file, and Fix all supported issues runs every fix the app knows, asking first before any that renames a file or changes an id.
- Errors for what is wrong on any reading, warnings for gaps
- Whether a warning fails is the root’s setting, kept in git
- The same findings in the app, a terminal, and CI
The Registry
Start from a framework someone already shaped
The Registry holds frameworks people have published: software, a book, research, a fictional world, a channel, a school, a renovation, a wedding, and more. Open one in the app and every piece is marked as missing from your root, the same, or different. Include in this root brings in the whole thing or only the collection you want, and asks before it replaces anything you hold differently.
- In the app, or
eidos install @owner/name - Keep current or Accept incoming, conflict by conflict
- Publish your own with a pull request
Collections
Every collection is a table
Each collection opens as a table of its blueprints, sorted, filtered, and searched by any property. The filters live in the address, so a link opens the same view, and Save as view keeps one for you or shares it with everyone in the root.
Surfaced, never refused
Properties are the agreement and sections are guidance. A missing property is noted and a missing section is offered; a file is never refused, because a check that refuses files gets worked around. A section the blueprint lacks is drawn greyed where it belongs, with a + that adds it.
A permanent id, wherever the file goes
Each blueprint keeps an id such as B-V63. Move it to another group, or give it a new id, and every task, decision, comment, canvas node, and link that points at it follows. Find anything by id or title from Quick Open.
Set up with your agent
Making a new root in the desktop app, Set up with AI Agent can have your agent read the folder first, then recommend a framework from the Registry or propose one of its own. Nothing is written until you have reviewed it and pressed Create root.
How it connects
Everything else points at a blueprint.
No plugin keeps a second copy of what a blueprint says. Each one refers to it by its permanent id, and most write what they know back into it.
- Backlog
A task serves blueprints by id, and each blueprint lists its tasks under Attached tasks and in a Tasks section.
- Decisions
A decision names the blueprints it was made for and is written into their Decisions section.
- Canvas
A node is a blueprint drawn live from its file, and a sketch becomes one through the same template.
- Comments
A thread anchors to a section or an acceptance criterion and is written at the foot of the file.
- AI Agent
The open blueprint rides along with each message, and
/checkruns the health check into the chat. - Linter
One markdown style on every save, with drift reported in the health check.
- Git
Every blueprint has its history and a diff, committed with the code it describes.
From the shell
The check, from a terminal
The same findings the page shows, with an exit code for CI and --json for an agent. A property is set from the shell, coerced to its declared type, and checked as it is written.
$ eidos check specs/billing/gift-cards.md
Blueprints (Eidos 5.5.0 · kebab-case) 1 blueprint
specs/billing/gift-cards.md
⚠ summary-missing no `summary`; the collection index will flag it
⚠ work-tracking-field `estimate` is a work-tracking field; a blueprint captures state and intent, not work (link to a tracker instead)
⚠ property-option `status: WIP` is not one of its options (Draft, Intake, In Progress, Done, Archived, Deprecated)
⚠ linter/list-marker one marker for every unordered list; the file drifted (eidos linter --fix)
⚠ 0 errors, 4 warnings
$ eidos property set @B-G24 status Draft
✓ specs/billing/gift-cards.md status: Draft
⚠ summary-missing no `summary`; the collection index will flag it
⚠ work-tracking-field `estimate` is a work-tracking field; a blueprint captures state and intent, not work (link to a tracker instead)Write down what you’re making.
Download Eidos MD, open a folder, and start from the framework closest to your work. Everything it gives you can be reshaped later.
Free for macOS, Windows, and Linux. Your files stay plain text in a folder you own.