Media / Book
@BuildableWorks/book
The book seed the standard ships, for a book, long-form argument, or course; frames for premise, reader, voice, and market, and chapters grouped by part.
1installs in the last 30 days1installs in total
Install
The whole root
npx eidosmd install @BuildableWorks/bookOne collection, or one variant into a collection you already have
npx eidosmd install @BuildableWorks/book --collection Framesnpx eidosmd install @BuildableWorks/book --variant Frames.reader- Source
- BuildableWorks/Eidos on GitHub
- Tag
v5.4.0- Path
seeds/book- Eidos version
- 5.4.0
- Naming
- kebab-case
- Keywords
- seedbookchapterswriting
- Published
- September 20, 2026
What it contains
Collections
Framesframe
What every chapter is judged against: what the book argues, who it is for, how it sounds, and where it sits.
Variants
premisedefaultwhat the book says, and why it has to exist
Template: templates/frame.premise.md
# Premise
## The Argument
_In a few sentences: what this book claims, or what story it tells. If you can't say it without a list, it isn't a premise yet._
## Why It Has To Exist
_What is wrong, missing, or misunderstood in the world without this book. The problem the reader has._
## The Shape of It
_How the whole book is built — parts, arc, the movement from the first page to the last. Not a table of contents; the logic behind one._
## What It Is Not
_The adjacent book you are deliberately not writing. This is where a book's scope is held._
readerwho it is for, and what changes for them
Template: templates/frame.reader.md
# Reader
## Who They Are
_The specific person you are writing to. One or a few kinds; name them. "Everyone" is not a reader._
## What They Bring
_What they already know, already believe, and already tried. What vocabulary you can use without explaining it, and what you cannot._
## What Changes For Them
_What they can do, believe, or feel at the end that they couldn't at the start. The book's promise, stated from their side._
## Who It Is Not For
_The reader you will lose, and are choosing to lose. Naming them is what lets you write plainly to the ones you keep._
voiceperson, tense, register, and the rules the prose keeps
Template: templates/frame.voice.md
# Voice
## Person & Tense
_First, second, or third; past or present. Whether it varies, and where._
## Register
_How it sounds read aloud — plain, formal, wry, urgent. Two or three writers or books it stands near, and how it differs from each._
## Rules It Keeps
_The specific, checkable habits: sentence length, jargon policy, how sources are cited, whether it addresses the reader directly, what it never does. These are what an editor checks a draft against._
## Rules It Breaks, On Purpose
_Where the book deliberately departs from its own register, and what that departure is for._
marketshelf, comparables, and how it reaches readers
Template: templates/frame.market.md
# Market
## The Shelf
_Where it sits in a shop or a store's category tree, and who it sits beside._
## Comparables
_Three or four books a reader would already own. For each: what it does well, and what this one does that it doesn't._
## How It Reaches Readers
_Publisher, self-published, serialized, a course, a newsletter first. The path from written to read._
## What Success Looks Like
_Copies, readers, citations, invitations, a changed mind. Say which, and roughly how much — a book with no stated bar can't be finished._
Chapterschapter
The book's units, one per chapter, grouped by part.
Grouped by Parts
Variants
fulldefaultthe complete chapter template
Template: templates/chapter.full.md
# {{title}}
## Intent
_Why this chapter exists — the work it does that no other chapter does. One or two paragraphs. This is the stable part: if Intent changes substantially, you probably have a different chapter, not an edit to this one._
### Assumptions
_What you're taking as given about the reader arriving here — what they already accept, what they've already read. Nested under Intent because they frame it. Surface them so a guess doesn't slip into What Happens as if it were settled._
## Open Questions
_Unresolved questions — what you don't yet know about this chapter and still need answered. Kept high, right after Intent, so uncertainty is seen rather than buried. When one is settled it graduates into an Assumption, a beat, or a Decision._
## What Happens
_The chapter's content as observable beats — the argument it makes or the events it covers, in order. Label each beat **B1:**, **B2:**, … (bold, unique within this chapter). Keep each beat short and checkable against a draft; push rich detail into a table or sub-section it points to. Evolves freely._
- **B1:** <!-- the first thing this chapter does to the reader -->
## What the Reader Leaves With
_The checkable outcome — what a reader can do, believe, or feel at the end that they couldn't at the start. If it isn't listed here, this chapter doesn't promise it._
## Out of Scope
_Explicit non-goals — what this chapter deliberately does not cover, and which chapter covers it instead. The section the standard leans on hardest, because this is where a book's structure is actually held. A chapter without it tends to sprawl into its neighbors._
## Dependencies
_What a reader must have read, or you must have written, before this chapter works: earlier chapters, a Frame, an interview, a permission. The `depends_on` property at the top is the chapter-only subset of this, as links. Reference other chapters as markdown links — never bare names._
## Notes & Decisions
_Two things under one header. **Notes**: sources, quotes to chase, craft reminders specific to this chapter. **Decisions**: an append-only log, one line each, with an optional but recommended date._
<!-- 2026-08-26: Moved the framing anecdote to Chapter 1, it was doing the same work twice. (Brenton) -->
sketchIntent, Open Questions, What Happens, Out of Scope; grow into full
Template: templates/chapter.sketch.md
# {{title}}
## Intent
_Why this chapter exists — the work it does that no other chapter does. A paragraph is plenty here._
## Open Questions
_What you don't yet know about this chapter. Honest holes beat invented certainty._
## What Happens
_The beats, in order, as far as you have them. Label each **B1:**, **B2:**, … Rough is fine; a sketch is allowed to be thin, but not vague._
- **B1:**
## Out of Scope
_What this chapter deliberately does not cover, and which chapter covers it instead. Even in a sketch, this is the section worth filling — it's what keeps neighboring chapters from eating each other._
Other folders
- assets Images, diagrams, and documents the blueprints link to.
Roles
Collaboratorroles/collaborator.md
# Collaborator
## Who they are
Writes alongside the owner — a co-author, ghostwriter, or researcher. Reads a chapter to answer "what exactly am I drafting, and in whose voice?"
## How to respond
- **Vocabulary & depth:** full detail. The Voice frame's rules, the beats in order, the dependencies, and anything still undecided that would send a draft the wrong way.
- **Decisions:** clarify and flag, don't decide. Argument, structure, and voice belong to the Framework Owner; surface the ambiguity rather than resolving it in the prose.
- **Surface / hide:** surface What Happens, Voice, Dependencies, and Open Questions. Say plainly when a beat is underspecified.
- **Focus:** what is promised versus what is vague; whether a chapter's beats can actually be drafted from what is written.
## Calibration
**Experience with the scope** sets how much of the Frames to restate before getting to the chapter.
Editorroles/editor.md
# Editor
## Who they are
Reads for structure before prose. Wants to know what each chapter is for, whether the book delivers what the Premise promises, and where two chapters are doing the same work.
## How to respond
- **Vocabulary & depth:** craft terms are welcome — arc, pacing, throughline, register. Skip production mechanics unless asked.
- **Decisions:** name the structural problem and the options; the cut, the merge, and the reorder belong to the Framework Owner.
- **Surface / hide:** surface Intent, What the Reader Leaves With, Out of Scope, and Dependencies across chapters. Fold away drafting notes.
- **Focus:** promises made in the Frames versus what the Chapters actually deliver; overlap between neighbors; a chapter whose Intent no longer matches its beats.
## Calibration
**Experience with the scope** sets how much of the book's argument to restate; **technical capacity** rarely matters here — talk craft, not tooling.
Framework Ownerroles/framework-owner.md
# Framework Owner
## Who they are
Holds the **intent, scope, and decisions** — true ownership of the product, whatever kind it is: an app, a body of research, a methodology, any other form of thought or effort. The person Eidos is built for — they think through what the product is, and they own the calls. Everything else serves their clarity.
## How to respond
- **Vocabulary & depth:** lead with the product's own terms and the decision at hand. But many Framework Owners are also technical — don't assume otherwise; follow their **technical capacity** calibration and go as deep as they want, rather than withholding mechanism by default.
- **Decisions:** theirs. Bring choices and trade-offs for them to decide; never decide direction or resolve an Open Question on their behalf. Press hardest on **Out of Scope**.
- **Surface / hide:** surface intent, scope, audience, criteria, and the consequences of a choice; fold mechanism into a link they can follow.
- **Focus:** Intent, Out of Scope, the Premise and Reader frames, and whether each chapter still says what they mean.
## Calibration
Their **experience with the scope** and **technical capacity** adjust the dials above — a non-technical owner gets less jargon and more translation; a technical owner gets the mechanism without hand-holding; a deeply-experienced one gets less orientation. Determining direction is the constant; technical fluency is not assumed either way.
Readerroles/reader.md
# Reader
## Who they are
A beta reader or early audience. Not a maker of the book — a test of it. Reads to react, not to fix.
## How to respond
- **Vocabulary & depth:** plain language. No craft jargon, no process, no drafting state. Talk about what the book says and does, never how it is being made.
- **Decisions:** none are theirs. Ask what landed and what didn't; don't invite them to redesign the book.
- **Surface / hide:** surface Intent and What the Reader Leaves With, in the book's own terms. Hide Open Questions, Decisions, Dependencies, and anything marked Cut.
- **Focus:** whether the promise in the Frames is one they'd want, and whether a chapter delivered it.
## Calibration
**Technical capacity** is assumed low for the book's craft regardless of the reader's own field; **experience with the scope** sets how much of the premise to set up first.
Top-level documents
- README
README.mdthe root's front door: what this book is, and pointers in.
Custom properties
status | Text | every collection | Lifecycle stage. (Draft | Outlined | Drafted | Revised | Final | Cut) |
|---|---|---|---|
date_created | Date | every collection | YYYY-MM-DD. Set once. |
date_modified | Date | every collection | YYYY-MM-DD. The last change. |
tags | List | every collection | Free tags. |
partrequired | Text | Chapters | The group: matches the blueprint's sub-folder. An unknown value warns. |
depends_on | List | Chapters | Chapters a reader must have read first, each a markdown link. |
README
The first top-level document, as the author wrote it at this tag, placeholders included. Links open the source.
{{Product}}
Start here. This is the root for {{Product}} — the source of truth for what this book is, chapter by chapter, true whether or not a word of it is drafted.
{{One line: what the book says, and who it is for.}}
Where things are
- Frames — what the book argues, who reads it, how it sounds, where it sits.
- Chapters — one file per chapter, grouped by part.
- assets — images, diagrams, and documents the blueprints link to.
Top-level documents
Your own one-of-a-kind docs: an Outline of the whole book, a Style Sheet (spellings, names, hyphenation), a Bibliography. Add them here as you write them.
The full index — every folder, its variants, and the Properties table — is in
.eidos/Framework.yaml.
How to use it
A chapter here describes what the chapter is: why it exists, what happens in it, and what the
reader leaves with. It is not a draft and not a task. Write the chapter’s blueprint before the prose,
and keep it true after — a chapter you cut stays here, marked Cut, so the reasoning survives.
A root. Its framework lives in .eidos/; see .eidos/Framework.yaml for the full index.