AddThisFeature

Block Editor

Edit long-form content as a stack of blocks you can reorder, nest, and mix with embeds.

involved Editors & Builders

What it adds

A typed-block editing surface for the app's long-form content, backed by a versioned block tree.

What your agent is told to do

5
  1. 1

    Define the block types the content actually needs: paragraph, heading, list, image, quote, code, divider, embed. Give each a stable stored shape and ship those, rather than an open-ended block system in the hope that types get added later.

  2. 2

    Extend the app's existing Rich Text Editor for inline formatting inside a block rather than running two editing engines side by side. The block editor owns the structure; the existing editor owns the text.

  3. 3

    Reuse the app's existing Autosave, Version History, and Undo Actions. A second history stack that only covers this editor will disagree with the record's real history.

  4. 4

    Convert pasted content into known block types on the way in. Storing pasted markup verbatim means storing whatever the source page happened to contain, scripts included.

  5. 5

    Reuse Drag-and-Drop Reordering for moving blocks, and make sure every reorder is also reachable from the keyboard.

Edge cases it handles

8
  • Content written today must still open after the block types change. Store a version on the tree, migrate forward on read, and keep unrecognised blocks intact rather than dropping them.
  • Pasted markup from a document or another site carries styles, scripts, and tracked-change annotations. Map what you recognise onto real block types and discard the rest.
  • Splitting a paragraph with Enter and merging it back with Backspace must leave the caret exactly where the writer expects. A caret that jumps to the top of the document on every merge makes the editor unusable.
  • Dragging to reorder on a touch screen competes with scrolling. Require a deliberate long press or a dedicated handle so a scroll gesture never moves a block.
  • A crashed or reloaded tab must not cost an hour of writing. Keep a local copy of unsaved blocks and offer to restore it, clearly distinguished from the saved version.
  • Images inside blocks must reserve their dimensions so the document does not reflow under the writer's cursor while they load, and each needs alt text.
  • An embed block renders somebody else's page. Show the source link and a readable fallback for when the third party is blocked, deleted, or down.
  • Two people opening the same document must not silently overwrite each other. Detect that the stored version has moved and say so rather than saving on top of it.

Definition of done

9
  • Content is stored as a versioned tree of typed blocks that survives schema changes.
  • Blocks can be added, reordered, nested, and deleted with both pointer and keyboard.
  • Pasted content becomes known block types and no raw markup is stored.
  • The caret stays where the writer expects across block splits and merges.
  • Touch drag moves blocks only on a deliberate gesture and never blocks page scroll.
  • Unsaved work is recoverable after a crashed or reloaded tab.
  • Autosave, undo, and version history come from the app's existing implementations.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.