Skip to content

eidos

The main skill: author and validate blueprints, against the framework your root declares.

It reads the framework from your root — never from a copy of its own — and takes three things from Framework.md: the Schema, the naming convention, and the target collection’s flavors. Then it:

  1. Picks a flavor (the default unless you choose another) and reads that shape for the body.
  2. Names the file for its title in the framework’s convention, with a permanent kebab-case id inside.
  3. Generates frontmatter from the properties that apply to that collection — so a scoped property never lands where it makes no sense.
  4. Leads with the shape’s opening section and presses hardest on its non-goals section.

Point it at an existing blueprint and it checks:

  • Frontmatter against the framework’s Schema — id kebab-case, dates as YYYY-MM-DD, custom properties scoped to the right collection.
  • Missing body sections against the blueprint’s flavor — a blueprint on a light flavor is never faulted for a fuller one’s sections.
  • An absent non-goals section, flagged first among the missing.
  • Anything skipping the labeling the shape asks for.
  • That no work-tracking fields crept in.

The output is a review a human acts on, never a gate. A missing core property is surfaced and added with a note on why; a missing section is noted and offered. It never refuses the file.

One of three skills that does. eidos ships with the EIDOS.md ruleset committed inside it, so it keeps working where it can’t reach the repository root. Why →