The same idea, two prompts
Every product page on this register ends with a build prompt — something meant to be copied directly into an AI coding agent, not read as prose. Early on, this register's own Coda entry had this one:
"Don't rebuild Coda's formula engine. If your real need is docs with an embedded checklist or simple table, build a rich-text editor with one embeddable table block (typed columns, add/edit rows inline) — no cross-document formulas, no automation buttons. That covers most personal use; the seamless doc-database fusion is genuinely the hard, differentiated part of the real product."
That's not a bad sentence. It's honest, it's correctly scoped, and everything in it is true. It's also not something you could hand to an agent and get a consistent result from — it names a shape without specifying it. Rewritten, the same idea became a structured spec an agent could actually execute against, and it's what the page shows today. The difference between those two versions is most of what this article is about.
What actually changed
Four specific things, none of them about writing more words for their own sake:
A numbered structure instead of one dense paragraph. The rewrite breaks 'a rich-text editor with one embeddable table block' into three separate, ordered pieces: the editor, the table component, and how the two connect. An agent working through a numbered list builds in a coherent order. An agent working through a single sentence has to infer that order itself.
Named tools instead of 'an existing solution.' The original says nothing about how to build the rich-text editor. The rewrite says Tiptap or Lexical, specifically ruling out a from-scratch contentEditable implementation. That's not pedantry — 'use an existing library' still leaves a real decision unmade, and an agent left to make it can pick something that doesn't fit the rest of the stack.
Concrete specifics instead of general nouns. 'A simple table' became a table with typed columns (text, number, checkbox, single-select, date), inline row editing, per-column sort and filter, and at least one saved view. Every one of those is a real decision that was previously left for the agent to make on its own — and an agent guessing at five small decisions rarely guesses the same way you would have.
The out-of-scope section is doing the most work
The original prompt's exclusion was a single clause: 'no cross-document formulas, no automation buttons.' The rewrite turns that into a real paragraph, explaining that cross-document formulas are 'a small programming language and runtime, not a feature,' and that real-time multi-user editing needs CRDT-level engineering a single-user build doesn't need to touch at all.
That distinction matters more than it looks like it should. An agent handed 'skip formulas' with no reasoning attached will sometimes take a run at a scoped-down version of the formula engine anyway, because the instruction reads like a stylistic preference rather than a hard boundary. An agent handed the actual reason — this is a different order of engineering problem, not a smaller version of the same one — treats it as a real constraint instead of a suggestion.
A checklist worth applying to your own prompt
Before handing a prompt to an agent, four questions worth actually checking against it:
Does it read as a numbered list, or one paragraph doing five things at once? Does every 'use an existing tool' reference name the actual tool? Does every feature have a concrete detail attached — an exact field, an exact behavior — instead of a general noun standing in for a decision nobody's made yet? And does anything explicitly out of scope come with a reason, not just an instruction?
If a prompt is a single sentence, it's very unlikely to clear more than one of those four. That's not a hard rule so much as a fast way to notice a prompt that's about to leave too much up to guesswork. Every product page on this register is built to this same standard, mostly as a side effect of applying this exact checklist across all 200+ of them.