Five layers. One system.

Specs are built from composable blocks - headings, code, tables, and live embeds - so structure comes free and nothing hides in a wall of text. Restructure a doc by moving blocks, not by rewriting it.

• Markdown-first input. Every shortcut you know - #, ```, > - maps to a block as you type.
• Live embeds. Issues, PRs, and files render inline and keep themselves up to date.
• Callouts & tables. Capture decisions and tradeoffs with structure, not formatting hacks.
• Keyboard navigation. Move, select, and edit blocks without touching the mouse.

A board is a document, so it lives in the same tree with the same URL, the same permissions and the same version history as the spec beside it. Which means an agent can draw on one: delegate "diagram the flow this spec describes" and it names the boxes, connects them, renders a picture of its own work, and moves what overlapped - while you drag the parts it got wrong in the same board it is still working on.

• One renderer, everywhere. The editor, the API, an embed and the image an agent looks at are all the same drawing code - so "these two overlap" means the same thing to all four.
• Every edit merges. Two people and an agent on one board: each write names the node it touches, so a drag and a batch of ops never take turns overwriting each other.
• Embed a frame in a spec. A document can carry a live thumbnail of one frame. It shows the board as it is now, not a copy that quietly went stale.
• Comments, sign-off, and history. A board takes conversations, a review workflow and a restore point for every state it has been in, because those hang off a document and a board is one.

A deck is the same board wearing an order: its slides are its top-level frames, and the number on a slide is where it sits rather than something anybody typed. So "draft the review deck" is a thing you ask an agent from the spec's own page - it reads the document, builds the slides beside it, and puts each section's text in the speaker notes. Then you present it from the browser, and everyone else in the deck follows the slide you are on.

• Speaker notes that are content. Notes ride the same document as the slide, so they merge while two people write them, restore with every version, and a phrase that only exists in the notes still finds the deck in search.
• Follow the presenter. A presenting session says which slide it is on and every viewer flips with it. Nothing is stored, so closing the tab ends the show and frees the room.
• Comment on the slide that is wrong. Pin a thread to a shape and it follows that shape through every drag, restyle and move to another slide - and an @mentioned agent answers in place.
• Sign-off, history, search. A deck is a document, so it takes a review workflow, a restore point for every state it has been in, and the workspace search - unchanged, because none of those know what kind of document they are on.

The same board does interface work: a frame that is a phone, a tablet or a desktop, children that fill their column or hug their content, and rows that wrap when they run out of room - so a mock re-flows when the copy grows instead of quietly overlapping. A frame you publish becomes a component the whole workspace can place, and every instance of it follows the original when you change it. Agents draft the layout with the same tools they draw diagrams with; you finish it in the same board they are still working in.

• Overrides that do not detach. Change the words or the picture inside one instance. Everything else still comes from the source - which is what keeps a component worth having.
• Named styles. A heading is a name, not a size repeated forty times. Rename it and every node using it follows; change it and they all restyle at once.
• Drop in a screenshot. Images are content-addressed, so the same file dropped on four boards is stored once, and the picture in the editor is the picture in the export.
• Share a link, export the file. A read-only link renders a board to somebody with no account, and revoking it 404s. A board exports as SVG or PNG, a deck as a PDF. Both leave a row in the audit log; an agent's share waits for a human first.

Everyone in the spec types into the same sentence at the same time, with each other's cursors, selections, and names in the text. There is no save, because a keystroke is not one - it is an edit on the wire, merged rather than refused, so nobody is ever told their work raced somebody else's.

• A CRDT, not a lock. Two people in one sentence converge; no file is locked and no keystroke is lost.
• Cursors and selections. Names and colours follow the text, and a closed tab takes its caret with it at once.
• The title merges too. Renaming a page while somebody types in it is an edit, not a fight over a field.
• Offline keeps typing. A dropped connection edits locally and syncs the moment it is back.

Every edit is recorded as it is made, so history is the document rather than a copy of it. Read what any version changed, and take the page back to one - which is itself an edit everyone watching sees arrive, not a rewrite of what happened.

• Restore is never a rewrite. Nothing is deleted to go back, so the version you restored away from is still there.
• Before an agent rewrites it. A whole-document write pins the state it replaces as a restore point, kept forever.
• Name a version. Call a state something - “before the rewrite” - and it outlives the edits around it.
• Restore points forever. A day's worth of a page is kept for as long as the page exists, on every plan.

Select any passage and start a conversation about it. The thread anchors to the text itself, so it follows the sentence as the spec is rewritten around it - and when the sentence is deleted, the thread stays and says so instead of disappearing with the argument.

• Anchored threads. Each conversation points at the passage it is about, in the margin beside it.
• Outdated, not gone. Delete the text and the thread keeps the quote it was opened on, marked outdated.
• @mentions reach agents too. Name an agent in a thread and it answers in that thread, with the passage in front of it.
• Searchable months later. Comment bodies land in the same index the docs do, so a phrase from the margin still finds the page.

A spec moves from draft to in review to approved, and the move to approved has to be earned: it needs a sign-off from somebody other than the author, and it is refused while anyone's request for changes still stands.

• An author can't approve their own spec. The same rule that stops an agent signing off on the draft it wrote.
• Every verdict is kept. Approvals are append-only, so who agreed and when survives them changing their mind.
• In the audit log. Status moves and verdicts are recorded with who, what and when - filterable to the Docs surface.
• Agents can be asked to review. An agent reviews through the same endpoint a person does, and is held to the same author rule.

Approve a spec and turn its sections into tracked issues in one step - one issue per heading, titled from the heading and bodied from the text under it. Nothing is copied: the page reads each issue's status live, and every issue carries the section that asked for it. Six months later, an issue still answers 'why did we build this?'

• Run it again safely. The heading is the identity, so a second run files only the sections you added since.
• Live status in the doc. Titles, states and assignees are resolved through the link on every read, never copied into it.
• Back-references. Each generated issue names the spec and the heading it came from, and follows a rename of either.
• Shipped is a reading, not a claim. The page moves to shipped when the last of its issues closes - and back again if one reopens.

Start from a structure the team already trusts - problem, proposal, rollout - instead of a blank page. Templates keep specs comparable across authors, teams, and quarters.

• Team-owned templates. Any doc can become a template with one action.
• A standard shape. The RFC template opens with problem, proposal, and rollout laid out.
• Auto-numbering. RFCs get sequential ids the whole team can cite.
• Nested docs. An RFC and its appendices stay together in one tree.

Every doc, issue, pull request, message, and file path lands in one index as it is written - so a half-remembered phrase from months ago still finds the spec it came from.

• As-you-type results. Ranked results update with every keystroke.
• Indexed on write. The request that saves a doc is the one that indexes it - no crawl, no lag.
• Weighted ranking. A title match outranks a body match, so the obvious answer comes first.
• Highlighted snippets. Each hit shows the sentence that matched, not just a title.

Draft an RFC from a structure the team already trusts, and write it where the work is - not in a thread scattered across three chat apps.

Once it is signed off, turn its sections into tracked issues in one step. The doc, the decision and the work stay linked for good - so a spec read six months later still shows what actually happened to the work it describes.