Shaping Your Framework

You picked a seed at init because it was closest. At some point it stops fitting, and that’s expected — a framework may reshape or override any of it without forking the standard.

The tool is configure. It edits _eidos/Framework.md, scaffolds folders and shape files, and reconciles the blueprints already on disk.

What it changes, and what it doesn’t

`configure` does	Use something else for
Add or change a collection	Authoring blueprints → `eidos`
Add or change a flavor	A collection’s `index.md` → `index`
Add, rename, or retire a custom property, and backfill it	Version upgrades → `migrate`
Refresh the Top-Level index	The Eidos core properties → `migrate`

Adding a collection

The common case: a decisions folder for ADRs, or Roles as content rather than as agent configuration.

Adding one means answering five things, which is configure’s whole interview:

Its name, in the naming convention.
A one-line description of what it holds.
Its flavors — at least one shape, with one marked default.
How the canvas draws it: file, card, or card from ## Section.
Whether it groups its blueprints one level deep, and if so, whether a property names the grouping.

Adding a flavor

Cheaper than a collection, and usually the right answer when blueprints in one collection vary.

The convention that constrains it: one shape family per collection, declared as flavors. What flexes is which sections appear and which flavor a blueprint uses — never their order or names within a flavor. The shape is never forked per category.

So: a lighter variant to grow out of, or a deliberate alternative, is a flavor. “Integration specs have these five different sections” is not a flavor — that’s a different collection, or a sign the sections should be optional in one shape.

Two patterns that work:

Light → full. micro grows into full. The light one keeps the non-negotiables (intent, criteria, non-goals) and drops what can wait.
Deliberate variant. Two flavors of equal weight for genuinely different kinds of unit in the same collection, neither one a stepping stone.

Adding a property

configure presses for all four fields, because a property missing any of them is unusable:

Field	Why it’s required
Name	The frontmatter key.
Type	One of `Text`, `List`, `Number`, `Checkbox`, `Date`, `Date & time`.
Applies To	`all`, or a list. This is what stops it landing where it makes no sense.
Meaning	What it’s for. Without it, people fill it inconsistently within a month.

Then it backfills the blueprints the property applies to, so the root stays uniform rather than splitting into before-and-after eras.

Before you add one, check three things

Would a body section be better? If it wants more structure than one of the six types, it belongs in the body. The standard limits property types to those six precisely to force this question.

Is it a soft label or is it structural? A category that drives views and filtering is a soft label — an off-list value stays valid. A category that changes which sections a blueprint has is a flavor, and flavor is the property that carries it.

Is it work tracking in disguise? The standard is absolute here: no sprint, estimate, or assignee. Also treat with suspicion anything that means “how far along”: a progress, a phase, a target_date. Bridge to your tracker with a link instead.

Retiring a property

Also configure. Retiring is the neglected half — a root accumulates properties nobody fills, and each one adds noise to every blueprint.

If a property has been blank on the last twenty blueprints, it isn’t part of your contract any more. Remove it.

Tuning a role

Role files are committed and team-tunable — edit them directly. If your developers want less orientation, or your stakeholder role is pitching too technical, change the file and everyone gets it.

Add a role by adding a file. The cast is your framework’s own; the seeds’ casts are illustrations, not a set. More →

Two conventions to keep in view while reshaping

When a framework is worth publishing

Once your framework has settled, it’s form with no content — which makes it exactly the artifact you hand to another team. That’s what a seed is.

If two products in your organisation should be described the same way, publish the framework rather than copying a root and deleting its contents. One framework, any number of roots.