Why we built Quill — the honest version
For decades, everything got a modern editor. Code got IDEs, notes got beautiful apps, documents got real-time collaboration — whole companies built on making writing surfaces better. The terminal — the place developers actually live — kept its one-line input box. Then AI arrived in the terminal, and suddenly the most important text you write all day goes through the least capable editor you own.
Every AI tool asks you to pour your best thinking into that box. Six requirements, three constraints, an output format — crammed into a single wrapping line you can barely edit, then sent with an accidental Enter. We built Quill because the prompt is where the work happens — Quill is the modern editor the terminal never got.
Does structure actually help the model?
Yes — and here's the honest mechanics, not the marketing version. Models don't parse Markdown. They were trained on oceans of it — READMEs, docs, code review — and learned what the shapes mean. Ask your own model whether it would rather receive a structured spec or a run-on paragraph. We asked ours; they were not subtle about it. Structured input separates context from instructions from constraints, so each gets handled instead of blended.
| Element | Signal | The honest read |
|---|---|---|
| ``` code fences | Strong | The clearest signal in all of Markdown. Fenced content is treated as code — not paraphrased, not reformatted, not summarised. |
| ## headings | Strong | Cleanly separate context from requirements from constraints in a multi-part prompt, so none of them blur together. |
| 1. and - lists | Moderate | List items get addressed more completely than the same content in prose — the benefit grows with the list. |
| **bold**, *italic* | Weak | Recognised, but mostly cosmetic for comprehension. We tell you this because the rest of the table is true too. |
Rule of thumb: a one-paragraph question gains little from structure. Three or more distinct concerns, and structure is the difference between followed completely and half-followed.
The deepest win isn't in the model at all
Writing ## Requirements forces you to actually know your requirements. Writing ## Constraintsmakes you state them instead of hoping they're implied. The clarity the model responds to is clarity you created by structuring your own thinking— Quill's editor just makes that the path of least resistance.
What it costs — honestly
Markdown syntax is real tokens: a heavily structured prompt can use 10–15% more than the same words as prose — economically, fractions of a cent. Weigh that against what prompts do now: in agentic workflows, one prompt steers many minutes of autonomous work, tool calls, and file edits. A well-designed prompt is the cheapest leverage in the entire loop— and in the agent era, prompts aren't throwaway lines. They're specs. Quill treats them that way: documents you draft, refine, version, and reuse.
Saved prompts compound. Blobs evaporate.
A prompt you typed into a chat box is gone the moment it works. A prompt you designed in Quill is an asset: saved as a .mdfile, reusable as a template, findable in History, improvable every time you run it. That's what prompt engineering actually is — iterating on a document until it reliably produces the output you want, then never paying the drafting cost again. The review prompt that took twenty minutes to get right runs in two seconds forever after — across projects, across models, across your team. Effort invested once; tokens, retries, and half-followed instructions saved every single run after.
Take the time to design the prompt. It's worth it now.